From owner-ipng@sunroof.eng.sun.com Wed Jan 2 04:56:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02CupZR027316 for ; Wed, 2 Jan 2002 04:56:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02CupvL027315 for ipng-dist; Wed, 2 Jan 2002 04:56:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02CumZR027308 for ; Wed, 2 Jan 2002 04:56:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17643 for ; Wed, 2 Jan 2002 04:56:50 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09522 for ; Wed, 2 Jan 2002 05:56:31 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA08282; Wed, 2 Jan 2002 13:56:48 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40250 from ; Wed, 2 Jan 2002 13:56:37 +0100 Message-Id: <3C32FD37.B79CDE36@hursley.ibm.com> Date: Wed, 02 Jan 2002 13:29:43 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Alex Conta Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, I don't agree. This restores the uncertainty that is preventing any current usage. Brian Alex Conta wrote: > > Making the field "immutable" by "default", but "mutable" when a router > is so instructed by a flow setup and flow processing mechanism is a > compromise that would satisfy all current and future possible cases. > > Therefore I think last sentence of the first paragraph > > All routers MUST pass the field on unchanged when forwarding a > packet. > > should be something like: > > All routers MUST leave the field unchanged, by default, when > forwarding a packet. > A specific flow setup/processing mechanism MAY give a "mutable" > character to the field, > by requesting routers, supporting the mechanism, to change the field > in certain ways. > Routers supporting such a mechanism MUST follow the steps indicated > by the flow > setup and flow processing mechanism. > > Alex > > Brian E Carpenter wrote: > > > > Taking Scott's suggestion, here's another try: > > > > I'd like to propose the following as the > > complete and total replacement of Section 6 of RFC 2460. > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to uniquely label sets of packets. Nodes that do not support > > the Flow Label field MUST set the field to zero when originating a > > packet, and MUST ignore the field when receiving a packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > > > This specification does not further define the meaning of the > > Flow Label. > > > > [and delete Appendix A, which is unhelpful.] > > > > Brian > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 04:57:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02CvHZR027326 for ; Wed, 2 Jan 2002 04:57:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02CvHU7027325 for ipng-dist; Wed, 2 Jan 2002 04:57:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02CvDZR027318 for ; Wed, 2 Jan 2002 04:57:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17683 for ; Wed, 2 Jan 2002 04:57:15 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09767 for ; Wed, 2 Jan 2002 05:56:57 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA09766; Wed, 2 Jan 2002 13:57:13 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21098 from ; Wed, 2 Jan 2002 13:57:02 +0100 Message-Id: <3C32FE88.BAF513E2@hursley.ibm.com> Date: Wed, 02 Jan 2002 13:35:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112271745.fBRHj5C15277@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you analyse the text closely, "uniquely" is a noise word anyway- a label is unique within the scope of the things it labels in any case. We can certainly take it out. Brian Scott Bradner wrote: > > agree > > --- > >From owner-ipng@sunroof.eng.sun.com Thu Dec 27 11:11:09 2001 > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > X-Sender: mrw@mail.windriver.com > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 > Date: Thu, 27 Dec 2001 11:08:43 -0500 > To: Brian E Carpenter > From: Margaret Wasserman > Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] > Cc: ipng@sunroof.eng.sun.com > In-Reply-To: <3C2B41B4.2EF8D01B@hursley.ibm.com> > References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> > <878zbp8vh7.fsf@snark.piermont.com> > <3C2B2103.1B167487@hursley.ibm.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Sender: owner-ipng@sunroof.eng.sun.com > Precedence: bulk > > Actually, I would take out the word "uniquely". I am > not sure that we want to confine possible QoS solutions > to "uniquely" labeling anything. > > Margaret > > At 10:43 AM 12/27/01 , Brian E Carpenter wrote: > >Taking Scott's suggestion, here's another try: > > > >I'd like to propose the following as the > >complete and total replacement of Section 6 of RFC 2460. > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to uniquely label sets of packets. Nodes that do not support > > the Flow Label field MUST set the field to zero when originating a > > packet, and MUST ignore the field when receiving a packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > > > This specification does not further define the meaning of the > > Flow Label. > > > > [and delete Appendix A, which is unhelpful.] > > > > Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 04:57:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02CvgZR027350 for ; Wed, 2 Jan 2002 04:57:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02Cvg3A027349 for ipng-dist; Wed, 2 Jan 2002 04:57:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02CvcZR027335 for ; Wed, 2 Jan 2002 04:57:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20835 for ; Wed, 2 Jan 2002 04:57:40 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25616 for ; Wed, 2 Jan 2002 04:57:39 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA12686; Wed, 2 Jan 2002 13:57:37 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46110 from ; Wed, 2 Jan 2002 13:57:29 +0100 Message-Id: <3C330228.154670CB@hursley.ibm.com> Date: Wed, 02 Jan 2002 13:50:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> <87d7103btc.fsf@snark.piermont.com> <15404.54703.385314.958490@thomasm-u1.cisco.com> <87lmfndp86.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [this also responds to Scott's comments, I think] "Perry E. Metzger" wrote: > > Michael Thomas writes: > > Perry E. Metzger writes: > > > > Sorry, the SPI is no good for diffserv classification > > > > because it has no semantics. > > > > > > Neither does the flow label. Both are just a number that can be used > > > to distinguish a bunch of traffic flowing between two hosts from other > > > traffic flowing between two hosts. Neither has any semantics beyond > > > that. > > > > Bzzt. You're overloading semantics. SPI's enumerate > > the set of packets for which a given security policy > > applies. That may have exactly zero to do with the > > QoS policies you'd like to apply. > > In the scheme proposed, flow labels just enumerate a set of packets > that a host has chosen to designate as a "flow" because, say, they're > all using the same TCP socket -- which may also have exactly zero to > do with the QoS policies you'd like to apply. How is it any different > than the SPI situation? In the intserv case, it is no different. In the diffserv case, the presumption is that we would use IANA-assigned, globally meaningful values, that are specific to a desired QOS treatment rather than to any individual traffic flow. The implementation details (including the DSCP value and router configurations) may differ from ISP to ISP, but the flow label bits convey end to end semantics. This is more powerful than port numbers whose semantics are poor at best for QOS purposes, and it works when the port numbers are invisible. > > > > > I didn't say it makes no difference. I said that the difference is more > > > > likely to be in cost and waste heat than in speed. > > > > > > Given that the manufacturers who are doing this are already building > > > the transistors in to walk the header chain... > > > > By all means, let's just ignore silicon considerations. > > Moore's Law trumps all, obviously. > > If they have to build tuple extraction into the hardware anyway to > deal with the implementations that don't do flow labels (i.e any > deployed in the next few years), how can we claim that we're going to > get around people having to build hardware? Given that several vendors > have already designed the hardware, how are we going to be helping? Hardware gets updated. The point of giving the flow label a clear definition is to allow hardware designers to build classifiers that include the flow label as one of the fields used for line-speed classification. What the next level up in the hardware/firmware/software does with the classified packets is a separate question. Brian > > -- > Perry E. Metzger perry@wasabisystems.com > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 05:41:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02DfEZR027428 for ; Wed, 2 Jan 2002 05:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02DfELF027427 for ipng-dist; Wed, 2 Jan 2002 05:41:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02DfBZR027420 for ; Wed, 2 Jan 2002 05:41:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24404 for ; Wed, 2 Jan 2002 05:41:14 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24669 for ; Wed, 2 Jan 2002 06:41:13 -0700 (MST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g02DeTR2018788; Wed, 2 Jan 2002 07:40:30 -0600 (CST) Message-ID: <021301c193ab$a5542390$0100a8c0@RepliGate> From: "Jim Fleming" To: "Brian E Carpenter" Cc: References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> <3C32FD37.B79CDE36@hursley.ibm.com> Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] Date: Wed, 2 Jan 2002 08:36:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk These are four interesting words: restores uncertainty preventing usage Restores implies that something used to be some way and it is now restored to be that way. That is not the case with technology very few people use. As for uncertainty, there does not seem to be any uncertainty when one looks at working code. Fortunately, people writing code and compiling their own operating systems are not prevented from using any data structure the way they want. When a large number of people start doing things in a similar manner a standard emerges. It seems unlikely that people could decide in advance what the standards will be and impose those on the population. Regarding the 20-bit Flow Label, in the bloated 40 byte IPv6 Header, one approach may be to divide the Flow Label into a 4-bit Length Field, an 8-bit StarGate and an 8-bit Identification Field similar to IPv4. The 4-bit Length Field can then be used to define the number of bytes of data carried in the useless, right-most, 64-bits of the IPv6 128-bit Address Fields. Those fields used to have MAC addresses but now some claim they have random numbers. The Protocol Field could of course further define the one to sixteen bytes of data carried directly in the IPv6 header. While 16 bytes be small for protocols involving huge files, streaming protocols and other object-oriented applications may find that 16 bytes is a nice size, and they could use the IPv6 header more efficiently. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "Brian E Carpenter" To: "Alex Conta" Cc: Sent: Wednesday, January 02, 2002 4:29 AM Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] > Alex, > > I don't agree. This restores the uncertainty that is preventing any > current usage. > > Brian > > Alex Conta wrote: > > > > Making the field "immutable" by "default", but "mutable" when a router > > is so instructed by a flow setup and flow processing mechanism is a > > compromise that would satisfy all current and future possible cases. > > > > Therefore I think last sentence of the first paragraph > > > > All routers MUST pass the field on unchanged when forwarding a > > packet. > > > > should be something like: > > > > All routers MUST leave the field unchanged, by default, when > > forwarding a packet. > > A specific flow setup/processing mechanism MAY give a "mutable" > > character to the field, > > by requesting routers, supporting the mechanism, to change the field > > in certain ways. > > Routers supporting such a mechanism MUST follow the steps indicated > > by the flow > > setup and flow processing mechanism. > > > > Alex > > > > Brian E Carpenter wrote: > > > > > > Taking Scott's suggestion, here's another try: > > > > > > I'd like to propose the following as the > > > complete and total replacement of Section 6 of RFC 2460. > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > source to uniquely label sets of packets. Nodes that do not support > > > the Flow Label field MUST set the field to zero when originating a > > > packet, and MUST ignore the field when receiving a packet. All routers > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > This specification does not further define the meaning of the > > > Flow Label. > > > > > > [and delete Appendix A, which is unhelpful.] > > > > > > Brian > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > Board Chairman, Internet Society http://www.isoc.org > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 05:42:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02DguZR027445 for ; Wed, 2 Jan 2002 05:42:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02Dguf4027444 for ipng-dist; Wed, 2 Jan 2002 05:42:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02DgqZR027437 for ; Wed, 2 Jan 2002 05:42:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24506 for ; Wed, 2 Jan 2002 05:42:54 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12008 for ; Wed, 2 Jan 2002 06:42:36 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g02Dg9Q08853; Wed, 2 Jan 2002 08:42:09 -0500 (EST) Date: Wed, 2 Jan 2002 08:42:09 -0500 (EST) From: Scott Bradner Message-Id: <200201021342.g02Dg9Q08853@newdev.harvard.edu> To: brian@hursley.ibm.com, perry@wasabisystems.com Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com, mat@cisco.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian sez: > In the intserv case, it is no different. In the diffserv case, the presumption > is that we would use IANA-assigned, globally meaningful values, that are > specific to a desired QOS treatment rather than to any individual traffic flow. > The implementation details (including the DSCP value and router configurations) > may differ from ISP to ISP, but the flow label bits convey end to end > semantics. This is more powerful than port numbers whose semantics are poor at > best for QOS purposes, and it works when the port numbers are invisible. this still begs the question why do folk think that ISPs half way around the world would find it useful to know what the sending computer wanted for QoS? at least in the case of difserv if an ISP gets a DSCP there is some implied authorization by the previous network (ISP or enterprise) - how does authorization happen in the case of imutable globally meaningful values? I see no reason to believe that such a field will be any use whatsoever in providing QoS in the Internet - and it is redundant in an enterprise because the enterprise can decide to not change the DSCP field unless there is some hint of a way for this change to serve any useful purpose we should just leave things as they are Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 06:39:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02EdiZR027502 for ; Wed, 2 Jan 2002 06:39:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02EdiIp027501 for ipng-dist; Wed, 2 Jan 2002 06:39:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02EdbZR027494 for ; Wed, 2 Jan 2002 06:39:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19635 for ; Wed, 2 Jan 2002 06:39:40 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23953 for ; Wed, 2 Jan 2002 07:40:38 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA08254; Wed, 2 Jan 2002 15:39:27 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30008 from ; Wed, 2 Jan 2002 15:39:22 +0100 Message-Id: <3C331B96.94FF2BF3@hursley.ibm.com> Date: Wed, 02 Jan 2002 15:39:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: perry@wasabisystems.com, ipng@sunroof.eng.sun.com, mat@cisco.com Subject: Re: Flow Label References: <200201021342.g02Dg9Q08853@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner wrote: > > Brian sez: > > In the intserv case, it is no different. In the diffserv case, the presumption > > is that we would use IANA-assigned, globally meaningful values, that are > > specific to a desired QOS treatment rather than to any individual traffic flow. > > The implementation details (including the DSCP value and router configurations) > > may differ from ISP to ISP, but the flow label bits convey end to end > > semantics. This is more powerful than port numbers whose semantics are poor at > > best for QOS purposes, and it works when the port numbers are invisible. > > this still begs the question > why do folk think that ISPs half way around the world would find it useful > to know what the sending computer wanted for QoS? s/computer/customer/ If A is a customer of ISP X in some distant country, there might be (and I am only saying might be) an SLA in place that says "whenever you get a packet from or to A, with 1234 in its flow label, give it such a level of service." I'm not saying that this is especially likely or plausible, but it certainly isn't impossible. > > at least in the case of difserv if an ISP gets a DSCP there is some > implied authorization by the previous network (ISP or enterprise) - how > does authorization happen in the case of imutable globally meaningful > values? In both cases you need an SLA in place - with the upstream ISP, or with the ultimate traffic source or destination. I agree that it certainly doesn't happen because the ISP is a nice guy. > > I see no reason to believe that such a field will be any use whatsoever > in providing QoS in the Internet - and it is redundant in an enterprise > because the enterprise can decide to not change the DSCP field I bet I could construct an enterprise scenario where you could use it, but you're basically correct, the only real use is when you jump over intermediate ISPs and need a field that hasn't been changed en route. > > unless there is some hint of a way for this change to serve any useful > purpose we should just leave things as they are No, I don't agree that we can leave the vagueness in 2460. IMNSHO we should either accept the rewording we've hammered out (which carefully doesn't say anything about QOS) or change it to MBZ. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 07:03:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02F3DZR027548 for ; Wed, 2 Jan 2002 07:03:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02F3DVq027547 for ipng-dist; Wed, 2 Jan 2002 07:03:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02F38ZR027540 for ; Wed, 2 Jan 2002 07:03:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03448 for ; Wed, 2 Jan 2002 07:03:09 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13542 for ; Wed, 2 Jan 2002 08:03:09 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g02F2mi08013; Wed, 2 Jan 2002 10:02:52 -0500 (EST) Message-Id: <200201021502.g02F2mi08013@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Scott Bradner cc: brian@hursley.ibm.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com, mat@cisco.com Subject: Re: Flow Label In-reply-to: Your message of "Wed, 02 Jan 2002 08:42:09 EST." <200201021342.g02Dg9Q08853@newdev.harvard.edu> Date: Wed, 02 Jan 2002 10:02:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > why do folk think that ISPs half way around the world would find it useful > to know what the sending computer wanted for QoS? because the sending computer (application) knows the nature of the traffic? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 07:11:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02FBXZR027582 for ; Wed, 2 Jan 2002 07:11:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02FBWSq027581 for ipng-dist; Wed, 2 Jan 2002 07:11:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02FBTZR027574 for ; Wed, 2 Jan 2002 07:11:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03917 for ; Wed, 2 Jan 2002 07:11:31 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15978 for ; Wed, 2 Jan 2002 08:11:30 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Ln38-000F3S-00; Wed, 02 Jan 2002 07:11:26 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021342.g02Dg9Q08853@newdev.harvard.edu> <200201021502.g02F2mi08013@astro.cs.utk.edu> Message-Id: Date: Wed, 02 Jan 2002 07:11:26 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> why do folk think that ISPs half way around the world would find it >> useful to know what the sending computer wanted for QoS? > because the sending computer (application) knows the nature of the > traffic? no need to signal. we already know that they think their traffic is more important than everybody else's. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 08:16:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02GGRZR027687 for ; Wed, 2 Jan 2002 08:16:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02GGQqK027686 for ipng-dist; Wed, 2 Jan 2002 08:16:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02GGMZR027679 for ; Wed, 2 Jan 2002 08:16:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12774 for ; Wed, 2 Jan 2002 08:16:24 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01299 for ; Wed, 2 Jan 2002 09:16:24 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g02GG0o09266; Wed, 2 Jan 2002 11:16:00 -0500 (EST) Date: Wed, 2 Jan 2002 11:16:00 -0500 (EST) From: Scott Bradner Message-Id: <200201021616.g02GG0o09266@newdev.harvard.edu> To: brian@hursley.ibm.com, sob@harvard.edu Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com, mat@cisco.com, perry@wasabisystems.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No, I don't agree that we can leave the vagueness in 2460. IMNSHO we > should either accept the rewording we've hammered out (which carefully > doesn't say anything about QOS) or change it to MBZ. I'm fine with the new wording - I'm just not fine with the assumption that we have any idea what to do with the static info > If A is a customer of ISP X in some distant country, there might be (and > I am only saying might be) an SLA in place that says "whenever you get > a packet from or to A, with 1234 in its flow label, give it such a level > of service." > > I'm not saying that this is especially likely or plausible, but it > certainly isn't impossible. scales well :-) Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 08:20:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02GKtZR027722 for ; Wed, 2 Jan 2002 08:20:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02GKtuq027721 for ipng-dist; Wed, 2 Jan 2002 08:20:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02GKpZR027714 for ; Wed, 2 Jan 2002 08:20:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01600 for ; Wed, 2 Jan 2002 08:20:53 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07560 for ; Wed, 2 Jan 2002 09:20:35 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g02GKju09321; Wed, 2 Jan 2002 11:20:45 -0500 (EST) Date: Wed, 2 Jan 2002 11:20:45 -0500 (EST) From: Scott Bradner Message-Id: <200201021620.g02GKju09321@newdev.harvard.edu> To: moore@cs.utk.edu, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, mat@cisco.com, perry@wasabisystems.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > why do folk think that ISPs half way around the world would find it useful > > to know what the sending computer wanted for QoS? > because the sending computer (application) knows the nature of the traffic? without a way for the remote ISP to get paid for treating the traffic in some way other then best-effort I do not see that this helps Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 09:28:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02HSaZR027843 for ; Wed, 2 Jan 2002 09:28:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02HSaAg027842 for ipng-dist; Wed, 2 Jan 2002 09:28:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02HSXZR027835 for ; Wed, 2 Jan 2002 09:28:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25902 for ; Wed, 2 Jan 2002 09:28:36 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06514 for ; Wed, 2 Jan 2002 10:29:35 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g02HSQq21459; Wed, 2 Jan 2002 09:28:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP22086; Wed, 2 Jan 2002 09:27:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA10885; Wed, 2 Jan 2002 09:28:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.17209.452224.850919@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 09:28:25 -0800 (PST) To: Scott Bradner Cc: moore@cs.utk.edu, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, mat@cisco.com, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200201021620.g02GKju09321@newdev.harvard.edu> References: <200201021620.g02GKju09321@newdev.harvard.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner writes: > > > why do folk think that ISPs half way around the world would find it useful > > > to know what the sending computer wanted for QoS? > > > because the sending computer (application) knows the nature of the traffic? > > without a way for the remote ISP to get paid for treating the traffic in > some way other then best-effort I do not see that this helps Are you claiming that RFC 3182 (nee 2752) is inadequate for interdomain? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 09:35:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02HZLZR027895 for ; Wed, 2 Jan 2002 09:35:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02HZLrx027894 for ipng-dist; Wed, 2 Jan 2002 09:35:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02HZHZR027887 for ; Wed, 2 Jan 2002 09:35:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03698 for ; Wed, 2 Jan 2002 09:35:20 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01667 for ; Wed, 2 Jan 2002 10:35:02 -0700 (MST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g02HYDR2028452; Wed, 2 Jan 2002 11:34:14 -0600 (CST) Message-ID: <02b101c193cc$4d4a4910$0100a8c0@RepliGate> From: "Jim Fleming" To: "Scott Bradner" , Cc: , , References: <200201021620.g02GKju09321@newdev.harvard.edu> Subject: Re: Flow Label Date: Wed, 2 Jan 2002 12:30:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Scott Bradner" To: ; Cc: ; ; ; Sent: Wednesday, January 02, 2002 8:20 AM Subject: Re: Flow Label > > > why do folk think that ISPs half way around the world would find it useful > > > to know what the sending computer wanted for QoS? > > > because the sending computer (application) knows the nature of the traffic? > > without a way for the remote ISP to get paid for treating the traffic in > some way other then best-effort I do not see that this helps > > Scott > -------------------------------------------------------------------- When presented with the concept of multiple windows on a graphics display screen, I once heard someone say that "they could not imagine why someone would want more than one window on a computer screen....", the person doing the demo quickly responded...."cross ventilation?" Sometimes....it helps to look at a bigger picture to see.... Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 10:02:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02I2ZZR028062 for ; Wed, 2 Jan 2002 10:02:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02I2Z0c028061 for ipng-dist; Wed, 2 Jan 2002 10:02:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02I2UZR028054 for ; Wed, 2 Jan 2002 10:02:30 -0800 (PST) Received: from lillen (hobo185.EBay.Sun.COM [129.150.99.82]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g02I2R313370; Wed, 2 Jan 2002 19:02:28 +0100 (MET) Date: Sat, 29 Dec 2001 00:56:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: '::' address as destination To: Lilian Fernandes Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hello, > > RFC 2373 states that: > "The unspecified address must not be used as the destination address > of IPv6 packets or in IPv6 Routing Headers." > > However it seems that certain stacks are using this address in a different > way. Yes, but I don't think there is an inherent conflict. RFC 2373 specifies the behavior on the wire i.e. what is carried in IPv6 packets. Implementations might do various things at the API interface, but the an implementation should ensure and :: doesn't appear as the destination in the IPv6 packets it sends. > When '::' is the destination address: > - some use the first available interface's address > - some use the loopback address > > Is there a chance that one of these will become the acceptable norm? It > would be interesting to know if the majority of implementations actually > return an error for this case. I know that for Solaris we interpret :: at the API as the loopback address. This was done to be consistent with the IPv4 Solaris code. Unfortunately the introduction of the mechanism in the IPv4 Solaris code was before my time. I don't think it existed in BSD 4.3tahoe but I haven't checked. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 10:14:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02IEvZR028096 for ; Wed, 2 Jan 2002 10:14:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02IEv9O028095 for ipng-dist; Wed, 2 Jan 2002 10:14:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02IErZR028088 for ; Wed, 2 Jan 2002 10:14:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06942 for ; Wed, 2 Jan 2002 10:14:56 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07689 for ; Wed, 2 Jan 2002 11:14:55 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g02IEad09837; Wed, 2 Jan 2002 13:14:36 -0500 (EST) Date: Wed, 2 Jan 2002 13:14:36 -0500 (EST) From: Scott Bradner Message-Id: <200201021814.g02IEad09837@newdev.harvard.edu> To: mat@cisco.com, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, moore@cs.utk.edu, perry@wasabisystems.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are you claiming that RFC 3182 (nee 2752) is inadequate for interdomain? for telling someone who you are its fine but that does not even start to address teh operational issues of how an ISP would make use of the information Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 10:26:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02IQ5ZR028131 for ; Wed, 2 Jan 2002 10:26:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02IQ55I028130 for ipng-dist; Wed, 2 Jan 2002 10:26:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02IQ1ZR028123 for ; Wed, 2 Jan 2002 10:26:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09960 for ; Wed, 2 Jan 2002 10:26:04 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07580 for ; Wed, 2 Jan 2002 11:26:04 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g02IPPw26554; Wed, 2 Jan 2002 10:25:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP23485; Wed, 2 Jan 2002 10:25:12 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10889; Wed, 2 Jan 2002 10:25:45 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.20649.14164.404636@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 10:25:45 -0800 (PST) To: Scott Bradner Cc: mat@cisco.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, moore@cs.utk.edu, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200201021814.g02IEad09837@newdev.harvard.edu> References: <200201021814.g02IEad09837@newdev.harvard.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner writes: > Are you claiming that RFC 3182 (nee 2752) is > inadequate for interdomain? > > for telling someone who you are its fine but that does not even > start to address teh operational issues of how an ISP would make use > of the information There is already an existence proof: cellular. Nobody's claiming that this is easy though. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 11:01:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02J1LZR028169 for ; Wed, 2 Jan 2002 11:01:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02J1L0b028168 for ipng-dist; Wed, 2 Jan 2002 11:01:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02J1IZR028161 for ; Wed, 2 Jan 2002 11:01:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17022 for ; Wed, 2 Jan 2002 11:01:19 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22391 for ; Wed, 2 Jan 2002 11:01:19 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g02J1Cv22923; Wed, 2 Jan 2002 11:01:13 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP24415; Wed, 2 Jan 2002 11:00:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA10901; Wed, 2 Jan 2002 11:01:11 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.22775.213852.888981@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 11:01:11 -0800 (PST) To: Scott Bradner Cc: brian@hursley.ibm.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com, mat@cisco.com Subject: Re: Flow Label In-Reply-To: <200201021342.g02Dg9Q08853@newdev.harvard.edu> References: <200201021342.g02Dg9Q08853@newdev.harvard.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner writes: > Brian sez: > > In the intserv case, it is no different. In the diffserv case, the presumption > > is that we would use IANA-assigned, globally meaningful values, that are > > specific to a desired QOS treatment rather than to any individual traffic flow. > > The implementation details (including the DSCP value and router configurations) > > may differ from ISP to ISP, but the flow label bits convey end to end > > semantics. This is more powerful than port numbers whose semantics are poor at > > best for QOS purposes, and it works when the port numbers are invisible. > > > this still begs the question > why do folk think that ISPs half way around the world would find it useful > to know what the sending computer wanted for QoS? > > at least in the case of difserv if an ISP gets a DSCP there is some > implied authorization by the previous network (ISP or enterprise) - how > does authorization happen in the case of imutable globally meaningful > values? > > I see no reason to believe that such a field will be any use whatsoever > in providing QoS in the Internet - and it is redundant in an enterprise > because the enterprise can decide to not change the DSCP field > > unless there is some hint of a way for this change to serve any useful > purpose we should just leave things as they are Since you can make the identical argument about 5-tuple based classification, all you're saying here is that you don't believe in Intserv/RSVP. Fine. There's a lot of people who disagree. With the current wording, a new flow spec for RSVP can be created ala RFC 2207 and we can all agree to disagree. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 11:22:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02JMYZR028252 for ; Wed, 2 Jan 2002 11:22:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02JMYUc028251 for ipng-dist; Wed, 2 Jan 2002 11:22:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02JMUZR028244 for ; Wed, 2 Jan 2002 11:22:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25357 for ; Wed, 2 Jan 2002 11:22:32 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23759 for ; Wed, 2 Jan 2002 12:22:31 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g02JMSa10173; Wed, 2 Jan 2002 14:22:28 -0500 (EST) Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) From: Scott Bradner Message-Id: <200201021922.g02JMSa10173@newdev.harvard.edu> To: mat@cisco.com, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, perry@wasabisystems.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk all you're saying here is that you don't believe in Intserv/RSVP. I did not say that at all I do not believe that there is currently any way to deal with the *business* and *operational* issues of asking some remote ISP to provide QoS service for you in any sort of scalable way please do not read into what I say any more than I actually say Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 12:21:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KLHZR028505 for ; Wed, 2 Jan 2002 12:21:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02KLHx1028504 for ipng-dist; Wed, 2 Jan 2002 12:21:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KLEZR028497 for ; Wed, 2 Jan 2002 12:21:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23563 for ; Wed, 2 Jan 2002 12:21:16 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05029 for ; Wed, 2 Jan 2002 13:20:57 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g02KKew22161; Wed, 2 Jan 2002 12:20:45 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP26669; Wed, 2 Jan 2002 12:20:27 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10910; Wed, 2 Jan 2002 12:20:59 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.27563.734410.55839@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 12:20:59 -0800 (PST) To: Scott Bradner Cc: mat@cisco.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200201021922.g02JMSa10173@newdev.harvard.edu> References: <200201021922.g02JMSa10173@newdev.harvard.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner writes: > all you're saying > here is that you don't believe in Intserv/RSVP. > > I did not say that at all > > I do not believe that there is currently any way to deal with the > *business* and *operational* issues of asking some remote ISP > to provide QoS service for you in any sort of scalable way Fine, but that's completely orthogonal to whether the flow label is a good idea or not. Only by placing a value judgement on the supposed intractability of that problem does it effect the outcome here. As in, if you don't think it's solvable, it would obviously be throwing good bits after bad. If you're in the "don't know" camp -- as I suspect many people are -- I think we can easily reserve a few bits and state that the flow label only applies when the reserved bits are zero and that all other combinations must be ignored. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 12:26:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KQ7ZR028523 for ; Wed, 2 Jan 2002 12:26:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02KQ6o9028522 for ipng-dist; Wed, 2 Jan 2002 12:26:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KQ2ZR028515 for ; Wed, 2 Jan 2002 12:26:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24345 for ; Wed, 2 Jan 2002 12:26:05 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08140 for ; Wed, 2 Jan 2002 13:25:46 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g02KQ1v10554; Wed, 2 Jan 2002 15:26:01 -0500 (EST) Date: Wed, 2 Jan 2002 15:26:01 -0500 (EST) From: Scott Bradner Message-Id: <200201022026.g02KQ1v10554@newdev.harvard.edu> To: mat@cisco.com, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, perry@wasabisystems.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we can easily reserve a few bits and state that the flow label only applies when the reserved bits ignored. as I said, I'm fine with the suggested wording but I don;t think that the base doc should say anything else having an experimental rfc that talks about ways to use the bits seems a reasonable thing also Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 12:37:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02Kb8ZR028548 for ; Wed, 2 Jan 2002 12:37:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02Kb8Gn028547 for ipng-dist; Wed, 2 Jan 2002 12:37:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02Kb5ZR028540 for ; Wed, 2 Jan 2002 12:37:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10101 for ; Wed, 2 Jan 2002 12:37:08 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00131 for ; Wed, 2 Jan 2002 13:38:08 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Ls8B-000NkU-00; Wed, 02 Jan 2002 12:36:59 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> Message-Id: Date: Wed, 02 Jan 2002 12:36:59 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I do not believe that there is currently any way to deal with the >> *business* and *operational* issues of asking some remote ISP >> to provide QoS service for you in any sort of scalable way > Fine, but that's completely orthogonal to whether the flow label is > a good idea or not. we don't care that no one can operationally use it. if it might sell one more router, let's kludge up the net a bit more. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 12:43:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KhhZR028570 for ; Wed, 2 Jan 2002 12:43:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02KhhfC028569 for ipng-dist; Wed, 2 Jan 2002 12:43:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KheZR028562 for ; Wed, 2 Jan 2002 12:43:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11791 for ; Wed, 2 Jan 2002 12:43:42 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15441 for ; Wed, 2 Jan 2002 13:43:42 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g02KhJw02866; Wed, 2 Jan 2002 12:43:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP27150; Wed, 2 Jan 2002 12:43:06 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10917; Wed, 2 Jan 2002 12:43:39 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.28923.226644.825039@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 12:43:39 -0800 (PST) To: Randy Bush Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush writes: > >> I do not believe that there is currently any way to deal with the > >> *business* and *operational* issues of asking some remote ISP > >> to provide QoS service for you in any sort of scalable way > > Fine, but that's completely orthogonal to whether the flow label is > > a good idea or not. > > we don't care that no one can operationally use it. if it might sell > one more router, let's kludge up the net a bit more. Oh, please. There is a very straighforward tweak to RSVP to support this, and this is an *anti*-kludge since the original kludge was overloading the use of L4 information for QoS. I'm not aware of anybody at my employer salivating at the revenue potentials for a newly defined flow label. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 12:49:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KnCZR028594 for ; Wed, 2 Jan 2002 12:49:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02KnBiA028593 for ipng-dist; Wed, 2 Jan 2002 12:49:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02Kn8ZR028586 for ; Wed, 2 Jan 2002 12:49:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12581 for ; Wed, 2 Jan 2002 12:49:11 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21473 for ; Wed, 2 Jan 2002 13:49:10 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16LsJs-000O4W-00; Wed, 02 Jan 2002 12:49:04 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> <15411.28923.226644.825039@thomasm-u1.cisco.com> Message-Id: Date: Wed, 02 Jan 2002 12:49:04 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>> I do not believe that there is currently any way to deal with the >>>> *business* and *operational* issues of asking some remote ISP >>>> to provide QoS service for you in any sort of scalable way >>> Fine, but that's completely orthogonal to whether the flow label is >>> a good idea or not. >> we don't care that no one can operationally use it. if it might sell >> one more router, let's kludge up the net a bit more. > Oh, please. There is a very straighforward tweak to RSVP to support > this i anxiously await a description the tweak which will provide "any way to deal with the *business* and *operational* issues of asking some remote ISP to provide QoS service for you in any sort of scalable way." randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 12:53:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KruZR028617 for ; Wed, 2 Jan 2002 12:53:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02Krte7028616 for ipng-dist; Wed, 2 Jan 2002 12:53:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02KrqZR028609 for ; Wed, 2 Jan 2002 12:53:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16327 for ; Wed, 2 Jan 2002 12:53:55 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09082 for ; Wed, 2 Jan 2002 12:53:54 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g02Krsq13317; Wed, 2 Jan 2002 12:53:54 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP27352; Wed, 2 Jan 2002 12:53:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10920; Wed, 2 Jan 2002 12:53:52 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.29536.276670.377209@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 12:53:52 -0800 (PST) To: Randy Bush Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> <15411.28923.226644.825039@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush writes: > >>>> I do not believe that there is currently any way to deal with the > >>>> *business* and *operational* issues of asking some remote ISP > >>>> to provide QoS service for you in any sort of scalable way > >>> Fine, but that's completely orthogonal to whether the flow label is > >>> a good idea or not. > >> we don't care that no one can operationally use it. if it might sell > >> one more router, let's kludge up the net a bit more. > > Oh, please. There is a very straighforward tweak to RSVP to support > > this > > i anxiously await a description the tweak which will provide "any way to > deal with the *business* and *operational* issues of asking some remote > ISP to provide QoS service for you in any sort of scalable way." Different problem. No cigar. This bait and switch reminds me of the same sort of tactics of those who endlessly pointed out that ip6 didn't solve the route explosion problem. As in, duh. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 13:11:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02LBkZR028645 for ; Wed, 2 Jan 2002 13:11:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02LBkJW028644 for ipng-dist; Wed, 2 Jan 2002 13:11:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02LBhZR028637 for ; Wed, 2 Jan 2002 13:11:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01125 for ; Wed, 2 Jan 2002 13:11:46 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23142 for ; Wed, 2 Jan 2002 14:11:45 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA08958; Wed, 2 Jan 2002 16:14:18 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA26435; Wed, 2 Jan 2002 16:14:17 -0500 Message-ID: <3C3377F8.6B9259AF@txc.com> Date: Wed, 02 Jan 2002 16:13:28 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> <3C32FD37.B79CDE36@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2C6D247BC51E28801A9EDD7E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms2C6D247BC51E28801A9EDD7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Let's take one simple example: **begin of example let's consider three neighboring routers: R1, R2, R3, forwarding one flow, characterized by src=a, dst=b, flow-label=10000, from R1 to R2, to R3. Input interfaces are I1 (on R1), I2 (on R2), I3 (on R3). Output interfaces are O1(R1), O2(R2), O3(R3). flow--->I1[R1]O1--->I2[R2]O2--->I3[R3]O3--->flow If for R2's I2's classification engine, flow label value 10, is significantloy better than 10000, R2 could notify R1, to change the value 10000 to 10, when forwarding the flow on interface O1 towards I2. R2 would also remember that on forwarding the flow internally from I2 to O2, it has to restore the value to 10000. Consequetly, R2 would classify the flow on I2, with value 10 instead of 10000, and forward it further on O2 after changing the value 10 to value 10000. The flow would arrive to R3 through I3, with flow label value 10000. **end of example. How is the mutability used by R1, and R2, affect R3 which is not part of the signaling between R1, and R2? It does not! There are cases in which network (forwarding) devices are the best to know what are the most optimum values for the flow label field. An adequate flow setup mechanism can take care of any local flow label value modification, and in the same time, restore flow label values to eliminate the effects on the rest of the network. How would you ensure that such devices can maximize their potential, if you do not leave any window of flexibility? Regards, Alex Brian E Carpenter wrote: > > Alex, > > I don't agree. This restores the uncertainty that is preventing any > current usage. > > Brian > > Alex Conta wrote: > > > > Making the field "immutable" by "default", but "mutable" when a router > > is so instructed by a flow setup and flow processing mechanism is a > > compromise that would satisfy all current and future possible cases. > > > > Therefore I think last sentence of the first paragraph > > > > All routers MUST pass the field on unchanged when forwarding a > > packet. > > > > should be something like: > > > > All routers MUST leave the field unchanged, by default, when > > forwarding a packet. > > A specific flow setup/processing mechanism MAY give a "mutable" > > character to the field, > > by requesting routers, supporting the mechanism, to change the field > > in certain ways. > > Routers supporting such a mechanism MUST follow the steps indicated > > by the flow > > setup and flow processing mechanism. > > > > Alex > > > > Brian E Carpenter wrote: > > > > > > Taking Scott's suggestion, here's another try: > > > > > > I'd like to propose the following as the > > > complete and total replacement of Section 6 of RFC 2460. > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > source to uniquely label sets of packets. Nodes that do not support > > > the Flow Label field MUST set the field to zero when originating a > > > packet, and MUST ignore the field when receiving a packet. All routers > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > This specification does not further define the meaning of the > > > Flow Label. > > > > > > [and delete Appendix A, which is unhelpful.] > > > > > > Brian > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > Board Chairman, Internet Society http://www.isoc.org > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms2C6D247BC51E28801A9EDD7E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMDIyMTEzMzBaMCMGCSqGSIb3DQEJ BDEWBBSdNDu6KMpfwAgb6TVdaAprzj6GqDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHEq+AOWZyZwk87CLjoh/vOsTnkTT8GuvT8PQntoT5B/1v+8 5JHmvAhbuXqrf64rU6f83BgukGMXezeJ+mnUr7tw42+/gwnIB9XauAn07e+Am/++8PrhnLDd lVpe3TIKZN/zdWTdrcAFSyQCEIK3cgKL5IiUfgxXTj3IFQAJjwhB --------------ms2C6D247BC51E28801A9EDD7E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 21:04:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g0354lZR029148 for ; Wed, 2 Jan 2002 21:04:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g0354lL2029147 for ipng-dist; Wed, 2 Jan 2002 21:04:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g0354iZR029140 for ; Wed, 2 Jan 2002 21:04:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06328 for ; Wed, 2 Jan 2002 21:04:47 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01421 for ; Wed, 2 Jan 2002 22:04:15 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0352sS02256; Thu, 3 Jan 2002 12:03:07 +0700 (ICT) From: Robert Elz To: Scott Bradner cc: mat@cisco.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200201021922.g02JMSa10173@newdev.harvard.edu> References: <200201021922.g02JMSa10173@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 12:02:54 +0700 Message-ID: <2254.1010034174@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) From: Scott Bradner Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> | I do not believe that there is currently any way to deal with the | *business* and *operational* issues of asking some remote ISP | to provide QoS service for you in any sort of scalable way Yes, that's a real hard problem. But it isn't the current one. There are two separate issues here - how to communicate the information, and then how to use it. Now it is certainly true that communicating information is a waste of time if the information can't be used -- but it is also true that there's no point figuring out how to use the information if there's no way to communicate it. Since the operational issues are hard, without doubt, there's a certain reluctance to attempt to find a solution to it - and as long as that can be avoided by resorting to "we don't need it yet, there'd be no way to use it anyway", that is what will keep happening. But there is a simple solution which can arise - I, as a customer, can work out what path my packets will take (AS path), make contact with all of the ISPs represented, and offer to pay them large amounts of cash to make some specific set of my packets get to some particular destination(s) much more reliably with much lower than normal (congested) delay. That's easy to do (assuming the availability of the cash). It can be done today. However, assuming I do that, how are all those ISPs supposed to implement my request? Currently they'd have to do it using port number snooping, and so I'd have to be able to specify the port numbers in advance. But that's not always possible, nor is it a rational design in any case (it just happens to be all that's probably possible with IPv4). With IPv6 I can simply arrange to label all the "important" packets, so all those ISPs, who are only too willing to accept the cash, can actually manage to earn it. Now of course, as an operational method, the one above doesn't scale at all. But that's OK, it doesn't have to - it isn't being proposed as a method to be adopted by all and sundry. What it has done is provided the motivation for the mechanism to exist that allows the packet classification to be reasonable. Given that, the desire to make use of this will grow, and the operational community will be forced to do the work to figure out how to make it feasible economically. This may end up falling back to explicit agreements between sender (or receiver) of the data and everyone along the path (as in a credit card number included in the RSVP reservation packet, or the equivalent) Or it could be done based on settlements between ISPs, with the ISPs perhaps using the DSCP in packets passing between them to indicate: "I am being paid more to achieve better results for this packet, it will offset as more than a normal packet if you also give it priority" with most likely, each ISP subtracting a little from the amount offered as their own compensation, so the sender would need to offer more to get priority through a long path than through a short one (which is entirely reasonable). Or it could be something quite different. I don't think it is for this working group to answer that question. I do think it is reasonable though for enough basic mechanism to be provided that the ISPs can actually process the packets reasonably though - and I think now that we know enough about how the protocol parts of all this can be made to work (as aside from the operational issues) that it can be done now - and so provide the rationale for actually doing the operational work. Chasing down header chains looking for a transport header certainly isn't the answer (even considering ESP headers as transport for this purpose, which I'm not sure I'd regard as correct anyway). Unlike in IPv4, there's no guarantee that the transport header will even occur in the first fragment of a large packet in IPv6. While it might seem to be folly to send fragmented packets at the IP level and expect any kind of quality of service, with IPv6 it really isn't. If the amount of data that has to be delivered (whether that be transport data, or additional data from extra "headers" is larger) than will fit across the path MTU, then some kind of fragmentation is required. Whether that's done at the IPv6 layer, or at the transport layer (with some kind of segmented messages) doesn't really make any difference - all the pieces need to arrive for the data to be interpreted (that's an assumption). In a scenario like that, it makes perfect sense to use IPv6 fragmentation. And if that's done, the port numbers (or even ESP SPI) might not be in the first fragment. This cannot disqualify the packet from receiving any kind of QoS treatment. With IPv6 there is no need for it to do so either - everything needed to classify the packet is in the IPv6 header (addresses and flow label). That's all routers should be looking at, as it is all that they can reliably expect to actually find (even ignoring the issue of "find quickly"). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 21:20:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g035KPZR029167 for ; Wed, 2 Jan 2002 21:20:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g035KP0o029166 for ipng-dist; Wed, 2 Jan 2002 21:20:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g035KMZR029159 for ; Wed, 2 Jan 2002 21:20:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18524 for ; Wed, 2 Jan 2002 21:20:26 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07679 for ; Wed, 2 Jan 2002 22:20:25 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16M0IJ-000CNY-00; Wed, 02 Jan 2002 21:19:59 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Wed, 02 Jan 2002 21:19:59 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Now it is certainly true that communicating information is a waste of > time if the information can't be used -- but it is also true that there's > no point figuring out how to use the information if there's no way to > communicate it. the ietf is becoming full of mechanisms of little use. yet there remain some very hard but useful and known to be usable problems to solve. can we spend our energies on these? on the other hand, there is the theory that it is better that idle hands be occupied with useless but non-damaging work lest they find damaging things to do. the problem with this approach is that the router code bases are unreliable and unstable. any unneeded additions will only make them worse. randy, a big fan of mbz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 2 23:32:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g037WcZR029213 for ; Wed, 2 Jan 2002 23:32:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g037Wc37029212 for ipng-dist; Wed, 2 Jan 2002 23:32:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g037WZZR029205 for ; Wed, 2 Jan 2002 23:32:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29377; Wed, 2 Jan 2002 23:32:38 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26533; Thu, 3 Jan 2002 00:32:37 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id IAA12694; Thu, 3 Jan 2002 08:32:35 +0100 Received: from dhcp222-86.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48354 from ; Thu, 3 Jan 2002 08:32:28 +0100 Message-Id: <3C34090C.2CC290C4@hursley.ibm.com> Date: Thu, 03 Jan 2002 08:32:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Erik Nordmark Cc: Lilian Fernandes , ipng@sunroof.eng.sun.com Subject: Re: '::' address as destination References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, You are correct of course in terms of the wire protocol. The issue is that people using heterogeneous systems will be confused by inconsistency between implementations. Brian Erik Nordmark wrote: > > > Hello, > > > > RFC 2373 states that: > > "The unspecified address must not be used as the destination address > > of IPv6 packets or in IPv6 Routing Headers." > > > > However it seems that certain stacks are using this address in a different > > way. > > Yes, but I don't think there is an inherent conflict. > RFC 2373 specifies the behavior on the wire i.e. what is carried in > IPv6 packets. > Implementations might do various things at the API interface, but the > an implementation should ensure and :: doesn't appear as the destination in > the IPv6 packets it sends. > > > When '::' is the destination address: > > - some use the first available interface's address > > - some use the loopback address > > > > Is there a chance that one of these will become the acceptable norm? It > > would be interesting to know if the majority of implementations actually > > return an error for this case. > > I know that for Solaris we interpret :: at the API as the loopback > address. This was done to be consistent with the IPv4 Solaris code. > Unfortunately the introduction of the mechanism in the IPv4 Solaris code > was before my time. I don't think it existed in BSD 4.3tahoe but I haven't > checked. > > Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 01:32:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g039WCZR029380 for ; Thu, 3 Jan 2002 01:32:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g039WCkQ029379 for ipng-dist; Thu, 3 Jan 2002 01:32:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g039W8ZR029372; Thu, 3 Jan 2002 01:32:09 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10921; Thu, 3 Jan 2002 01:32:13 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19505; Thu, 3 Jan 2002 02:32:12 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 5B459A; Thu, 3 Jan 2002 11:32:41 +0200 (EET) Message-ID: <3C342515.10904@nomadiclab.com> Date: Thu, 03 Jan 2002 11:32:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 07:10:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03FAuZR000144 for ; Thu, 3 Jan 2002 07:10:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03FAuS8000143 for ipng-dist; Thu, 3 Jan 2002 07:10:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03FArZR000136 for ; Thu, 3 Jan 2002 07:10:53 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11959 for ; Thu, 3 Jan 2002 07:10:57 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07413 for ; Thu, 3 Jan 2002 07:10:55 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA08312; Thu, 3 Jan 2002 16:10:54 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA65450 from ; Thu, 3 Jan 2002 16:10:53 +0100 Message-Id: <3C34747D.A10A4C0F@hursley.ibm.com> Date: Thu, 03 Jan 2002 16:10:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Alex Conta Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> <3C32FD37.B79CDE36@hursley.ibm.com> <3C3377F8.6B9259AF@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, What you describe is the argument for the mutability of DSCPs (plus the need for out of band magic to restore the original value). I just don't see a win in having the same property, and resultant complexity, in the flow label as well. Brian Alex Conta wrote: > > Brian, > > Let's take one simple example: > > **begin of example > > let's consider three neighboring routers: R1, R2, R3, forwarding one > flow, characterized by > src=a, dst=b, flow-label=10000, from R1 to R2, to R3. > > Input interfaces are I1 (on R1), I2 (on R2), I3 (on R3). > Output interfaces are O1(R1), O2(R2), O3(R3). > > flow--->I1[R1]O1--->I2[R2]O2--->I3[R3]O3--->flow > > If for R2's I2's classification engine, flow label value 10, is > significantloy better than 10000, R2 could notify R1, to change the > value 10000 to 10, when forwarding the flow on interface O1 towards I2. > R2 would also remember that on forwarding the flow internally from I2 to > O2, it has to restore the value to 10000. Consequetly, R2 would classify > the flow on I2, with value 10 instead of 10000, and forward it further > on O2 after changing the value 10 to value 10000. The flow would arrive > to R3 through I3, with flow label value 10000. > > **end of example. > > How is the mutability used by R1, and R2, affect R3 which is not part of > the signaling between R1, and R2? It does not! > > There are cases in which network (forwarding) devices are the best to > know what are the most optimum values for the flow label field. An > adequate flow setup mechanism can take care of any local flow label > value modification, and in the same time, restore flow label values to > eliminate the effects on the rest of the network. > > How would you ensure that such devices can maximize their potential, if > you do not leave any window of flexibility? > > Regards, > Alex > > Brian E Carpenter wrote: > > > > Alex, > > > > I don't agree. This restores the uncertainty that is preventing any > > current usage. > > > > Brian > > > > Alex Conta wrote: > > > > > > Making the field "immutable" by "default", but "mutable" when a router > > > is so instructed by a flow setup and flow processing mechanism is a > > > compromise that would satisfy all current and future possible cases. > > > > > > Therefore I think last sentence of the first paragraph > > > > > > All routers MUST pass the field on unchanged when forwarding a > > > packet. > > > > > > should be something like: > > > > > > All routers MUST leave the field unchanged, by default, when > > > forwarding a packet. > > > A specific flow setup/processing mechanism MAY give a "mutable" > > > character to the field, > > > by requesting routers, supporting the mechanism, to change the field > > > in certain ways. > > > Routers supporting such a mechanism MUST follow the steps indicated > > > by the flow > > > setup and flow processing mechanism. > > > > > > Alex > > > > > > Brian E Carpenter wrote: > > > > > > > > Taking Scott's suggestion, here's another try: > > > > > > > > I'd like to propose the following as the > > > > complete and total replacement of Section 6 of RFC 2460. > > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > source to uniquely label sets of packets. Nodes that do not support > > > > the Flow Label field MUST set the field to zero when originating a > > > > packet, and MUST ignore the field when receiving a packet. All routers > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > This specification does not further define the meaning of the > > > > Flow Label. > > > > > > > > [and delete Appendix A, which is unhelpful.] > > > > > > > > Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 07:34:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03FYWZR000412 for ; Thu, 3 Jan 2002 07:34:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03FYW0E000411 for ipng-dist; Thu, 3 Jan 2002 07:34:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03FYTZR000404 for ; Thu, 3 Jan 2002 07:34:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02593 for ; Thu, 3 Jan 2002 07:34:30 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27139 for ; Thu, 3 Jan 2002 08:34:30 -0700 (MST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03FYD8j029822; Thu, 3 Jan 2002 09:34:14 -0600 (CST) Message-ID: <06cc01c19484$b595eca0$0100a8c0@RepliGate> From: "Jim Fleming" To: "Brian E Carpenter" , "Alex Conta" Cc: References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> <3C32FD37.B79CDE36@hursley.ibm.com> <3C3377F8.6B9259AF@txc.com> <3C34747D.A10A4C0F@hursley.ibm.com> Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] Date: Thu, 3 Jan 2002 10:30:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This all sounds very abstract, is there any working code ? Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "Brian E Carpenter" To: "Alex Conta" Cc: Sent: Thursday, January 03, 2002 7:10 AM Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] > Alex, > > What you describe is the argument for the mutability of > DSCPs (plus the need for out of band magic to restore > the original value). I just don't see a win in having the > same property, and resultant complexity, in the flow label > as well. > > Brian > > Alex Conta wrote: > > > > Brian, > > > > Let's take one simple example: > > > > **begin of example > > > > let's consider three neighboring routers: R1, R2, R3, forwarding one > > flow, characterized by > > src=a, dst=b, flow-label=10000, from R1 to R2, to R3. > > > > Input interfaces are I1 (on R1), I2 (on R2), I3 (on R3). > > Output interfaces are O1(R1), O2(R2), O3(R3). > > > > flow--->I1[R1]O1--->I2[R2]O2--->I3[R3]O3--->flow > > > > If for R2's I2's classification engine, flow label value 10, is > > significantloy better than 10000, R2 could notify R1, to change the > > value 10000 to 10, when forwarding the flow on interface O1 towards I2. > > R2 would also remember that on forwarding the flow internally from I2 to > > O2, it has to restore the value to 10000. Consequetly, R2 would classify > > the flow on I2, with value 10 instead of 10000, and forward it further > > on O2 after changing the value 10 to value 10000. The flow would arrive > > to R3 through I3, with flow label value 10000. > > > > **end of example. > > > > How is the mutability used by R1, and R2, affect R3 which is not part of > > the signaling between R1, and R2? It does not! > > > > There are cases in which network (forwarding) devices are the best to > > know what are the most optimum values for the flow label field. An > > adequate flow setup mechanism can take care of any local flow label > > value modification, and in the same time, restore flow label values to > > eliminate the effects on the rest of the network. > > > > How would you ensure that such devices can maximize their potential, if > > you do not leave any window of flexibility? > > > > Regards, > > Alex > > > > Brian E Carpenter wrote: > > > > > > Alex, > > > > > > I don't agree. This restores the uncertainty that is preventing any > > > current usage. > > > > > > Brian > > > > > > Alex Conta wrote: > > > > > > > > Making the field "immutable" by "default", but "mutable" when a router > > > > is so instructed by a flow setup and flow processing mechanism is a > > > > compromise that would satisfy all current and future possible cases. > > > > > > > > Therefore I think last sentence of the first paragraph > > > > > > > > All routers MUST pass the field on unchanged when forwarding a > > > > packet. > > > > > > > > should be something like: > > > > > > > > All routers MUST leave the field unchanged, by default, when > > > > forwarding a packet. > > > > A specific flow setup/processing mechanism MAY give a "mutable" > > > > character to the field, > > > > by requesting routers, supporting the mechanism, to change the field > > > > in certain ways. > > > > Routers supporting such a mechanism MUST follow the steps indicated > > > > by the flow > > > > setup and flow processing mechanism. > > > > > > > > Alex > > > > > > > > Brian E Carpenter wrote: > > > > > > > > > > Taking Scott's suggestion, here's another try: > > > > > > > > > > I'd like to propose the following as the > > > > > complete and total replacement of Section 6 of RFC 2460. > > > > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > > source to uniquely label sets of packets. Nodes that do not support > > > > > the Flow Label field MUST set the field to zero when originating a > > > > > packet, and MUST ignore the field when receiving a packet. All routers > > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > > > This specification does not further define the meaning of the > > > > > Flow Label. > > > > > > > > > > [and delete Appendix A, which is unhelpful.] > > > > > > > > > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 08:09:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03G9CZR000448 for ; Thu, 3 Jan 2002 08:09:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03G9CVk000447 for ipng-dist; Thu, 3 Jan 2002 08:09:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03G98ZR000440 for ; Thu, 3 Jan 2002 08:09:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19520 for ; Thu, 3 Jan 2002 08:09:13 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23129 for ; Thu, 3 Jan 2002 08:09:12 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g03G9BK13474 for ; Thu, 3 Jan 2002 17:09:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Jan 03 17:08:55 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 17:09:11 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C196@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 3 Jan 2002 17:08:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, [ Sorry catching up on old emails] > >come back to basics and say that the flow label > >is part of the IPv6 header, therefore it seems > >rational to let IPv6 WG define its use. > >I don't see anything wrong with this, no other > >fields in the IPv6 header are defined by other > >groups. > > This is acceptable to me, if it represents a consensus view > of the WG. But, in this case, we should go all the way > and actually specify a useful flow label -- one that > could be used to look-up cached information on intermediate > routers without a signalling protocol, for example. => OK, so what you're saying is that it's ok to have an immutable flow label but we should not have to mandate signalling to install the value in routers. That's also fine with me. What that means to me is that we can have some of the FL values reserved for assignment by IANA, provided we maintain immutability. Ie. using IANA as a signalling protocol :) I'm ok with that, but I know some (a lot ?) of people don't agree with it. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 08:15:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GF3ZR000467 for ; Thu, 3 Jan 2002 08:15:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03GF3m7000466 for ipng-dist; Thu, 3 Jan 2002 08:15:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GExZR000459 for ; Thu, 3 Jan 2002 08:15:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25037 for ; Thu, 3 Jan 2002 08:15:04 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01644 for ; Thu, 3 Jan 2002 09:14:45 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g03GF2J05780 for ; Thu, 3 Jan 2002 17:15:02 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Jan 03 17:15:02 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 17:15:02 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C197@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" Cc: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 3 Jan 2002 17:14:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you're trying to avoid exposing the encryption key, you > can use x, where x is any number that both nodes are > aware of. > > => I don't understand why the peer has to be aware of x. > Do you want to provide QoS inside end nodes? IMHO this is => No, just trying to allow the receiver to verify the value. Nothing to do with QoS > not a bad idea because the CPU is far faster than I/O subsystems, => I guess you meant, "it IS a bad idea" ? :) > BTW most implementations don't provide an API to get the received > flow ID or label, just because this is not considered as useful. => Well, some of us want to. Itojun had draft on this for example. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 08:19:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GJ7ZR000487 for ; Thu, 3 Jan 2002 08:19:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03GJ7KD000486 for ipng-dist; Thu, 3 Jan 2002 08:19:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GJ4ZR000479 for ; Thu, 3 Jan 2002 08:19:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09875 for ; Thu, 3 Jan 2002 08:19:08 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04565 for ; Thu, 3 Jan 2002 08:19:07 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA11232; Thu, 3 Jan 2002 17:19:01 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38046 from ; Thu, 3 Jan 2002 17:19:00 +0100 Message-Id: <3C348472.DD2BE3C9@hursley.ibm.com> Date: Thu, 03 Jan 2002 17:18:58 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Randy Bush Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, The proposed new words for 2460 effectively say - you don't have to set it - you don't have to look at it - you mustn't change it I don't think encourages kludge significantly more than MBZ text, but it does allow for future usage. Brian Randy Bush wrote: > > >> I do not believe that there is currently any way to deal with the > >> *business* and *operational* issues of asking some remote ISP > >> to provide QoS service for you in any sort of scalable way > > Fine, but that's completely orthogonal to whether the flow label is > > a good idea or not. > > we don't care that no one can operationally use it. if it might sell > one more router, let's kludge up the net a bit more. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 08:20:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GK1ZR000504 for ; Thu, 3 Jan 2002 08:20:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03GK1fb000503 for ipng-dist; Thu, 3 Jan 2002 08:20:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GJwZR000496 for ; Thu, 3 Jan 2002 08:19:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25974 for ; Thu, 3 Jan 2002 08:20:03 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08776 for ; Thu, 3 Jan 2002 09:20:02 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g03GK1J08644 for ; Thu, 3 Jan 2002 17:20:01 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 03 17:19:45 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 17:11:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C198@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian E Carpenter'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 3 Jan 2002 17:19:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The IANA assignment approach comes afterwards - once we get the > immutability property in the standard, we can use IANA assigned > values without further work. For diffserv we would use the > PHB ID values of RFC 3140, but there is no need to specify that > as part of the flow label definition; it comes free of charge. > => You need to make sure this is done before the fl text becomes standard, otherwise there will be conflicts between implementors who are not aware of IANA-based thoughts and the values that IANA may reserve. Hesham > > > > > > => Well, there is no requirement that the > flow label is > > > > > > globally unique. So this should work as long > as you use > > > > > > a unique value between 2 addresses. > > > > > > > > > > > > > > > > However, it's only useful for a subset of cases, > > > > > > > > => I didn't really understand what you mean by 'subset > > > > of cases'. > > > > > > It doesn't apply to the diffserv usage (where the label > > > is unique to a traffic class, not a flow or a pair of ports, > > > and may be IANA-registered) > > > > => That's why I didn't know what you meant :) > > I went back and re-read the draft but I couldn't > > see anything about IANA assignment. > > In fact I brought this up in the meeting but there > > was no support for the idea, so is this something > > you'd like to add or have I completely misunderstood > > something ? > > > > Hesham > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 08:26:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GQYZR000530 for ; Thu, 3 Jan 2002 08:26:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03GQYWB000529 for ipng-dist; Thu, 3 Jan 2002 08:26:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GQVZR000522 for ; Thu, 3 Jan 2002 08:26:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11270 for ; Thu, 3 Jan 2002 08:26:36 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09586 for ; Thu, 3 Jan 2002 09:26:16 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA12928 for ; Thu, 3 Jan 2002 17:26:32 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59674 from ; Thu, 3 Jan 2002 17:26:30 +0100 Message-Id: <3C348636.DB130121@hursley.ibm.com> Date: Thu, 03 Jan 2002 17:26:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Where are the WG chairs when we need them? [was Re: Flow Label] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The one acronym summary of kre's point is: SLA. I'd venture to say that no QoS solution will ever work in the absence of an SLA. And guess what, the IETF doesn't discuss business models and SLAs. The most we can do is standardise tools that can be deployed to support SLAs. So, I think it's time for a hum on this one (the simple update to 2460 that Scott and I at least seem to agree on). Brian Robert Elz wrote: > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) > From: Scott Bradner > Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> > > | I do not believe that there is currently any way to deal with the > | *business* and *operational* issues of asking some remote ISP > | to provide QoS service for you in any sort of scalable way > > Yes, that's a real hard problem. But it isn't the current one. > > There are two separate issues here - how to communicate the information, > and then how to use it. > > Now it is certainly true that communicating information is a waste of time > if the information can't be used -- but it is also true that there's no > point figuring out how to use the information if there's no way to communicate > it. > > Since the operational issues are hard, without doubt, there's a certain > reluctance to attempt to find a solution to it - and as long as that can > be avoided by resorting to "we don't need it yet, there'd be no way to use > it anyway", that is what will keep happening. > > But there is a simple solution which can arise - I, as a customer, can work > out what path my packets will take (AS path), make contact with all of the > ISPs represented, and offer to pay them large amounts of cash to make some > specific set of my packets get to some particular destination(s) much more > reliably with much lower than normal (congested) delay. That's easy to do > (assuming the availability of the cash). It can be done today. > > However, assuming I do that, how are all those ISPs supposed to implement > my request? Currently they'd have to do it using port number snooping, > and so I'd have to be able to specify the port numbers in advance. But > that's not always possible, nor is it a rational design in any case (it > just happens to be all that's probably possible with IPv4). With IPv6 > I can simply arrange to label all the "important" packets, so all those > ISPs, who are only too willing to accept the cash, can actually manage to > earn it. > > Now of course, as an operational method, the one above doesn't scale at all. > But that's OK, it doesn't have to - it isn't being proposed as a method > to be adopted by all and sundry. What it has done is provided the > motivation for the mechanism to exist that allows the packet classification > to be reasonable. Given that, the desire to make use of this will grow, > and the operational community will be forced to do the work to figure out > how to make it feasible economically. > > This may end up falling back to explicit agreements between sender > (or receiver) of the data and everyone along the path (as in a credit > card number included in the RSVP reservation packet, or the equivalent) > Or it could be done based on settlements between ISPs, with the ISPs > perhaps using the DSCP in packets passing between them to indicate: > "I am being paid more to achieve better results for this packet, it will > offset as more than a normal packet if you also give it priority" with > most likely, each ISP subtracting a little from the amount offered as > their own compensation, so the sender would need to offer more to get > priority through a long path than through a short one (which is entirely > reasonable). Or it could be something quite different. > > I don't think it is for this working group to answer that question. > I do think it is reasonable though for enough basic mechanism to be > provided that the ISPs can actually process the packets reasonably > though - and I think now that we know enough about how the protocol > parts of all this can be made to work (as aside from the operational > issues) that it can be done now - and so provide the rationale for > actually doing the operational work. > > Chasing down header chains looking for a transport header certainly > isn't the answer (even considering ESP headers as transport for this > purpose, which I'm not sure I'd regard as correct anyway). Unlike > in IPv4, there's no guarantee that the transport header will even occur > in the first fragment of a large packet in IPv6. While it might seem to > be folly to send fragmented packets at the IP level and expect any kind > of quality of service, with IPv6 it really isn't. If the amount of > data that has to be delivered (whether that be transport data, or > additional data from extra "headers" is larger) than will fit across the > path MTU, then some kind of fragmentation is required. Whether that's > done at the IPv6 layer, or at the transport layer (with some kind of > segmented messages) doesn't really make any difference - all the pieces > need to arrive for the data to be interpreted (that's an assumption). > In a scenario like that, it makes perfect sense to use IPv6 fragmentation. > And if that's done, the port numbers (or even ESP SPI) might not be in > the first fragment. This cannot disqualify the packet from receiving > any kind of QoS treatment. With IPv6 there is no need for it to do so > either - everything needed to classify the packet is in the IPv6 header > (addresses and flow label). That's all routers should be looking at, as > it is all that they can reliably expect to actually find (even ignoring the > issue of "find quickly"). > > kre -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 08:27:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GRrZR000550 for ; Thu, 3 Jan 2002 08:27:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03GRr6E000549 for ipng-dist; Thu, 3 Jan 2002 08:27:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GRoZR000542 for ; Thu, 3 Jan 2002 08:27:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21895 for ; Thu, 3 Jan 2002 08:27:55 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10692 for ; Thu, 3 Jan 2002 09:27:54 -0700 (MST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03GRp8j020467; Thu, 3 Jan 2002 10:27:51 -0600 (CST) Message-ID: <07d401c1948c$336c4370$0100a8c0@RepliGate> From: "Jim Fleming" To: "Hesham Soliman \(ERA\)" , "'Margaret Wasserman'" Cc: References: <4DA6EA82906FD511BE2F00508BCF053801C4C196@Esealnt861.al.sw.ericsson.se> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 3 Jan 2002 11:24:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" ; "Hesham Soliman (ERA)" > That's also fine with me. What that means to me > is that we can have some of the FL values reserved > for assignment by IANA, provided we maintain > immutability. Ie. using IANA as a signalling > protocol :) > > I'm ok with that, but I know some (a lot ?) of > people don't agree with it. > > Is the ICANN Board able to understand how to do that ? http://www.icann.org/general/iana-contract-09feb00.htm Contract Between ICANN and the United States Government for Performance of the IANA Function Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 08:31:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GVtZR000572 for ; Thu, 3 Jan 2002 08:31:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03GVtxX000571 for ipng-dist; Thu, 3 Jan 2002 08:31:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03GVpZR000564 for ; Thu, 3 Jan 2002 08:31:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12217 for ; Thu, 3 Jan 2002 08:31:56 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15854 for ; Thu, 3 Jan 2002 09:32:58 -0700 (MST) Received: from kenawang ([192.168.1.71]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA21517; Thu, 3 Jan 2002 08:30:38 -0800 (PST) Message-Id: <4.2.2.20020103112950.045b4320@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Jan 2002 11:31:14 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3C348636.DB130121@hursley.ibm.com> References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So, I think it's time for a hum on this one (the simple >update to 2460 that Scott and I at least seem to agree >on). Hum. Could someone publish an internet draft with this wording? The only draft that we have now is pretty far away from this. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:02:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03H2WZR000624 for ; Thu, 3 Jan 2002 09:02:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03H2Vi4000623 for ipng-dist; Thu, 3 Jan 2002 09:02:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03H2SZR000616 for ; Thu, 3 Jan 2002 09:02:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27517 for ; Thu, 3 Jan 2002 09:02:33 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29302 for ; Thu, 3 Jan 2002 10:03:35 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA03181; Thu, 3 Jan 2002 09:02:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g03H2V412742; Thu, 3 Jan 2002 09:02:31 -0800 X-mProtect: Thu, 3 Jan 2002 09:02:31 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBaQv8k; Thu, 03 Jan 2002 09:02:30 PST Message-ID: <3C348EA6.65D2D415@iprg.nokia.com> Date: Thu, 03 Jan 2002 09:02:30 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <3C348636.DB130121@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Brian et.al., Brian E Carpenter wrote: > The one acronym summary of kre's point is: SLA. I'd venture > to say that no QoS solution will ever work in the absence of > an SLA. And guess what, the IETF doesn't discuss business > models and SLAs. The most we can do is standardise tools > that can be deployed to support SLAs. > > So, I think it's time for a hum on this one (the simple > update to 2460 that Scott and I at least seem to agree > on). Although I have not participated in this discussion, I have followed it closely. I like the simple update to 2460 that you folks seem to have agreed on, but I also believe that workable solutions can be made that do NOT necessarily depend on SLAs. As a separate point, however, I would like to raise another issue. Let's say that the flow label enables some way to distinguish a packet flow for special or faster processing. A malicious node could insert packets with the flow label, possibly causing the traffic conditioner on the receiving end to flag an exception and disrupt further traffic to the destination. This could happen, right? This isn't any worse than a lot of other problems that would come up a long time before flow-label impersonation, but I wondered whether there had been discussion about it. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:09:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03H9sZR000641 for ; Thu, 3 Jan 2002 09:09:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03H9sBl000640 for ipng-dist; Thu, 3 Jan 2002 09:09:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03H9oZR000633 for ; Thu, 3 Jan 2002 09:09:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28944 for ; Thu, 3 Jan 2002 09:09:55 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03070 for ; Thu, 3 Jan 2002 10:10:56 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g03H9ii13070; Thu, 3 Jan 2002 12:09:44 -0500 (EST) Message-Id: <200201031709.g03H9ii13070@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Randy Bush , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "Thu, 03 Jan 2002 17:18:58 +0100." <3C348472.DD2BE3C9@hursley.ibm.com> Date: Thu, 03 Jan 2002 12:09:43 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Randy, > > The proposed new words for 2460 effectively say > - you don't have to set it > - you don't have to look at it > - you mustn't change it > > I don't think encourages kludge significantly more than MBZ text, but it > does allow for future usage. as I see it, the proposed words let us get Flow Label off our plates for now, which is good because we don't know what to do with it anyway. maybe someday someone wall make a convincing case for how to use it. for now, other things are probably more worthy of attetion. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:11:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HB8ZR000658 for ; Thu, 3 Jan 2002 09:11:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03HB8rK000657 for ipng-dist; Thu, 3 Jan 2002 09:11:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HB5ZR000650 for ; Thu, 3 Jan 2002 09:11:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04787 for ; Thu, 3 Jan 2002 09:11:10 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12608 for ; Thu, 3 Jan 2002 10:10:51 -0700 (MST) Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA10171; Thu, 3 Jan 2002 11:11:02 -0600 (CST) Message-Id: <4.3.2.7.2.20020103110729.00b16470@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jan 2002 11:08:16 -0600 To: Brian E Carpenter , ipng@sunroof.eng.sun.com From: Richard Carlson Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] In-Reply-To: <3C348636.DB130121@hursley.ibm.com> References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I hum for this. Rich At 05:26 PM 1/3/02 +0100, Brian E Carpenter wrote: >The one acronym summary of kre's point is: SLA. I'd venture >to say that no QoS solution will ever work in the absence of >an SLA. And guess what, the IETF doesn't discuss business >models and SLAs. The most we can do is standardise tools >that can be deployed to support SLAs. > >So, I think it's time for a hum on this one (the simple >update to 2460 that Scott and I at least seem to agree >on). > > Brian > >Robert Elz wrote: > > > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) > > From: Scott Bradner > > Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> > > > > | I do not believe that there is currently any way to deal with the > > | *business* and *operational* issues of asking some remote ISP > > | to provide QoS service for you in any sort of scalable way > > > > Yes, that's a real hard problem. But it isn't the current one. > > > > There are two separate issues here - how to communicate the information, > > and then how to use it. > > > > Now it is certainly true that communicating information is a waste of time > > if the information can't be used -- but it is also true that there's no > > point figuring out how to use the information if there's no way to > communicate > > it. > > > > Since the operational issues are hard, without doubt, there's a certain > > reluctance to attempt to find a solution to it - and as long as that can > > be avoided by resorting to "we don't need it yet, there'd be no way to use > > it anyway", that is what will keep happening. > > > > But there is a simple solution which can arise - I, as a customer, can work > > out what path my packets will take (AS path), make contact with all of the > > ISPs represented, and offer to pay them large amounts of cash to make some > > specific set of my packets get to some particular destination(s) much more > > reliably with much lower than normal (congested) delay. That's easy to do > > (assuming the availability of the cash). It can be done today. > > > > However, assuming I do that, how are all those ISPs supposed to implement > > my request? Currently they'd have to do it using port number snooping, > > and so I'd have to be able to specify the port numbers in advance. But > > that's not always possible, nor is it a rational design in any case (it > > just happens to be all that's probably possible with IPv4). With IPv6 > > I can simply arrange to label all the "important" packets, so all those > > ISPs, who are only too willing to accept the cash, can actually manage to > > earn it. > > > > Now of course, as an operational method, the one above doesn't scale at > all. > > But that's OK, it doesn't have to - it isn't being proposed as a method > > to be adopted by all and sundry. What it has done is provided the > > motivation for the mechanism to exist that allows the packet classification > > to be reasonable. Given that, the desire to make use of this will grow, > > and the operational community will be forced to do the work to figure out > > how to make it feasible economically. > > > > This may end up falling back to explicit agreements between sender > > (or receiver) of the data and everyone along the path (as in a credit > > card number included in the RSVP reservation packet, or the equivalent) > > Or it could be done based on settlements between ISPs, with the ISPs > > perhaps using the DSCP in packets passing between them to indicate: > > "I am being paid more to achieve better results for this packet, it will > > offset as more than a normal packet if you also give it priority" with > > most likely, each ISP subtracting a little from the amount offered as > > their own compensation, so the sender would need to offer more to get > > priority through a long path than through a short one (which is entirely > > reasonable). Or it could be something quite different. > > > > I don't think it is for this working group to answer that question. > > I do think it is reasonable though for enough basic mechanism to be > > provided that the ISPs can actually process the packets reasonably > > though - and I think now that we know enough about how the protocol > > parts of all this can be made to work (as aside from the operational > > issues) that it can be done now - and so provide the rationale for > > actually doing the operational work. > > > > Chasing down header chains looking for a transport header certainly > > isn't the answer (even considering ESP headers as transport for this > > purpose, which I'm not sure I'd regard as correct anyway). Unlike > > in IPv4, there's no guarantee that the transport header will even occur > > in the first fragment of a large packet in IPv6. While it might seem to > > be folly to send fragmented packets at the IP level and expect any kind > > of quality of service, with IPv6 it really isn't. If the amount of > > data that has to be delivered (whether that be transport data, or > > additional data from extra "headers" is larger) than will fit across the > > path MTU, then some kind of fragmentation is required. Whether that's > > done at the IPv6 layer, or at the transport layer (with some kind of > > segmented messages) doesn't really make any difference - all the pieces > > need to arrive for the data to be interpreted (that's an assumption). > > In a scenario like that, it makes perfect sense to use IPv6 fragmentation. > > And if that's done, the port numbers (or even ESP SPI) might not be in > > the first fragment. This cannot disqualify the packet from receiving > > any kind of QoS treatment. With IPv6 there is no need for it to do so > > either - everything needed to classify the packet is in the IPv6 header > > (addresses and flow label). That's all routers should be looking at, as > > it is all that they can reliably expect to actually find (even ignoring the > > issue of "find quickly"). > > > > kre > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM >On assignment at the IBM Zurich Laboratory, Switzerland >Board Chairman, Internet Society http://www.isoc.org >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:14:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HE4ZR000683 for ; Thu, 3 Jan 2002 09:14:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03HE4ko000682 for ipng-dist; Thu, 3 Jan 2002 09:14:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HE1ZR000675 for ; Thu, 3 Jan 2002 09:14:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05177 for ; Thu, 3 Jan 2002 09:14:06 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29486 for ; Thu, 3 Jan 2002 09:14:05 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MBQv-0009tK-00; Thu, 03 Jan 2002 09:13:37 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: Brian E Carpenter , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <3C348472.DD2BE3C9@hursley.ibm.com> <200201031709.g03H9ii13070@astro.cs.utk.edu> Message-Id: Date: Thu, 03 Jan 2002 09:13:37 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The proposed new words for 2460 effectively say >> - you don't have to set it >> - you don't have to look at it >> - you mustn't change it >> I don't think encourages kludge significantly more than MBZ text, but it >> does allow for future usage. > as I see it, the proposed words let us get Flow Label off our > plates for now, which is good because we don't know what to do > with it anyway. maybe someday someone wall make a convincing > case for how to use it. and, if we do mbz, they can then write the rfc which changes that randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:34:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HY7ZR000832 for ; Thu, 3 Jan 2002 09:34:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03HY7hY000831 for ipng-dist; Thu, 3 Jan 2002 09:34:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HY3ZR000824 for ; Thu, 3 Jan 2002 09:34:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25186 for ; Thu, 3 Jan 2002 09:34:09 -0800 (PST) Received: from berkshire.research.att.com (H-135-207-52-179.research.att.com [135.207.52.179]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01825 for ; Thu, 3 Jan 2002 10:34:08 -0700 (MST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id D319C7B55; Thu, 3 Jan 2002 12:34:07 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Randy Bush Cc: Keith Moore , Brian E Carpenter , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 12:34:07 -0500 Message-Id: <20020103173407.D319C7B55@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Randy Bush writes: >>> The proposed new words for 2460 effectively say >>> - you don't have to set it >>> - you don't have to look at it >>> - you mustn't change it >>> I don't think encourages kludge significantly more than MBZ text, but it >>> does allow for future usage. >> as I see it, the proposed words let us get Flow Label off our >> plates for now, which is good because we don't know what to do >> with it anyway. maybe someday someone wall make a convincing >> case for how to use it. > >and, if we do mbz, they can then write the rfc which changes that The problem then is all the implementations -- or firewalls -- that will check that the bits really are zero upon receipt. If you want MBZ, say "sender MUST set to zero; receiver and middle boxes MUST NOT check". Then you have to hope that folks listen to that part. Especially for firewalls, I wouldn't count on that. (For precedent, so to speak, look at what happened with the ECN bits when a particular version of Linux started using them.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:37:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HbCZR000855 for ; Thu, 3 Jan 2002 09:37:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03HbCPH000854 for ipng-dist; Thu, 3 Jan 2002 09:37:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03Hb9ZR000847 for ; Thu, 3 Jan 2002 09:37:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25300 for ; Thu, 3 Jan 2002 09:37:15 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01504 for ; Thu, 3 Jan 2002 10:36:56 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MBnl-000B4j-00; Thu, 03 Jan 2002 09:37:13 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <20020103173407.D319C7B55@berkshire.research.att.com> Message-Id: Date: Thu, 03 Jan 2002 09:37:13 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> and, if we do mbz, they can then write the rfc which changes that > The problem then is all the implementations -- or firewalls -- that > will check that the bits really are zero upon receipt. If you want > MBZ, say "sender MUST set to zero; receiver and middle boxes MUST NOT > check". as i thought it was the stated mbz formulation, i was assuming this. > Then you have to hope that folks listen to that part. Especially for > firewalls, I wouldn't count on that. (For precedent, so to speak, look > at what happened with the ECN bits when a particular version of Linux > started using them.) hmmm. i think i am starting to reconsider. idiots are soooo creative. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:46:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03Hk5ZR000881 for ; Thu, 3 Jan 2002 09:46:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03Hk5No000880 for ipng-dist; Thu, 3 Jan 2002 09:46:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03Hk2ZR000873 for ; Thu, 3 Jan 2002 09:46:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27532 for ; Thu, 3 Jan 2002 09:46:08 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04378 for ; Thu, 3 Jan 2002 10:46:03 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03HjpS00682; Thu, 3 Jan 2002 09:45:52 -0800 (PST) Message-ID: <008101c1947e$4395b780$7e6015ac@T23KEMPF> From: "James Kempf" To: "Brian E Carpenter" , , "Richard Carlson" References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <4.3.2.7.2.20020103110729.00b16470@atalanta.ctd.anl.gov> Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] Date: Thu, 3 Jan 2002 09:44:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I hum as well. jak ----- Original Message ----- From: "Richard Carlson" To: "Brian E Carpenter" ; Sent: Thursday, January 03, 2002 9:08 AM Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] > I hum for this. > > Rich > > At 05:26 PM 1/3/02 +0100, Brian E Carpenter wrote: > >The one acronym summary of kre's point is: SLA. I'd venture > >to say that no QoS solution will ever work in the absence of > >an SLA. And guess what, the IETF doesn't discuss business > >models and SLAs. The most we can do is standardise tools > >that can be deployed to support SLAs. > > > >So, I think it's time for a hum on this one (the simple > >update to 2460 that Scott and I at least seem to agree > >on). > > > > Brian > > > >Robert Elz wrote: > > > > > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) > > > From: Scott Bradner > > > Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> > > > > > > | I do not believe that there is currently any way to deal with the > > > | *business* and *operational* issues of asking some remote ISP > > > | to provide QoS service for you in any sort of scalable way > > > > > > Yes, that's a real hard problem. But it isn't the current one. > > > > > > There are two separate issues here - how to communicate the information, > > > and then how to use it. > > > > > > Now it is certainly true that communicating information is a waste of time > > > if the information can't be used -- but it is also true that there's no > > > point figuring out how to use the information if there's no way to > > communicate > > > it. > > > > > > Since the operational issues are hard, without doubt, there's a certain > > > reluctance to attempt to find a solution to it - and as long as that can > > > be avoided by resorting to "we don't need it yet, there'd be no way to use > > > it anyway", that is what will keep happening. > > > > > > But there is a simple solution which can arise - I, as a customer, can work > > > out what path my packets will take (AS path), make contact with all of the > > > ISPs represented, and offer to pay them large amounts of cash to make some > > > specific set of my packets get to some particular destination(s) much more > > > reliably with much lower than normal (congested) delay. That's easy to do > > > (assuming the availability of the cash). It can be done today. > > > > > > However, assuming I do that, how are all those ISPs supposed to implement > > > my request? Currently they'd have to do it using port number snooping, > > > and so I'd have to be able to specify the port numbers in advance. But > > > that's not always possible, nor is it a rational design in any case (it > > > just happens to be all that's probably possible with IPv4). With IPv6 > > > I can simply arrange to label all the "important" packets, so all those > > > ISPs, who are only too willing to accept the cash, can actually manage to > > > earn it. > > > > > > Now of course, as an operational method, the one above doesn't scale at > > all. > > > But that's OK, it doesn't have to - it isn't being proposed as a method > > > to be adopted by all and sundry. What it has done is provided the > > > motivation for the mechanism to exist that allows the packet classification > > > to be reasonable. Given that, the desire to make use of this will grow, > > > and the operational community will be forced to do the work to figure out > > > how to make it feasible economically. > > > > > > This may end up falling back to explicit agreements between sender > > > (or receiver) of the data and everyone along the path (as in a credit > > > card number included in the RSVP reservation packet, or the equivalent) > > > Or it could be done based on settlements between ISPs, with the ISPs > > > perhaps using the DSCP in packets passing between them to indicate: > > > "I am being paid more to achieve better results for this packet, it will > > > offset as more than a normal packet if you also give it priority" with > > > most likely, each ISP subtracting a little from the amount offered as > > > their own compensation, so the sender would need to offer more to get > > > priority through a long path than through a short one (which is entirely > > > reasonable). Or it could be something quite different. > > > > > > I don't think it is for this working group to answer that question. > > > I do think it is reasonable though for enough basic mechanism to be > > > provided that the ISPs can actually process the packets reasonably > > > though - and I think now that we know enough about how the protocol > > > parts of all this can be made to work (as aside from the operational > > > issues) that it can be done now - and so provide the rationale for > > > actually doing the operational work. > > > > > > Chasing down header chains looking for a transport header certainly > > > isn't the answer (even considering ESP headers as transport for this > > > purpose, which I'm not sure I'd regard as correct anyway). Unlike > > > in IPv4, there's no guarantee that the transport header will even occur > > > in the first fragment of a large packet in IPv6. While it might seem to > > > be folly to send fragmented packets at the IP level and expect any kind > > > of quality of service, with IPv6 it really isn't. If the amount of > > > data that has to be delivered (whether that be transport data, or > > > additional data from extra "headers" is larger) than will fit across the > > > path MTU, then some kind of fragmentation is required. Whether that's > > > done at the IPv6 layer, or at the transport layer (with some kind of > > > segmented messages) doesn't really make any difference - all the pieces > > > need to arrive for the data to be interpreted (that's an assumption). > > > In a scenario like that, it makes perfect sense to use IPv6 fragmentation. > > > And if that's done, the port numbers (or even ESP SPI) might not be in > > > the first fragment. This cannot disqualify the packet from receiving > > > any kind of QoS treatment. With IPv6 there is no need for it to do so > > > either - everything needed to classify the packet is in the IPv6 header > > > (addresses and flow label). That's all routers should be looking at, as > > > it is all that they can reliably expect to actually find (even ignoring the > > > issue of "find quickly"). > > > > > > kre > > > >-- > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > >Brian E Carpenter > >Distinguished Engineer, Internet Standards & Technology, IBM > >On assignment at the IBM Zurich Laboratory, Switzerland > >Board Chairman, Internet Society http://www.isoc.org > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > ------------------------------------ > > Richard A. Carlson e-mail: RACarlson@anl.gov > Network Research Section phone: (630) 252-7289 > Argonne National Laboratory fax: (630) 252-4021 > 9700 Cass Ave. S. > Argonne, IL 60439 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 09:59:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HxLZR000929 for ; Thu, 3 Jan 2002 09:59:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03HxLYm000928 for ipng-dist; Thu, 3 Jan 2002 09:59:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HxIZR000921 for ; Thu, 3 Jan 2002 09:59:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01030 for ; Thu, 3 Jan 2002 09:59:24 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09583 for ; Thu, 3 Jan 2002 10:59:23 -0700 (MST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03HxB8j025136; Thu, 3 Jan 2002 11:59:12 -0600 (CST) Message-ID: <087501c19498$f677a2e0$0100a8c0@RepliGate> From: "Jim Fleming" To: "Keith Moore" , "Brian E Carpenter" Cc: "Michael Thomas" , References: <200201031709.g03H9ii13070@astro.cs.utk.edu> Subject: Re: Flow Label Date: Thu, 3 Jan 2002 12:55:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Keith Moore" To: "Brian E Carpenter" Cc: "Randy Bush" ; "Michael Thomas" ; Sent: Thursday, January 03, 2002 9:09 AM Subject: Re: Flow Label > > Randy, > > > > The proposed new words for 2460 effectively say > > - you don't have to set it > > - you don't have to look at it > > - you mustn't change it > > > > I don't think encourages kludge significantly more than MBZ text, but it > > does allow for future usage. > > as I see it, the proposed words let us get Flow Label off our > plates for now, which is good because we don't know what to do > with it anyway. maybe someday someone wall make a convincing > case for how to use it. for now, other things are probably more > worthy of attetion. > > Keith > -------------------------------------------------------------------- For people that build serious (reliable) networks, outside of the research and academic worlds, those 20 bits will be very useful. They also help to free up (and use) 16 more bytes in the IPv6 Header. In order to fill out the 48 byte ATM payloads, it would be good to have the ability to add up to 8 additional bytes beyond the IPv6 Header. The easiest way to do that is to use 3 bits of the Protocol Field for the extended length, 1-8 and an isolated Protocol value for the case where there are 0 extended bytes. This will yield a 1-24 byte data field in the 48 byte payload. With vPC wide-pipe encoding, those 24 bytes will on average be able to carry about 18 bytes of data from 6 streams (flows). That can be 3 8-bit voice samples, which is not a bad sample rate, and key-strokes and telnet chat can ride in the gaps. The code should only take a few hours to test.... http://www.dot-biz.com/INFO/Papers/VPC/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 10:07:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03I7SZR000946 for ; Thu, 3 Jan 2002 10:07:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03I7RK0000945 for ipng-dist; Thu, 3 Jan 2002 10:07:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03I7OZR000938 for ; Thu, 3 Jan 2002 10:07:24 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02361 for ; Thu, 3 Jan 2002 10:07:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26564 for ; Thu, 3 Jan 2002 10:07:29 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g03I7Ii14740; Thu, 3 Jan 2002 13:07:19 -0500 (EST) Message-Id: <200201031807.g03I7Ii14740@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Steven M. Bellovin" cc: Randy Bush , Keith Moore , Brian E Carpenter , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "Thu, 03 Jan 2002 12:34:07 EST." <20020103173407.D319C7B55@berkshire.research.att.com> Date: Thu, 03 Jan 2002 13:07:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >and, if we do mbz, they can then write the rfc which changes that > > The problem then is all the implementations -- or firewalls -- that > will check that the bits really are zero upon receipt. If you want > MBZ, say "sender MUST set to zero; receiver and middle boxes MUST NOT > check". right. > Then you have to hope that folks listen to that part. Especially for > firewalls, I wouldn't count on that. nor I. but clearly stating that routers and firewalls are supposed to ignore Flow Label is probably the best we can do. Keith p.s. I *wish* we had a mechanism for clearly pointing the finger at intermediaries that cause application failures by violating the specs - it would be so wonderful if an application could say "you aren't receiving any incoming mail because your boneheaded network administrator installed a firewall that won't permit SMTP over TLS traffic to pass" complete with a clickable button that says "Terminate Administrator" (and another that says "...With Extreme Prejudice") -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 10:55:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03It8ZR001084 for ; Thu, 3 Jan 2002 10:55:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03It7JP001083 for ipng-dist; Thu, 3 Jan 2002 10:55:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03It3ZR001076 for ; Thu, 3 Jan 2002 10:55:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16099 for ; Thu, 3 Jan 2002 10:55:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24314 for ; Thu, 3 Jan 2002 11:55:07 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g03Isui15041; Thu, 3 Jan 2002 13:54:57 -0500 (EST) Message-Id: <200201031854.g03Isui15041@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "James Kempf" cc: "Brian E Carpenter" , ipng@sunroof.eng.sun.com, "Richard Carlson" Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] In-reply-to: Your message of "Thu, 03 Jan 2002 09:44:16 PST." <008101c1947e$4395b780$7e6015ac@T23KEMPF> Date: Thu, 03 Jan 2002 13:54:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hum. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 11:01:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03J1mZR001106 for ; Thu, 3 Jan 2002 11:01:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03J1mj3001105 for ipng-dist; Thu, 3 Jan 2002 11:01:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03J1jZR001098 for ; Thu, 3 Jan 2002 11:01:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15864 for ; Thu, 3 Jan 2002 11:01:49 -0800 (PST) Received: from southstation.m5p.com (dsl-209-162-215-52.easystreet.com [209.162.215.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28297 for ; Thu, 3 Jan 2002 12:01:44 -0700 (MST) Received: from m5p.com (localhost [127.0.0.1]) by southstation.m5p.com (8.12.1/8.12.1) with ESMTP id g03J1gdO057741 for ; Thu, 3 Jan 2002 11:01:42 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.1/8.12.1/Submit) id g03J1fJu057738; Thu, 3 Jan 2002 11:01:41 -0800 (PST) Date: Thu, 3 Jan 2002 11:01:41 -0800 (PST) Message-Id: <200201031901.g03J1fJu057738@m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: Flow Label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a quick question from an interested lurker: Are these hums of acquiescence in response, specifically, to the idea that an originating node may set the flow label to any value, and that nodes forwarding packets will leave that value alone? -- George Mitchell -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 11:08:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03J8kZR001180 for ; Thu, 3 Jan 2002 11:08:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03J8kSs001179 for ipng-dist; Thu, 3 Jan 2002 11:08:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03J8hZR001172 for ; Thu, 3 Jan 2002 11:08:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19047 for ; Thu, 3 Jan 2002 11:08:48 -0800 (PST) Received: from pdxpo.dsl-only.net (pdxpo.dsl-only.net [63.105.16.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01598 for ; Thu, 3 Jan 2002 11:08:47 -0800 (PST) Received: from bonfire (unverified [63.105.18.201]) by pdxpo.dsl-only.net (Rockliffe SMTPRA 4.5.4) with SMTP id ; Thu, 3 Jan 2002 11:07:18 -0800 From: "Bill Strahm" To: "Brian E Carpenter" , Subject: RE: Where are the WG chairs when we need them? [was Re: Flow Label] Date: Thu, 3 Jan 2002 11:16:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C348636.DB130121@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'll hum for this... it is a long time coming... By the way, where is the RFC describing the monitoring and counting of hums anyway Please lets not make something more complex than MPLS here Bill -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter Sent: Thursday, January 03, 2002 8:27 AM To: ipng@sunroof.eng.sun.com Subject: Where are the WG chairs when we need them? [was Re: Flow Label] The one acronym summary of kre's point is: SLA. I'd venture to say that no QoS solution will ever work in the absence of an SLA. And guess what, the IETF doesn't discuss business models and SLAs. The most we can do is standardise tools that can be deployed to support SLAs. So, I think it's time for a hum on this one (the simple update to 2460 that Scott and I at least seem to agree on). Brian Robert Elz wrote: > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) > From: Scott Bradner > Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> > > | I do not believe that there is currently any way to deal with the > | *business* and *operational* issues of asking some remote ISP > | to provide QoS service for you in any sort of scalable way > > Yes, that's a real hard problem. But it isn't the current one. > > There are two separate issues here - how to communicate the information, > and then how to use it. > > Now it is certainly true that communicating information is a waste of time > if the information can't be used -- but it is also true that there's no > point figuring out how to use the information if there's no way to communicate > it. > > Since the operational issues are hard, without doubt, there's a certain > reluctance to attempt to find a solution to it - and as long as that can > be avoided by resorting to "we don't need it yet, there'd be no way to use > it anyway", that is what will keep happening. > > But there is a simple solution which can arise - I, as a customer, can work > out what path my packets will take (AS path), make contact with all of the > ISPs represented, and offer to pay them large amounts of cash to make some > specific set of my packets get to some particular destination(s) much more > reliably with much lower than normal (congested) delay. That's easy to do > (assuming the availability of the cash). It can be done today. > > However, assuming I do that, how are all those ISPs supposed to implement > my request? Currently they'd have to do it using port number snooping, > and so I'd have to be able to specify the port numbers in advance. But > that's not always possible, nor is it a rational design in any case (it > just happens to be all that's probably possible with IPv4). With IPv6 > I can simply arrange to label all the "important" packets, so all those > ISPs, who are only too willing to accept the cash, can actually manage to > earn it. > > Now of course, as an operational method, the one above doesn't scale at all. > But that's OK, it doesn't have to - it isn't being proposed as a method > to be adopted by all and sundry. What it has done is provided the > motivation for the mechanism to exist that allows the packet classification > to be reasonable. Given that, the desire to make use of this will grow, > and the operational community will be forced to do the work to figure out > how to make it feasible economically. > > This may end up falling back to explicit agreements between sender > (or receiver) of the data and everyone along the path (as in a credit > card number included in the RSVP reservation packet, or the equivalent) > Or it could be done based on settlements between ISPs, with the ISPs > perhaps using the DSCP in packets passing between them to indicate: > "I am being paid more to achieve better results for this packet, it will > offset as more than a normal packet if you also give it priority" with > most likely, each ISP subtracting a little from the amount offered as > their own compensation, so the sender would need to offer more to get > priority through a long path than through a short one (which is entirely > reasonable). Or it could be something quite different. > > I don't think it is for this working group to answer that question. > I do think it is reasonable though for enough basic mechanism to be > provided that the ISPs can actually process the packets reasonably > though - and I think now that we know enough about how the protocol > parts of all this can be made to work (as aside from the operational > issues) that it can be done now - and so provide the rationale for > actually doing the operational work. > > Chasing down header chains looking for a transport header certainly > isn't the answer (even considering ESP headers as transport for this > purpose, which I'm not sure I'd regard as correct anyway). Unlike > in IPv4, there's no guarantee that the transport header will even occur > in the first fragment of a large packet in IPv6. While it might seem to > be folly to send fragmented packets at the IP level and expect any kind > of quality of service, with IPv6 it really isn't. If the amount of > data that has to be delivered (whether that be transport data, or > additional data from extra "headers" is larger) than will fit across the > path MTU, then some kind of fragmentation is required. Whether that's > done at the IPv6 layer, or at the transport layer (with some kind of > segmented messages) doesn't really make any difference - all the pieces > need to arrive for the data to be interpreted (that's an assumption). > In a scenario like that, it makes perfect sense to use IPv6 fragmentation. > And if that's done, the port numbers (or even ESP SPI) might not be in > the first fragment. This cannot disqualify the packet from receiving > any kind of QoS treatment. With IPv6 there is no need for it to do so > either - everything needed to classify the packet is in the IPv6 header > (addresses and flow label). That's all routers should be looking at, as > it is all that they can reliably expect to actually find (even ignoring the > issue of "find quickly"). > > kre -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 11:52:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03Jq1lJ001488 for ; Thu, 3 Jan 2002 11:52:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g03Jq1gJ001487 for ipng-dist; Thu, 3 Jan 2002 11:52:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03JpvlJ001480 for ; Thu, 3 Jan 2002 11:51:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13488 for ; Thu, 3 Jan 2002 11:52:02 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14995 for ; Thu, 3 Jan 2002 12:53:02 -0700 (MST) Received: from kenawang ([192.168.1.71]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA01333; Thu, 3 Jan 2002 11:50:42 -0800 (PST) Message-Id: <4.2.2.20020103144313.045caa60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Jan 2002 14:51:00 -0500 To: george+ipng@m5p.com From: Margaret Wasserman Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200201031901.g03J1fJu057738@m5p.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi George, Yes, we are "humming" in agreement to the proposal that we replace section 6 of RFC 2460 with the following text: > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to label sets of packets. Nodes that do not support > the Flow Label field MUST set the field to zero when originating a > packet, and MUST ignore the field when receiving a packet. All routers > MUST pass the field on unchanged when forwarding a packet. > > This specification does not further define the meaning of the > Flow Label. > And that we delete Appendix A from RFC 2460. Actually, we probably won't update RFC 2460. We'll probably just publish a separate RFC that updates 2460. Margaret At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: >Just a quick question from an interested lurker: Are these hums of >acquiescence in response, specifically, to the idea that an originating >node may set the flow label to any value, and that nodes forwarding >packets will leave that value alone? -- George Mitchell > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 11:52:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03JqtlJ001505 for ; Thu, 3 Jan 2002 11:52:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g03JqtM0001504 for ipng-dist; Thu, 3 Jan 2002 11:52:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03JqolJ001497 for ; Thu, 3 Jan 2002 11:52:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08453 for ; Thu, 3 Jan 2002 11:52:55 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10613 for ; Thu, 3 Jan 2002 12:52:54 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g03JpUi15349; Thu, 3 Jan 2002 14:51:31 -0500 (EST) Message-Id: <200201031951.g03JpUi15349@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: george+ipng@m5p.com cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "Thu, 03 Jan 2002 11:01:41 PST." <200201031901.g03J1fJu057738@m5p.com> Date: Thu, 03 Jan 2002 14:51:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Just a quick question from an interested lurker: Are these hums of > acquiescence in response, specifically, to the idea that an originating > node may set the flow label to any value, and that nodes forwarding > packets will leave that value alone? -- George Mitchell not quite. if we someday define how the flow label is to be used, originating nodes can follow that spec. that's not the same thing as saying that originating nodes can set the flow label field to whatever value they like. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 11:54:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03JsIlJ001522 for ; Thu, 3 Jan 2002 11:54:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g03JsIs8001521 for ipng-dist; Thu, 3 Jan 2002 11:54:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03JsFlJ001514 for ; Thu, 3 Jan 2002 11:54:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28312 for ; Thu, 3 Jan 2002 11:54:19 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04988 for ; Thu, 3 Jan 2002 12:54:01 -0700 (MST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03JsEJk004325; Thu, 3 Jan 2002 13:54:15 -0600 (CST) Message-ID: <090b01c194a9$09229610$0100a8c0@RepliGate> From: "Jim Fleming" To: "Brian E Carpenter" , References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <3C348636.DB130121@hursley.ibm.com> Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] Date: Thu, 3 Jan 2002 14:50:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Thursday, January 03, 2002 8:26 AM Subject: Where are the WG chairs when we need them? [was Re: Flow Label] > The one acronym summary of kre's point is: SLA. I'd venture > to say that no QoS solution will ever work in the absence of > an SLA. And guess what, the IETF doesn't discuss business > models and SLAs. The most we can do is standardise tools > that can be deployed to support SLAs. > That would be handled by your Multi-Level-Marketing (MLM) sales team ? http://aso.icann.org/meetings/ac/ac-20012105.html attendees from 16 countries were present, 55 emerging clients, 5 guests (Andrew McLaughlin, John Crain, Axel Pawlik, Ray Plzak, Andrea Caro). The agend was as follows: a. IPv6 Tutorial ---- Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 12:08:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03K8LlJ001567 for ; Thu, 3 Jan 2002 12:08:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g03K8Lpo001566 for ipng-dist; Thu, 3 Jan 2002 12:08:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03K8HlJ001559 for ; Thu, 3 Jan 2002 12:08:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11468 for ; Thu, 3 Jan 2002 12:08:22 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19319 for ; Thu, 3 Jan 2002 12:08:21 -0800 (PST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03K7wJk009043; Thu, 3 Jan 2002 14:07:59 -0600 (CST) Message-ID: <092d01c194aa$f4433180$0100a8c0@RepliGate> From: "Jim Fleming" To: "Keith Moore" , Cc: References: <200201031951.g03JpUi15349@astro.cs.utk.edu> Subject: Re: Flow Label Date: Thu, 3 Jan 2002 15:04:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Keith Moore" To: Cc: Sent: Thursday, January 03, 2002 11:51 AM Subject: Re: Flow Label > > Just a quick question from an interested lurker: Are these hums of > > acquiescence in response, specifically, to the idea that an originating > > node may set the flow label to any value, and that nodes forwarding > > packets will leave that value alone? -- George Mitchell > > not quite. if we someday define how the flow label is to be used, > originating nodes can follow that spec. that's not the same thing > as saying that originating nodes can set the flow label field to > whatever value they like. > Originating nodes can always set any values to anything they want. The consensus of the nodes in the network then works to process what the originating node sets the values to, and the result is observed. Some people may or may not change the way they set the values, based on the observed results. In summary, people will route around the damage and gravitate to solutions that work. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 15:05:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03N5nNg002015 for ; Thu, 3 Jan 2002 15:05:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g03N5nqp002014 for ipng-dist; Thu, 3 Jan 2002 15:05:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03N5kNg002007 for ; Thu, 3 Jan 2002 15:05:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22437 for ; Thu, 3 Jan 2002 15:05:51 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04665 for ; Thu, 3 Jan 2002 16:06:53 -0700 (MST) Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03N5f0F009129; Thu, 3 Jan 2002 17:05:42 -0600 (CST) Message-ID: <09e501c194c3$c806b1a0$0100a8c0@RepliGate> From: "Jim Fleming" To: , References: <200201031901.g03J1fJu057738@m5p.com> Subject: Re: Flow Label Date: Thu, 3 Jan 2002 18:01:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: To: Sent: Thursday, January 03, 2002 11:01 AM Subject: Flow Label > Just a quick question from an interested lurker: Are these hums of > acquiescence in response, specifically, to the idea that an originating > node may set the flow label to any value, and that nodes forwarding > packets will leave that value alone? -- George Mitchell > Keep in mind that there is not really a 20-bit Flow Label. Go read the code. The BSD code is a common reference. What you really have is a 64-bit "control field" and that is broken into a 32-bit flow, and another 32 bit field that has a 16-bit length, 8-bit Protocol, and 8-bit TTL. The 32-bit flow has 4-bits of Version, 8-bits of TOS, and ???? The ???? is alignment to the 32-bit boundary, it happens to be 20 bits. The code should be easy to fix up to make something more useful. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 16:14:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g040EdNg002062 for ; Thu, 3 Jan 2002 16:14:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g040Edsu002061 for ipng-dist; Thu, 3 Jan 2002 16:14:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g040EaNg002054 for ; Thu, 3 Jan 2002 16:14:36 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19167 for ; Thu, 3 Jan 2002 16:14:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25850 for ; Thu, 3 Jan 2002 16:14:40 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA25746; Thu, 3 Jan 2002 16:14:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g040Eek22156; Thu, 3 Jan 2002 16:14:40 -0800 X-mProtect: Thu, 3 Jan 2002 16:14:40 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdA2BOqd; Thu, 03 Jan 2002 16:14:37 PST Message-Id: <4.3.2.7.2.20020103161323.0272e488@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jan 2002 16:13:52 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft IPv6 Working Group minutes Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft minutes from the IPv6 sessions at the Salt Lake City IETF are available at: http://playground.sun.com/pub/ipng/html/minutes/ipv6-minutes-dec2001.txt Presentations are available at: http://playground.sun.com/ipng/meetings.html Please send me comments and corrections. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 3 22:50:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g046ohNg002496 for ; Thu, 3 Jan 2002 22:50:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g046ohrw002495 for ipng-dist; Thu, 3 Jan 2002 22:50:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g046odNg002488 for ; Thu, 3 Jan 2002 22:50:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20391 for ; Thu, 3 Jan 2002 22:50:44 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05480 for ; Thu, 3 Jan 2002 22:50:43 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:38b9:10d9:71fd:9f10]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g046of329151 for ; Fri, 4 Jan 2002 15:50:41 +0900 (JST) Date: Fri, 04 Jan 2002 15:51:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: References: <200112181820.KAA08787@feller.mentat.com> <3C20DD00.1C8D1AA8@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 54 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 20 Dec 2001 14:34:24 +0900, >>>>> JINMEI Tatuya said: > In summary, I'd still support the 03 behavior if we had to choose one. > However, since the usage of receiving the optional info on TCP sockets > is relatively a minor issue, I'm okay with leaving it unspecified if > we cannot reach consensus. There has been no opinion on this, so I'd like to revise the draft with making the TCP implication section unspecified. I'll make the revise version next week. If you have a strong objection on this decision, please speak up now. (For those who are interested but forgot the context) here is a brief summary so far: We have 3 options on how to get optional information (such as extension headers) of incoming TCP segments; (a) use recvmsg() + ancillary data (as defined in rfc2292bis-02 and before), (b) use a separate getsockopt (as defined in rfc2292bis-03), and (c) not to specify a particular mechanism. In the very old discussion, there were two reasons for the option (a): (1) not to overload the semantics of IPV6_HOPOPTS, IPV6_DSTOPTS, ... (2) to provide a uniform interface for TCP and others The reason (1) is actually not essential to the option (a). This can be achieved by separating IPV6_xxx and IPV6_RECVxxx. (2) is controversial. Someone says the uniform behavior is important, while someone says using most application programmers are not familiar with using recvmsg() on TCP sockets...etc. Meanwhile, there is actually no usage of receiving the optional information on TCP sockets. And, actually, we cannot expect to use the information just like on UDP/raw sockets (e.g. for access control), and some information such as the destination address is meaningless for TCP sockets. The lack of usage also means that backward compatibility to existing implementations does not matter (much), so we can basically take either approach. However, we could not reach consensus on a particular behavior, and the comparison between (a) and (b) was quite controversial (someone said (a) is simpler, while some other guy said (b) is simpler, etc.) With the fact of the lack of usage and consensus on a particular behavior, I believe the best current approach is to just leave this mechanism unspecified. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 01:40:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g049elNg002649 for ; Fri, 4 Jan 2002 01:40:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g049elMi002648 for ipng-dist; Fri, 4 Jan 2002 01:40:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g049eiNg002641 for ; Fri, 4 Jan 2002 01:40:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19187 for ; Fri, 4 Jan 2002 01:40:49 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA04032 for ; Fri, 4 Jan 2002 02:41:51 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id KAA09824; Fri, 4 Jan 2002 10:40:46 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59814 from ; Fri, 4 Jan 2002 10:40:44 +0100 Message-Id: <3C35789C.5C695FF7@hursley.ibm.com> Date: Fri, 04 Jan 2002 10:40:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Charles E. Perkins" Cc: ipng@sunroof.eng.sun.com Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <3C348636.DB130121@hursley.ibm.com> <3C348EA6.65D2D415@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, Theft of service by spoofing the flow label seems to be the same risk as theft of service by spoofing the DSCP. That is discussed in RFC 2474 and RFC 2475 and I imagine the considerations are just about the same. Brian "Charles E. Perkins" wrote: > > Hello Brian et.al., > > Brian E Carpenter wrote: > > > The one acronym summary of kre's point is: SLA. I'd venture > > to say that no QoS solution will ever work in the absence of > > an SLA. And guess what, the IETF doesn't discuss business > > models and SLAs. The most we can do is standardise tools > > that can be deployed to support SLAs. > > > > So, I think it's time for a hum on this one (the simple > > update to 2460 that Scott and I at least seem to agree > > on). > > Although I have not participated in this discussion, I have > followed it closely. I like the simple update to 2460 that you > folks seem to have agreed on, but I also believe that workable > solutions can be made that do NOT necessarily depend on SLAs. > > As a separate point, however, I would like to raise another > issue. Let's say that the flow label enables some way to > distinguish a packet flow for special or faster processing. > A malicious node could insert packets with the flow label, > possibly causing the traffic conditioner on the receiving > end to flag an exception and disrupt further traffic to the > destination. This could happen, right? This isn't any worse > than a lot of other problems that would come up a long time > before flow-label impersonation, but I wondered whether there > had been discussion about it. > > Regards, > Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 01:43:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g049hRNg002666 for ; Fri, 4 Jan 2002 01:43:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g049hQTJ002665 for ipng-dist; Fri, 4 Jan 2002 01:43:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g049hNNg002658 for ; Fri, 4 Jan 2002 01:43:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19308 for ; Fri, 4 Jan 2002 01:43:28 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA04926 for ; Fri, 4 Jan 2002 02:44:32 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id KAA07040; Fri, 4 Jan 2002 10:43:25 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56032 from ; Fri, 4 Jan 2002 10:43:24 +0100 Message-Id: <3C35793C.CB24C2B6@hursley.ibm.com> Date: Fri, 04 Jan 2002 10:43:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Where are the WG chairs when we need them? [was Re: FlowLabel] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <4.2.2.20020103112950.045b4320@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > >So, I think it's time for a hum on this one (the simple > >update to 2460 that Scott and I at least seem to agree > >on). > > Hum. > > Could someone publish an internet draft with this wording? > The only draft that we have now is pretty far away from this. Good point. What we need is a short simple draft to update 2460, independent of draft-rajahalme- . Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 02:41:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04AfqNg002698 for ; Fri, 4 Jan 2002 02:41:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04AfqpN002697 for ipng-dist; Fri, 4 Jan 2002 02:41:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04AfnNg002690 for ; Fri, 4 Jan 2002 02:41:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25000 for ; Fri, 4 Jan 2002 02:41:54 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01974 for ; Fri, 4 Jan 2002 03:41:53 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA09954; Fri, 4 Jan 2002 11:41:51 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20146 from ; Fri, 4 Jan 2002 11:41:49 +0100 Message-Id: <3C3586EE.9B8D002A@hursley.ibm.com> Date: Fri, 04 Jan 2002 11:41:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: george+ipng@m5p.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <4.2.2.20020103144313.045caa60@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And, truth in advertising, we have heard two dissenting views: a) that the field should be defined as MUST BE ZERO, i.e. the MAY clause below gets deleted b) that the 3rd MUST should be SHOULD, i.e. immutability should be default instead of mandatory. Brian Margaret Wasserman wrote: > > Hi George, > > Yes, we are "humming" in agreement to the proposal that we > replace section 6 of RFC 2460 with the following text: > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to label sets of packets. Nodes that do not support > > the Flow Label field MUST set the field to zero when originating a > > packet, and MUST ignore the field when receiving a packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > > > This specification does not further define the meaning of the > > Flow Label. > > > > And that we delete Appendix A from RFC 2460. > > Actually, we probably won't update RFC 2460. We'll probably > just publish a separate RFC that updates 2460. > > Margaret > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > >Just a quick question from an interested lurker: Are these hums of > >acquiescence in response, specifically, to the idea that an originating > >node may set the flow label to any value, and that nodes forwarding > >packets will leave that value alone? -- George Mitchell > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 05:19:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04DJqNg002803 for ; Fri, 4 Jan 2002 05:19:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04DJqLA002802 for ipng-dist; Fri, 4 Jan 2002 05:19:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04DJnNg002795 for ; Fri, 4 Jan 2002 05:19:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12297 for ; Fri, 4 Jan 2002 05:19:54 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16530 for ; Fri, 4 Jan 2002 06:19:32 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g04DHuL00882; Fri, 4 Jan 2002 20:17:58 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Margaret Wasserman , george+ipng@m5p.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <3C3586EE.9B8D002A@hursley.ibm.com> References: <3C3586EE.9B8D002A@hursley.ibm.com> <4.2.2.20020103144313.045caa60@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 20:17:56 +0700 Message-ID: <880.1010150276@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 Jan 2002 11:41:50 +0100 From: Brian E Carpenter Message-ID: <3C3586EE.9B8D002A@hursley.ibm.com> | b) that the 3rd MUST should be SHOULD, i.e. immutability should | be default instead of mandatory. I'm not sure I believe the 100% immutable argument, but I certainly wouldn't deviate from it that far. That is, I'd keep it at MUST with just a very precise exception (which amounts to when the sender has specifically notified the router that the field may be changed). I'm pretty sure I'd never want to actually use the exception, except possibly to explicitly say "Do what you like" (or if you like, "this field isn't being used") - but I can't see what harm would be done by leaving that small exception available. In practical cases, explicitly notifying routers about specific flows where the label may be altered is most likely too difficult to ever happen, so this would probably just amount to allowing a single router to change the field from a sender's explicit "I don't care" into some other value. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 07:04:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04F4qNg002900 for ; Fri, 4 Jan 2002 07:04:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04F4qOO002899 for ipng-dist; Fri, 4 Jan 2002 07:04:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04F4nNg002892 for ; Fri, 4 Jan 2002 07:04:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04107 for ; Fri, 4 Jan 2002 07:04:52 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23304 for ; Fri, 4 Jan 2002 08:04:52 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id KAA11350; Fri, 4 Jan 2002 10:07:25 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id KAA00506; Fri, 4 Jan 2002 10:07:25 -0500 Message-ID: <3C35C4F8.3C9B290D@txc.com> Date: Fri, 04 Jan 2002 10:06:32 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Where are the WG chairs when we need them? [was Re: FlowLabel] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <4.2.2.20020103112950.045b4320@mail.windriver.com> <3C35793C.CB24C2B6@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1D1B25D8D73BD95D30456695" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms1D1B25D8D73BD95D30456695 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, In fact, Jarno, who took vacation around the holidays, promised to work on a new WG flow label draft immediately on his return. So we will have that, and everything is going to come out in one package (you are a co-author). Alex Brian E Carpenter wrote: > > Margaret Wasserman wrote: > > > > >So, I think it's time for a hum on this one (the simple > > >update to 2460 that Scott and I at least seem to agree > > >on). > > > > Hum. > > > > Could someone publish an internet draft with this wording? > > The only draft that we have now is pretty far away from this. > > Good point. What we need is a short simple draft to update > 2460, independent of draft-rajahalme- . > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms1D1B25D8D73BD95D30456695 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMDQxNTA2MzRaMCMGCSqGSIb3DQEJ BDEWBBQw04WYZ/bMgpq3OZm1aeJInZf5VjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgGefNRoMtAs/0TzdcVQocYdF4XRkRySd/F8iomCFw8RmZuJG 75GJhBgIi5WxJ+k7KeG5/Wf1SC6jA90l1JpTz3crNsr8AqULJQbhb25UTX4H/fVll4sIJ/qf eNxKtRE4vJN2iMqss//eNt7E0tdoufluwUp2Fh8xvuhqEn/P3tEW --------------ms1D1B25D8D73BD95D30456695-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 07:35:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FZrNg002948 for ; Fri, 4 Jan 2002 07:35:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04FZrMA002947 for ipng-dist; Fri, 4 Jan 2002 07:35:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FZoNg002940 for ; Fri, 4 Jan 2002 07:35:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08433 for ; Fri, 4 Jan 2002 07:35:54 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01908 for ; Fri, 4 Jan 2002 08:35:53 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MWNq-000OLS-00; Fri, 04 Jan 2002 07:35:50 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <4.2.2.20020103144313.045caa60@mail.windriver.com> <3C3586EE.9B8D002A@hursley.ibm.com> Message-Id: Date: Fri, 04 Jan 2002 07:35:50 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And, truth in advertising, we have heard two dissenting > views: > > a) that the field should be defined as MUST BE ZERO, i.e. > the MAY clause below gets deleted fwiw, i withdraw my dissent randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 07:37:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FbmNg002973 for ; Fri, 4 Jan 2002 07:37:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04FbmqN002972 for ipng-dist; Fri, 4 Jan 2002 07:37:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FbfNg002957; Fri, 4 Jan 2002 07:37:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29503; Fri, 4 Jan 2002 07:37:44 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25751; Fri, 4 Jan 2002 08:38:47 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04Fbdb12345; Fri, 4 Jan 2002 16:37:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA03449; Fri, 4 Jan 2002 16:37:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g04FbdQ03170; Fri, 4 Jan 2002 16:37:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-reply-to: Your message of Wed, 26 Dec 2001 21:38:53 +0200. <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> Date: Fri, 04 Jan 2002 16:37:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: However, I'm concerned about the "applied allover" part. Specifically - while I'm very much fond of the AAA solutions - I'm concerned whether we can expect all parts of the Internet to have an infrastructure that really can figure out the home addresses. What if there's a coin-operated (or Visa-) airport WLAN? => this is a problem of trust in the local/visited domain *and* in the remote/home domain. In your example if I understand the issue is the lack of trust in the local/visited domain, so one may reject traffic with home address options from it. Finally, I seem to remember there was a discussion a long time ago whether we could somehow provide automatic, mandatory, ingress filtering in IPv6. => my concern is that the "mandatory" term in a RFC is not enough to enforce it in the real world. Currently, we are headed towards the same situation as in IPv4 where ingress filtering is only partially applied, and we keep coming up with "patch" solutions such as I-trace to help the situation. => ingress filtering has more problems with IPv4, mainly because it was not considered from the beginning. But it is already a BCP and it seems that most ISPs use it (feedback from ISPs please). Interestingly, these solutions typically need changes to a large fraction of the routers in the Internet which we already are doing anyway to move to IPv6... => we can expect to avoid the same errors with IPv6. Unfortunately ingress filtering (like network management) is something where IPv6 is not yet at the same level than for IPv4 today. We hope this situation will be improved very fast. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 07:57:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FvGNg003136 for ; Fri, 4 Jan 2002 07:57:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04FvFi3003135 for ipng-dist; Fri, 4 Jan 2002 07:57:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FvCNg003128; Fri, 4 Jan 2002 07:57:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11153; Fri, 4 Jan 2002 07:57:17 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01410; Fri, 4 Jan 2002 08:56:57 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g04FvEU25373; Fri, 4 Jan 2002 17:57:14 +0200 Date: Fri, 4 Jan 2002 17:57:13 +0200 (EET) From: Pekka Savola To: cc: Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 4 Jan 2002, Francis Dupont wrote: > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). Feedback you get here does *not* reflect to the real world -- those who work around here, are usually even a little conscientious. The problem is the ignorant and the uncaring. FWIW, we provide connectivity for every university and the like in Finland, and they're all ingress-filtered at ISP-organization border. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 08:04:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04G4CNg003268 for ; Fri, 4 Jan 2002 08:04:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04G4C3h003267 for ipng-dist; Fri, 4 Jan 2002 08:04:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04G45Ng003251; Fri, 4 Jan 2002 08:04:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03625; Fri, 4 Jan 2002 08:04:09 -0800 (PST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14157; Fri, 4 Jan 2002 08:04:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id g04G45F30252; Fri, 4 Jan 2002 11:04:05 -0500 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access References: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> From: stanislav shalunov Date: 04 Jan 2002 11:04:01 -0500 In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> Message-ID: <871yh6gl1q.fsf@cain.internet2.edu> Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > => ingress filtering has more problems with IPv4, mainly because it > was not considered from the beginning. But it is already a BCP and > it seems that most ISPs use it (feedback from ISPs please). With IPv4, Abilene (and most large R&E networks I am familiar with), don't do ingress filtering because of problems with multihoming. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ A fool's brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education. -- G. B. Shaw -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 08:12:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GCmNg003316 for ; Fri, 4 Jan 2002 08:12:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04GCmTr003315 for ipng-dist; Fri, 4 Jan 2002 08:12:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GCfNg003300; Fri, 4 Jan 2002 08:12:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27700; Fri, 4 Jan 2002 08:12:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11029; Fri, 4 Jan 2002 09:12:26 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04GCab14846; Fri, 4 Jan 2002 17:12:36 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA04118; Fri, 4 Jan 2002 17:12:36 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g04GCaQ03314; Fri, 4 Jan 2002 17:12:36 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201041612.g04GCaQ03314@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 27 Dec 2001 14:38:10 +0200. Date: Fri, 04 Jan 2002 17:12:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: About section 2 on Correspondent Nodes; could you elaborate in the document why exactly solution is too drastic? => because this gives no choice between bidirectional tunnel and route optimization, so in some cases mobile IPv6 becomes far less attractive. The real impact depends on how mobile IPv6 is used, in fact one can argue that bidirectional tunnels are enough, but I don't believe that mobile-ip list members will agree... Note that BCE check is not the only way to ensure legitimity of HAO: if it's secured by AH, it's ok; if some SUCV/.. weak authentication method is used, it's probably also ok; the same might even apply to return routability. It's too early to crush CN solutions. => these CN solutions have the same cost than full routing optimization, so I consider them as BCE check variants. (I think the solution for HAO should most likely consist of two separate, "strong-enough" layers, one mandated at CN, one possible at firewalls, but that's not the topic of this draft). => one mandated at CN == no third choice. Note: it seems every site, even if it had only a few MN's, will have to have AAA infrastructure, so that it could interact, certify etc. home address use for remote AAA systems when MN goes roaming and there's a need to punch a hole in ingress filtering of remote sites. => I don't know if the "remote sites" are home sites (sites with home agents) or correspondent sites (sites with correspondent nodes). In the last case the only issue is the iDDoS because both care-of and home addresses are external. In the first case one can rely on home registrations (which have to be strongly secured) in order to understand what happens (and what HAO are valid), in fact this is just remote network access control (in AAA terms this can be done directly (IKE with certificate for instance) or (better because simpler) using the local/visited AAA system as a mediator, note the issue is for first home registrations because they have to create security contexts). (If this is the approach for security, it should be required in the main MIPv6 draft). => I disagree, the iDDoS security threat is not a major one because ingress filtering is not really mandatory. The purpose of my draft is not to fill the hole, it is to get back the previous (i.e. before HAO) situation. Or have I missed something? This seems unnecessary in many environments, e.g. university campus area WLAN or company's internal network. => this depends on where are the visited, home and correspondent domains. For an university campus area WLAN home agents are in campus area too so a bidirectional tunnel with a good local security seems enough (i.e. visited domain = home domain with home agents in the path between MNs and CNs). In a company internal network all three domains are the same so there is no security problems as soon as basic security (i.e. no physical intruders) is enforced. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 08:53:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GrHNg003664 for ; Fri, 4 Jan 2002 08:53:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04GrH5t003663 for ipng-dist; Fri, 4 Jan 2002 08:53:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GrBNg003648; Fri, 4 Jan 2002 08:53:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12002; Fri, 4 Jan 2002 08:53:15 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28064; Fri, 4 Jan 2002 09:54:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04GrAb19477; Fri, 4 Jan 2002 17:53:10 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA04760; Fri, 4 Jan 2002 17:53:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g04Gr9Q03466; Fri, 4 Jan 2002 17:53:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201041653.g04Gr9Q03466@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 03 Jan 2002 11:32:05 +0200. <3C342515.10904@nomadiclab.com> Date: Fri, 04 Jan 2002 17:53:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. => this is not exactly I propose, my idea is: - to do better ingress filtering based on AAA for sites where there are some mobile nodes (aka visited sites). - to do better anti-spoofing filtering for sites from where some mobile nodes are (aka home sites). There is no constraint on sites where are the regular correspondent nodes (aka correspondent domains) which should be the vast majority of sites. I don't know how this is done everywhere but in many sites I can see a special network for nomadic nodes with special network access control and small priviledges just because by definition local network managers have not the control of them, so IMHO this is not unrealistic to ask to sites which welcome mobile nodes to have a responsible attitude towards security. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. => this is exactly what we don't like... Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) => this is very unrealistic because this forgets the third letter of AAA. And of course this doesn't go well with the responsible use of the network principle. Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. => note that the use of reflectors (i.e. iDDoS) makes the number of primary attackers less important. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, => the solution in this case is just to filter out HAO, i.e. to refuse mobile nodes. or AAA at all. => in the case of home users AAA is used by ISPs. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. => this is more a DDoS vs ingress filtering topics... Don't forget that my idea is not to fill the hole but to get back the previous situation, i.e. to make ingress filtering a reply to the DDoS threat again. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 09:16:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HG9Ng003809 for ; Fri, 4 Jan 2002 09:16:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04HG98u003808 for ipng-dist; Fri, 4 Jan 2002 09:16:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HG6Ng003801; Fri, 4 Jan 2002 09:16:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19028; Fri, 4 Jan 2002 09:16:11 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24218; Fri, 4 Jan 2002 10:15:52 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g04HFZw22070; Fri, 4 Jan 2002 09:15:36 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP61420; Fri, 4 Jan 2002 09:15:23 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11717; Fri, 4 Jan 2002 09:15:56 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15413.58187.884431.562406@thomasm-u1.cisco.com> Date: Fri, 4 Jan 2002 09:15:55 -0800 (PST) To: Francis Dupont Cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> References: <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I sure hope that nobody's making the assumption that you need to be a mobile node to send BU's and/or HAO's. My provider doesn't care diddly squat about any of this, nor is it likely that if I tunnel to the 6bone they're going to care much either. If this is your only line of defense of protecting CN's from senders of malicious HAO's, I'm pretty skeptical. RPF checks "work" mainly because they are so painless for ISP's to implement. Anything beyond that is likely to be a complete non-starter. Mike Francis Dupont writes: > In your previous mail you wrote: > > However, I'm concerned about the "applied allover" > part. Specifically - while I'm very much fond of the AAA solutions - > I'm concerned whether we can expect all parts of the Internet to have > an infrastructure that really can figure out the home addresses. What > if there's a coin-operated (or Visa-) airport WLAN? > > => this is a problem of trust in the local/visited domain *and* in the > remote/home domain. In your example if I understand the issue is the lack > of trust in the local/visited domain, so one may reject traffic with > home address options from it. > > Finally, I seem to remember there was a discussion a long time ago whether > we could somehow provide automatic, mandatory, ingress filtering in IPv6. > > => my concern is that the "mandatory" term in a RFC is not enough to > enforce it in the real world. > > Currently, we are headed towards the same situation as in IPv4 > where ingress filtering is only partially applied, and we keep coming > up with "patch" solutions such as I-trace to help the situation. > > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). > > Interestingly, these solutions typically need changes to a large > fraction of the routers in the Internet which we already are doing > anyway to move to IPv6... > > => we can expect to avoid the same errors with IPv6. Unfortunately > ingress filtering (like network management) is something where IPv6 > is not yet at the same level than for IPv4 today. We hope this situation > will be improved very fast. > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 09:33:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HXMNg003994 for ; Fri, 4 Jan 2002 09:33:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04HXMdK003993 for ipng-dist; Fri, 4 Jan 2002 09:33:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HXHNg003975 for ; Fri, 4 Jan 2002 09:33:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12984 for ; Fri, 4 Jan 2002 09:33:22 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16139 for ; Fri, 4 Jan 2002 10:34:25 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA02143; Fri, 4 Jan 2002 09:33:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g04HXKO20195; Fri, 4 Jan 2002 09:33:20 -0800 X-mProtect: Fri, 4 Jan 2002 09:33:20 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdabeGEn; Fri, 04 Jan 2002 09:33:07 PST Message-ID: <3C35E74F.40A490D7@iprg.nokia.com> Date: Fri, 04 Jan 2002 09:33:03 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <4.2.2.20020103144313.045caa60@mail.windriver.com> <3C3586EE.9B8D002A@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Brian, Brian E Carpenter wrote: > > And, truth in advertising, we have heard two dissenting > views: > > a) that the field should be defined as MUST BE ZERO, i.e. > the MAY clause below gets deleted I would say that MAY is a lot better. It suggests the truth, which is that people are going to try to figure out ways to use the flow label. It also motivates immutability. Otherwise, it is possible that some router vendors could simply zero out the field -- if it MUST BE ZERO, then zeroing it preserves immutability... We wouldn't want that. > b) that the 3rd MUST should be SHOULD, i.e. immutability should > be default instead of mandatory. Any future technique for using the flow label would, if it violates immutability, be viewed as obsoleting this part of the specification anyway. So I would hope for a MUST here. Language suggesting that it is merely the default would allow for a tunable know in the user interface labeled thusly: "Flow Label treatment (default: do not change): " to be filled in by the system administrator. Possible other values selectable by the operator could be "randomize", "ones-complement", "store current time", ... (?). I don't know why anyone would do this, but I think we ought to be pretty clear about prohibiting it at least for now. Regards, Charlie P. > > Brian > > Margaret Wasserman wrote: > > > > Hi George, > > > > Yes, we are "humming" in agreement to the proposal that we > > replace section 6 of RFC 2460 with the following text: > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > source to label sets of packets. Nodes that do not support > > > the Flow Label field MUST set the field to zero when originating a > > > packet, and MUST ignore the field when receiving a packet. All routers > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > This specification does not further define the meaning of the > > > Flow Label. > > > > > > > And that we delete Appendix A from RFC 2460. > > > > Actually, we probably won't update RFC 2460. We'll probably > > just publish a separate RFC that updates 2460. > > > > Margaret > > > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > > >Just a quick question from an interested lurker: Are these hums of > > >acquiescence in response, specifically, to the idea that an originating > > >node may set the flow label to any value, and that nodes forwarding > > >packets will leave that value alone? -- George Mitchell > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 09:40:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HekNg004030 for ; Fri, 4 Jan 2002 09:40:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04Hekdl004029 for ipng-dist; Fri, 4 Jan 2002 09:40:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HegNg004022 for ; Fri, 4 Jan 2002 09:40:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22039 for ; Fri, 4 Jan 2002 09:40:47 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08005 for ; Fri, 4 Jan 2002 10:40:47 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA02493; Fri, 4 Jan 2002 09:40:46 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g04HekJ30192; Fri, 4 Jan 2002 09:40:46 -0800 X-mProtect: Fri, 4 Jan 2002 09:40:46 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmSQjqL; Fri, 04 Jan 2002 09:40:44 PST Message-ID: <3C35E91D.37D93CC1@iprg.nokia.com> Date: Fri, 04 Jan 2002 09:40:45 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Oops! Typo! Re: Flow Label References: <4.2.2.20020103144313.045caa60@mail.windriver.com> <3C3586EE.9B8D002A@hursley.ibm.com> <3C35E74F.40A490D7@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Typo alert in my last message: "Charles E. Perkins" wrote: > ... So I would hope for a MUST here. Language suggesting that > it is merely the default would allow for a tunable know in the user knob > interface labeled thusly: ... Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 09:51:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HphNg004047 for ; Fri, 4 Jan 2002 09:51:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04HphHl004046 for ipng-dist; Fri, 4 Jan 2002 09:51:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HpeNg004039 for ; Fri, 4 Jan 2002 09:51:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04285 for ; Fri, 4 Jan 2002 09:51:45 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11001 for ; Fri, 4 Jan 2002 10:51:45 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id MAA29173; Fri, 4 Jan 2002 12:51:42 -0500 (EST) From: "Subrata Goswami" To: "Charles E. Perkins" Cc: Subject: RE: Flow Label Date: Fri, 4 Jan 2002 09:55:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3C35E74F.40A490D7@iprg.nokia.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The wording for immutability aside, to really enforce immutability of the Flow Label , there must be a mechanism to verify that the Flow Label has not been changed. As can be seen from the ICV computation for IPv6 (RFC2402) even AH considers Flow label to be mutable. Hence there needs to be a new IPv6 header option for Flow Label immutability. 3.3.3.1.2 ICV Computation for IPv6 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header) Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Charles E. Perkins Sent: Friday, January 04, 2002 9:33 AM To: Brian E Carpenter Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com Subject: Re: Flow Label Hello Brian, Brian E Carpenter wrote: > > And, truth in advertising, we have heard two dissenting > views: > > a) that the field should be defined as MUST BE ZERO, i.e. > the MAY clause below gets deleted I would say that MAY is a lot better. It suggests the truth, which is that people are going to try to figure out ways to use the flow label. It also motivates immutability. Otherwise, it is possible that some router vendors could simply zero out the field -- if it MUST BE ZERO, then zeroing it preserves immutability... We wouldn't want that. > b) that the 3rd MUST should be SHOULD, i.e. immutability should > be default instead of mandatory. Any future technique for using the flow label would, if it violates immutability, be viewed as obsoleting this part of the specification anyway. So I would hope for a MUST here. Language suggesting that it is merely the default would allow for a tunable know in the user interface labeled thusly: "Flow Label treatment (default: do not change): " to be filled in by the system administrator. Possible other values selectable by the operator could be "randomize", "ones-complement", "store current time", ... (?). I don't know why anyone would do this, but I think we ought to be pretty clear about prohibiting it at least for now. Regards, Charlie P. > > Brian > > Margaret Wasserman wrote: > > > > Hi George, > > > > Yes, we are "humming" in agreement to the proposal that we > > replace section 6 of RFC 2460 with the following text: > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > source to label sets of packets. Nodes that do not support > > > the Flow Label field MUST set the field to zero when originating a > > > packet, and MUST ignore the field when receiving a packet. All routers > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > This specification does not further define the meaning of the > > > Flow Label. > > > > > > > And that we delete Appendix A from RFC 2460. > > > > Actually, we probably won't update RFC 2460. We'll probably > > just publish a separate RFC that updates 2460. > > > > Margaret > > > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > > >Just a quick question from an interested lurker: Are these hums of > > >acquiescence in response, specifically, to the idea that an originating > > >node may set the flow label to any value, and that nodes forwarding > > >packets will leave that value alone? -- George Mitchell > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 10:10:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IAKNg004085 for ; Fri, 4 Jan 2002 10:10:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04IAKII004084 for ipng-dist; Fri, 4 Jan 2002 10:10:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IAHNg004077; Fri, 4 Jan 2002 10:10:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21587; Fri, 4 Jan 2002 10:10:22 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28578; Fri, 4 Jan 2002 10:10:21 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id A9473A; Fri, 4 Jan 2002 20:10:53 +0200 (EET) Message-ID: <3C35F009.6020202@nomadiclab.com> Date: Fri, 04 Jan 2002 20:10:17 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access References: <200201041653.g04Gr9Q03466@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I wrote: >> The draft is quite nice, thanks for writing it. There are a few problems, >> though, that I see. Firstly, I really do find it unrealistic to assume >> that each and every site in the world would understand AAA, and change their >> ingress filtering rules based on AAA information. Francis Dupont wrote: > => this is not exactly I propose, my idea is: > - to do better ingress filtering based on AAA for sites where there are > some mobile nodes (aka visited sites). Why do you assume that AAA would be used everywhere where there are mobile nodes? For example, if I am visiting with my friends at their place, why couldn't I just use their private WLAN to connect my wireless PDA to the Internet? If I could not use their private WLAN, I would consider that as a flaw in the design if the Internet. Similarily, our local university campus provides open WLAN for anyone, for anyone to connect to the Internet. It is so much simpler to run these kinds of networks without any kinds of authentication that they will continue to exist, even though many current open WLAN networks may turn into requiring some kind of authentication. But even when they start to require authentication and/or authorization, that authentication or authorization is more likely to be based on 802.1x or PANA than AAA, and even if RADIUS/DIAMETER is used, the non-ISP connectivity providers are unlikely to be part of the AAA infrastruture. For example, I run an open WLAN at my home, and even though I may require some kind of authentication in the future, it is very unlikely that I would run RADIUS or DIAMETER. Thus, making your system to help at all, it would require that EVERYBODY ELSE FORBIDS Home Address Option altogether. It is not only a mobile host that can send HAO, any host can send it. If an intruder can break into 10 million poorly protected home PCs, they can be converted into MN looking devices that send fake HAOs. Sure the ISP can drop all packets containing HAO sent from their home customer sites, but that would break the ability to use your PDA/other device through your friend's WLAN while visiting at their place. Do you see my point now? > - to do better anti-spoofing filtering for sites from where some mobile > nodes are (aka home sites). I do not argue with that part. You draft may well have some value protecting the home sites of MNs. > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. As I said above, either you must assume that any site can host MNs (in addition to CNs), ---or--- you must forbid sending HAO containing packets from those sites that are assumed not tho host MNs. My main point is that forbidding HAOs to be sent from the majority of the Internet would largely foil the purpose of Mobile IPv6. > I don't know how this is done everywhere but in many sites I can see > a special network for nomadic nodes with special network access control > and small priviledges just because by definition local network managers > have not the control of them, so IMHO this is not unrealistic to ask > to sites which welcome mobile nodes to have a responsible attitude towards > security. My point is that almost every home will, in the future, be a potential site hosting MNs. -------------------------------- > Secondly, such a the proposed practice would basically foil all of the > designed zero-configuration nature of IPv6. That is, the reason for IPv6 > stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 > network without any prior configuration. IMHO, such a practice would be > very good in many environments, even in public access WLANs. (I know that > some people disagree with me.) > > => this is very unrealistic because this forgets the third letter of AAA. > And of course this doesn't go well with the responsible use of the network > principle. Most homes do not even know about responsible use of network principle. It is just that since you can buy an Apple Airport (or whatever) from your local shop, and set it up within minutes, that will happen. Actually, it is already happening in many places in the US and scandinavia. Remember me setting up an WLAN access point at IPCN'2001 in Paris? --------------------------------- > Now, the point is that those are also exactly the organizations > that are most _unlikely_ to use advanced ingress filtering methods, > > => the solution in this case is just to filter out HAO, i.e. to refuse > mobile nodes. ... and what I am saying, such a practise is unreasonable and would severly restrict our possibility to use the future Internet. In other words, madating that ingress filtering MUST refuse HAO (unless special means is used to ensure that the Home Address is valid), besides being expensive and unrealistic, would result in MIPv6 being used only be the telecom vendors, not by the rest of us. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 10:56:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IuhNg004249 for ; Fri, 4 Jan 2002 10:56:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04IugGg004248 for ipng-dist; Fri, 4 Jan 2002 10:56:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IudNg004241; Fri, 4 Jan 2002 10:56:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10315; Fri, 4 Jan 2002 10:56:43 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23488; Fri, 4 Jan 2002 10:56:41 -0800 (PST) Received: from jariws1 ([62.248.238.9]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020104185640.TKLJ11987.fep01-app.kolumbus.fi@jariws1>; Fri, 4 Jan 2002 20:56:40 +0200 Message-ID: <007101c19551$90358240$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" , "Pekka Nikander" Cc: , References: <200201041653.g04Gr9Q03466@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Fri, 4 Jan 2002 20:56:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. I am concerned that this would be an obstacle to deploying MIPv6: I couldn't put my node to network X because X will not get AAA within five years. > Secondly, such a the proposed practice would basically foil all of the > designed zero-configuration nature of IPv6. That is, the reason for IPv6 > stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 > network without any prior configuration. IMHO, such a practice would be > very good in many environments, even in public access WLANs. (I know that > some people disagree with me.) > > => this is very unrealistic because this forgets the third letter of AAA. > And of course this doesn't go well with the responsible use of the network > principle. Uh... there are legitimate uses for accounting and AAA but I really don't think we should impose configuration and AAA in all situations. There's plenty of examples where there is no business or security need for complicated configuration or even accounting. Such as closed company or free university networks, or my access-paid-by-visa WLAN. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 15:22:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NMXNg005266 for ; Fri, 4 Jan 2002 15:22:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04NMXdv005265 for ipng-dist; Fri, 4 Jan 2002 15:22:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NMUNg005258 for ; Fri, 4 Jan 2002 15:22:30 -0800 (PST) Received: from eng.sun.com (sappey.Eng.Sun.COM [129.146.85.69]) by jurassic.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NMY6m574118; Fri, 4 Jan 2002 15:22:34 -0800 (PST) Message-ID: <3C36391C.A4DF3C3F@eng.sun.com> Date: Fri, 04 Jan 2002 15:22:04 -0800 From: Alain Durand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <3C348636.DB130121@hursley.ibm.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > The one acronym summary of kre's point is: SLA. I'd venture > to say that no QoS solution will ever work in the absence of > an SLA. And guess what, the IETF doesn't discuss business > models and SLAs. The most we can do is standardise tools > that can be deployed to support SLAs. > > So, I think it's time for a hum on this one (the simple > update to 2460 that Scott and I at least seem to agree > on). > I humm for it. It's time to move on. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 15:27:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NRhNg005305 for ; Fri, 4 Jan 2002 15:27:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04NRhiY005304 for ipng-dist; Fri, 4 Jan 2002 15:27:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NRgNg005297 for ; Fri, 4 Jan 2002 15:27:42 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g04NR13W006570 for ; Fri, 4 Jan 2002 15:27:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g04NR0Q5006569 for ipng@sunroof.eng.sun.com; Fri, 4 Jan 2002 15:27:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBT78aZR023559 for ; Fri, 28 Dec 2001 23:08:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12309 for ; Fri, 28 Dec 2001 23:08:38 -0800 (PST) Received: from tx.citynet.net (tx.citynet.net [208.154.179.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA10865 for ; Fri, 28 Dec 2001 23:08:38 -0800 (PST) Received: from a (63-144-68-171.citynet.net [63.144.68.171]) by tx.citynet.net (8.11.3/8.11.3=Outbound) with SMTP id fBT77wI30235 for ; Sat, 29 Dec 2001 02:07:58 -0500 Message-ID: <000a01c19037$79cd8e40$ab44903f@a> From: "Bill Cunningham" To: Subject: 128 bit IP addresses Date: Sat, 29 Dec 2001 02:07:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1900D.8DDC8AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1900D.8DDC8AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the 128 bit IP addresses are needed so badly why aren't they already = in use. I 've been hearing about these IP addresses for 2 years now. = Will they retire the 32 bit addresses or absorb them into IPv6? ------=_NextPart_000_0007_01C1900D.8DDC8AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If the 128 bit IP addresses are needed = so badly why=20 aren't they already in use. I 've been hearing about these IP addresses = for 2=20 years now. Will they retire the 32 bit addresses or absorb them into=20 IPv6?
------=_NextPart_000_0007_01C1900D.8DDC8AA0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 15:28:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NSGNg005322 for ; Fri, 4 Jan 2002 15:28:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04NSGXF005321 for ipng-dist; Fri, 4 Jan 2002 15:28:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NSENg005314 for ; Fri, 4 Jan 2002 15:28:14 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g04NRX3W006579 for ; Fri, 4 Jan 2002 15:27:33 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g04NRXqC006578 for ipng@sunroof.eng.sun.com; Fri, 4 Jan 2002 15:27:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02JxUZR028476 for ; Wed, 2 Jan 2002 11:59:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03916 for ; Wed, 2 Jan 2002 11:59:33 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04282 for ; Wed, 2 Jan 2002 12:59:32 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g02Jwqi25682; Wed, 2 Jan 2002 13:58:53 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 13:57:21 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E014CBED9@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Brian E Carpenter Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Wed, 2 Jan 2002 13:57:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C193C7.BD4E12F0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C193C7.BD4E12F0 Content-Type: text/plain; charset="iso-8859-1" Brian, Diff-serv itself is a sort of signaling and the field it operates on is mutable is it not? I hope you at least agree that is is either configured or signaled. I believe you can signal to routers and have routers that are not configured or capable of handling the signaling ignore the signaling. IPv6's option definitions were designed specifically for this filtering function. So I guess what I'm saying is, the example you gave to indicate that the fields should be immutable is not immutable itself and so I don't think the reasoning holds up. Making the field mutable or not is disjoint from the signaling or configuration argument in order to act on a field. With diff-serv you either configure or signal to set up the behavior of its operational field. The merits of configuration vs signaling might be argued but IMO configuration (especially remote configuration) is a form of signaling as well. I do see value in out of the box schemas for on-net solutions; however, I don't think mutability will thwart this ability or desire as long as the signaling or subsequent configuration can change the default schema. I also don't understand why people are so terrified of mutability of certain fields. The original point was that if there is a business reason to make a field mutable or not, it will be mutable irrespective of what an RFC says. It seems to me that making things immutable reduces the use of the fields in question from a functional perspective. Mutability with signaling and at least configuration seems to increase flexibility and extensibility. It seems to me that for the long term we should not try to restrict the use of fields but rather detail the use and expectations for particular applications as their need arises. I don't see a problem with an RFC saying, "for this particular network layer service, the field is expected to be immutable as it traverses certain parts of the network or the whole network". But this would be for just one type of network-layer service and would leave the door open for other uses in the future. regards, Glenn > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, December 23, 2001 9:17 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > > Glenn Morrow wrote: > > > If "function A" wants the field immutable so be it. The > signaling for "function A" needs to convey the mutability > rules to affected parties > > either implicitly or by optionality. > > This is broken. You can't signal to routers that aren't aware of > the "function A", because they won't be aware of the relevant > signalling either. Also, we need to be able to construct > signalling-free > solutions (such as diffserv) for scalability. > > Immutability is the only viable answer. > > Brian > > > ------_=_NextPart_001_01C193C7.BD4E12F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-rajahalme-ipv6-flow-label-00.txt

Brian,

Diff-serv itself is a sort of signaling and the field = it operates on is mutable is it not? I hope you at least agree that is = is either configured or signaled. I believe you can signal to routers = and have routers that are not configured or capable of handling the = signaling ignore the signaling. IPv6's option definitions were designed = specifically for this filtering function.

So I guess what I'm saying is, the example you gave = to indicate that the fields should be immutable is not immutable itself = and so I don't think the reasoning holds up. Making the field mutable = or not is disjoint from the signaling or configuration argument in = order to act on a field. With diff-serv you either configure or signal = to set up the behavior of its operational field. The merits of = configuration vs signaling might be argued but IMO configuration = (especially remote configuration) is a form of signaling as well. I do = see value in out of the box schemas for on-net solutions; however, I = don't think mutability will thwart this ability or desire as long as = the signaling or subsequent configuration can change the default = schema.

I also don't understand why people are so terrified = of mutability of certain fields. The original point was that if there = is a business reason to make a field mutable or not, it will be mutable = irrespective of what an RFC says. It seems to me that making things = immutable reduces the use of the fields in question from a functional = perspective. Mutability with signaling and at least configuration seems = to increase flexibility and extensibility. It seems to me that for the = long term we should not try to restrict the use of fields but rather = detail the use and expectations for particular applications as their = need arises. I don't see a problem with an RFC saying, "for this = particular network layer service, the field is expected to be immutable = as it traverses certain parts of the network or the whole = network". But this would be for just one type of network-layer = service and would leave the door open for other uses in the = future.

regards,

Glenn

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Sunday, December 23, 2001 9:17 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Margaret Wasserman; = ipng@sunroof.eng.sun.com
> Subject: Re: = draft-rajahalme-ipv6-flow-label-00.txt
>
>
> Glenn Morrow wrote:
>
> > If "function A" wants the field = immutable so be it. The
> signaling for "function A" needs to = convey the mutability
> rules to affected parties
> > either implicitly or by optionality. =
>
> This is broken. You can't signal to routers = that aren't aware of
> the "function A", because they won't = be aware of the relevant
> signalling either. Also, we need to be able to = construct
> signalling-free
> solutions (such as diffserv) for = scalability.
>
> Immutability is the only viable answer.
>
>   Brian
>
>
>

------_=_NextPart_001_01C193C7.BD4E12F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 4 15:29:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NTENg005357 for ; Fri, 4 Jan 2002 15:29:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04NTEb0005356 for ipng-dist; Fri, 4 Jan 2002 15:29:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NTCNg005349 for ; Fri, 4 Jan 2002 15:29:13 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g04NSV3W006587 for ; Fri, 4 Jan 2002 15:28:31 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g04NSVh5006586 for ipng@sunroof.eng.sun.com; Fri, 4 Jan 2002 15:28:31 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04KRtNg004581; Fri, 4 Jan 2002 12:27:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07324; Fri, 4 Jan 2002 12:28:00 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28036; Fri, 4 Jan 2002 13:29:00 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g04KRuQ27975; Fri, 4 Jan 2002 14:27:56 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 14:26:25 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0152FC17@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Was Node Mobility a Requirement for IPng? Date: Fri, 4 Jan 2002 14:26:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1955E.25F9D900" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/plain; charset="iso-8859-1" Hello, Does anyone know if node mobility was a requirement for IPng during the debates among the proposals? If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on. I'm just trying to understand the thinking of the past and how each might be reason to affect the other. Thanks, Glenn ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/html; charset="iso-8859-1"
Hello,
 
Does anyone know if node mobility was a requirement for IPng during the debates among the proposals?
 
If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on.
 
I'm just trying to understand the thinking of the past and how each might be reason to affect the other.
 
Thanks,
 
Glenn
------_=_NextPart_001_01C1955E.25F9D900-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 6 06:28:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06ESINg007948 for ; Sun, 6 Jan 2002 06:28:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06ESIJp007947 for ipng-dist; Sun, 6 Jan 2002 06:28:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06ESFNg007940; Sun, 6 Jan 2002 06:28:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00673; Sun, 6 Jan 2002 06:28:20 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02932; Sun, 6 Jan 2002 07:28:19 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g06ESGb01069; Sun, 6 Jan 2002 15:28:16 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g06ESGQ10317; Sun, 6 Jan 2002 15:28:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061428.g06ESGQ10317@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-reply-to: Your message of Fri, 04 Jan 2002 09:15:55 PST. <15413.58187.884431.562406@thomasm-u1.cisco.com> Date: Sun, 06 Jan 2002 15:28:15 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I sure hope that nobody's making the assumption that you need to be a mobile node to send BU's and/or HAO's. => by definition if a node which sends BUs is a mobile node. But I agree that HAOs are useful for nodes which are not mobile nodes, so the BCE check is not a good solution. My provider doesn't care diddly squat about any of this, nor is it likely that if I tunnel to the 6bone they're going to care much either. => my proposal is not based on traditional unicast RPF ingress filtering done by routers, it is based on firewalls at the border of source sites. But don't believe RPF checks are obsolete, the idea is to use it against traditional DDoS and to use enhanced ingress filtering against the iDDoS threat from HAOs. If this is your only line of defense of protecting CN's from senders of malicious HAO's, I'm pretty skeptical. => enhanced ingress and anti-spoofing filterings are based on the knowledge of bindings. If there should be no HAO sender in a site, the extra ingress filtering rule is just "drop packets with a HAO". If there should be no home agent in a site, the extra anti-spoofing filtering rule is just "applies anti-spoofing to addresses in HAOs". So in common cases the job is easy and even scalable. RPF checks "work" mainly because they are so painless for ISP's to implement. => I don't believe this is so easy but this is an indication that ISPs are ready to implement a kind of access control which gives them no direct benefit. IMHO we can trust smart ingress filtering as much as current ingress filtering... Anything beyond that is likely to be a complete non-starter. => we'll see... We (IETF) can't do far more than to provide technical solutions. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 6 08:20:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GKoNg008493 for ; Sun, 6 Jan 2002 08:20:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06GKo99008492 for ipng-dist; Sun, 6 Jan 2002 08:20:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GKhNg008477; Sun, 6 Jan 2002 08:20:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23685; Sun, 6 Jan 2002 08:20:48 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13958; Sun, 6 Jan 2002 09:20:46 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g06GKgb06875; Sun, 6 Jan 2002 17:20:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA20993; Sun, 6 Jan 2002 17:20:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g06GKgQ10673; Sun, 6 Jan 2002 17:20:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061620.g06GKgQ10673@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-reply-to: Your message of Fri, 04 Jan 2002 20:10:17 +0200. <3C35F009.6020202@nomadiclab.com> Date: Sun, 06 Jan 2002 17:20:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > - to do better ingress filtering based on AAA for sites where there are > some mobile nodes (aka visited sites). Why do you assume that AAA would be used everywhere where there are mobile nodes? => this (to use AAA everywhere where there are mobile nodes) is the price to pay to have an alternative to bidirectional tunnels with home agents, i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling (i.e. real world mobile IPv4). For example, if I am visiting with my friends at their place, why couldn't I just use their private WLAN to connect my wireless PDA to the Internet? => this is a problem of responsibility and trust between you, your friends and their ISP(s). You already have it for network access, with my proposal you only have a new "mobile node" option... If I could not use their private WLAN, I would consider that as a flaw in the design if the Internet. => there is a flaw in the laws of Economics: not everything is free for ever. Similarily, our local university campus provides open WLAN for anyone, for anyone to connect to the Internet. => same answer. It is so much simpler to run these kinds of networks without any kinds of authentication that they will continue to exist, even though many current open WLAN networks may turn into requiring some kind of authentication. => yes, there are still some bad guys in the world... But even when they start to require authentication and/or authorization, that authentication or authorization is more likely to be based on 802.1x or PANA than AAA, => I don't understand your argument: 802.1x or PANA are parts of an AAA system. and even if RADIUS/DIAMETER is used, the non-ISP connectivity providers are unlikely to be part of the AAA infrastruture. => I believe your argument is that all AAA systems are not instances of the AAA architecture. This is an AAA issue which is not in the scope of IPv6 and mobile WGs. For example, I run an open WLAN at my home, and even though I may require some kind of authentication in the future, it is very unlikely that I would run RADIUS or DIAMETER. => again this is a problem of trust and responsability. If your neighbors want to harm you, IMHO the wild Internet access provided by open WLAN is enough. So one day you'll secure it (or your ISP will ask you to secure it), this day the possibility to accommodate mobile nodes shall become an option. Thus, making your system to help at all, it would require that EVERYBODY ELSE FORBIDS Home Address Option altogether. => everybody else is better than everybody (:-). It is not only a mobile host that can send HAO, any host can send it. => this argument is mainly against BCE checks in CNs solution. If an intruder can break into 10 million poorly protected home PCs, they can be converted into MN looking devices that send fake HAOs. => our job is to make "they can be converted into MN looking devices" a detail, i.e. this adds no new major security threat. Sure the ISP can drop all packets containing HAO sent from their home customer sites, but that would break the ability to use your PDA/other device through your friend's WLAN while visiting at their place. => again the same answer. Do you see my point now? => BTW I have a friend with a private WLAN (not an open one, he uses WEP and a MAC address filter, i.e. common private WLAN security tools). When I visit him I use my laptop with a secure bidir tunnel to my office (I use SSH, in the best open WLAN example I know (IETF meetings) most of us use SSH or IPsec (or both)). I don't use real mobility because I don't know how to roam between private WLANs, i.e. this is a nomadic situation where I use two identities, a remote one using a secure bidir tunnel and a local one for short and/or local interactions like web browsing or printing. So if I understand the constraints with my proposal on private WLANs, they are not a good example. > - to do better anti-spoofing filtering for sites from where some mobile > nodes are (aka home sites). I do not argue with that part. You draft may well have some value protecting the home sites of MNs. => my concern is more sites that are not home sites (their anti-spoofing filtering must be enhanced, fortunately this is very easy). > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. As I said above, either you must assume that any site can host MNs (in addition to CNs), ---or--- you must forbid sending HAO containing packets from those sites that are assumed not tho host MNs. => I can't see a problem: they don't take the responsability, I don't trust them... I stress this idea and its relationship with network access control because the ingress filtering is not a reply to DDoS but a reply to source address spoofing: DDoS is still possible but sources can be traced back, i.e. know who has given the network access to attacker nodes. RFC 2827 summary finishes by this statement: It is the responsibility of all network administrators to ensure they do not become the unwitting source of an attack of this nature. My main point is that forbidding HAOs to be sent from the majority of the Internet would largely foil the purpose of Mobile IPv6. => I don't believe that because I don't assume the same things about mobile IPv6 applicability. My point is that almost every home will, in the future, be a potential site hosting MNs. => this is a point where we obviously disagree. > => this is very unrealistic because this forgets the third letter of AAA. > And of course this doesn't go well with the responsible use of the network > principle. Most homes do not even know about responsible use of network principle. => if they read the contract between them and their ISPs they should know. It is just that since you can buy an Apple Airport (or whatever) from your local shop, and set it up within minutes, that will happen. Actually, it is already happening in many places in the US and scandinavia. => I've already answered about private WLANs. Remember me setting up an WLAN access point at IPCN'2001 in Paris? => this was like IETF meetings: a typical nomadic environment, no need of real mobility because there was no other network to move to keeping connections. I believe the issue in in the *local* area, but with a public WWAN associated ISPs should manage a proper network access control, at least in order to implement the third A of AAA (:-). > Now, the point is that those are also exactly the organizations > that are most _unlikely_ to use advanced ingress filtering methods, > > => the solution in this case is just to filter out HAO, i.e. to refuse > mobile nodes. ... and what I am saying, such a practise is unreasonable and would severly restrict our possibility to use the future Internet. In other words, madating that ingress filtering MUST refuse HAO (unless special means is used to ensure that the Home Address is valid), besides being expensive and unrealistic, would result in MIPv6 being used only be the telecom vendors, not by the rest of us. => the only scenario where this can harm is a roaming from a public WWAN to a visited private LAN, do you agree? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 6 08:43:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GhaNg008660 for ; Sun, 6 Jan 2002 08:43:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06Gha78008659 for ipng-dist; Sun, 6 Jan 2002 08:43:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GhXNg008652 for ; Sun, 6 Jan 2002 08:43:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25145 for ; Sun, 6 Jan 2002 08:43:37 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-1.kolumbus.fi [193.229.5.107]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19278 for ; Sun, 6 Jan 2002 09:43:36 -0700 (MST) Received: from jariws1 ([62.248.238.9]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020106164309.PVOQ1587.fep07-app.kolumbus.fi@jariws1>; Sun, 6 Jan 2002 18:43:09 +0200 Message-ID: <00bf01c196d1$523f5ca0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" Cc: , References: <200201061620.g06GKgQ10673@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Sun, 6 Jan 2002 18:43:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => this (to use AAA everywhere where there are mobile nodes) is the price > to pay to have an alternative to bidirectional tunnels with home agents, > i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling > (i.e. real world mobile IPv4). This seems like a bad design tradeoff to me. We already have a highly optimised mode of operation in MIPv6 (RO), and if you're not using it you are falling back to something less efficient. Your tradeoff improves the fallback solution a bit, but doesn't improve the optimised solution. And the cost is extreme: we need a new global infrastructure (though I admit some of it will be built anyway), MIPv6 deployment is delayed, most if not all small sites and homes will not be able to benefit from RO, etc. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 6 08:44:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06Gi0Ng008678 for ; Sun, 6 Jan 2002 08:44:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06GhxcM008677 for ipng-dist; Sun, 6 Jan 2002 08:43:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GhoNg008662; Sun, 6 Jan 2002 08:43:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25161; Sun, 6 Jan 2002 08:43:55 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05102; Sun, 6 Jan 2002 09:44:58 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g06Ghnb07750; Sun, 6 Jan 2002 17:43:49 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA21198; Sun, 6 Jan 2002 17:43:50 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g06GhnQ10753; Sun, 6 Jan 2002 17:43:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061643.g06GhnQ10753@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: "Pekka Nikander" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Fri, 04 Jan 2002 20:56:48 +0200. <007101c19551$90358240$8a1b6e0a@arenanet.fi> Date: Sun, 06 Jan 2002 17:43:49 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. I am concerned that this would be an obstacle to deploying MIPv6: I couldn't put my node to network X because X will not get AAA within five years. => don't forget you still can use a bidirectional tunnel with your home agent, so this is a constraint for the standard mode of MIPv6, not the anti-optimized but optionaly really secure mode ((secure) bidir tunnel). We have already some problems with the (route) optimized mode, I believe we shouldn't like to lost standard mode too. Uh... there are legitimate uses for accounting and AAA but I really don't think we should impose configuration and AAA in all situations. There's plenty of examples where there is no business or security need for complicated configuration or even accounting. Such as closed company => there should be no security issue in a closed company or free university networks, => there is a problem for them but I don't believe this is very different than for the Internet access. A balance between the freedom and the responsability in case of problems has to be found. or my access-paid-by-visa WLAN. => I believe this is not a WLAN but a network of WLANs (i.e. a WWAN made with WLANs). In this case the problem is very easy to use, even statically (i.e. with a home address bound to the VISA account). Of course I expect the mobile support will be in the offered service list, something we all like to get but perhaps is not understood by operators... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 6 08:57:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06Gv8Ng008841 for ; Sun, 6 Jan 2002 08:57:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06Gv8gg008840 for ipng-dist; Sun, 6 Jan 2002 08:57:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06Gv3Ng008826; Sun, 6 Jan 2002 08:57:03 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26493; Sun, 6 Jan 2002 08:57:07 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16240; Sun, 6 Jan 2002 08:57:06 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g06Gv4b08215; Sun, 6 Jan 2002 17:57:04 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA21331; Sun, 6 Jan 2002 17:57:04 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g06Gv4Q10837; Sun, 6 Jan 2002 17:57:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061657.g06Gv4Q10837@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Was Node Mobility a Requirement for IPng? In-reply-to: Your message of Fri, 04 Jan 2002 14:26:53 CST. <933FADF5E673D411B8A30002A5608A0E0152FC17@zrc2c012.us.nortel.com> Date: Sun, 06 Jan 2002 17:57:04 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Does anyone know if node mobility was a requirement for IPng during the debates among the proposals? => I believe it was but which kind of mobility? At least the current Mobile IPv4 situation, i.e. bidirectional tunnel between the mobile node and its home agent. If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on. => I don't believe for SIPP but PIP has some support for mobility (look at the "Pip Near-term Arch" document section 14 "Host Mobility", some of us preciously kept some copies of it). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 6 08:57:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GvANg008849 for ; Sun, 6 Jan 2002 08:57:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06GvAx6008848 for ipng-dist; Sun, 6 Jan 2002 08:57:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06Gv4Ng008833; Sun, 6 Jan 2002 08:57:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26497; Sun, 6 Jan 2002 08:57:09 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16241; Sun, 6 Jan 2002 08:57:07 -0800 (PST) Received: from jariws1 ([62.248.238.9]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020106165705.ZPFV24037.fep02-app.kolumbus.fi@jariws1>; Sun, 6 Jan 2002 18:57:05 +0200 Message-ID: <00c901c196d3$359f9040$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" Cc: "Pekka Nikander" , , References: <200201061643.g06GhnQ10753@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Sun, 6 Jan 2002 18:57:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => don't forget you still can use a bidirectional tunnel with your home > agent, so this is a constraint for the standard mode of MIPv6, > not the anti-optimized but optionaly really secure mode ((secure) bidir > tunnel). We have already some problems with the (route) optimized mode, > I believe we shouldn't like to lost standard mode too. AAA-based solution would allow you to keep the standard mode, but at a cost which would propably prevent some good size fraction of nodes from using the optimised mode. The BCE check solution allows you to keep the optimised mode in wide usage, but does force you to go back to bidirectional tunneling if you didn't do RO. Take your pick what is the right tradeoff here, but my preference is the last one. > or my access-paid-by-visa WLAN. > > => I believe this is not a WLAN but a network of WLANs (i.e. a WWAN made > with WLANs). In this case the problem is very easy to use, even > statically (i.e. with a home address bound to the VISA account). > Of course I expect the mobile support will be in the offered service list, > something we all like to get but perhaps is not understood by operators... Right. You expect the support to be there. So, instead of me turning on MIPv6 when my code supports it and your code supports it, we have to wait five years before VISA deploys the technology for both of us. And for that, we get to pay a montly service fee! By the way, didn't we already decide that a global infrastructure linking people to their home addresses was out of the question? I don't think it matters whether the acronym for this infrastructure was PKI, DNS, or AAA? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 6 10:41:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06IfENg009394 for ; Sun, 6 Jan 2002 10:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06IfDf8009393 for ipng-dist; Sun, 6 Jan 2002 10:41:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06IfANg009386; Sun, 6 Jan 2002 10:41:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02879; Sun, 6 Jan 2002 10:41:16 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20093; Sun, 6 Jan 2002 10:41:15 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 36971A; Sun, 6 Jan 2002 20:41:41 +0200 (EET) Message-ID: <3C389A41.4000702@nomadiclab.com> Date: Sun, 06 Jan 2002 20:41:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access References: <200201061620.g06GKgQ10673@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, I wrote: > Thus, making your system to help at all, it would require that > EVERYBODY ELSE FORBIDS Home Address Option altogether. Francis Dupont wrote: > => everybody else is better than everybody (:-). I think the main reason for our disagreement is that you mostly seem to think that MIPv6 will be employed by operators. I don't. If MIPv6 will ever become common, I certainly want to run my own MIPv6 Home Agent, in the same way I am running my own DNS server, my own SMTP server, etc. That is, the only service that I buy is IP connectivity, and I really really really want to have an Internet that allows you to buy IP connectivity, and provide all of the rest of the infrastructure yourself. I don't want to be part of a global AAA. [Personally, I would consider such a requirement fascist.] Now, returning to the real issue. I just want to second Jari Arkko's statement: A. We seem to agree that HAO may be dangerous since it potentially makes IP traceback more difficult. B. There seems to be two possible solutions: B.1 Make the Binding Cache hard state instead of a cache. That is, mandate that CN accepts HAO if and only if there is a corresponding binding in the binding cache. (Or, at minimum, that it keeps trace of received HAOs for traceback purposes.) B.2 Mandate that every ingress router everywhere in the Internet either checks that the HAO is legitimate, or drops it. That is, my (possibly flawed) understanding of your ingress filtering draft requires B.2. If B.2 was mandated, the CN could accept HAO and rely that it is authentic. On the B.1 case, on the other hand, it is the CN's responsibility to decide whether to rely on HAO or not. As far as I can see, that is the difference. As a practical result, B.1 allows anybody to use MIPv6 security protocols (whatever it will be), establish bindings, and use HAOs. B.2, on the other hand, would restrict where you can use BUs, and that your home agent must be part of the still-not-existing global AAA infrastructure so that you could use HAO. As a result, all the work that we have done with RR and CGA would be unnecessary, since you would mandate AAA, and while you are mandating it, you just could use it for basic MIPv6 security as well. Francis, if you insist to keep your opinion that B.2 with all its consequences is better, there is nothing I can do. On the other hand, if I have really misunderstood the practical consequences of your draft, please enlighten me, and explain in detail how you expect it to work so that MIPv6 route optimization could still be used by private persons and small organizations that are not part of the alledged global AAA infrastructure. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 01:04:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07942Ng010230 for ; Mon, 7 Jan 2002 01:04:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07942OG010229 for ipng-dist; Mon, 7 Jan 2002 01:04:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0793rNg010216 for ; Mon, 7 Jan 2002 01:03:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20938 for ; Mon, 7 Jan 2002 01:03:48 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17267 for ; Mon, 7 Jan 2002 01:03:47 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0793ib12849; Mon, 7 Jan 2002 10:03:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA02043; Mon, 7 Jan 2002 10:03:44 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0793iQ13069; Mon, 7 Jan 2002 10:03:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201070903.g0793iQ13069@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 06 Jan 2002 18:43:51 +0200. <00bf01c196d1$523f5ca0$8a1b6e0a@arenanet.fi> Date: Mon, 07 Jan 2002 10:03:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => this (to use AAA everywhere where there are mobile nodes) is the price > to pay to have an alternative to bidirectional tunnels with home agents, > i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling > (i.e. real world mobile IPv4). This seems like a bad design tradeoff to me. We already have a highly optimised mode of operation in MIPv6 (RO), => no, we have not this until the security problem is solved, i.e. it works but we may not deploy it... In fact (you sent this mail to the IPv6 WG mailing list only so I can say that without being nuke in some minutes) if Mobile IPv6 is expensive for CNs and only at the benefit of MNs it is in a real trouble. IMHO Routing Optimization has this problem, obviously not the bidirectional tunneling and not the triangular routing *if* the reply to the ingress filtering problem is not the burden of CNs. I disagree with most of the IESG security concerns with MIPv6 but the statement "This has negative implications for larger servers that process many 100s of thousands of connections at a time" is true, not only for AH/IPsec SAs. I think we must put the responsability of using HAOs to senders! and if you're not using it you are falling back to something less efficient. Your tradeoff improves the fallback solution a bit, but doesn't improve the optimised solution. And the cost is extreme: => I disagree, and the cost of RO is really extreme for CNs so if most of CNs just deny BUs we'll be happy to have a better fallback solution. we need a new global infrastructure (though I admit some of it will be built anyway), => first the implementation of smart ingress filtering and AAA is not even a SHOULD (RFC 2827 is a BCP), it seems you believe it is a MUST. Second the ingress filtering and HAOs is not a major security threat (like unprotected BUs in an open network is). To summary your argument would be valid if ingress filtering was mandatory and efficient, but today ingress filtering is not used by every ISPs and unfortunately to know where are the attackers is not enough to stop DDoS. MIPv6 deployment is delayed, => no, the only possible effect on deployment is another argument is favor of a better/real AAA. most if not all small sites and homes will not be able to benefit from RO, etc. => I agree that to ask for a better network access control in general stresses the trust/responsability problem. Regards Francis.Dupont@enst-bretagne.fr PS: don't forget that the BCE check solution has many drawbacks: - it doesn't work with not-MIPv6 uses of HAOs - it doesn't work without routing optimization - it makes CNs processing more complex/expensive - BCEs should be hard state. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 01:22:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g079MMNg010290 for ; Mon, 7 Jan 2002 01:22:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g079MLE1010289 for ipng-dist; Mon, 7 Jan 2002 01:22:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g079MFNg010274; Mon, 7 Jan 2002 01:22:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22650; Mon, 7 Jan 2002 01:22:19 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06893; Mon, 7 Jan 2002 02:22:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g079MAb14981; Mon, 7 Jan 2002 10:22:10 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA02374; Mon, 7 Jan 2002 10:22:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g079MAQ13141; Mon, 7 Jan 2002 10:22:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201070922.g079MAQ13141@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: "Pekka Nikander" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 06 Jan 2002 18:57:22 +0200. <00c901c196d3$359f9040$8a1b6e0a@arenanet.fi> Date: Mon, 07 Jan 2002 10:22:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => don't forget you still can use a bidirectional tunnel with your home > agent, so this is a constraint for the standard mode of MIPv6, > not the anti-optimized but optionaly really secure mode ((secure) bidir > tunnel). We have already some problems with the (route) optimized mode, > I believe we shouldn't like to lost standard mode too. AAA-based solution would allow you to keep the standard mode, but at a cost which would propably prevent some good size fraction of nodes from using the optimised mode. The BCE check solution allows you to keep the optimised mode in wide usage, but does force you to go back to bidirectional tunneling if you didn't do RO. Take your pick what is the right tradeoff here, but my preference is the last one. => your argument is based on the bet that full CN function will be implemented by everybody and enabled everywhere. IMHO this is a very dangerous bet... > or my access-paid-by-visa WLAN. > > => I believe this is not a WLAN but a network of WLANs (i.e. a WWAN made > with WLANs). In this case the problem is very easy to use, even > statically (i.e. with a home address bound to the VISA account). > Of course I expect the mobile support will be in the offered service list, > something we all like to get but perhaps is not understood by operators... Right. You expect the support to be there. => the "even statically" is only an example of what can be done. So, instead of me turning on MIPv6 when my code supports it and your code supports it, => this (when your code supports it) is the real question... we have to wait five years before VISA deploys the technology for both of us. => not VISA, our ISPs (and far less than five years). And for that, we get to pay a montly service fee! => if it is VISA, we'll pay a monthly fee for no service (:-)! By the way, didn't we already decide that a global infrastructure linking people to their home addresses was out of the question? => not exactly, the key term is "rely on". I don't think it matters whether the acronym for this infrastructure was PKI, DNS, or AAA? => I agree but it is not forbidden to get advantages of it, only to rely on it. As we don't rely on ingress filtering for defense against DDoS, I can't see a problem to propose to use AAA in order to improve ingress filtering. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 02:15:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07AF8Ng010491 for ; Mon, 7 Jan 2002 02:15:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07AF88f010490 for ipng-dist; Mon, 7 Jan 2002 02:15:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07AF5Ng010483 for ; Mon, 7 Jan 2002 02:15:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26922 for ; Mon, 7 Jan 2002 02:15:10 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06471 for ; Mon, 7 Jan 2002 02:15:09 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA13276; Mon, 7 Jan 2002 11:15:07 +0100 Received: from dhcp30_20.lagaude.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27398 from ; Mon, 7 Jan 2002 11:14:57 +0100 Message-Id: <3C397521.A5D1660F@hursley.ibm.com> Date: Mon, 07 Jan 2002 11:14:57 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We've already discussed the weak trust model aspect. Basically nobody will be doing cryptographic authentication of the flow label at line speed, and if it isn't done at line speed what's the point? Brian Subrata Goswami wrote: > > The wording for immutability aside, to really enforce immutability > of the Flow Label , there must be a mechanism to verify that the > Flow Label has not been changed. As can be seen from the ICV computation > for IPv6 (RFC2402) even AH considers Flow label to be mutable. Hence there > needs to be a new IPv6 header option for Flow Label immutability. > > 3.3.3.1.2 ICV Computation for IPv6 > > 3.3.3.1.2.1 Base Header Fields > > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header (This should be the value for AH.) > Source Address > Destination Address (without Routing Extension Header) > > Mutable but predictable > Destination Address (with Routing Extension Header) > > Mutable (zeroed prior to ICV calculation) > Class > Flow Label > Hop Limit > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Charles E. Perkins > Sent: Friday, January 04, 2002 9:33 AM > To: Brian E Carpenter > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Flow Label > > Hello Brian, > > Brian E Carpenter wrote: > > > > And, truth in advertising, we have heard two dissenting > > views: > > > > a) that the field should be defined as MUST BE ZERO, i.e. > > the MAY clause below gets deleted > > I would say that MAY is a lot better. It suggests the truth, > which is that people are going to try to figure out ways to > use the flow label. It also motivates immutability. Otherwise, > it is possible that some router vendors could simply zero out > the field -- if it MUST BE ZERO, then zeroing it preserves > immutability... We wouldn't want that. > > > b) that the 3rd MUST should be SHOULD, i.e. immutability should > > be default instead of mandatory. > > Any future technique for using the flow label would, if it violates > immutability, be viewed as obsoleting this part of the specification > anyway. So I would hope for a MUST here. Language suggesting that > it is merely the default would allow for a tunable know in the user > interface labeled thusly: > "Flow Label treatment (default: do not change): " > to be filled in by the system administrator. Possible other values > selectable by the operator could be "randomize", "ones-complement", > "store current time", ... (?). I don't know why anyone would do > this, but I think we ought to be pretty clear about prohibiting it > at least for now. > > Regards, > Charlie P. > > > > > Brian > > > > Margaret Wasserman wrote: > > > > > > Hi George, > > > > > > Yes, we are "humming" in agreement to the proposal that we > > > replace section 6 of RFC 2460 with the following text: > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > source to label sets of packets. Nodes that do not support > > > > the Flow Label field MUST set the field to zero when originating a > > > > packet, and MUST ignore the field when receiving a packet. All > routers > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > This specification does not further define the meaning of the > > > > Flow Label. > > > > > > > > > > And that we delete Appendix A from RFC 2460. > > > > > > Actually, we probably won't update RFC 2460. We'll probably > > > just publish a separate RFC that updates 2460. > > > > > > Margaret > > > > > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > > > >Just a quick question from an interested lurker: Are these hums of > > > >acquiescence in response, specifically, to the idea that an originating > > > >node may set the flow label to any value, and that nodes forwarding > > > >packets will leave that value alone? -- George Mitchell > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 02:51:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ApINg010568 for ; Mon, 7 Jan 2002 02:51:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07ApH43010567 for ipng-dist; Mon, 7 Jan 2002 02:51:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ApANg010552; Mon, 7 Jan 2002 02:51:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17311; Mon, 7 Jan 2002 02:51:16 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01834; Mon, 7 Jan 2002 03:51:15 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g07Ap9b26741; Mon, 7 Jan 2002 11:51:09 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA04055; Mon, 7 Jan 2002 11:51:09 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g07Ap8Q13420; Mon, 7 Jan 2002 11:51:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 06 Jan 2002 20:41:05 +0200. <3C389A41.4000702@nomadiclab.com> Date: Mon, 07 Jan 2002 11:51:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think the main reason for our disagreement is that you mostly seem to think that MIPv6 will be employed by operators. I don't. If MIPv6 will ever become common, I certainly want to run my own MIPv6 Home Agent, in the same way I am running my own DNS server, my own SMTP server, etc. That is, the only service that I buy is IP connectivity, and I really really really want to have an Internet that allows you to buy IP connectivity, and provide all of the rest of the infrastructure yourself. I don't want to be part of a global AAA. [Personally, I would consider such a requirement fascist.] => first the term requirement is too strong, second the recommendation for AAA in home domains is for your protection because without remote network access control if a bad guy tries to use an address in your (home) prefix you can't just reply "no, this is mine". Now, returning to the real issue. I just want to second Jari Arkko's statement: A. We seem to agree that HAO may be dangerous since it potentially makes IP traceback more difficult. => we agree. B. There seems to be two possible solutions: B.1 Make the Binding Cache hard state instead of a cache. That is, mandate that CN accepts HAO if and only if there is a corresponding binding in the binding cache. (Or, at minimum, that it keeps trace of received HAOs for traceback purposes.) B.2 Mandate that every ingress router everywhere in the Internet either checks that the HAO is legitimate, or drops it. => in both cases the term mandate is far too strong. That is, my (possibly flawed) understanding of your ingress filtering draft requires B.2. If B.2 was mandated, the CN could accept HAO and rely that it is authentic. On the B.1 case, on the other hand, it is the CN's responsibility to decide whether to rely on HAO or not. => I agree, the whole issue is where to put the responsability (or who trust to). As far as I can see, that is the difference. As a practical result, B.1 allows anybody to use MIPv6 security protocols (whatever it will be), establish bindings, and use HAOs. B.2, on the other hand, would restrict where you can use BUs, => this is not a restriction: the responsability is put on senders, so we trust (or filter out) senders. This is exactly the same for the current ingress filtering: we trust source address because ISPs say we can (they may use a tool which makes source address spoofing impossible). and that your home agent must be part of the still-not-existing global AAA infrastructure so that you could use HAO. => as I've said, this *recommendation* is for your protection: without remote network access control you can be a target... As a result, all the work that we have done with RR and CGA would be unnecessary, since you would mandate AAA, and while you are mandating it, you just could use it for basic MIPv6 security as well. => no, I never propose to base MIPv6 security on AAA. If I believe that AAA is a fine alternative for MN-HA security (I tried full IPsec, this works but this is so heavy and inefficient than near everything else should be better :-), but AAA for MN-CN security is possible only in some very special cases. Francis, if you insist to keep your opinion that B.2 with all its consequences is better, there is nothing I can do. On the other hand, if I have really misunderstood the practical consequences of your draft, please enlighten me, and explain in detail how you expect it to work so that MIPv6 route optimization could still be used by private persons and small organizations that are not part of the alledged global AAA infrastructure. => first, kill the idea to use (or to rely on) AAA for the general MN-CN case. Second, don't forget the target: we have a nasty attack, DDoS with source address spoofing, and a reply, ingress filtering, which is not used by every ISPs and is not very efficient against DDoSs (just because it is a reply to source address spoofing, not DDoSs themselves). HAO may be dangerous since it potentially makes IP traceback (ingress filtering is the only deploied tool which provides IP traceback) more difficult. The idea is to improve ingress filtering in order to get back the previous situation (the one before HAO). The obvious solution is to make the knowledge of bindings available to ingress filtering devices. My proposal is to use the local network access control in order to carry this knowledge from MNs to ingress filtering devices, this assumes only that there is a local network access control (of any kind) and ingress filtering devices are between the Internet access and the site, and have enough capabilities (i.e. the firewall(s) which already filter(s) inbound traffic). If there is a AAA infrastructure and if both the local and remote network access controls are connected to this infrastructure you have two extra benefits: the remote network access control works locally and ingress filtering devices can verify bindings: without an AAA connection between local/visited and remote/home domain, ingress filtering devices can only check HAOs against registered bindings (IMHO this is enough to make spoofing based on HAOs unattractive). With an AAA connection, bindings can be verifed when they are declared/registered. This is a far stronger property, we'd like to get it in an ideal world (a world where there are AAA infrastructures :-). In summary participation to a global AAA infrastructure is not needed, it has just many new advantages (and should be discussed in the AAA WG mailing list, not here). Regards Francis.Dupont@enst-bretagne.fr PS: I'll add in the draft a statement against BCE checks (they work only for mobility) and an extra space between the "network access control" and the "AAA" paragraphs (showing there is no dependency). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 06:50:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EoRNg011566 for ; Mon, 7 Jan 2002 06:50:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07EoRZh011565 for ipng-dist; Mon, 7 Jan 2002 06:50:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EoNNg011555 for ; Mon, 7 Jan 2002 06:50:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21546 for ; Mon, 7 Jan 2002 06:50:29 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12614 for ; Mon, 7 Jan 2002 07:51:31 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g07EoNJ13613 for ; Mon, 7 Jan 2002 15:50:23 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 07 15:50:22 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:50:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1A6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Jari Arkko Cc: Pekka Nikander , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Mon, 7 Jan 2002 15:49:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => I believe this is not a WLAN but a network of WLANs > (i.e. a WWAN made > with WLANs). In this case the problem is very easy to use, even > statically (i.e. with a home address bound to the VISA account). => I agree you can still use it, but definitely not in this way. Home address is bound to the HA and NOT the AAAH server. Please let's not go down the MIPv4-AAA-wedding road ! I could have my HA@home and visa paying my access bills. No need for Visa to know my Home address. They should know my identity of course, NAI, IMSI, credit card number ....etc but absolutely no need to know my Home address, which I can change regularly. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 08:30:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07GU5Ng011878 for ; Mon, 7 Jan 2002 08:30:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07GU5AZ011877 for ipng-dist; Mon, 7 Jan 2002 08:30:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07GU2Ng011870; Mon, 7 Jan 2002 08:30:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22646; Mon, 7 Jan 2002 08:30:05 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02401; Mon, 7 Jan 2002 09:30:36 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g07GT9X28639; Mon, 7 Jan 2002 18:29:09 +0200 Date: Mon, 7 Jan 2002 18:29:09 +0200 (EET) From: Pekka Savola To: cc: Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041612.g04GCaQ03314@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 4 Jan 2002, Francis Dupont wrote: > About section 2 on Correspondent Nodes; could you elaborate in the > document why exactly solution is too drastic? > > => because this gives no choice between bidirectional tunnel and > route optimization, so in some cases mobile IPv6 becomes far less > attractive. The real impact depends on how mobile IPv6 is used, > in fact one can argue that bidirectional tunnels are enough, but > I don't believe that mobile-ip list members will agree... Nothing prevents from applying some kind of RR tests to HAO (without BU) use too. The HAO implementation would just be a .. little .. more complicated.. but then again it hasn't been defined in the spec anyway. > Note that BCE check is not > the only way to ensure legitimity of HAO: if it's secured by AH, it's ok; > if some SUCV/.. weak authentication method is used, it's probably also ok; > the same might even apply to return routability. It's too early to crush > CN solutions. > > => these CN solutions have the same cost than full routing optimization, > so I consider them as BCE check variants. See above. > (I think the solution for HAO should most likely consist of two separate, > "strong-enough" layers, one mandated at CN, one possible at firewalls, but > that's not the topic of this draft). > > => one mandated at CN == no third choice. One must be available for CN, because CN cannot trust the source if it isn't authenticated or in some form authorized. [snip rest] I won't get into this more here, because I must say I agree almost 100% with comments from Pekka Nikander, Jari Arkko et al. (You should be very, very afraid if you ever venture in Finland, Francis ;-). One point I've made before: perhaps the check is trivial, but IMO _the most important thing_ is that *every* site could easily check from incoming packets with HAO, whether the HAO is is spoofed to belong to *destination site in question* or some other site the destination site trust at some level. This form of spoofing can be protected against now. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 09:03:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07H3SNg012057 for ; Mon, 7 Jan 2002 09:03:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07H3Sa9012056 for ipng-dist; Mon, 7 Jan 2002 09:03:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07H3PNg012049 for ; Mon, 7 Jan 2002 09:03:25 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11042 for ; Mon, 7 Jan 2002 09:03:30 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02805 for ; Mon, 7 Jan 2002 09:03:28 -0800 (PST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id MAA29638; Mon, 7 Jan 2002 12:03:17 -0500 (EST) From: "Subrata Goswami" To: "Brian E Carpenter" Cc: Subject: RE: Flow Label Date: Mon, 7 Jan 2002 09:06:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C397521.A5D1660F@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The main point is, if I am a provider and I get a packet, how can I be sure that some malicious entity in the middle has not modified the flow label so that it can avail of better QoS ? Second your assumption of not being able to handle flow label authentication may be too conservative in light of Moore's law and developments in optics. Third, not everybody works at the speed of 10GigE or OC-192 - there are networks that works at lower speed where it is entirely possible to do header processing in silicon even now. Fourth, you would still need to change a Proposed Standard - so while we are at it why not make it more complete. Also unless there is a mechanism to verify the immutation of the flow label, just saying it is immutable is akin to making a law and having no way to enforce it. So my vote ( I am not sure how much it is worth) would be not to make it immutable unless we provide a way to verify the immutation. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter Sent: Monday, January 07, 2002 2:15 AM To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label We've already discussed the weak trust model aspect. Basically nobody will be doing cryptographic authentication of the flow label at line speed, and if it isn't done at line speed what's the point? Brian Subrata Goswami wrote: > > The wording for immutability aside, to really enforce immutability > of the Flow Label , there must be a mechanism to verify that the > Flow Label has not been changed. As can be seen from the ICV computation > for IPv6 (RFC2402) even AH considers Flow label to be mutable. Hence there > needs to be a new IPv6 header option for Flow Label immutability. > > 3.3.3.1.2 ICV Computation for IPv6 > > 3.3.3.1.2.1 Base Header Fields > > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header (This should be the value for AH.) > Source Address > Destination Address (without Routing Extension Header) > > Mutable but predictable > Destination Address (with Routing Extension Header) > > Mutable (zeroed prior to ICV calculation) > Class > Flow Label > Hop Limit > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Charles E. Perkins > Sent: Friday, January 04, 2002 9:33 AM > To: Brian E Carpenter > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Flow Label > > Hello Brian, > > Brian E Carpenter wrote: > > > > And, truth in advertising, we have heard two dissenting > > views: > > > > a) that the field should be defined as MUST BE ZERO, i.e. > > the MAY clause below gets deleted > > I would say that MAY is a lot better. It suggests the truth, > which is that people are going to try to figure out ways to > use the flow label. It also motivates immutability. Otherwise, > it is possible that some router vendors could simply zero out > the field -- if it MUST BE ZERO, then zeroing it preserves > immutability... We wouldn't want that. > > > b) that the 3rd MUST should be SHOULD, i.e. immutability should > > be default instead of mandatory. > > Any future technique for using the flow label would, if it violates > immutability, be viewed as obsoleting this part of the specification > anyway. So I would hope for a MUST here. Language suggesting that > it is merely the default would allow for a tunable know in the user > interface labeled thusly: > "Flow Label treatment (default: do not change): " > to be filled in by the system administrator. Possible other values > selectable by the operator could be "randomize", "ones-complement", > "store current time", ... (?). I don't know why anyone would do > this, but I think we ought to be pretty clear about prohibiting it > at least for now. > > Regards, > Charlie P. > > > > > Brian > > > > Margaret Wasserman wrote: > > > > > > Hi George, > > > > > > Yes, we are "humming" in agreement to the proposal that we > > > replace section 6 of RFC 2460 with the following text: > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > source to label sets of packets. Nodes that do not support > > > > the Flow Label field MUST set the field to zero when originating a > > > > packet, and MUST ignore the field when receiving a packet. All > routers > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > This specification does not further define the meaning of the > > > > Flow Label. > > > > > > > > > > And that we delete Appendix A from RFC 2460. > > > > > > Actually, we probably won't update RFC 2460. We'll probably > > > just publish a separate RFC that updates 2460. > > > > > > Margaret > > > > > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > > > >Just a quick question from an interested lurker: Are these hums of > > > >acquiescence in response, specifically, to the idea that an originating > > > >node may set the flow label to any value, and that nodes forwarding > > > >packets will leave that value alone? -- George Mitchell > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 09:23:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07HNWNg012136 for ; Mon, 7 Jan 2002 09:23:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07HNWOp012135 for ipng-dist; Mon, 7 Jan 2002 09:23:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07HNTNg012128; Mon, 7 Jan 2002 09:23:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04110; Mon, 7 Jan 2002 09:23:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17974; Mon, 7 Jan 2002 09:23:33 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g07HNVb26193; Mon, 7 Jan 2002 18:23:31 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA12500; Mon, 7 Jan 2002 18:23:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g07HNUQ15139; Mon, 7 Jan 2002 18:23:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201071723.g07HNUQ15139@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 18:29:09 +0200. Date: Mon, 07 Jan 2002 18:23:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Nothing prevents from applying some kind of RR tests to HAO (without BU) use too. The HAO implementation would just be a .. little .. more complicated.. but then again it hasn't been defined in the spec anyway. => I believe the ".. little .. more complicated.." is a joke, isn't it? > (I think the solution for HAO should most likely consist of two > separate, "strong-enough" layers, one mandated at CN, one possible > at firewalls, but that's not the topic of this draft). > > => one mandated at CN == no third choice. One must be available for CN, because CN cannot trust the source if it isn't authenticated or in some form authorized. => again, if you rely on routing optimization (RO) or something equivalent then you close the door to the third choice (aka triangular routing). IMHO HAO has nothing to do with RO: if for sanity HAOs can be checked against the BCE (i.e. if they don't match something is wrong), the only way to reply to the iDDoS threat by this way is to mandate the check and to forbid HAOs without RO. [snip rest] I won't get into this more here, because I must say I agree almost 100% with comments from Pekka Nikander, Jari Arkko et al. (You should be very, very afraid if you ever venture in Finland, Francis ;-). => so you agree to kill triangular routing? One point I've made before: perhaps the check is trivial, but IMO _the most important thing_ is that *every* site could easily check from incoming packets with HAO, whether the HAO is is spoofed to belong to *destination site in question* or some other site the destination site trust at some level. => so the easiest solution for someone which doesn't want to implement or enable RO is just to drop HAOs. In France we have an expression for that: "la politique du pire". Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 09:40:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07HeVNg012389 for ; Mon, 7 Jan 2002 09:40:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07HeVkp012388 for ipng-dist; Mon, 7 Jan 2002 09:40:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07HeSNg012381 for ; Mon, 7 Jan 2002 09:40:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19890 for ; Mon, 7 Jan 2002 09:40:33 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11782 for ; Mon, 7 Jan 2002 10:41:39 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA02373; Mon, 7 Jan 2002 09:40:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g07HeVX23788; Mon, 7 Jan 2002 09:40:31 -0800 X-mProtect: Mon, 7 Jan 2002 09:40:31 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaKIpKd; Mon, 07 Jan 2002 09:40:28 PST Message-ID: <3C39DD8D.41FB94F6@iprg.nokia.com> Date: Mon, 07 Jan 2002 09:40:29 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Subrata Goswami CC: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Subrata, You wrote: > So my vote ( I am not sure how much it is worth) would be > not to make it immutable unless we provide a way to verify the > immutation. I think we ought to make it immutable now, and worry over verification later. Maybe it won't be very much later, but the specification for immutability should not be made to wait for it. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 10:48:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ImWNg012639 for ; Mon, 7 Jan 2002 10:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07ImWCp012638 for ipng-dist; Mon, 7 Jan 2002 10:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ImRNg012628; Mon, 7 Jan 2002 10:48:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07589; Mon, 7 Jan 2002 10:48:33 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03911; Mon, 7 Jan 2002 11:48:33 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07ImVt28740; Mon, 7 Jan 2002 12:48:31 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 12:46:43 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01530670@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Was Node Mobility a Requirement for IPng? Date: Mon, 7 Jan 2002 12:47:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C197AB.C695EA80" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C197AB.C695EA80 Content-Type: text/plain; charset="iso-8859-1" Francis, Thanks for the insight. These mobility and namespace things seem to keep coming up over and over in different groups with different names. Might as well call a duck a duck. I was just wondering if they affected the choice at all and if SIPP and MIPv6 were supposed to equal the functionality somehow. The add-on syndrome has proven to not give us ubiquity of any sort which IMO is what you want for a network layer. Thanks again, Glenn > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Sunday, January 06, 2002 10:57 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Was Node Mobility a Requirement for IPng? > > > Does anyone know if node mobility was a requirement for > IPng during the > debates among the proposals? > > => I believe it was but which kind of mobility? At least the current > Mobile IPv4 situation, i.e. bidirectional tunnel between the > mobile node > and its home agent. > > If so was SIPP supposed to rely on MIPv6 to fullfill this > requirement or are > these really disjunct with MIPv6 being an add on. > > => I don't believe for SIPP but PIP has some support for mobility > (look at the "Pip Near-term Arch" document section 14 "Host Mobility", > some of us preciously kept some copies of it). > > Regards > > Francis.Dupont@enst-bretagne.fr > ------_=_NextPart_001_01C197AB.C695EA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Was Node Mobility a Requirement for IPng? =

Francis,

Thanks for the insight. These mobility and namespace = things seem to keep coming up over and over in different groups with = different names. Might as well call a duck a duck. I was just wondering = if they affected the choice at all and if SIPP and MIPv6 were supposed = to equal the functionality somehow. The add-on syndrome has proven to = not give us ubiquity of any sort which IMO is what you want for a = network layer.

Thanks again,

Glenn

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@en= st-bretagne.fr]
> Sent: Sunday, January 06, 2002 10:57 AM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: ipng@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Was Node Mobility a = Requirement for IPng?
>
>
>    Does anyone know if node = mobility was a requirement for
> IPng during the
>    debates among the proposals? =
>    
> =3D> I believe it was but which kind of = mobility? At least the current
> Mobile IPv4 situation, i.e. bidirectional = tunnel between the
> mobile node
> and its home agent.
>
>    If so was SIPP supposed to = rely on MIPv6 to fullfill this
> requirement or are
>    these really disjunct with = MIPv6 being an add on.
>    
> =3D> I don't believe for SIPP but PIP has = some support for mobility
> (look at the "Pip Near-term Arch" = document section 14 "Host Mobility",
> some of us preciously kept some copies of = it).
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>

------_=_NextPart_001_01C197AB.C695EA80-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 11:18:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07JIoNg012952 for ; Mon, 7 Jan 2002 11:18:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07JIoBV012951 for ipng-dist; Mon, 7 Jan 2002 11:18:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07JIlNg012944 for ; Mon, 7 Jan 2002 11:18:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14659 for ; Mon, 7 Jan 2002 11:18:51 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00945 for ; Mon, 7 Jan 2002 12:18:50 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g07JICJ28687; Mon, 7 Jan 2002 11:18:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP90663; Mon, 7 Jan 2002 11:17:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA12736; Mon, 7 Jan 2002 11:18:11 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15417.62579.622952.287748@thomasm-u1.cisco.com> Date: Mon, 7 Jan 2002 11:18:11 -0800 (PST) To: Francis Dupont Cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201070903.g0793iQ13069@givry.rennes.enst-bretagne.fr> References: <00bf01c196d1$523f5ca0$8a1b6e0a@arenanet.fi> <200201070903.g0793iQ13069@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So here's a most-likely crazy idea: why can't we treat the ingress filtering router like a CN which must first be sent a BU which it verifies in whatever manner the CN would? This already has a requirement to not be bound to mythical PKI's, etc. Given FMIP, the access routers are probably going to end up having to process things like BU's anyway. Also: if we have ingress filtering taken care of directly, is there any reason to preserve the HAO at all? I thought its entire raison d'etre was to provide a means of coexisting with ingress filtering -- which we've already proven is just shifting the problem around instead of providing something useful. Mike Francis Dupont writes: > In your previous mail you wrote: > > > => this (to use AAA everywhere where there are mobile nodes) is the price > > to pay to have an alternative to bidirectional tunnels with home agents, > > i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling > > (i.e. real world mobile IPv4). > > This seems like a bad design tradeoff to me. We already have a > highly optimised mode of operation in MIPv6 (RO), > > => no, we have not this until the security problem is solved, > i.e. it works but we may not deploy it... > In fact (you sent this mail to the IPv6 WG mailing list only > so I can say that without being nuke in some minutes) if Mobile IPv6 > is expensive for CNs and only at the benefit of MNs it is in a real trouble. > IMHO Routing Optimization has this problem, obviously not the > bidirectional tunneling and not the triangular routing *if* > the reply to the ingress filtering problem is not the burden of CNs. > I disagree with most of the IESG security concerns with MIPv6 but > the statement "This has negative implications for larger servers that > process many 100s of thousands of connections at a time" is true, > not only for AH/IPsec SAs. > I think we must put the responsability of using HAOs to senders! > > and if you're > not using it you are falling back to something less efficient. Your > tradeoff improves the fallback solution a bit, but doesn't improve > the optimised solution. And the cost is extreme: > > => I disagree, and the cost of RO is really extreme for CNs so if > most of CNs just deny BUs we'll be happy to have a better fallback > solution. > > we need a new > global infrastructure (though I admit some of it will be built anyway), > > => first the implementation of smart ingress filtering and AAA is not > even a SHOULD (RFC 2827 is a BCP), it seems you believe it is a MUST. > Second the ingress filtering and HAOs is not a major security threat > (like unprotected BUs in an open network is). > To summary your argument would be valid if ingress filtering was mandatory > and efficient, but today ingress filtering is not used by every ISPs > and unfortunately to know where are the attackers is not enough to > stop DDoS. > > MIPv6 deployment is delayed, > > => no, the only possible effect on deployment is another argument is > favor of a better/real AAA. > > most if not all small sites and homes > will not be able to benefit from RO, etc. > > => I agree that to ask for a better network access control in general > stresses the trust/responsability problem. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: don't forget that the BCE check solution has many drawbacks: > - it doesn't work with not-MIPv6 uses of HAOs > - it doesn't work without routing optimization > - it makes CNs processing more complex/expensive > - BCEs should be hard state. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 12:06:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07K6INg013065 for ; Mon, 7 Jan 2002 12:06:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07K6IrT013064 for ipng-dist; Mon, 7 Jan 2002 12:06:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07K6ENg013057 for ; Mon, 7 Jan 2002 12:06:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25293 for ; Mon, 7 Jan 2002 12:06:19 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14086 for ; Mon, 7 Jan 2002 13:06:18 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id F0E65A; Mon, 7 Jan 2002 22:06:51 +0200 (EET) Message-ID: <3C39FFB7.7000303@nomadiclab.com> Date: Mon, 07 Jan 2002 22:06:15 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: Francis Dupont , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <00bf01c196d1$523f5ca0$8a1b6e0a@arenanet.fi> <200201070903.g0793iQ13069@givry.rennes.enst-bretagne.fr> <15417.62579.622952.287748@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > So here's a most-likely crazy idea: why can't we > treat the ingress filtering router like a CN which > must first be sent a BU which it verifies in > whatever manner the CN would? This already has a > requirement to not be bound to mythical PKI's, > etc. Given FMIP, the access routers are probably > going to end up having to process things like BU's > anyway. I was drifting into this direction myself. But how? Introduce a new ICMP message saying: send me a BU if you want to use HAO? > Also: if we have ingress filtering taken care of > directly, is there any reason to preserve the HAO > at all? I thought its entire raison d'etre was to > provide a means of coexisting with ingress > filtering -- which we've already proven is just > shifting the problem around instead of providing > something useful. Now THAT sounds like the most reasonable thing that I have heard about ingress filtering for a long time! To me, it seems like combinding RR and CGA, the ingress filtering router can fairly easily determine that the MN really "owns" the home address, and thereafter pass it. As an immediate reaction, the only problem seems to be that CGA requires fairly heavy CPU load. Could RR be enough in this case, since the CoA and HoA are on the different sides of the router? --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 12:12:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KCDNg013087 for ; Mon, 7 Jan 2002 12:12:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07KCDbh013086 for ipng-dist; Mon, 7 Jan 2002 12:12:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KCANg013079 for ; Mon, 7 Jan 2002 12:12:10 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27125 for ; Mon, 7 Jan 2002 12:12:15 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29837 for ; Mon, 7 Jan 2002 12:12:14 -0800 (PST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id PAA30097; Mon, 7 Jan 2002 15:14:48 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA02703; Mon, 7 Jan 2002 15:14:47 -0500 Message-ID: <3C3A017F.8FE859EB@txc.com> Date: Mon, 07 Jan 2002 15:13:51 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Subrata Goswami CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms44A46AC3B890DC00D88A8F77" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms44A46AC3B890DC00D88A8F77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The facts you mentioned (checksum and AH calculation) are wellknown, but a clear reminder is certainly useful for those who forgot, or ignored that. One of the comments pro "immutability" was that you cannot trust the flow label if it is not "immutable". But the no way to enforce or validate it -- possibly grotesque inconsistency -- is not why I am NOT for "immutability". The list of the flow setup and flow processing mechanisms is an open list: we do not know today all possible ways in which the flow label would be setup or used, in 10 or 20 years from now. Current or future flow setup and flow processing mechanisms, do now, or will, in the future, KNOW BEST the micro-details of the flow label usage. Therefore responsibility of the immutability/mutability of the flow label value should stay ALONE with those mechanisms. By leaving mutability alone, possible issues with checksum, and AH calculation can be really forgotten, or ignored. Alex Subrata Goswami wrote: > > The main point is, if I am a provider and I get a packet, how can > I be sure that some malicious entity in the middle has not modified > the flow label so that it can avail of better QoS ? Second your > assumption of not being able to handle flow label authentication may be > too conservative in light of Moore's law and developments in optics. > Third, not everybody works at the speed of 10GigE or OC-192 - there > are networks that works at lower speed where it is entirely possible > to do header processing in silicon even now. Fourth, you would still > need to change a Proposed Standard - so while we are at it why not > make it more complete. > > Also unless there is a mechanism to verify the immutation of the > flow label, just saying it is immutable is akin to making a law > and having no way to enforce it. > > So my vote ( I am not sure how much it is worth) would be > not to make it immutable unless we provide a way to verify the > immutation. > > Subrata > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter > Sent: Monday, January 07, 2002 2:15 AM > To: Subrata Goswami > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Flow Label > > We've already discussed the weak trust model aspect. Basically nobody will > be > doing cryptographic authentication of the flow label at line speed, and if > it isn't > done at line speed what's the point? > > Brian > > Subrata Goswami wrote: > > > > The wording for immutability aside, to really enforce immutability > > of the Flow Label , there must be a mechanism to verify that the > > Flow Label has not been changed. As can be seen from the ICV computation > > for IPv6 (RFC2402) even AH considers Flow label to be mutable. Hence > there > > needs to be a new IPv6 header option for Flow Label immutability. > > > > 3.3.3.1.2 ICV Computation for IPv6 > > > > 3.3.3.1.2.1 Base Header Fields > > > > The IPv6 base header fields are classified as follows: > > > > Immutable > > Version > > Payload Length > > Next Header (This should be the value for AH.) > > Source Address > > Destination Address (without Routing Extension Header) > > > > Mutable but predictable > > Destination Address (with Routing Extension Header) > > > > Mutable (zeroed prior to ICV calculation) > > Class > > Flow Label > > Hop Limit > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Charles E. Perkins > > Sent: Friday, January 04, 2002 9:33 AM > > To: Brian E Carpenter > > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > > Subject: Re: Flow Label > > > > Hello Brian, > > > > Brian E Carpenter wrote: > > > > > > And, truth in advertising, we have heard two dissenting > > > views: > > > > > > a) that the field should be defined as MUST BE ZERO, i.e. > > > the MAY clause below gets deleted > > > > I would say that MAY is a lot better. It suggests the truth, > > which is that people are going to try to figure out ways to > > use the flow label. It also motivates immutability. Otherwise, > > it is possible that some router vendors could simply zero out > > the field -- if it MUST BE ZERO, then zeroing it preserves > > immutability... We wouldn't want that. > > > > > b) that the 3rd MUST should be SHOULD, i.e. immutability should > > > be default instead of mandatory. > > > > Any future technique for using the flow label would, if it violates > > immutability, be viewed as obsoleting this part of the specification > > anyway. So I would hope for a MUST here. Language suggesting that > > it is merely the default would allow for a tunable know in the user > > interface labeled thusly: > > "Flow Label treatment (default: do not change): " > > to be filled in by the system administrator. Possible other values > > selectable by the operator could be "randomize", "ones-complement", > > "store current time", ... (?). I don't know why anyone would do > > this, but I think we ought to be pretty clear about prohibiting it > > at least for now. > > > > Regards, > > Charlie P. > > > > > > > > Brian > > > > > > Margaret Wasserman wrote: > > > > > > > > Hi George, > > > > > > > > Yes, we are "humming" in agreement to the proposal that we > > > > replace section 6 of RFC 2460 with the following text: > > > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > > source to label sets of packets. Nodes that do not support > > > > > the Flow Label field MUST set the field to zero when originating a > > > > > packet, and MUST ignore the field when receiving a packet. All > > routers > > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > > > This specification does not further define the meaning of the > > > > > Flow Label. > > > > > > > > > > > > > And that we delete Appendix A from RFC 2460. > > > > > > > > Actually, we probably won't update RFC 2460. We'll probably > > > > just publish a separate RFC that updates 2460. > > > > > > > > Margaret > > > > > > > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > > > > >Just a quick question from an interested lurker: Are these hums of > > > > >acquiescence in response, specifically, to the idea that an > originating > > > > >node may set the flow label to any value, and that nodes forwarding > > > > >packets will leave that value alone? -- George Mitchell > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms44A46AC3B890DC00D88A8F77 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMDcyMDEzNTNaMCMGCSqGSIb3DQEJ BDEWBBT7Oz+aWmvIB04YzhjpnnDOlB2W1DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgDG1R7GOU5lxk0UuRZ6QMFnfQoNbYSsqDhHi2lBrxKeie1so IvJIru8+NdrI0SOJusHEkXDhqgW/01/qUz8OCVwSpAYmOCnbvIMS9/WHgng/bYvEqJ5GRizg WTz0quh4d4U4oJP/8yWtDDmVvAMBmZc1R6ZXP7NA6dj/VJfLzr8t --------------ms44A46AC3B890DC00D88A8F77-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 12:23:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KN7Ng013147 for ; Mon, 7 Jan 2002 12:23:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07KN78V013146 for ipng-dist; Mon, 7 Jan 2002 12:23:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KN4Ng013139 for ; Mon, 7 Jan 2002 12:23:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03318 for ; Mon, 7 Jan 2002 12:23:09 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18825 for ; Mon, 7 Jan 2002 13:23:07 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g07KMi930388; Mon, 7 Jan 2002 22:22:45 +0200 Date: Mon, 7 Jan 2002 22:22:44 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: Michael Thomas , Francis Dupont , Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <3C39FFB7.7000303@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 7 Jan 2002, Pekka Nikander wrote: > Michael Thomas wrote: > > Also: if we have ingress filtering taken care of > > directly, is there any reason to preserve the HAO > > at all? I thought its entire raison d'etre was to > > provide a means of coexisting with ingress > > filtering -- which we've already proven is just > > shifting the problem around instead of providing > > something useful. > > Now THAT sounds like the most reasonable thing that > I have heard about ingress filtering for a long time! > > To me, it seems like combinding RR and CGA, the > ingress filtering router can fairly easily determine > that the MN really "owns" the home address, and > thereafter pass it. As an immediate reaction, the > only problem seems to be that CGA requires fairly > heavy CPU load. Could RR be enough in this case, > since the CoA and HoA are on the different sides > of the router? Moreover, ingress filtering is usually performed at more than one router. The network manager of the LAN might perform it. The network manager of the site should perform it. The network manager of the ISP should also perform it. Etc. Therefore, this "notification" or "ingress filtering registration" would have to operate a bit like path MTU discovery or a router alert option. Also, this would get more difficult in the case of multiple, changing paths (multihoming). Certainly an interesting idea, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 12:27:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KRZNg013169 for ; Mon, 7 Jan 2002 12:27:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07KRZbY013168 for ipng-dist; Mon, 7 Jan 2002 12:27:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KRWNg013161; Mon, 7 Jan 2002 12:27:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25482; Mon, 7 Jan 2002 12:27:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03124; Mon, 7 Jan 2002 12:27:36 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g07KRYP30420; Mon, 7 Jan 2002 22:27:34 +0200 Date: Mon, 7 Jan 2002 22:27:34 +0200 (EET) From: Pekka Savola To: cc: Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201071723.g07HNUQ15139@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 7 Jan 2002, Francis Dupont wrote: > Nothing prevents from applying some kind of RR tests to HAO (without BU) > use too. The HAO implementation would just be a .. little .. more > complicated.. but then again it hasn't been defined in the spec anyway. > > => I believe the ".. little .. more complicated.." is a joke, isn't it? Of course. :-) [snip] > I won't get into this more here, because I must say I agree almost 100% > with comments from Pekka Nikander, Jari Arkko et al. (You should be very, > very afraid if you ever venture in Finland, Francis ;-). > > => so you agree to kill triangular routing? What's the point of it, really? If you don't want routing optiomization, nothing prevents you from establishing tunnels to your home agent: no need for HAO etc. either then. This is probably better for TCP and the like which like symmetric propagation properties. > One point I've made before: perhaps the check is trivial, but IMO _the > most important thing_ is that *every* site could easily check from > incoming packets with HAO, whether the HAO is is spoofed to belong to > *destination site in question* or some other site the destination site > trust at some level. > > => so the easiest solution for someone which doesn't want to implement > or enable RO is just to drop HAOs. In France we have an expression for > that: "la politique du pire". Sure, if that only means the connections will break if the MN moves. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 12:30:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KUGNg013246 for ; Mon, 7 Jan 2002 12:30:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07KUGrL013245 for ipng-dist; Mon, 7 Jan 2002 12:30:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KUCNg013238 for ; Mon, 7 Jan 2002 12:30:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23437 for ; Mon, 7 Jan 2002 12:30:17 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24061 for ; Mon, 7 Jan 2002 13:29:59 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g07KU8401082; Mon, 7 Jan 2002 12:30:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP92855; Mon, 7 Jan 2002 12:29:35 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA12747; Mon, 7 Jan 2002 12:30:07 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.1359.224876.629706@thomasm-u1.cisco.com> Date: Mon, 7 Jan 2002 12:30:07 -0800 (PST) To: Pekka Savola Cc: Pekka Nikander , Michael Thomas , Francis Dupont , Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: References: <3C39FFB7.7000303@nomadiclab.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola writes: > On Mon, 7 Jan 2002, Pekka Nikander wrote: > > Michael Thomas wrote: > Moreover, ingress filtering is usually performed at more than one router. > > The network manager of the LAN might perform it. The network manager of > the site should perform it. The network manager of the ISP should also > perform it. Etc. > > Therefore, this "notification" or "ingress filtering registration" would > have to operate a bit like path MTU discovery or a router alert option. > Also, this would get more difficult in the case of multiple, changing > paths (multihoming). > > Certainly an interesting idea, though. This entire question is being begged by multihoming which RPF checks fail at pretty miserably. And of course, asymmetric routes. We need something better. Essentially, I think what I'm proposing is something in lieu of RPF checks. The open question is whether we can make this pervasive too. If we can, we can safely turn off RPF checks. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 12:35:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KZFNg013332 for ; Mon, 7 Jan 2002 12:35:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07KZF0e013331 for ipng-dist; Mon, 7 Jan 2002 12:35:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KZCNg013324 for ; Mon, 7 Jan 2002 12:35:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27312 for ; Mon, 7 Jan 2002 12:35:17 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22597 for ; Mon, 7 Jan 2002 13:35:16 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g07KYPk14037; Mon, 7 Jan 2002 12:34:27 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP92975; Mon, 7 Jan 2002 12:34:14 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA12750; Mon, 7 Jan 2002 12:34:46 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.1638.828954.275439@thomasm-u1.cisco.com> Date: Mon, 7 Jan 2002 12:34:46 -0800 (PST) To: Pekka Nikander Cc: Michael Thomas , Francis Dupont , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <3C39FFB7.7000303@nomadiclab.com> References: <00bf01c196d1$523f5ca0$8a1b6e0a@arenanet.fi> <200201070903.g0793iQ13069@givry.rennes.enst-bretagne.fr> <15417.62579.622952.287748@thomasm-u1.cisco.com> <3C39FFB7.7000303@nomadiclab.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander writes: > Michael Thomas wrote: > > > So here's a most-likely crazy idea: why can't we > > treat the ingress filtering router like a CN which > > must first be sent a BU which it verifies in > > whatever manner the CN would? This already has a > > requirement to not be bound to mythical PKI's, > > etc. Given FMIP, the access routers are probably > > going to end up having to process things like BU's > > anyway. > > > I was drifting into this direction myself. But how? > Introduce a new ICMP message saying: send me a BU > if you want to use HAO? Sounds good to me. This also takes care of the case where somebody has RPF checks running farther into the network. I would expect that a MN would always send the BU to its access router. Making this a MUST implement for a v6 router would probably be a good thing too. > > Also: if we have ingress filtering taken care of > > directly, is there any reason to preserve the HAO > > at all? I thought its entire raison d'etre was to > > provide a means of coexisting with ingress > > filtering -- which we've already proven is just > > shifting the problem around instead of providing > > something useful. > > Now THAT sounds like the most reasonable thing that > I have heard about ingress filtering for a long > time! Heavens. Didn't mean to scare anybody :-) > To me, it seems like combinding RR and CGA, the > ingress filtering router can fairly easily determine > that the MN really "owns" the home address, and > thereafter pass it. As an immediate reaction, the > only problem seems to be that CGA requires fairly > heavy CPU load. Could RR be enough in this case, > since the CoA and HoA are on the different sides > of the router? I think that if RR is viable for anything, it's probably fine for lifting RPF checks. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 7 20:31:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g084VTNg014087 for ; Mon, 7 Jan 2002 20:31:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g084VTUw014086 for ipng-dist; Mon, 7 Jan 2002 20:31:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g084VQNg014079 for ; Mon, 7 Jan 2002 20:31:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27391 for ; Mon, 7 Jan 2002 20:31:32 -0800 (PST) Received: from mailweb16.rediffmail.com ([203.199.83.28]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA04936 for ; Mon, 7 Jan 2002 21:32:39 -0700 (MST) Received: (qmail 15887 invoked by uid 510); 8 Jan 2002 04:29:44 -0000 Date: 8 Jan 2002 04:29:44 -0000 Message-ID: <20020108042944.15886.qmail@mailweb16.rediffmail.com> Received: from unknown (203.196.145.150) by rediffmail.com via HTTP; 08 Jan 2002 04:29:44 -0000 MIME-Version: 1.0 From: "Ramakrishnan" Reply-To: "Ramakrishnan" To: ipng@sunroof.eng.sun.com Subject: Query About IPv6 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g084VRNg014080 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Sir/Madam, I have some queries regarding IPv6. I am still in the learning stage. So, my question may look very simple for you, but if you answer it, that will help me a lot. 1. What are the entries in the routing table under IPv6? 2. Can an Interface have more than one link local address? I'll be looking forward for the answers... regards, Ramakrishnan. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 01:24:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g089ObNg014841 for ; Tue, 8 Jan 2002 01:24:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g089ObkC014840 for ipng-dist; Tue, 8 Jan 2002 01:24:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g089OXNg014833 for ; Tue, 8 Jan 2002 01:24:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17113 for ; Tue, 8 Jan 2002 01:24:38 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20174 for ; Tue, 8 Jan 2002 02:24:19 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g089OPb12133; Tue, 8 Jan 2002 10:24:25 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA23567; Tue, 8 Jan 2002 10:24:25 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g089OOQ17946; Tue, 8 Jan 2002 10:24:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201080924.g089OOQ17946@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 11:18:11 PST. <15417.62579.622952.287748@thomasm-u1.cisco.com> Date: Tue, 08 Jan 2002 10:24:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: So here's a most-likely crazy idea: why can't we treat the ingress filtering router like a CN which must first be sent a BU which it verifies in whatever manner the CN would? This already has a requirement to not be bound to mythical PKI's, etc. Given FMIP, the access routers are probably going to end up having to process things like BU's anyway. => I suggest this in the smart anti-spoofing section (because this is what we used and the alternative is based on remote network access control or HA collaboration, i.e. something which needs a protocol) but this has many drawbacks: - if there is more than one path, some coordination is needed between routers on these paths - this works if HAOs are not used before BUs (with standard mobility, this is true because of home registrations but this is a restriction) - this puts constraints on how BUs/BAs are protected (no ESP hiding some parameters like the home address) - as a special case of the previous point, it is fine to be able to check the status in BAs of home registrations - this is complex and expensive (this is not bound to the number of MNs inside the site, this argument doesn't apply for the anti-spoofing because HAs are in general statically configured and in case of a flood of home registrations HAs should be overloaded before firewalls). So I believe this is a good complement but not a good candidate for smart ingress filtering. Also: if we have ingress filtering taken care of directly, is there any reason to preserve the HAO at all? I thought its entire raison d'etre was to provide a means of coexisting with ingress filtering -- which we've already proven is just shifting the problem around instead of providing something useful. => if I understand well your idea, you propose to disable traditional ingress filtering (so HAOs are no more useful). I believe this depends on the fraction of packets with HAOs, if it is high then I agree with you, if it is low then I believe ingress filtering remains useful... Regards Francis.Dupont@enst-bretagne.fr PS: I take advantage of this discussion to argue in favor of better network access control. It seems that today DDoS bad guys no more use random source address (i.e. ingress filtering is more efficient than one can believe), they try source addresses in the same prefix (change last bits in IPv4) in order to vary them (more harm for the target, counter measure more difficult). Of course this is easier for IPv6 but with a good network access control (even passive, i.e. the maximum number of boxes in a side is known) this can be detected and in many cases be fixed. (Thanks to Stanislav Shalunov who brought this point to my attention. Even if the purpose is to save the HAO by a reply on the paper to the traceback threat, it is fine to provide more applicable weapons against DDoSs) (Of course, a good network access control doesn't fit well with RFC 3041 but we already know there are some tradeoffs between privacy and access control :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 02:22:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AMwNg014930 for ; Tue, 8 Jan 2002 02:22:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08AMwwm014929 for ipng-dist; Tue, 8 Jan 2002 02:22:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AMtNg014922 for ; Tue, 8 Jan 2002 02:22:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00584 for ; Tue, 8 Jan 2002 02:22:59 -0800 (PST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA14615 for ; Tue, 8 Jan 2002 03:24:06 -0700 (MST) Received: from cnniczh ([159.226.7.114]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GPM7KA00.BHM; Tue, 8 Jan 2002 18:24:10 +0800 Message-ID: <03de01c1982e$9cb9e2b0$01000001@cnniczh> Reply-To: "zhang hong" From: "zhang hong" To: "Ramakrishnan" Cc: References: <20020108042944.15886.qmail@mailweb16.rediffmail.com> Subject: Re: Query About IPv6 Date: Tue, 8 Jan 2002 18:24:10 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1. The routing table under IPv6 is very similar to that of IPv4. For example, In my cisco router, one of the route entries is as following(see the Cisco reference for detail): B 3FFE:2401::/32 [20/3] via FE80::806B:F0FE, Tunnel4, 00:37:14/never In this entry: B - BGP protocol 3FFE:2401::/32 - prefix of the remote network [20/3] - The first is the administrative distance of the information source; the second number is the metric for the route via FE80::806B:F0FE - next router Tunnel4 - interface to remote network 00:37:14/never - route update time / route expire time And in linux, the route table entry consists of "Destination , Next Hop, Flags, Metric, Ref, Use, Iface" , almost the same as IPv4. 2. The link local address is generated automaticlly when u config the interface to support Ipv6. and it can be added manually to more than one( I have tried in RH Linux7, but don't know the reason to have more link local address) . Happy new year! : ) Zhang Hong ----- Original Message ----- From: "Ramakrishnan" To: Sent: Tuesday, January 08, 2002 12:29 PM Subject: Query About IPv6 > > Dear Sir/Madam, > > I have some queries regarding IPv6. I am still in the learning stage. So, my question may look very simple for you, but if you answer it, that will help me a lot. > > 1. What are the entries in the routing table under IPv6? > 2. Can an Interface have more than one link local address? > > I'll be looking forward for the answers... > > regards, > Ramakrishnan. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 02:26:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AQKNg014949 for ; Tue, 8 Jan 2002 02:26:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08AQJie014948 for ipng-dist; Tue, 8 Jan 2002 02:26:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AQGNg014941 for ; Tue, 8 Jan 2002 02:26:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00974 for ; Tue, 8 Jan 2002 02:26:21 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18730 for ; Tue, 8 Jan 2002 03:26:02 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g08AQ6b21390; Tue, 8 Jan 2002 11:26:06 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA24731; Tue, 8 Jan 2002 11:26:06 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g08AQ6Q18134; Tue, 8 Jan 2002 11:26:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081026.g08AQ6Q18134@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 22:06:15 +0200. <3C39FFB7.7000303@nomadiclab.com> Date: Tue, 08 Jan 2002 11:26:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > So here's a most-likely crazy idea: why can't we > treat the ingress filtering router like a CN which > must first be sent a BU which it verifies in > whatever manner the CN would? This already has a > requirement to not be bound to mythical PKI's, > etc. Given FMIP, the access routers are probably > going to end up having to process things like BU's > anyway. I was drifting into this direction myself. But how? Introduce a new ICMP message saying: send me a BU if you want to use HAO? => no, Michael's idea is to look at packets going through access routers in order to find BUs (i.e. this is passive). And if you'd like to use an active scheme, why not the network access control? To me, it seems like combinding RR and CGA, the ingress filtering router can fairly easily determine that the MN really "owns" the home address, and thereafter pass it. => I believe this is overkilling to ask for verification of home addresses. To know bindings is enough to make HAO spoofing not attractive. As an immediate reaction, the only problem seems to be that CGA requires fairly heavy CPU load. => both CPU load and IPR issue: enough to kill any good idea. Could RR be enough in this case, since the CoA and HoA are on the different sides of the router? => I don't know what is RR in this case (not only check that CoA is inside and HoA is outside?). I suggest to look at BAs too, i.e. at least home agents are far better equipped to verify BUs! (note that I still believe this is overkilling) Regards Francis.Dupont@enst-bretagne.fr PS: the main issue is this restricts the use of HAOs to mobility (i.e. to use the network access control is better). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 02:28:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08ASqNg014969 for ; Tue, 8 Jan 2002 02:28:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08ASqFE014968 for ipng-dist; Tue, 8 Jan 2002 02:28:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08ASmNg014961 for ; Tue, 8 Jan 2002 02:28:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01215 for ; Tue, 8 Jan 2002 02:28:53 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19960 for ; Tue, 8 Jan 2002 03:28:34 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g08ASQb21731; Tue, 8 Jan 2002 11:28:26 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA24784; Tue, 8 Jan 2002 11:28:26 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g08ASQQ18161; Tue, 8 Jan 2002 11:28:26 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081028.g08ASQQ18161@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Pekka Nikander , Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 22:22:44 +0200. Date: Tue, 08 Jan 2002 11:28:26 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Also, this would get more difficult in the case of multiple, changing paths (multihoming). => as multi-homing is a place we could want to use home address options this is a real issue... Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 02:31:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AVtNg014986 for ; Tue, 8 Jan 2002 02:31:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08AVtq7014985 for ipng-dist; Tue, 8 Jan 2002 02:31:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AVqNg014978; Tue, 8 Jan 2002 02:31:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10381; Tue, 8 Jan 2002 02:31:57 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21428; Tue, 8 Jan 2002 03:31:37 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g08AVsb22165; Tue, 8 Jan 2002 11:31:54 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA24887; Tue, 8 Jan 2002 11:31:54 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g08AVrQ18185; Tue, 8 Jan 2002 11:31:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081031.g08AVrQ18185@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 22:27:34 +0200. Date: Tue, 08 Jan 2002 11:31:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Sure, if that only means the connections will break if the MN moves. => no, that only means the only solution is to use a bidirectional tunnel with the home agent (i.e. we are back to the current mobile IPv4 situation). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 02:48:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AmWNg015185 for ; Tue, 8 Jan 2002 02:48:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08AmWaM015184 for ipng-dist; Tue, 8 Jan 2002 02:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AmTNg015177 for ; Tue, 8 Jan 2002 02:48:29 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03816 for ; Tue, 8 Jan 2002 02:48:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07280 for ; Tue, 8 Jan 2002 02:48:29 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g08Ae6b23117; Tue, 8 Jan 2002 11:40:06 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA25050; Tue, 8 Jan 2002 11:40:06 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g08Ae5Q18222; Tue, 8 Jan 2002 11:40:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081040.g08Ae5Q18222@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Pekka Savola , Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 12:30:07 PST. <15418.1359.224876.629706@thomasm-u1.cisco.com> Date: Tue, 08 Jan 2002 11:40:05 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: This entire question is being begged by multihoming which RPF checks fail at pretty miserably. And of course, asymmetric routes. We need something better. Essentially, I think what I'm proposing is something in lieu of RPF checks. The open question is whether we can make this pervasive too. If we can, we can safely turn off RPF checks. => the idea that RPF checks always fail with multihoming is a myth (cf http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf). Regards Francis.Dupont@enst-bretagne.fr PS: don't forget we don't need an absolute reply to source address spoofing, in fact it seems that with the current deployment of ingress filtering, random source address spoofing is enough unattractive. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 02:48:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AmtNg015195 for ; Tue, 8 Jan 2002 02:48:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08Amsac015194 for ipng-dist; Tue, 8 Jan 2002 02:48:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AmoNg015187 for ; Tue, 8 Jan 2002 02:48:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26459 for ; Tue, 8 Jan 2002 02:48:55 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11642 for ; Tue, 8 Jan 2002 03:48:54 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g08AmZb04359; Tue, 8 Jan 2002 12:48:35 +0200 Date: Tue, 8 Jan 2002 12:48:35 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Pekka Nikander , Michael Thomas , Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201081028.g08ASQQ18161@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 8 Jan 2002, Francis Dupont wrote: > In your previous mail you wrote: > > Also, this would get more difficult in the case of multiple, changing > paths (multihoming). > > => as multi-homing is a place we could want to use home address options > this is a real issue... I've always thought using Home Address option as a way of getting around ingress filtering checks in multihoming is like "if words fail you, mumble!" -approach. Much more analysis is needed IMO before HAO is to be used outside of MIPv6 context. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 04:11:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08CBSNg015497 for ; Tue, 8 Jan 2002 04:11:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08CBSei015496 for ipng-dist; Tue, 8 Jan 2002 04:11:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08CBPNg015489 for ; Tue, 8 Jan 2002 04:11:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11807 for ; Tue, 8 Jan 2002 04:11:28 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA19903 for ; Tue, 8 Jan 2002 05:12:36 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g08BAWb28384; Tue, 8 Jan 2002 12:10:33 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA25805; Tue, 8 Jan 2002 12:10:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g08BAWQ18568; Tue, 8 Jan 2002 12:10:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081110.g08BAWQ18568@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Pekka Nikander , Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Tue, 08 Jan 2002 12:48:35 +0200. Date: Tue, 08 Jan 2002 12:10:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => as multi-homing is a place we could want to use home address options > this is a real issue... I've always thought using Home Address option as a way of getting around ingress filtering checks in multihoming is like "if words fail you, mumble!" -approach. => I agree if it is only a way of getting around ingress filtering checks but there are some situations where to have more than one source address is very fine. And don't forget the degenerate tunneling argument. Much more analysis is needed IMO before HAO is to be used outside of MIPv6 context. => yes and to provide an independent and complete definition of HAO should be very useful too. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 08:40:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08GeCNg016060 for ; Tue, 8 Jan 2002 08:40:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08GeCo2016059 for ipng-dist; Tue, 8 Jan 2002 08:40:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08Ge9Ng016052 for ; Tue, 8 Jan 2002 08:40:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14516 for ; Tue, 8 Jan 2002 08:40:13 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10359 for ; Tue, 8 Jan 2002 09:40:13 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08GdxF01031; Tue, 8 Jan 2002 08:39:59 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAQ09395; Tue, 8 Jan 2002 08:39:26 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA13100; Tue, 8 Jan 2002 08:39:58 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.8414.384615.139500@thomasm-u1.cisco.com> Date: Tue, 8 Jan 2002 08:39:58 -0800 (PST) To: Francis Dupont Cc: Pekka Nikander , Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201081026.g08AQ6Q18134@givry.rennes.enst-bretagne.fr> References: <3C39FFB7.7000303@nomadiclab.com> <200201081026.g08AQ6Q18134@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > > So here's a most-likely crazy idea: why can't we > > treat the ingress filtering router like a CN which > > must first be sent a BU which it verifies in > > whatever manner the CN would? This already has a > > requirement to not be bound to mythical PKI's, > > etc. Given FMIP, the access routers are probably > > going to end up having to process things like BU's > > anyway. > > I was drifting into this direction myself. But how? > Introduce a new ICMP message saying: send me a BU > if you want to use HAO? > > => no, Michael's idea is to look at packets going through > access routers in order to find BUs (i.e. this is passive). > And if you'd like to use an active scheme, why not the > network access control? No, actually, it was to have the MN send the BU's directly to the access router. On a router the BU just has an additional effect of removing any restrictions on source addresses it will let through. Hence Pekka's question about use of ICMP was correct. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 08:43:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08GhZNg016080 for ; Tue, 8 Jan 2002 08:43:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08GhZS2016079 for ipng-dist; Tue, 8 Jan 2002 08:43:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08GhWNg016072 for ; Tue, 8 Jan 2002 08:43:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07911 for ; Tue, 8 Jan 2002 08:43:36 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18095 for ; Tue, 8 Jan 2002 08:43:35 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08GhRF03276; Tue, 8 Jan 2002 08:43:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAQ09447; Tue, 8 Jan 2002 08:42:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA13103; Tue, 8 Jan 2002 08:43:27 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.8623.247757.734122@thomasm-u1.cisco.com> Date: Tue, 8 Jan 2002 08:43:27 -0800 (PST) To: Francis Dupont Cc: Pekka Savola , Pekka Nikander , Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201081028.g08ASQQ18161@givry.rennes.enst-bretagne.fr> References: <200201081028.g08ASQQ18161@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > Also, this would get more difficult in the case of multiple, changing > paths (multihoming). > > => as multi-homing is a place we could want to use home address options > this is a real issue... I think we need to take a step back here. If you could do route optimization effectively and use the "home address" you started a session with, there isn't any motivation for a separate identifier in the packet, right? CoA would always be a routing construct. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 08:52:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08Gq7Ng016100 for ; Tue, 8 Jan 2002 08:52:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08Gq78t016099 for ipng-dist; Tue, 8 Jan 2002 08:52:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08Gq3Ng016092 for ; Tue, 8 Jan 2002 08:52:03 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17032 for ; Tue, 8 Jan 2002 08:52:08 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29410 for ; Tue, 8 Jan 2002 08:52:07 -0800 (PST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GPM0011SPIRIM@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Tue, 08 Jan 2002 10:52:03 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g08Gq3l06548 for ; Tue, 08 Jan 2002 10:52:03 -0600 (CST) Date: Tue, 08 Jan 2002 10:52:03 -0600 From: Matt Crawford Subject: Re: I-D ACTION:draft-goswami-ipv6-discovery-link-option-00.txt In-reply-to: "08 Jan 2002 08:46:19 EST." <200201081346.IAA20693@ietf.org> To: ipng@sunroof.eng.sun.com Message-id: <200201081652.g08Gq3l06548@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm afraid I don't get it. The proposed new option does nothing the existing source/target link layer options don't do. On a medium "foonet" with a variable length link-layer address, you'd have to encode the length of the address in the link-layer address field either way. (Actually, I'd imagine the length would be likely to be self-encoding, but that's irrelevant.) You can specify it in your ipv6-over-foonet document. Unless you're envisioning some new way to transmit frames over an existing physical layer with new address formats ...? And I assume this is a typo of some sort: Length The length of the option (including the type and length fields) in units of 1/8 th octets. Forexample, the length for IEEE 802 addresses is 1 [IPv6- ETHER]. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 09:05:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08H5iNg016122 for ; Tue, 8 Jan 2002 09:05:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08H5hV1016121 for ipng-dist; Tue, 8 Jan 2002 09:05:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08H5eNg016114 for ; Tue, 8 Jan 2002 09:05:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23156 for ; Tue, 8 Jan 2002 09:05:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07568 for ; Tue, 8 Jan 2002 10:05:26 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g08H5gb20431 for ; Tue, 8 Jan 2002 18:05:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA04190 for ; Tue, 8 Jan 2002 18:05:42 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g08H5gQ21789 for ; Tue, 8 Jan 2002 18:05:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081705.g08H5gQ21789@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: draft-goswami-ipv6-discovery-link-option-00.txt Date: Tue, 08 Jan 2002 18:05:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is this a joke or the notion of padding so obscure? RFC 2529 (aka 6over4) is an example of a link-layer address which is not 6+8*n, RFC 2492 (IPv6 over ATM) is an example of a complex and variable length link-layer address format in neighbor discovery extension! Francis.Dupont@enst-bretagne.fr PS: fortunately I am not in the acknowledgment section (:-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 09:40:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08He3Ng016168 for ; Tue, 8 Jan 2002 09:40:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08He3Tw016167 for ipng-dist; Tue, 8 Jan 2002 09:40:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08He0Ng016160 for ; Tue, 8 Jan 2002 09:40:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27009 for ; Tue, 8 Jan 2002 09:40:05 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00812 for ; Tue, 8 Jan 2002 10:40:04 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g08Hdib30978; Tue, 8 Jan 2002 18:39:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA05166; Tue, 8 Jan 2002 18:39:45 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g08HdiQ21918; Tue, 8 Jan 2002 18:39:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081739.g08HdiQ21918@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Tue, 08 Jan 2002 08:39:58 PST. <15419.8414.384615.139500@thomasm-u1.cisco.com> Date: Tue, 08 Jan 2002 18:39:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: No, actually, it was to have the MN send the BU's directly to the access router. On a router the BU just has an additional effect of removing any restrictions on source addresses it will let through. => I believed your proposal was BU snooping. But you can name it as you'd like, the purpose is to provide the knowledge of bindings, so there is no deep difference with my proposal (i.e. I can say you use a non-standard network access control device, as I don't specify one (I only give an example with AAA because it is the best on the paper) I could argue your proposal is included in mine :-). Hence Pekka's question about use of ICMP was correct. => I am reluctant to define new ICMPs for anything. There is already a format for BUs, why a new thing? Another point: HAOs are inside packets, to look at them is legitimate for my firewall but not for any router on the path, i.e. I'd like to have the check done once and others to trust it (this idea is exactly the network access control). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 10:20:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08IKaNg016217 for ; Tue, 8 Jan 2002 10:20:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08IKZ5A016216 for ipng-dist; Tue, 8 Jan 2002 10:20:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08IKWNg016209; Tue, 8 Jan 2002 10:20:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20345; Tue, 8 Jan 2002 10:20:36 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13796; Tue, 8 Jan 2002 11:20:36 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g08IKQJ22990; Tue, 8 Jan 2002 10:20:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAQ11895; Tue, 8 Jan 2002 10:19:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13118; Tue, 8 Jan 2002 10:20:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.14441.941556.661985@thomasm-u1.cisco.com> Date: Tue, 8 Jan 2002 10:20:25 -0800 (PST) To: Francis Dupont Cc: Michael Thomas , Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201081739.g08HdiQ21918@givry.rennes.enst-bretagne.fr> References: <15419.8414.384615.139500@thomasm-u1.cisco.com> <200201081739.g08HdiQ21918@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Phil suggested I add mobileip back which was dropped somewhere along the way] Francis, I'm not sure we're communicating, so let me be a little more explicit with what I had in mind: 1) MN arrives on new AR 2) It sends a packet using its home address as the *source* address -- no HAO at all. 3) AR recognizes that the source address is not one of the subnets it subtends and sends an ICMP message to MN which explains the problem 4) MN sends AR a normal CN binding update 5) AR lifts the restriction for that source address 6) MN now sends packets as in (2), but unimpeded If MN knows that there is likely to be a source address check on AR, it can delete steps 2 and 3. ICMP seems like a natural here because the router really is reporting a network problem back to MN (or not MN if a host were incorrectly configured, etc). If this is a subset of your proposal, fine. It does seem that what I propose gets rid of the HAO altogether which you don't seem to agree with. However, may I suggest that it's the AAA part that has become the lightning rod? And that maybe it shouldn't be quite so ambitious? :-) Mike Francis Dupont writes: > In your previous mail you wrote: > > No, actually, it was to have the MN send the > BU's directly to the access router. On a router > the BU just has an additional effect of removing > any restrictions on source addresses it will > let through. > > => I believed your proposal was BU snooping. But you can name it > as you'd like, the purpose is to provide the knowledge of bindings, > so there is no deep difference with my proposal (i.e. I can say > you use a non-standard network access control device, as I don't > specify one (I only give an example with AAA because it is the best > on the paper) I could argue your proposal is included in mine :-). > > Hence Pekka's question about use of ICMP was correct. > > => I am reluctant to define new ICMPs for anything. There is already > a format for BUs, why a new thing? > > Another point: HAOs are inside packets, to look at them is legitimate > for my firewall but not for any router on the path, i.e. I'd like > to have the check done once and others to trust it (this idea is > exactly the network access control). > > Regards > > Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 12:20:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08KKINg017004 for ; Tue, 8 Jan 2002 12:20:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08KKIVc017003 for ipng-dist; Tue, 8 Jan 2002 12:20:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08KKFNg016994 for ; Tue, 8 Jan 2002 12:20:15 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07464 for ; Tue, 8 Jan 2002 12:20:20 -0800 (PST) Received: from spidey.speakeasy.net (webmail.speakeasy.net [216.254.0.16]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02425 for ; Tue, 8 Jan 2002 12:20:19 -0800 (PST) Received: (from nobody@localhost) by spidey.speakeasy.net (8.11.6/8.11.2) id g08K6f525669; Tue, 8 Jan 2002 12:06:41 -0800 Message-Id: <200201082006.g08K6f525669@spidey.speakeasy.net> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Tue, 8 Jan 2002 12:06:40 -0800 From: Qing Li To: ipng@sunroof.eng.sun.com Subject: Question on draft-ietf-ipngwg-rfc2096-update-00 X-Sender: qingli@speakeasy.net X-Originating-Ip: [147.11.38.42] X-Mailer: Speakeasy Network Webmail 2.1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The inetCidrRouteTable refers to the node's routing table, not the forwarding table inside the kernel (such as FreeBSD), is that correct? If the router participates in multiple routing domains then this table should contain routing info from multiple routing tables, is that so? Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 19:07:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0937uNg017502 for ; Tue, 8 Jan 2002 19:07:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0937uPL017501 for ipng-dist; Tue, 8 Jan 2002 19:07:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0937qNg017494 for ; Tue, 8 Jan 2002 19:07:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15632 for ; Tue, 8 Jan 2002 19:07:57 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA00503 for ; Tue, 8 Jan 2002 20:08:58 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0938SH03344; Wed, 9 Jan 2002 10:08:29 +0700 (ICT) From: Robert Elz To: Alex Conta cc: Subrata Goswami , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <3C3A017F.8FE859EB@txc.com> References: <3C3A017F.8FE859EB@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jan 2002 10:08:28 +0700 Message-ID: <3342.1010545708@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 07 Jan 2002 15:13:51 -0500 From: Alex Conta Message-ID: <3C3A017F.8FE859EB@txc.com> | One of the comments pro "immutability" was that you cannot trust the | flow label if it is not "immutable". I didn't ever see that argument. What I saw was that you can't rely upon it if it isn't - but not from the point of view of the recipient, from the point of view of the sender. That is, if the value might be changed to any random thing, what's the point of setting it all, ever? It would just be meaningless bits (imagine a router forwarding a packet through an encrypting tunnel, and seeing some mutable bits - ones it is allowed to alter - and filling them with a random value in order to make cryptanalysis more difficult). | Current or future flow setup and flow processing mechanisms, do now, or | will, in the future, | KNOW BEST the micro-details of the flow label usage. Therefore | responsibility of the immutability/mutability of the flow label value | should stay ALONE with those mechanisms. I think in this case, you really favour making the field immutable, but unverified. If it were truly mutable, it would never be able to be used for any of those uses, as no-one could ever rely upon any value they set remaining intact to the point where it was supposed to be used (the "router" in my previous paragraph might be a link level bridge type object - even imagine a NIC that sees this mutable field and uses it to send to the destination a count of the number of times it deferred because of a busy link before sending the packet...) If some future spec wants to make the field mutable, then as long as we have not done anything silly (like modify the current AH rules) to prevent it, then that spec will be able to do that - and with a good chance of being able to rely upon the value only being changed as the future new spec actually says should happen. | By leaving mutability alone, possible issues with checksum, and AH | calculation can be really forgotten, or ignored. This amounts to "make it immutable, don't change AH, and explain in the doc that AH explicitly doesn't include the flow label, to leave open the possibility that some later spec might specify conditions under which the field can be changed". Until this later spec appears though, I don't think we need to anticipate its requirements, and waste time here debating whether or not those unknown future requirements are a good thing or a bad thing. All we need to do now is avoid doing something truly silly like revising AH to have it include the flow label. The only plausible "mutable" argument I can see remaining for now is to have a case where the source host says "I don't care what is in this field, I am not setting it to anything". I haven't yet even seen an argument as to why that value has to be immutable (by definition it has no meaning to anyone). So, I'm still in favour of allowing that. But not so much as to object to a doc that doesn't include it - after all, no-one will ever care if that value is changed, so if anyone wants to do so, they can, regardless of what this new spec on the flow label claims. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 19:15:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g093FbNg017524 for ; Tue, 8 Jan 2002 19:15:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g093FbOm017523 for ipng-dist; Tue, 8 Jan 2002 19:15:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g093FYNg017516 for ; Tue, 8 Jan 2002 19:15:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16261 for ; Tue, 8 Jan 2002 19:15:28 -0800 (PST) Received: from spidey.speakeasy.net (webmail.speakeasy.net [216.254.0.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11082 for ; Tue, 8 Jan 2002 20:15:10 -0700 (MST) Received: (from nobody@localhost) by spidey.speakeasy.net (8.11.6/8.11.2) id g0931mg22742; Tue, 8 Jan 2002 19:01:48 -0800 Message-Id: <200201090301.g0931mg22742@spidey.speakeasy.net> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Tue, 8 Jan 2002 19:01:48 -0800 From: Qing Li To: ipng@sunroof.eng.sun.com Subject: Re: Question on draft-ietf-ipngwg-rfc2096-update-00 X-Sender: qingli@speakeasy.net X-Originating-Ip: [147.11.38.42] X-Mailer: Speakeasy Network Webmail 2.1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 08 Jan 2002, Qing Li wrote: > >If the router participates in multiple > >routing domains then this table should > >contain routing info from multiple routing > >tables, is that so? > > If I understand your question, > ipCidrRouteTable already shows the origin of a > route installed in the FIB, see > ipCidrRouteProto. > My question was incorrectly worded. I meant to say if the ipCidrRouteTable represents the RIB then does that imply this table is the conglomeration of all the RIBs of the participated routing protocols. Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 21:25:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g095PWNg017853 for ; Tue, 8 Jan 2002 21:25:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g095PWLT017852 for ipng-dist; Tue, 8 Jan 2002 21:25:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g095PTNg017845 for ; Tue, 8 Jan 2002 21:25:29 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03971 for ; Tue, 8 Jan 2002 21:25:35 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28183 for ; Tue, 8 Jan 2002 21:25:34 -0800 (PST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id AAA22061 for ; Wed, 9 Jan 2002 00:25:32 -0500 (EST) From: "Dr. Subrata Goswami" To: Subject: RE: Flow Label Date: Tue, 8 Jan 2002 21:28:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3342.1010545708@brandenburg.cs.mu.OZ.AU> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here we go again, I guess first we need to make sure what immutability really is. The proper semantic of something immutable is that it can not be changed - as when you ship a CD that is only readable. With an IPv6 packet that is not possible unless every router vendor and IP stack vendor is some how forced to do that. Even the IP address fields are mutable as any intervening router can change (and they do in case of NAT). So the only way to enforce immutability is to add something like the AH so that anyone who is concerned with the Flow Label can be sure that no router in the middle has tempered it. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Robert Elz Sent: Tuesday, January 08, 2002 7:08 PM To: Alex Conta Cc: Subrata Goswami; Brian E Carpenter; ipng@sunroof.eng.sun.com Subject: Re: Flow Label Date: Mon, 07 Jan 2002 15:13:51 -0500 From: Alex Conta Message-ID: <3C3A017F.8FE859EB@txc.com> | One of the comments pro "immutability" was that you cannot trust the | flow label if it is not "immutable". I didn't ever see that argument. What I saw was that you can't rely upon it if it isn't - but not from the point of view of the recipient, from the point of view of the sender. That is, if the value might be changed to any random thing, what's the point of setting it all, ever? It would just be meaningless bits (imagine a router forwarding a packet through an encrypting tunnel, and seeing some mutable bits - ones it is allowed to alter - and filling them with a random value in order to make cryptanalysis more difficult). | Current or future flow setup and flow processing mechanisms, do now, or | will, in the future, | KNOW BEST the micro-details of the flow label usage. Therefore | responsibility of the immutability/mutability of the flow label value | should stay ALONE with those mechanisms. I think in this case, you really favour making the field immutable, but unverified. If it were truly mutable, it would never be able to be used for any of those uses, as no-one could ever rely upon any value they set remaining intact to the point where it was supposed to be used (the "router" in my previous paragraph might be a link level bridge type object - even imagine a NIC that sees this mutable field and uses it to send to the destination a count of the number of times it deferred because of a busy link before sending the packet...) If some future spec wants to make the field mutable, then as long as we have not done anything silly (like modify the current AH rules) to prevent it, then that spec will be able to do that - and with a good chance of being able to rely upon the value only being changed as the future new spec actually says should happen. | By leaving mutability alone, possible issues with checksum, and AH | calculation can be really forgotten, or ignored. This amounts to "make it immutable, don't change AH, and explain in the doc that AH explicitly doesn't include the flow label, to leave open the possibility that some later spec might specify conditions under which the field can be changed". Until this later spec appears though, I don't think we need to anticipate its requirements, and waste time here debating whether or not those unknown future requirements are a good thing or a bad thing. All we need to do now is avoid doing something truly silly like revising AH to have it include the flow label. The only plausible "mutable" argument I can see remaining for now is to have a case where the source host says "I don't care what is in this field, I am not setting it to anything". I haven't yet even seen an argument as to why that value has to be immutable (by definition it has no meaning to anyone). So, I'm still in favour of allowing that. But not so much as to object to a doc that doesn't include it - after all, no-one will ever care if that value is changed, so if anyone wants to do so, they can, regardless of what this new spec on the flow label claims. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 22:43:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g096hjNg017922 for ; Tue, 8 Jan 2002 22:43:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g096hj7W017921 for ipng-dist; Tue, 8 Jan 2002 22:43:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g096hgNg017914 for ; Tue, 8 Jan 2002 22:43:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23445 for ; Tue, 8 Jan 2002 22:43:48 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29879 for ; Tue, 8 Jan 2002 23:43:30 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g096j4N00876; Wed, 9 Jan 2002 13:45:05 +0700 (ICT) From: Robert Elz To: "Dr. Subrata Goswami" cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jan 2002 13:45:04 +0700 Message-ID: <874.1010558704@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 8 Jan 2002 21:28:11 -0800 From: "Dr. Subrata Goswami" Message-ID: | Here we go again, I guess first we need to make sure | what immutability really is. The proper semantic of | something immutable is that it can not be changed - | as when you ship a CD that is only readable. Yes, though we perhaps aren't using it in quite that sense, more in the "must not be changed" rather than "can not be changed". | With an IPv6 | packet that is not possible unless every router vendor | and IP stack vendor is some how forced to do that. But that's certainly not true. We don't have to force them, we just need to tell them what is right. That's all the IETF ever really does. | Even the IP address fields are mutable as any intervening router | can change (and they do in case of NAT). Yes, exactly. Yes and (NAT set aside for a minute) the IP address fields have just the properties that we are really aiming for here. That is, they aren't changed by random routers along the path - packets get delivered with the same addresses in them that they had when they left the source (or did, pre NAT). And that was achieved without AH existing yet to validate things - the routers simply didn't alter the fields. That's what is desirable here. But then, along came the need for NAT (as evil as it is, there must be a pretty strong case for it, given its widespread use). Implementing that meant that the address field, which previously had never been altered, now needed to be changed by routers. Had there been any enforcement of the immutability of the addresses, then there would have been no way to add NAT to the net (which might have been good, or bad, but for sure the net now would be nothing like it is if not for it). | So the only way | to enforce immutability is to add something like the AH so | that anyone who is concerned with the Flow Label can be | sure that no router in the middle has tempered it. If there was any reason to enforce it, that would be correct. But there isn't - so we don't need this. And if we did, then there'd be no possibility later to come up with some new use which requires the field to be mutable (and argue about it a lot in the IETF and perhaps eventually agree to it). At this stage in the evolution of the flow label, completely cutting off that possibility is unreasonable. In practice, if actual immutability is required by applications that use the flow label, then what will "enforce" the immutability is the screams of the users at the router vendors/operators if they start playing about with the data. Just as would happen if (aside from the explicitly configured NAT, and even that generates plenty of screaming) routers started randomly changing IP addresses. If there's never an application actually deployed that cares, then why would anyone else? In that case, if someone decides to alter the field, no-one would notice - and there's no reason to go and add a mechanism just to detect something that no-one cares about anyway. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 8 23:09:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0979RNg017993 for ; Tue, 8 Jan 2002 23:09:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0979Rbg017992 for ipng-dist; Tue, 8 Jan 2002 23:09:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0979ONg017985 for ; Tue, 8 Jan 2002 23:09:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05297 for ; Tue, 8 Jan 2002 23:09:29 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21944 for ; Wed, 9 Jan 2002 00:09:10 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id CAA28604 for ; Wed, 9 Jan 2002 02:09:27 -0500 (EST) From: "Dr. Subrata Goswami" To: Subject: RE: Flow Label Date: Tue, 8 Jan 2002 23:12:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <874.1010558704@brandenburg.cs.mu.OZ.AU> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well I would not recommend settling something with screams. Making the Flow Label immutable would infact need more than screams. I can not see how by just saying something is immutable going to help. It would infact be the ground for more confusion, uncertainty, doubt and vendor specific interpretations. I would also recommend adopting the semantics of immutability from the AH RFC 2402 - I guess that is where the word immutable first appears. Also, as you know AH is completely broken by NAT. Why has NAT become popular ? I can only guess: a quick and dirty fix for IPv4 address scarcity; some firewall benefits. The -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Robert Elz Sent: Tuesday, January 08, 2002 10:45 PM To: Dr. Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label Date: Tue, 8 Jan 2002 21:28:11 -0800 From: "Dr. Subrata Goswami" Message-ID: | Here we go again, I guess first we need to make sure | what immutability really is. The proper semantic of | something immutable is that it can not be changed - | as when you ship a CD that is only readable. Yes, though we perhaps aren't using it in quite that sense, more in the "must not be changed" rather than "can not be changed". | With an IPv6 | packet that is not possible unless every router vendor | and IP stack vendor is some how forced to do that. But that's certainly not true. We don't have to force them, we just need to tell them what is right. That's all the IETF ever really does. | Even the IP address fields are mutable as any intervening router | can change (and they do in case of NAT). Yes, exactly. Yes and (NAT set aside for a minute) the IP address fields have just the properties that we are really aiming for here. That is, they aren't changed by random routers along the path - packets get delivered with the same addresses in them that they had when they left the source (or did, pre NAT). And that was achieved without AH existing yet to validate things - the routers simply didn't alter the fields. That's what is desirable here. But then, along came the need for NAT (as evil as it is, there must be a pretty strong case for it, given its widespread use). Implementing that meant that the address field, which previously had never been altered, now needed to be changed by routers. Had there been any enforcement of the immutability of the addresses, then there would have been no way to add NAT to the net (which might have been good, or bad, but for sure the net now would be nothing like it is if not for it). | So the only way | to enforce immutability is to add something like the AH so | that anyone who is concerned with the Flow Label can be | sure that no router in the middle has tempered it. If there was any reason to enforce it, that would be correct. But there isn't - so we don't need this. And if we did, then there'd be no possibility later to come up with some new use which requires the field to be mutable (and argue about it a lot in the IETF and perhaps eventually agree to it). At this stage in the evolution of the flow label, completely cutting off that possibility is unreasonable. In practice, if actual immutability is required by applications that use the flow label, then what will "enforce" the immutability is the screams of the users at the router vendors/operators if they start playing about with the data. Just as would happen if (aside from the explicitly configured NAT, and even that generates plenty of screaming) routers started randomly changing IP addresses. If there's never an application actually deployed that cares, then why would anyone else? In that case, if someone decides to alter the field, no-one would notice - and there's no reason to go and add a mechanism just to detect something that no-one cares about anyway. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 02:33:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09AXpNg018432 for ; Wed, 9 Jan 2002 02:33:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09AXpoV018431 for ipng-dist; Wed, 9 Jan 2002 02:33:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09AXjNg018416; Wed, 9 Jan 2002 02:33:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06981; Wed, 9 Jan 2002 02:33:51 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13053; Wed, 9 Jan 2002 03:33:50 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g09AXab21950; Wed, 9 Jan 2002 11:33:36 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA17521; Wed, 9 Jan 2002 11:33:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g09AXWQ24892; Wed, 9 Jan 2002 11:33:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Tue, 08 Jan 2002 10:20:25 PST. <15419.14441.941556.661985@thomasm-u1.cisco.com> Date: Wed, 09 Jan 2002 11:33:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: [Phil suggested I add mobileip back which was dropped somewhere along the way] I'm not sure we're communicating, so let me be a little more explicit with what I had in mind: 1) MN arrives on new AR => many (academic or R&D) sites I know don't use firewalls (they use a router for filtering) but have a passive management box which detects new addresses and builds a database with MAC, IP, name, location, etc, something very useful in case of problems. So even if classical network access control is not performed on 1) at the first packet, unusual behaviors are detected (i.e. there is a passive and without automatic reaction kind of network access control). At the opposite I know some (commercial) ISPs which use the (traditional) network access control to punch holes in the firewall for outbound traffic, i.e. all source addresses are blocked by default and network access control is used to open some of them (in AAA term the authorized resource is the Internet access): this is ingress filtering at the address level, usually it is done at the access device (e.g. modem) level too. 2) It sends a packet using its home address as the *source* address -- no HAO at all. => I propose that the packet is sent to the home agent (or something similar). 3) AR recognizes that the source address is not one of the subnets it subtends and sends an ICMP message to MN which explains the problem => perhaps I should add a statement in the draft with a requirement (modulo ICMP rate limitation) for ICMPs when a HAO is filtered out. I believe a router should implement this by default but a detailed text should help. What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option), as the router is not the destination of the packet the MN should understand what's happened. Note that 1 (Destination Unreachable) - 1 (administratively prohibited) is too ambiguous. 4) MN sends AR a normal CN binding update => 4) is what I consider as a kind of network access control. 5) AR lifts the restriction for that source address => the difference with my proposal is here, I propose to accept corresponding HAOs, you propose to directly open the ingress filtering. See more comments after. 6) MN now sends packets as in (2), but unimpeded If MN knows that there is likely to be a source address check on AR, it can delete steps 2 and 3. => i.e. active/reactive modes. ICMP seems like a natural here because the router really is reporting a network problem back to MN (or not MN if a host were incorrectly configured, etc). => in any case ICMP errors have to be sent when packets are dropped, I believe we can reach a consensus about this very quickly. If this is a subset of your proposal, fine. It does seem that what I propose gets rid of the HAO altogether which you don't seem to agree with. => in order to get rid of the HAO your proposal has to be supported on every ingress filtering devices where a packet from the MN can go though. This is not in fact like path MTU discovery (which is already difficult to get in the real world) because your proposal uses a signaling with all the usual problems of signaling (scalability, security, ...). Even if to get rid of the HAO would be very nice, I don't believe this will work in practice. To summary this has the same kind of problems (i.e. limitations) than micro-mobility (i.e. mobility based on host routing). However, may I suggest that it's the AAA part that => I insist about AAA: AAA is not an essential part of my proposal, it only brings extra goodies: - an instance of network access control which is well known and already has proposed extensions for (mobile) IPv6 - remote network access control - a connection between local and remote access control. has become the lightning rod? And that maybe it shouldn't be quite so ambitious? :-) => too ambitious for a global deployment, and for local/special cases I am afraid that micro-mobility is more attractive (it gets rid of the routing header too). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 06:29:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09ETDNg019160 for ; Wed, 9 Jan 2002 06:29:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09ETD58019159 for ipng-dist; Wed, 9 Jan 2002 06:29:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09ETANg019152 for ; Wed, 9 Jan 2002 06:29:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09059 for ; Wed, 9 Jan 2002 06:29:17 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27143 for ; Wed, 9 Jan 2002 07:29:17 -0700 (MST) Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g09EQLGx002586; Wed, 9 Jan 2002 08:26:22 -0600 (CST) Message-ID: <224701c19932$47774d60$0100a8c0@RepliGate> From: "Jim Fleming" To: "Robert Elz" , "Dr. Subrata Goswami" Cc: References: <874.1010558704@brandenburg.cs.mu.OZ.AU> Subject: Re: Flow Label Date: Wed, 9 Jan 2002 09:22:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Robert Elz" To: "Dr. Subrata Goswami" Cc: Sent: Tuesday, January 08, 2002 10:45 PM Subject: Re: Flow Label > > But that's certainly not true. We don't have to force them, we just > need to tell them what is right. That's all the IETF ever really does. ... > In practice, if actual immutability is required by applications that use the > flow label, then what will "enforce" the immutability is the screams of the > users at the router vendors/operators if they start playing about with the > data. "tell them what is right" ???? NAT is a bogus example, because addresses are not changed by the carriers (ISPs?) that take in native IPv4 packets on one side of the legacy IPv4 cloud and produce the same packets on the other side of the cloud, based on the address. A person with a PC--NAT configuration, has just buult a super PC with their stack remoted to the NAT appliance. With two PCs and Internet Connection Sharing (ICS), the trio of machines still appear as one aggregate to the legacy IPv4 transport. More of the bits in the IPv4 header can be used, because the NAT appliance can be upgraded easier than their PCs. There are only 20 bytes in the typical IPv4 header and most users do not use them all effectively. The TOS field is a much better example to use, with respect to changing bits that the user does not want changed. The TOS field is 8 bits, and what goes in should come out. Why does the IETF, (described by the ICANN Board, as their "Engineering Division"), think it can come in after the fact and start having carriers change the bits in the user's TOS field ? Is the reason that the IETF does not want users to discover that those 8-bits can be used as two 4-bit fields to expand the addressing of the Internet by adding 15 more layers, flows, etc. ??? Why is it that the IETF's attempts to encourage carriers to change the TOS fields, removing them from the user's usage, are viewed as OK, while NAT is the poster child for all things bad ? Why is it that the IETF (and ICANN) are able to be so selective (and inaccurate) in choosing what they view as breaking the net ?...yet, run around claiming that they know what is right.... Do you use a 2002 prefix ? http://www.dot-biz.com/INFO/Papers/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 06:40:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09EeJNg019191 for ; Wed, 9 Jan 2002 06:40:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09EeJIQ019190 for ipng-dist; Wed, 9 Jan 2002 06:40:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09EeGNg019183 for ; Wed, 9 Jan 2002 06:40:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16846 for ; Wed, 9 Jan 2002 06:40:24 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00898 for ; Wed, 9 Jan 2002 07:40:05 -0700 (MST) Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g09EeKGx006748; Wed, 9 Jan 2002 08:40:21 -0600 (CST) Message-ID: <225901c19934$3bbce9b0$0100a8c0@RepliGate> From: "Jim Fleming" To: "Dr. Subrata Goswami" , References: Subject: Why has NAT become popular ? Date: Wed, 9 Jan 2002 09:36:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Dr. Subrata Goswami" > > Also, as you know AH is completely broken by NAT. Why has > NAT become popular ? I can only guess: a quick and dirty fix > for IPv4 address scarcity; some firewall benefits. > NAT has become popular, partly because of the absurd, subjective, IPv4 allocation policies, enacted by the academics and government employees (who usually pay nothing for allocations), and backed by the large corporations who have their own massive allocations separate from the rest of the peasants. NAT has also become popular because of a natural tendancy for humans to simplify via aggregation and encapsulation. Look at everyday life, much of what goes on is people putting things into other things and labeling the result. You might try working the other direction to see why NAT makes sense. Take a typical PC. Look at the physical components, CPU, Keyboard, Mouse, Monitor, Printer. Imagine that all of those components were on a high-speed LAN as their interconnect. Imagine that each of the components had a unique IP address. Would people find it useful to ping the mouse of someone on the other side of planet Earth ? No, they box it all up and call it a PC, and give it one IP address, they then box their PC up with a NAT appliance and call that a vPC (Virtual PC). They then move in the other direction with a focus on the "services" that their vPC can provide and access. It is a natural evolution. The control freaks of course do not like people having knowledge and the ability to do their own packaging and administration. They have built their careers making resources scarce and telling people what is "right". Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 07:36:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09FaYNg019336 for ; Wed, 9 Jan 2002 07:36:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09FaYgB019335 for ipng-dist; Wed, 9 Jan 2002 07:36:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09FaVNg019328 for ; Wed, 9 Jan 2002 07:36:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05408 for ; Wed, 9 Jan 2002 07:36:37 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22075 for ; Wed, 9 Jan 2002 07:36:37 -0800 (PST) Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g09FaXGx025519; Wed, 9 Jan 2002 09:36:34 -0600 (CST) Message-ID: <232401c1993c$16559700$0100a8c0@RepliGate> From: "Jim Fleming" To: "Dr. Subrata Goswami" , References: Subject: Re: Flow Label Date: Wed, 9 Jan 2002 10:33:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Dr. Subrata Goswami" > > I can not see how by just saying something is immutable going > to help. It would infact be the ground for more confusion, If users use a field and expect it not to change, then carriers (ISPs?) have to take note of that. In IPv6++, every bit in the 40 byte header is used. The 20 bits that were not defined, have a 4-bit length field and a 16-bit value. There are also 16 other bytes for data. Small packets, such as the common ping, fit totally in the header. Add an IPv4 Routing Header in the front (where it belongs), and use all of the bits in that 20 byte data structure and call it a day. Why would carriers change those 60 bytes ? Jim Fleming Unir Corporation - UNIR and COM worlds @ http://www.activeworlds.com vPC + C+@ + IPv8 + 2,048 TLDs...this network solution is simple... http://www.ddj.com/articles/index/author/idx10133.htm -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 09:22:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09HMxNg019487 for ; Wed, 9 Jan 2002 09:22:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09HMx1A019486 for ipng-dist; Wed, 9 Jan 2002 09:22:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09HMuNg019479 for ; Wed, 9 Jan 2002 09:22:56 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15247 for ; Wed, 9 Jan 2002 09:23:03 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17398 for ; Wed, 9 Jan 2002 09:23:02 -0800 (PST) Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g09HN0Gx004202 for ; Wed, 9 Jan 2002 11:23:01 -0600 (CST) Message-ID: <248401c1994a$f4fb15d0$0100a8c0@RepliGate> From: "Jim Fleming" To: Subject: Fw: FreeBSD-4.3 IPv6 bug - Further information. Date: Wed, 9 Jan 2002 12:19:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: )> To: "June Carey" Cc: ; Sent: Wednesday, January 09, 2002 9:10 AM Subject: Re: FreeBSD-4.3 IPv6 bug - Further information. > >>>>> On Tue, 08 Jan 2002 17:57:00 +0000, > >>>>> "June Carey" said: > > > END OF CLIENT/SERVER CONNECTION RESULTS > > ======================================= > > > The "bug" is that netstat(1) shows a tcp4 connection between the Server and > > the Client, but accept(2) is filling out the address structure with a > > sin_family of 28, when it should be 2 (AF_INET). > > > The other "bug" I've recently discovered, and which is demonstrated above, > > is that when you've got a tcp4 connection between the Client and the Server, > > "addrLen" is 28, when it should be 16. > > Well, unfortunately, this behavior is not a bug. An AF_INET6 socket > can accept an IPv4 connection with IPv4-mapped IPv6 addresses, as > specified in draft-ietf-ipngwg-rfc2553bis-04.txt. In this case, of > course, the sa_family field is AF_INET6, and the sa_len field is > sizeof(sockaddr_in6). > > FreeBSD 4.4-RELEASE has a partial support to disable this feature by > the IPV6_V6ONLY option, which, as far as I know, is not included in > FreeBSD 4.3. If you do not want to accept an IPv4 connection on an > AF_INET6 socket, I'd recommend you to migrate to FreeBSD 4.4 and > rewrite the application with the option. > > By the way, detail behaviors about IPv4-mapped IPv6 addresses are very > different among various OSes, so you should be careful if you want to > make your applications portable on other OSes. You may also want to > check at the following web page to see the differences: > http://www.kame.net/newsletter/20010504/ > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 09:54:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09HsWNg019720 for ; Wed, 9 Jan 2002 09:54:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09HsVb9019719 for ipng-dist; Wed, 9 Jan 2002 09:54:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09HsSNg019712 for ; Wed, 9 Jan 2002 09:54:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04500 for ; Wed, 9 Jan 2002 09:54:22 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20033 for ; Wed, 9 Jan 2002 10:54:21 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g09HsKJ19007 for ; Wed, 9 Jan 2002 18:54:20 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Jan 09 18:54:19 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 18:45:26 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1C2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" , Francis Dupont Cc: Jari Arkko , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Wed, 9 Jan 2002 18:54:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, Just catching up on this thread, a couple of questions below. > So here's a most-likely crazy idea: why can't we > treat the ingress filtering router like a CN which > must first be sent a BU which it verifies in > whatever manner the CN would? This already has a > requirement to not be bound to mythical PKI's, > etc. Given FMIP, the access routers are probably > going to end up having to process things like BU's > anyway. => Let me understand what this would do: what happens after the MN sends a BU ? Does the default router look though each packet to verify the HAO ? > > Also: if we have ingress filtering taken care of > directly, is there any reason to preserve the HAO > at all? I thought its entire raison d'etre was to > provide a means of coexisting with ingress > filtering -- => Well, no, it is a form of tunnelling, (combined with RH) if you remove it you'd have to tunnel right ? I feel like I misunderstood a few things in your text. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 10:38:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09IcUNg019858 for ; Wed, 9 Jan 2002 10:38:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09IcUpj019857 for ipng-dist; Wed, 9 Jan 2002 10:38:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09IcRNg019850 for ; Wed, 9 Jan 2002 10:38:27 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19677 for ; Wed, 9 Jan 2002 10:38:35 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27145 for ; Wed, 9 Jan 2002 10:38:34 -0800 (PST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-130.cisco.com [161.44.149.130]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04169; Wed, 9 Jan 2002 13:38:02 -0500 (EST) Message-Id: <4.3.2.7.2.20020109133527.0369add0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 13:38:35 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: DHC WG last call for DHCPv6 Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you've reviewed the most recent rev of the DHCPv6 spec , please post your comments to dhcwg@ietf.org - even if your comments are as brief as "looks ready for submission for Proposed Standard"... - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 10:38:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09IcoNg019895 for ; Wed, 9 Jan 2002 10:38:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09IcoQG019892 for ipng-dist; Wed, 9 Jan 2002 10:38:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09IcjNg019867 for ; Wed, 9 Jan 2002 10:38:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15579 for ; Wed, 9 Jan 2002 10:38:53 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10031 for ; Wed, 9 Jan 2002 11:38:52 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-130.cisco.com [161.44.149.130]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04295 for ; Wed, 9 Jan 2002 13:38:51 -0500 (EST) Message-Id: <4.3.2.7.2.20020109133137.00b8f698@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 13:35:25 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: DHCPv6 spec in DHC WG last call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The latest rev of the DHCPv6 spec is now available at www.ietf.org. This spec is now in DHC WG last call review. We'd also like to get feedback from interested member of the IPv6 WG as well. Please respond with comments on draft-ietf-dhc-dhcpv6-22.txt to the DHC WG mailing list, dhcwg@ietf.org. - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 9 11:27:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09JRuNg020314 for ; Wed, 9 Jan 2002 11:27:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09JRuML020313 for ipng-dist; Wed, 9 Jan 2002 11:27:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09JRrNg020306; Wed, 9 Jan 2002 11:27:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16115; Wed, 9 Jan 2002 11:27:59 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00423; Wed, 9 Jan 2002 12:27:58 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g09JRiF23420; Wed, 9 Jan 2002 11:27:44 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAQ37759; Wed, 9 Jan 2002 11:27:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA13717; Wed, 9 Jan 2002 11:27:43 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15420.39343.715475.192551@thomasm-u1.cisco.com> Date: Wed, 9 Jan 2002 11:27:43 -0800 (PST) To: Francis Dupont Cc: Michael Thomas , Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> References: <15419.14441.941556.661985@thomasm-u1.cisco.com> <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As originally advertised, I am now convinced that this was indeed a crazy idea -- a bit too good to be true. Thanks for the link on the "loose" RPF checking; I wasn't aware of that. Having to signal many routers in the path would be a non-starter, and ISP's certainly have incentive to perform the loose RPF, therefore this is an insurmountable obstacle. Oh well. Mike Francis Dupont writes: > In your previous mail you wrote: > > [Phil suggested I add mobileip back which was > dropped somewhere along the way] > > I'm not sure we're communicating, so let me be a little > more explicit with what I had in mind: > > 1) MN arrives on new AR > > => many (academic or R&D) sites I know don't use firewalls > (they use a router for filtering) but have a passive management box > which detects new addresses and builds a database with MAC, IP, > name, location, etc, something very useful in case of problems. > So even if classical network access control is not performed on 1) > at the first packet, unusual behaviors are detected (i.e. there is > a passive and without automatic reaction kind of network access control). > At the opposite I know some (commercial) ISPs which use the (traditional) > network access control to punch holes in the firewall for outbound > traffic, i.e. all source addresses are blocked by default and > network access control is used to open some of them (in AAA term > the authorized resource is the Internet access): this is ingress > filtering at the address level, usually it is done at the access > device (e.g. modem) level too. > > 2) It sends a packet using its home address as the > *source* address -- no HAO at all. > > => I propose that the packet is sent to the home agent (or something > similar). > > 3) AR recognizes that the source address is not one of > the subnets it subtends and sends an ICMP message > to MN which explains the problem > > => perhaps I should add a statement in the draft with a requirement > (modulo ICMP rate limitation) for ICMPs when a HAO is filtered out. > I believe a router should implement this by default but a detailed > text should help. > What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option), > as the router is not the destination of the packet the MN should > understand what's happened. Note that 1 (Destination Unreachable) - > 1 (administratively prohibited) is too ambiguous. > > 4) MN sends AR a normal CN binding update > > => 4) is what I consider as a kind of network access control. > > 5) AR lifts the restriction for that source address > > => the difference with my proposal is here, I propose to accept > corresponding HAOs, you propose to directly open the ingress filtering. > See more comments after. > > 6) MN now sends packets as in (2), but unimpeded > > If MN knows that there is likely to be a source > address check on AR, it can delete steps 2 and 3. > > => i.e. active/reactive modes. > > ICMP seems like a natural here because the router > really is reporting a network problem back to MN > (or not MN if a host were incorrectly configured, > etc). > > => in any case ICMP errors have to be sent when packets are dropped, > I believe we can reach a consensus about this very quickly. > > If this is a subset of your proposal, fine. It > does seem that what I propose gets rid of the HAO > altogether which you don't seem to agree with. > > => in order to get rid of the HAO your proposal has to be > supported on every ingress filtering devices where a packet > from the MN can go though. This is not in fact like path MTU > discovery (which is already difficult to get in the real world) > because your proposal uses a signaling with all the usual > problems of signaling (scalability, security, ...). > Even if to get rid of the HAO would be very nice, I don't > believe this will work in practice. To summary this has the > same kind of problems (i.e. limitations) than micro-mobility > (i.e. mobility based on host routing). > > However, may I suggest that it's the AAA part that > > => I insist about AAA: AAA is not an essential part of > my proposal, it only brings extra goodies: > - an instance of network access control which is well known > and already has proposed extensions for (mobile) IPv6 > - remote network access control > - a connection between local and remote access control. > > has become the lightning rod? And that maybe it > shouldn't be quite so ambitious? :-) > > => too ambitious for a global deployment, and for local/special cases > I am afraid that micro-mobility is more attractive (it gets rid > of the routing header too). > > Regards > > Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 06:09:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AE9DNg021672 for ; Thu, 10 Jan 2002 06:09:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AE9DlF021671 for ipng-dist; Thu, 10 Jan 2002 06:09:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AE9ANg021664 for ; Thu, 10 Jan 2002 06:09:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08311 for ; Thu, 10 Jan 2002 06:09:17 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09505 for ; Thu, 10 Jan 2002 07:09:16 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA10652; Thu, 10 Jan 2002 15:09:14 +0100 Received: from dhcp222-86.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40928 from ; Thu, 10 Jan 2002 15:09:11 +0100 Message-Id: <3C3DA086.CC6FB497@hursley.ibm.com> Date: Thu, 10 Jan 2002 15:09:10 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Subrata Goswami wrote: > > The main point is, if I am a provider and I get a packet, how can > I be sure that some malicious entity in the middle has not modified > the flow label so that it can avail of better QoS ? You can't, any more than you can be sure the DSCP hasn't changed, or that somebody isn't playing games with port numbers to fool your classifier. The ISP's defence against this is that more QoS will result in a higher bill. So the ISP actually doesn't care; they get paid accordingly. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 06:16:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AEGXNg021722 for ; Thu, 10 Jan 2002 06:16:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AEGXO3021721 for ipng-dist; Thu, 10 Jan 2002 06:16:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AEGTNg021714 for ; Thu, 10 Jan 2002 06:16:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28311 for ; Thu, 10 Jan 2002 06:16:36 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21379 for ; Thu, 10 Jan 2002 07:17:43 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA09696; Thu, 10 Jan 2002 15:16:32 +0100 Received: from dhcp222-86.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60912 from ; Thu, 10 Jan 2002 15:16:30 +0100 Message-Id: <3C3DA23E.CDD8C163@hursley.ibm.com> Date: Thu, 10 Jan 2002 15:16:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Robert Elz Cc: "Dr. Subrata Goswami" , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <874.1010558704@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre is correct IMHO, and we won't get any further by repeating this loop again. However there is one qualification on kre's final comment: > ...if someone decides to alter the field, no-one > would notice - and there's no reason to go and add a mechanism just to detect > something that no-one cares about anyway. The field could theoretically be abused as a signalling channel by malicious people - detecting this might be of value in some circumstances. Brian Robert Elz wrote: > > Date: Tue, 8 Jan 2002 21:28:11 -0800 > From: "Dr. Subrata Goswami" > Message-ID: > > | Here we go again, I guess first we need to make sure > | what immutability really is. The proper semantic of > | something immutable is that it can not be changed - > | as when you ship a CD that is only readable. > > Yes, though we perhaps aren't using it in quite that sense, more > in the "must not be changed" rather than "can not be changed". > > | With an IPv6 > | packet that is not possible unless every router vendor > | and IP stack vendor is some how forced to do that. > > But that's certainly not true. We don't have to force them, we just > need to tell them what is right. That's all the IETF ever really does. > > | Even the IP address fields are mutable as any intervening router > | can change (and they do in case of NAT). > > Yes, exactly. Yes and (NAT set aside for a minute) the IP address fields > have just the properties that we are really aiming for here. That is, > they aren't changed by random routers along the path - packets get delivered > with the same addresses in them that they had when they left the source > (or did, pre NAT). And that was achieved without AH existing yet to > validate things - the routers simply didn't alter the fields. > > That's what is desirable here. > > But then, along came the need for NAT (as evil as it is, there must be > a pretty strong case for it, given its widespread use). Implementing that > meant that the address field, which previously had never been altered, > now needed to be changed by routers. Had there been any enforcement of > the immutability of the addresses, then there would have been no way to > add NAT to the net (which might have been good, or bad, but for sure the > net now would be nothing like it is if not for it). > > | So the only way > | to enforce immutability is to add something like the AH so > | that anyone who is concerned with the Flow Label can be > | sure that no router in the middle has tempered it. > > If there was any reason to enforce it, that would be correct. But there > isn't - so we don't need this. > > And if we did, then there'd be no possibility later to come up with some > new use which requires the field to be mutable (and argue about it a lot > in the IETF and perhaps eventually agree to it). At this stage in the > evolution of the flow label, completely cutting off that possibility is > unreasonable. > > In practice, if actual immutability is required by applications that use the > flow label, then what will "enforce" the immutability is the screams of the > users at the router vendors/operators if they start playing about with the > data. Just as would happen if (aside from the explicitly configured NAT, > and even that generates plenty of screaming) routers started randomly > changing IP addresses. > > If there's never an application actually deployed that cares, then why would > anyone else? In that case, if someone decides to alter the field, no-one > would notice - and there's no reason to go and add a mechanism just to detect > something that no-one cares about anyway. > > kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 06:52:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AEqENg021965 for ; Thu, 10 Jan 2002 06:52:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AEqEhx021964 for ipng-dist; Thu, 10 Jan 2002 06:52:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AEq8Ng021957 for ; Thu, 10 Jan 2002 06:52:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13780 for ; Thu, 10 Jan 2002 06:52:14 -0800 (PST) From: jarno.rajahalme@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08657 for ; Thu, 10 Jan 2002 07:52:00 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0AEq2k08575 for ; Thu, 10 Jan 2002 16:52:02 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jan 2002 16:51:58 +0200 Received: by esebh03nok with Internet Mail Service (5.5.2652.78) id ; Thu, 10 Jan 2002 16:51:58 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F911757198092@esebe004.NOE.Nokia.com> To: mrw@windriver.com, brian@hursley.ibm.com, RACarlson@anl.gov, kempf@docomolabs-usa.com, moore@cs.utk.edu, bill@strahm.net, alain.durand@eng.sun.com, randy@psg.com, smb@research.att.com, kre@munnari.OZ.AU, mat@cisco.com, sob@harvard.edu Cc: ipng@sunroof.eng.sun.com Subject: Update: Proposed update to RFC 2460 [was Re: Flow Label] Date: Thu, 10 Jan 2002 16:51:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just reviewed the related threads on this list and the proposed text quoted below seems to have unanimous support (less ~2 persons) on the list. I support this text as well, but have a worry about it not stating in which context flow label, when set, is meaningful. The text below says that the label is used to "label sets of packets". In the SLC meeting I presented our proposal to consider the (Source Address, Flow Label, Destination Address) 3-tuple to classify the "set of packets". There was wide support for this in the room (as is recorded in the minutes: http://playground.sun.com/ipng/minutes/ipv6-minutes-dec2001.txt). See the presentation for the rationale for the 3-tuple: http://playground.sun.com/ipng/presentations/dec2001/draft-rajahalme-ipv 6-flow-label-001.pdf. The problem with not stating this is that we could end up having multiple state establishment methods specifying conflicting classifiers, which would make classification in routers ambiguous. Also, not stating how the "set" can be classified will not help HW-designers to do the right thing with their designs ASAP. Text including the S+D addresses would be like (the second sentence is added, no other changes): The 20-bit Flow Label field in the IPv6 header MAY be set by a source to label sets of packets. A packet can be classified to a set with the source address, flow label, destination address triplet. Nodes that do not support the Flow Label field MUST set the field to zero when originating a packet, and MUST ignore the field when receiving a packet. All routers MUST pass the field on unchanged when forwarding a packet. This specification does not further define the meaning of the Flow Label. [and delete Appendix A, which is unhelpful.] The added benefit of the above is that IF there is an SLA referring to specific flow label values, those values would only effect the treatment of the packets of the customer having the SLA (one of the customer's IP addresses being either in the source or destination address fields). Also, note that the above does not prevent having multiple triplets indicate the same "set" (so, IMO, no generality is lost). So, for those who have hummed yes to the text below, how many of you would oppose modifying it to include mentioning the fields used for classification, and why? Jarno > -----Original Message----- > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 27. joulukuuta 2001 18:09 > To: Brian E Carpenter > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] > > > > Actually, I would take out the word "uniquely". I am > not sure that we want to confine possible QoS solutions > to "uniquely" labeling anything. > > Margaret > > > At 10:43 AM 12/27/01 , Brian E Carpenter wrote: > >Taking Scott's suggestion, here's another try: > > > >I'd like to propose the following as the > >complete and total replacement of Section 6 of RFC 2460. > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to uniquely label sets of packets. Nodes that do > not support > > the Flow Label field MUST set the field to zero when > originating a > > packet, and MUST ignore the field when receiving a > packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > > > This specification does not further define the meaning of the > > Flow Label. > > > > [and delete Appendix A, which is unhelpful.] > > > > Brian > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 07:29:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AFTYNg022089 for ; Thu, 10 Jan 2002 07:29:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AFTYrd022088 for ipng-dist; Thu, 10 Jan 2002 07:29:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AFTVNg022081 for ; Thu, 10 Jan 2002 07:29:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23751 for ; Thu, 10 Jan 2002 07:29:37 -0800 (PST) From: Gerard.Gastaud@alcatel.fr Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26964 for ; Thu, 10 Jan 2002 07:29:36 -0800 (PST) Received: from frmta004.netfr.alcatel.fr (frmta004.netfr.alcatel.fr [155.132.182.160]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id QAA09400; Thu, 10 Jan 2002 16:29:15 +0100 (MET) Received: by frmta004.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256B3D.005511DB ; Thu, 10 Jan 2002 16:29:11 +0100 X-Lotus-FromDomain: ALCATEL To: Brian E Carpenter cc: Subrata Goswami , ipng@sunroof.eng.sun.com Message-ID: Date: Thu, 10 Jan 2002 16:29:04 +0100 Subject: Re: Flow Label Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable and the user may refuse to pay because it idid not ask for the flow lab= el that the malicious entity overwrote g=E9rard Brian E Carpenter on 10/01/2002 15:09:10 =20 =20 =20 To: Subrata Goswami =20 =20 cc: ipng@sunroof.eng.sun.com(bcc: Gerard =20 GASTAUD/FR/ALCATEL) =20 =20 =20 =20 Subject Re: Flow Label =20 : =20 =20 = --0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subrata Goswami wrote: > > The main point is, if I am a provider and I get a packet, how can > I be sure that some malicious entity in the middle has not modified > the flow label so that it can avail of better QoS ? You can't, any more than you can be sure the DSCP hasn't changed, or that somebody isn't playing games with port numbers to fool your classifier. The ISP's defence against this is that more QoS will result in a higher bill. So the ISP actually doesn't care; they get paid accordingly. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 08:04:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AG4wNg022249 for ; Thu, 10 Jan 2002 08:04:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AG4w2F022248 for ipng-dist; Thu, 10 Jan 2002 08:04:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AG4sNg022241 for ; Thu, 10 Jan 2002 08:04:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27185 for ; Thu, 10 Jan 2002 08:05:00 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03383 for ; Thu, 10 Jan 2002 09:04:59 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA11554; Thu, 10 Jan 2002 17:04:57 +0100 Received: from dhcp222-86.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60906 from ; Thu, 10 Jan 2002 17:04:53 +0100 Message-Id: <3C3DBBA4.AAD1A280@hursley.ibm.com> Date: Thu, 10 Jan 2002 17:04:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Gerard.Gastaud@alcatel.fr Cc: Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0AG4tNg022242 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gerard.Gastaud@alcatel.fr wrote: > > and the user may refuse to pay because it idid not ask for the flow label that the malicious entity overwrote Indeed, and then the lawyers get involved. This is nothing new. Brian > gérard > > Brian E Carpenter on 10/01/2002 15:09:10 > > > > To: Subrata Goswami > > cc: ipng@sunroof.eng.sun.com(bcc: Gerard > GASTAUD/FR/ALCATEL) > > > > Subject Re: Flow Label > : > > > -------------------------------------------------------------------------------------------------------------------------------- > > Subrata Goswami wrote: > > > > The main point is, if I am a provider and I get a packet, how can > > I be sure that some malicious entity in the middle has not modified > > the flow label so that it can avail of better QoS ? > > You can't, any more than you can be sure the DSCP hasn't changed, or that > somebody isn't playing games with port numbers to fool your classifier. > > The ISP's defence against this is that more QoS will result in a higher bill. > So the ISP actually doesn't care; they get paid accordingly. > > Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 09:33:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AHX0Ng022395 for ; Thu, 10 Jan 2002 09:33:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AHX074022394 for ipng-dist; Thu, 10 Jan 2002 09:33:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AHWuNg022387 for ; Thu, 10 Jan 2002 09:32:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02245 for ; Thu, 10 Jan 2002 09:33:03 -0800 (PST) Received: from berkshire.research.att.com (nevada.hpl.external.hp.com [192.6.19.94]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28347 for ; Thu, 10 Jan 2002 10:33:02 -0700 (MST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 2D4A37B69; Thu, 10 Jan 2002 12:26:08 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Gerard.Gastaud@alcatel.fr Cc: Brian E Carpenter , Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jan 2002 12:26:08 -0500 Message-Id: <20020110172608.2D4A37B69@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Gerard.Gastaud@alc atel.fr writes: > > > >and the user may refuse to pay because it idid not ask for the flow label that the malicious entity overwrote An enemy who is overwriting flow labels could generate fake packets with arbitrary flow labels. It's strictly easier -- instead of deleting and reinserting packets, you just generate them, with any fields you want. If the routers can't cryptographically verify every flow labeled-packet -- and they can't do that in any rational fashion, I suspect -- then the only other choice is border control. Your border routers -- including the peering routers, if necessary -- have to check that incoming packets are, in some sense, "legal". In particular, if you're going to charge someone extra for such services, you have to ensure that the right party sent the packets. (This creates an interesting problem at peering links -- what do you do with packets that have a legal flow label for the peer, but not for you?) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 10:02:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AI2BNg022461 for ; Thu, 10 Jan 2002 10:02:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AI2BG5022460 for ipng-dist; Thu, 10 Jan 2002 10:02:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AI27Ng022453 for ; Thu, 10 Jan 2002 10:02:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16338 for ; Thu, 10 Jan 2002 10:02:13 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27051 for ; Thu, 10 Jan 2002 11:01:54 -0700 (MST) Received: from kenawang ([204.181.204.228]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA17213; Thu, 10 Jan 2002 10:00:59 -0800 (PST) Message-Id: <4.2.2.20020110123646.03743350@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 10 Jan 2002 13:01:55 -0500 To: jarno.rajahalme@nokia.com From: Margaret Wasserman Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <009CA59D1752DD448E07F8EB2F911757198092@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jarno, At 09:51 AM 1/10/02 , jarno.rajahalme@nokia.com wrote: >I just reviewed the related threads on this list and the proposed text >quoted below seems to have unanimous support (less ~2 persons) on the >list. I support this text as well, but have a worry about it not stating >in which context flow label, when set, is meaningful. I do not think that we should define this as part of the IPv6 base specification. The semantics of the flow label (including how it can (or can't) be used to identify a flow) should be specified as part of any flow management mechanism that uses the IPv6 flow label field. This may differ from one mechanism to another. I do not think that the base IPv6 specs should place any constraints on how flow management mechanisms can use the flow label. NOTE: I realize that immutability is a constraint. I have agreed to compromise on that one point. >The text below >says that the label is used to "label sets of packets". In the SLC >meeting I presented our proposal to consider the (Source Address, Flow >Label, Destination Address) 3-tuple to classify the "set of packets". It would be okay with me to take out the words "sets of", if you believe that this is confusing without further context. I do not think that we want to specify, as part of IPv6, that a 3-tuple can be used to identify a flow. I have two reasons for this: - The 3-tuple that you describe is not sufficient to unambiguously identify a flow without further specification of how/when flow labels can be re-used by hosts. - How to classify a flow shouldn't be part of the base IPv6 specification -- it is specific to a flow management mechanism. [...] >Also, not stating >how the "set" can be classified will not help HW-designers to do the >right thing with their designs ASAP. Can you give examples of "right things" that could be done if we make this change that could not be done if we don't make this change? >Text including the S+D addresses would be like (the second sentence is >added, no other changes): > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to label sets of packets. A packet can be classified to a set > with the source address, flow label, destination address triplet. [...] >So, for those who have hummed yes to the text below, how many of you >would oppose modifying it to include mentioning the fields used for >classification, and why? I strongly object to mentioning "the fields used for classification" as part of the base IPv6 specs. I think that flow management mechanisms and their semantics (including flow classification mechanism(s)) should be specified in separate documents (and by separate WGs). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 12:06:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0AK6vKE022782 for ; Thu, 10 Jan 2002 12:06:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0AK6v9P022781 for ipng-dist; Thu, 10 Jan 2002 12:06:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0AK6sKE022774 for ; Thu, 10 Jan 2002 12:06:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13561 for ; Thu, 10 Jan 2002 12:07:00 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28217 for ; Thu, 10 Jan 2002 12:06:59 -0800 (PST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id PAA03638 for ; Thu, 10 Jan 2002 15:09:36 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA05993; Thu, 10 Jan 2002 15:09:35 -0500 Message-ID: <3C3DF4BF.9DB23528@txc.com> Date: Thu, 10 Jan 2002 15:08:31 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <3C3DBBA4.AAD1A280@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0AC59D9CB57DA86218F62297" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms0AC59D9CB57DA86218F62297 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit And engineers get the blame? Alex Brian E Carpenter wrote: > > Gerard.Gastaud@alcatel.fr wrote: > > > > and the user may refuse to pay because it idid not ask for the flow label that the malicious entity overwrote > > Indeed, and then the lawyers get involved. This is nothing new. > > Brian > > > gérard > > > > Brian E Carpenter on 10/01/2002 15:09:10 > > > > > > > > To: Subrata Goswami > > > > cc: ipng@sunroof.eng.sun.com(bcc: Gerard > > GASTAUD/FR/ALCATEL) > > > > > > > > Subject Re: Flow Label > > : > > > > > > --------------------------------------------------------------------------------------------------------------------------------- > > > > Subrata Goswami wrote: > > > > > > The main point is, if I am a provider and I get a packet, how can > > > I be sure that some malicious entity in the middle has not modified > > > the flow label so that it can avail of better QoS ? > > > > You can't, any more than you can be sure the DSCP hasn't changed, or that > > somebody isn't playing games with port numbers to fool your classifier. > > > > The ISP's defence against this is that more QoS will result in a higher bill. > > So the ISP actually doesn't care; they get paid accordingly. > > > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms0AC59D9CB57DA86218F62297 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMTAyMDA4MzNaMCMGCSqGSIb3DQEJ BDEWBBTZ7BpNKiAVv7YkKGjj0KGMQZu2OjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgIEFCN5LPEEh1CmY4Z30E9Y77wI1ZHuzUbqq2VaJnpbeTDoR QEbHsLVJ6mGUH0R9altAEvXKIQGdiHxvDYC8ifdUnzEd1UrYKHuRvXOFbmfB+ZdRe/pAc5XW 4uJanCCE7EvBvtiNite1MIKY92mN44dQuNFziQIshS834UWbGuYI --------------ms0AC59D9CB57DA86218F62297-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 23:51:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0B7p1KE023515 for ; Thu, 10 Jan 2002 23:51:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0B7p1LC023514 for ipng-dist; Thu, 10 Jan 2002 23:51:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0B7owKE023507 for ; Thu, 10 Jan 2002 23:50:58 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03167 for ; Thu, 10 Jan 2002 23:51:04 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08911 for ; Thu, 10 Jan 2002 23:51:02 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id IAA10616; Fri, 11 Jan 2002 08:51:00 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA65024 from ; Fri, 11 Jan 2002 08:50:58 +0100 Message-Id: <3C3E9963.A64C55CE@hursley.ibm.com> Date: Fri, 11 Jan 2002 08:50:59 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label] References: <4.2.2.20020110123646.03743350@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Margaret. To give one example of where Jarno's addition can lead us into trouble, an SCTP flow may have several different addresses at different times; we could discuss for days whether Jarno's extra text is consistent with that case. But let's not do so; fewer words are better in this case. Brian Margaret Wasserman wrote: > > Hi Jarno, > > At 09:51 AM 1/10/02 , jarno.rajahalme@nokia.com wrote: > >I just reviewed the related threads on this list and the proposed text > >quoted below seems to have unanimous support (less ~2 persons) on the > >list. I support this text as well, but have a worry about it not stating > >in which context flow label, when set, is meaningful. > > I do not think that we should define this as part of the IPv6 > base specification. The semantics of the flow label (including how > it can (or can't) be used to identify a flow) should be specified > as part of any flow management mechanism that uses the IPv6 flow label > field. This may differ from one mechanism to another. > > I do not think that the base IPv6 specs should place any constraints > on how flow management mechanisms can use the flow label. > > NOTE: I realize that immutability is a constraint. I have > agreed to compromise on that one point. > > >The text below > >says that the label is used to "label sets of packets". In the SLC > >meeting I presented our proposal to consider the (Source Address, Flow > >Label, Destination Address) 3-tuple to classify the "set of packets". > > It would be okay with me to take out the words "sets of", if you > believe that this is confusing without further context. > > I do not think that we want to specify, as part of IPv6, that a 3-tuple > can be used to identify a flow. I have two reasons for this: > > - The 3-tuple that you describe is not sufficient to unambiguously > identify a flow without further specification of how/when > flow labels can be re-used by hosts. > - How to classify a flow shouldn't be part of the base IPv6 > specification -- it is specific to a flow management > mechanism. > > [...] > >Also, not stating > >how the "set" can be classified will not help HW-designers to do the > >right thing with their designs ASAP. > > Can you give examples of "right things" that could be done if we make > this change that could not be done if we don't make this change? > > >Text including the S+D addresses would be like (the second sentence is > >added, no other changes): > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to label sets of packets. A packet can be classified to a set > > with the source address, flow label, destination address triplet. > [...] > >So, for those who have hummed yes to the text below, how many of you > >would oppose modifying it to include mentioning the fields used for > >classification, and why? > > I strongly object to mentioning "the fields used for classification" as > part of the base IPv6 specs. I think that flow management mechanisms > and their semantics (including flow classification mechanism(s)) should > be specified in separate documents (and by separate WGs). > > Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 10 23:58:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0B7wsKE023548 for ; Thu, 10 Jan 2002 23:58:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0B7wsA4023547 for ipng-dist; Thu, 10 Jan 2002 23:58:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0B7wpKE023540 for ; Thu, 10 Jan 2002 23:58:51 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25764 for ; Thu, 10 Jan 2002 23:58:57 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11182 for ; Thu, 10 Jan 2002 23:58:55 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id IAA11756; Fri, 11 Jan 2002 08:58:53 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60366 from ; Fri, 11 Jan 2002 08:58:51 +0100 Message-Id: <3C3E9B37.486A9A8F@hursley.ibm.com> Date: Fri, 11 Jan 2002 08:58:47 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Steven M. Bellovin" Cc: Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <20020110172608.2D4A37B69@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Indeed. All of this is the same for the DSCP actually, and the assumption is that operators will protect themselves with admission control. (See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for detailed discussion) Brian "Steven M. Bellovin" wrote: > > In message , Gerard.Gastaud@alc > atel.fr writes: > > > > > > > > >and the user may refuse to pay because it idid not ask for the flow label > that the malicious entity overwrote > > An enemy who is overwriting flow labels could generate fake packets > with arbitrary flow labels. It's strictly easier -- instead of > deleting and reinserting packets, you just generate them, with any > fields you want. > > If the routers can't cryptographically verify every flow labeled-packet > -- and they can't do that in any rational fashion, I suspect -- then > the only other choice is border control. Your border routers -- > including the peering routers, if necessary -- have to check that > incoming packets are, in some sense, "legal". In particular, if you're > going to charge someone extra for such services, you have to ensure > that the right party sent the packets. (This creates an interesting > problem at peering links -- what do you do with packets that have a > legal flow label for the peer, but not for you?) > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 05:54:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BDsvKE023912 for ; Fri, 11 Jan 2002 05:54:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BDsvQR023911 for ipng-dist; Fri, 11 Jan 2002 05:54:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BDsrKE023904 for ; Fri, 11 Jan 2002 05:54:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04479 for ; Fri, 11 Jan 2002 05:55:00 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08247 for ; Fri, 11 Jan 2002 06:54:59 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14496; Fri, 11 Jan 2002 08:54:56 -0500 (EST) Message-Id: <200201111354.IAA14496@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-host-load-sharing-00.txt Date: Fri, 11 Jan 2002 08:54:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Host to Router Load Sharing Author(s) : B. Hinden Filename : draft-ietf-ipv6-host-load-sharing-00.txt Pages : 4 Date : 10-Jan-02 This document defines a change to IPv6 Neighbor Discovery that IPv6 hosts can use to load share their outgoing traffic between multiple default routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-host-load-sharing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020110150256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-host-load-sharing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150256.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 07:03:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BF31KE023968 for ; Fri, 11 Jan 2002 07:03:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BF31qI023967 for ipng-dist; Fri, 11 Jan 2002 07:03:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BF2uKE023960 for ; Fri, 11 Jan 2002 07:02:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09304 for ; Fri, 11 Jan 2002 07:02:55 -0800 (PST) Received: from berkshire.research.att.com (H-135-207-53-60.research.att.com [135.207.53.60]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04043 for ; Fri, 11 Jan 2002 08:02:53 -0700 (MST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id D34077B4B; Fri, 11 Jan 2002 10:02:46 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Brian E Carpenter Cc: Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jan 2002 10:02:46 -0500 Message-Id: <20020111150246.D34077B4B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3C3E9B37.486A9A8F@hursley.ibm.com>, Brian E Carpenter writes: >Indeed. All of this is the same for the DSCP actually, and the >assumption is that operators will protect themselves with >admission control. > >(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for detailed discussion) > Right. The question now is how to do that. I was about to agree strongly with the "must send as zero if not a flow, routers must not modify" until I started thinking along these lines. What should a border router do with a packet that doesn't meet its constraints? I only see three choices: reset the flow label to something locally acceptable, drop the packet, or tunnel. But dropping the packet means that flow labels can only be used for flows that stay within a particular flow label domain, and the tunneling path leads to madness. (Well, perhaps to MPLS, but I don't think we want to go down that rathole now.) I'm forced to conclude that we have two choices: either we give up on flow labels entirely, or we permit them to be modified en route. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 07:15:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BFFOKE023992 for ; Fri, 11 Jan 2002 07:15:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BFFOsG023991 for ipng-dist; Fri, 11 Jan 2002 07:15:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BFFGKE023984 for ; Fri, 11 Jan 2002 07:15:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19501 for ; Fri, 11 Jan 2002 07:15:22 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07278 for ; Fri, 11 Jan 2002 07:15:18 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BFFHK02626 for ; Fri, 11 Jan 2002 16:15:18 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jan 11 16:15:08 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 16:15:08 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1DC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Steven M. Bellovin'" , Brian E Carpenter Cc: Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: RE: Flow Label Date: Fri, 11 Jan 2002 16:14:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3C3E9B37.486A9A8F@hursley.ibm.com>, Brian E > Carpenter writes: > >Indeed. All of this is the same for the DSCP actually, and the > >assumption is that operators will protect themselves with > >admission control. > > > >(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for > detailed discussion) > > > > Right. The question now is how to do that. I was about to agree > strongly with the "must send as zero if not a flow, routers > must not modify" > until I started thinking along these lines. What should a border > router do with a packet that doesn't meet its constraints? > I only see > three choices: reset the flow label to something locally > acceptable, > drop the packet, or tunnel. But dropping the packet means > that flow > labels can only be used for flows that stay within a > particular flow > label domain, and the tunneling path leads to madness. > (Well, perhaps > to MPLS, but I don't think we want to go down that rathole > now.) I'm > forced to conclude that we have two choices: either we > give up on flow > labels entirely, or we permit them to be modified en route. > => But as Robert Elz mentioned in a previous email, this is the same argument for IP addresses really. All we can do is mandate it in the standard, and if routers don't follow it, then they're breaking communication. I realise AH solves the problem for IP addresses, but how often is it used? or how often is it used specifically to protect addresses ? In addition AH is used for e2e integrity, not for intermediate routers. Doing something similar for intermediate routers is clearly...difficult. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 07:51:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BFpKKE024042 for ; Fri, 11 Jan 2002 07:51:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BFpKM9024041 for ipng-dist; Fri, 11 Jan 2002 07:51:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BFpHKE024034 for ; Fri, 11 Jan 2002 07:51:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24498 for ; Fri, 11 Jan 2002 07:51:23 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08713 for ; Fri, 11 Jan 2002 07:51:22 -0800 (PST) Received: from repligate (as1b-15.chi.il.dial.anet.com [198.92.157.15]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0BFoUnE028571; Fri, 11 Jan 2002 09:50:31 -0600 (CST) Message-ID: <028701c19ab7$b6195250$8328fea9@repligate> From: "Jim Fleming" To: "Steven M. Bellovin" , "Brian E Carpenter" Cc: , "Subrata Goswami" , References: <20020111150246.D34077B4B@berkshire.research.att.com> Subject: Re: Flow Label Date: Fri, 11 Jan 2002 07:50:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Steven M. Bellovin" I'm > forced to conclude that we have two choices: either we give up on flow > labels entirely, or we permit them to be modified en route. > There is a third option, which is consistent with the way flow labels are embodied in the running code (remember that notion? running code) In the IPv6 running code, the flow labels don't really exist. This is very much like the way Unix had non-existent bits to the left of a char. The getchar function was then able to read a char and detect EOF, even though there was no EOF char. Many people have used the following code ...while((c=getchar()) != EOF)....and still assume the char is 8 bits. They do not spend their time running around trying to police what is in the bits to the left of those 8 bits. With IPv6++, the 20 bits have a 4 bit in-header data length value. The other 16 bits have a unified StarGate value. Routing is only done on the left-most 64 bits of the Source and Destination fields. Depending on the Protocol field (NXTHDR), the protocol designer is able to define how the 4 bit length, 16 bit StarGate and 16 data bytes are defined/used, etc. Just as with the EOF, that may be totally outside of the user's view. As one example, the VPC protocol can ride inside of the header. That allows for remote downloading and control of the protocol engine. The program running in the protocol engine, then defines how the other bits in the packets are processed. The 20 bits and 16 bytes used by VPC are in another dimension from the user's information. That dimension is best left out of the view of the users, just like the EOF bits. http://www.dot-biz.com/INFO/Papers/VPC In summary, forget about the 20 bit flow label. Just imagine it is not there. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info http://www.dot-biz.com/INFO/Papers/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 08:06:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BG6PKE024086 for ; Fri, 11 Jan 2002 08:06:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BG6PwG024085 for ipng-dist; Fri, 11 Jan 2002 08:06:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BG6MKE024078 for ; Fri, 11 Jan 2002 08:06:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22684 for ; Fri, 11 Jan 2002 08:06:28 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02914 for ; Fri, 11 Jan 2002 08:06:26 -0800 (PST) Received: from repligate (as1b-15.chi.il.dial.anet.com [198.92.157.15]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0BG6BnE004554; Fri, 11 Jan 2002 10:06:12 -0600 (CST) Message-ID: <02b901c19ab9$e71e1460$8328fea9@repligate> From: "Jim Fleming" To: "Hesham Soliman \(ERA\)" , "'Steven M. Bellovin'" , "Brian E Carpenter" Cc: , "Subrata Goswami" , References: <4DA6EA82906FD511BE2F00508BCF053801C4C1DC@Esealnt861.al.sw.ericsson.se> Subject: Mandating Standards in the United States ? Date: Fri, 11 Jan 2002 08:06:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Hesham Soliman (ERA)" > => But as Robert Elz mentioned in a previous email, this > is the same argument for IP addresses really. All we can > do is mandate it in the standard, and if routers don't > follow it, then they're breaking communication. ----- Some countries have an approach to standards where they "mandate" and the people all listen and nod their heads without asking questions. The United States develops standards in the open marketplace. VHS and Betamax is a good example. NTSC and PAL have an interesting history. The Minister of Communication of Canada once pointed out to me that Canada and the U.S., even though similar in culture, are very different in this area. He said that Canada can not afford for any of their engineers to fail, they do not have enough. As a result, the government and various groups spend enormous amounts of time mandating standards to make sure that the engineers are endorsed and succeed. He pointed out that the U.S. is like an arena full of gladiators, and standards are set by the marketplace. He also pointed out that many Canadians leave Canada to work in the U.S. because they prefer to see their ideas live of die on their own merits, rather than the backing of some clueless group that mandates what they likely do not even understand. The ICANN/IETF crowd is a perfect example. They can now go to Africa to preach their gospel. In the U.S. and parts of Canada, people are developing standards in the marketplace, with rough consensus and working code. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 12:08:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BK8TKE024343 for ; Fri, 11 Jan 2002 12:08:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BK8T6N024342 for ipng-dist; Fri, 11 Jan 2002 12:08:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BK8QKE024335 for ; Fri, 11 Jan 2002 12:08:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28396 for ; Fri, 11 Jan 2002 12:08:28 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13329 for ; Fri, 11 Jan 2002 13:08:28 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0BK8PF03419; Fri, 11 Jan 2002 12:08:25 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAQ84298; Fri, 11 Jan 2002 12:07:49 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA14456; Fri, 11 Jan 2002 12:08:21 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.17973.145302.745873@thomasm-u1.cisco.com> Date: Fri, 11 Jan 2002 12:08:21 -0800 (PST) To: "Steven M. Bellovin" Cc: Brian E Carpenter , Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <20020111150246.D34077B4B@berkshire.research.att.com> References: <20020111150246.D34077B4B@berkshire.research.att.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin writes: > In message <3C3E9B37.486A9A8F@hursley.ibm.com>, Brian E Carpenter writes: > >Indeed. All of this is the same for the DSCP actually, and the > >assumption is that operators will protect themselves with > >admission control. > > > >(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for detailed discussion) > > > > Right. The question now is how to do that. I was about to agree > strongly with the "must send as zero if not a flow, routers must not modify" > until I started thinking along these lines. What should a border > router do with a packet that doesn't meet its constraints? I only see > three choices: reset the flow label to something locally acceptable, > drop the packet, or tunnel. But dropping the packet means that flow > labels can only be used for flows that stay within a particular flow > label domain, and the tunneling path leads to madness. (Well, perhaps > to MPLS, but I don't think we want to go down that rathole now.) I'm > forced to conclude that we have two choices: either we give up on flow > labels entirely, or we permit them to be modified en route. First of all, there's nothing that is defined from which to take action based on the flow label, so I think this is largely an academic question. If we suspend some disbelief and posit an edge device which, say, polices a flow to a particular rate, why does it follow that the router would need the ability to rewrite the label? Certainly in the Intserv case, policers don't rewrite the 5 tuple. Their only option is to change the PHB or drop it. In diffserv style, it can in addition to dropping and changing its queuing characteristics, rewrite the DSCP. So I guess I just don't see where a policer would need the ability to alter it. Also: pragmatically, we can alway change our mind on the mutability front if it starts life as *immutable*. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 15:38:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BNcfKE024731 for ; Fri, 11 Jan 2002 15:38:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BNce4I024730 for ipng-dist; Fri, 11 Jan 2002 15:38:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BNcdKE024723 for ; Fri, 11 Jan 2002 15:38:39 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0BNbsAd005825 for ; Fri, 11 Jan 2002 15:37:54 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0BNbrFL005824 for ipng@sunroof.eng.sun.com; Fri, 11 Jan 2002 15:37:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07AknNg010538 for ; Mon, 7 Jan 2002 02:46:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14580 for ; Mon, 7 Jan 2002 02:46:55 -0800 (PST) Received: from spidey.speakeasy.net (webmail.speakeasy.net [216.254.0.16]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15497 for ; Mon, 7 Jan 2002 02:46:54 -0800 (PST) Received: (from nobody@localhost) by spidey.speakeasy.net (8.11.6/8.11.2) id g07AXNr20081; Mon, 7 Jan 2002 02:33:23 -0800 Message-Id: <200201071033.g07AXNr20081@spidey.speakeasy.net> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Mon, 7 Jan 2002 02:33:23 -0800 From: Qing Li To: ipng@sunroof.eng.sun.com Subject: Ques. on draft-ietf-ipngwg-rfc2096-update-00 X-Sender: qingli@speakeasy.net X-Originating-Ip: [64.81.55.94] X-Mailer: Speakeasy Network Webmail 2.1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The last sentence in the description for "inetCidrRouteAge" states "....except through knowledge of the routing protocol by which the route was learned." Does that mean "inetCidrRouteAge" applies to entries with "inetCidrRouteProto" in the range of 5 - 16 as stated in rfc2096? Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 15:39:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BNdIKE024741 for ; Fri, 11 Jan 2002 15:39:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BNdHT8024740 for ipng-dist; Fri, 11 Jan 2002 15:39:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BNdGKE024733 for ; Fri, 11 Jan 2002 15:39:16 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0BNcUAd005833 for ; Fri, 11 Jan 2002 15:38:30 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0BNcUx8005832 for ipng@sunroof.eng.sun.com; Fri, 11 Jan 2002 15:38:30 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08B9oNg015255; Tue, 8 Jan 2002 03:09:50 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15811; Tue, 8 Jan 2002 03:09:54 -0800 (PST) Received: from cgprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14407; Tue, 8 Jan 2002 03:09:51 -0800 (PST) Received: from [193.136.92.65] (HELO trantor.it.pt) by cgprelay.ua.pt (CommuniGate Pro SMTP 3.5.2) with ESMTP id 933335; Tue, 08 Jan 2002 11:09:44 +0000 Received: from verne.av.it.pt (verne.av.it.pt [193.136.92.50]) by trantor.it.pt (sendmail) with ESMTP id 683542C1A; Tue, 8 Jan 2002 11:09:12 +0000 (PWT) Received: from IT/SpoolDir by verne.av.it.pt (Mercury 1.47); 8 Jan 02 11:07:20 GMT Received: from SpoolDir by IT (Mercury 1.47); 8 Jan 02 11:07:02 GMT Received: from loliveira (193.136.92.235) by verne.av.it.pt (Mercury 1.47); 8 Jan 02 11:06:58 GMT Message-ID: <006e01c19877$f23786e0$eb5c88c1@loliveira> From: =?iso-8859-1?Q?Lu=EDs_Miguel_Oliveira?= To: Cc: Subject: IPv6 Mobility in transition scenarios Date: Tue, 8 Jan 2002 11:09:06 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C19834.E3CC6870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C19834.E3CC6870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am to study IPv6 mobility in transition scenarios. This type of = scenarios involves a MN that change to different IPv4, IPv6 or IPv4/IPv6 = network.=20 The correspondent node could be IPV4 or IPv6. Which must be the requirements of the Home Network, Foreign Network, the = MN and the HA? And what are the requirements for the transition = IPv4<->IPv6 mechanisms? Thanks in advance. _________________________________ Luis Miguel L. de Oliveira loliveira@av.it.pt ; loliveira@ipt.pt IPT - Instituto Polit=E9cnico de Tomar Quinta do Contador - Estrada da Serra 2300 TOMAR Instituto de Telecomunica=E7=F5es Campus Universit=E1rio de Santiago 3810-193 AVEIRO - PORTUGAL _________________________________ ------=_NextPart_000_006B_01C19834.E3CC6870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am to study = IPv6 mobility=20 in transition scenarios. This type of scenarios involves a MN that = change to=20 different IPv4, IPv6 or IPv4/IPv6 network.

The correspondent = node=20 could be IPV4 or IPv6.

Which must be the = requirements of the Home Network, Foreign Network, the MN and the HA? = And what=20 are the requirements for the transition IPv4<->IPv6=20 mechanisms?

Thanks in=20 advance.

_________________________________
Luis Miguel L. de = Oliveira
loliveira@av.it.pt ; loliveira@ipt.pt
 
IPT - Instituto Polit=E9cnico de = Tomar
Quinta do=20 Contador - Estrada da Serra
2300 TOMAR
 
Instituto de = Telecomunica=E7=F5es
Campus=20 Universit=E1rio de Santiago
3810-193 AVEIRO -=20 PORTUGAL
_________________________________
------=_NextPart_000_006B_01C19834.E3CC6870-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 11 15:39:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BNdmKE024758 for ; Fri, 11 Jan 2002 15:39:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0BNdm5X024757 for ipng-dist; Fri, 11 Jan 2002 15:39:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0BNdkKE024750 for ; Fri, 11 Jan 2002 15:39:46 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0BNd1Ad005841 for ; Fri, 11 Jan 2002 15:39:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0BNd1OO005840 for ipng@sunroof.eng.sun.com; Fri, 11 Jan 2002 15:39:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09GJpNg019388 for ; Wed, 9 Jan 2002 08:19:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10062 for ; Wed, 9 Jan 2002 08:19:58 -0800 (PST) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24816 for ; Wed, 9 Jan 2002 09:21:06 -0700 (MST) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id g09GJtK62826 for ; Wed, 9 Jan 2002 17:19:55 +0100 (CET) Message-ID: <001501c19929$32d7d900$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPCN 2002 (IP-based Cellular Networks) Date: Wed, 9 Jan 2002 16:13:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0206_01C19928.89A1ABE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0206_01C19928.89A1ABE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One of the most interesting subjects of IPCN 2002 (IP-based Cellular = Networks) is the relationship between the licensed 2.5/3G services and = 802.11 hotspots. How can optimal use be made of both environments such = that a realistic business service is possible?=20 Carriers will bring answers next April 23-26 during the third edition of = IPCN (Intersection of Mobile WAN and WLAN).=20 All details at: http://www.upperside.fr/ipcn02/baipcn02intro.htm ------=_NextPart_000_0206_01C19928.89A1ABE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
One of the = most=20 interesting subjects of IPCN 2002 (IP-based Cellular Networks) is the=20 relationship between the licensed 2.5/3G services and 802.11 hotspots. = How can=20 optimal use be made of both environments such that a realistic business = service=20 is possible?
Carriers will bring answers next = April 23-26=20 during the third edition of IPCN (Intersection of Mobile WAN and = WLAN).
All details=20 at:
http://www.uppe= rside.fr/ipcn02/baipcn02intro.htm
 
 
------=_NextPart_000_0206_01C19928.89A1ABE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 12 22:27:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0D6RSKE026503 for ; Sat, 12 Jan 2002 22:27:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0D6RSjx026502 for ipng-dist; Sat, 12 Jan 2002 22:27:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0D6ROKE026495 for ; Sat, 12 Jan 2002 22:27:25 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA26668 for ; Sat, 12 Jan 2002 22:27:32 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA15295 for ; Sat, 12 Jan 2002 22:27:32 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26473; Sun, 13 Jan 2002 01:22:58 -0500 Date: Sun, 13 Jan 2002 01:22:57 -0500 (EST) From: Jim Bound To: jarno.rajahalme@nokia.com Cc: mrw@windriver.com, brian@hursley.ibm.com, RACarlson@anl.gov, kempf@docomolabs-usa.com, moore@cs.utk.edu, bill@strahm.net, alain.durand@eng.sun.com, randy@psg.com, smb@research.att.com, kre@munnari.OZ.AU, mat@cisco.com, sob@harvard.edu, ipng@sunroof.eng.sun.com Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label] In-Reply-To: <009CA59D1752DD448E07F8EB2F911757198092@esebe004.NOE.Nokia.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree. The triplet is necessary and will avoid state deadlocks for sure. This is what I thought I agreed to at SLC as you suggest. I support your change. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 13 09:46:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkZKE027087 for ; Sun, 13 Jan 2002 09:46:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0DHkZA2027086 for ipng-dist; Sun, 13 Jan 2002 09:46:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkSKE027072; Sun, 13 Jan 2002 09:46:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02648; Sun, 13 Jan 2002 09:46:32 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13546; Sun, 13 Jan 2002 10:46:31 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 731086A909; Sun, 13 Jan 2002 19:46:25 +0200 (EET) Message-ID: <3C41B457.6080604@kolumbus.fi> Date: Sun, 13 Jan 2002 18:22:47 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: Pekka Nikander , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis writes: > and that your home agent must be part of the > still-not-existing global AAA infrastructure so that you could use HAO. > > => as I've said, this *recommendation* is for your protection: > without remote network access control you can be a target... Ah, but I think the issue is who the victims are. If *I* add protection in my network, that does *not* guarantee I won't be hit by reflection attacks from someone's network that only has regular ingress filtering (without the stateful and AAA patches). Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 13 09:48:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHmAKE027160 for ; Sun, 13 Jan 2002 09:48:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0DHmAhD027159 for ipng-dist; Sun, 13 Jan 2002 09:48:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHm6KE027152; Sun, 13 Jan 2002 09:48:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12527; Sun, 13 Jan 2002 09:48:13 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15048; Sun, 13 Jan 2002 09:48:12 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 251FE6A908; Sun, 13 Jan 2002 19:48:04 +0200 (EET) Message-ID: <3C41C1D7.4070509@kolumbus.fi> Date: Sun, 13 Jan 2002 19:20:23 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: How to move forward in the HAO & ingress filter discussion References: <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, We've had a very long discussion on what to do with MIPv6 Home Address Options and Ingress Filtering, basically centering around (a) solutions restricting HAOs to nodes that employ Route Optimization, (b) solutions employing AAA in firewalls, and (c) solutions that discard HAOs altogether and use BU authentication procedures (e.g. RR) from the access router to the MN. I'm not sure we are near consensus yet -- though we could be, it's hard to say on the list because just a handful of people have participated the discussion. In any case, I'm thinking about how to go forward in a practical manner. We need a solution. And we don't have much time to redesign MIPv6, so I'd really like to see a solution that doesn't need too much new work. But how do we decide between a-c? I have a proposal. But first, let me make some observations: - Most people do seem to agree that HAO reflection is an issue that needs to be dealt with somehow. - A restriction can be relaxed easier than tightened. User groups with better technology can run relaxed versions, or future standard versions can have relaxed rules if we see that the infrastructure around us allows it. - As a general rule, I'd like the Internet to use end-to-end mechanisms more than network assistance. This isn't just an architectural principle, but it will also ensure that we can deploy our things without waiting for providers to catch up. - The different solutions have different impacts on various use cases of MIPv6. Some benefit regular MNs, some those that use RO with a CN, for instance. So, my proposal is as follows: 1. We will not use the alternative (c), because it is not an end-to-end mechanism, because multi-hop ingress filtering could generate delays, and because scalability of intermediate routers with ingress filtering feature might become a question mark if there's a lot of state to hold. As a tradeoff, we have to carry HAOs in our packets. 2. We will have a two-phased approach to the MIPv6 spec and its treatment of reflection attacks: the first phase uses method (a) and the second phase relaxes the rules to allow also (b). The first phase will be put to the MIPv6 RFC. When and if experience shows that we can have AAA-based filtering in access routers and firewalls, an extension can be defined to allow the more relaxed use of HAOs. Comments or other proposals are welcome. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 13 16:34:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0E0Yc2Q027674 for ; Sun, 13 Jan 2002 16:34:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0E0YbTB027673 for ipng-dist; Sun, 13 Jan 2002 16:34:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0E0YY2Q027666 for ; Sun, 13 Jan 2002 16:34:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26599 for ; Sun, 13 Jan 2002 16:34:40 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA00904 for ; Sun, 13 Jan 2002 17:34:39 -0700 (MST) Received: from repligate (as1-126.chi.il.dial.anet.com [198.92.156.126]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0E0U1iS019821; Sun, 13 Jan 2002 18:30:01 -0600 (CST) Message-ID: <00fa01c19ca3$6c96f7c0$8328fea9@repligate> From: "Jim Fleming" To: "Jim Bound" , Cc: , , , , , , , , , , , , References: Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label] Date: Sun, 13 Jan 2002 18:30:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Using an Exclusive OR function on the two StarGate values means that the bit difference is carried across the IPv4 transport. Either end knows itself and can derive the other side by doing another Exclusive OR. This is similar to using Exclusive OR values in linked lists where only one address is stored. When one knows the location of the node, and a node where they came from, they can compute where they are going. http://www.dot-biz.com/RepliGate/ Jim Fleming http://www.RepliGate.net ----- Original Message ----- From: "Jim Bound" To: Cc: ; ; ; ; ; ; ; ; ; ; ; ; Sent: Saturday, January 12, 2002 10:22 PM Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label] > I agree. The triplet is necessary and will avoid state deadlocks for > sure. This is what I thought I agreed to at SLC as you suggest. I support > your change. > > regards, > > > /jim > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 01:59:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0E9xh2Q028052 for ; Mon, 14 Jan 2002 01:59:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0E9xhMJ028051 for ipng-dist; Mon, 14 Jan 2002 01:59:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0E9xa2Q028036; Mon, 14 Jan 2002 01:59:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22878; Mon, 14 Jan 2002 01:59:43 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11496; Mon, 14 Jan 2002 02:59:42 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0E9xY505787; Mon, 14 Jan 2002 10:59:34 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA03071; Mon, 14 Jan 2002 10:59:34 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0E9xXQ45670; Mon, 14 Jan 2002 10:59:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201140959.g0E9xXQ45670@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Sun, 13 Jan 2002 19:20:23 +0200. <3C41C1D7.4070509@kolumbus.fi> Date: Mon, 14 Jan 2002 10:59:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: We've had a very long discussion on what to do with MIPv6 Home Address Options and Ingress Filtering, basically centering around (a) solutions restricting HAOs to nodes that employ Route Optimization, (b) solutions employing AAA in firewalls, and (c) solutions that => for (b) I prefer network access control (AAA is only one way to provide it). discard HAOs altogether and use BU authentication procedures (e.g. RR) from the access router to the MN. I'm not sure we are near consensus yet -- though we could be, it's hard to say on the list because just a handful of people have participated the discussion. => so it seems we have to wait for the face-to-face meeting. I have a proposal. But first, let me make some observations: - Most people do seem to agree that HAO reflection is an issue that needs to be dealt with somehow. => we have to deal with it but we don't need a stronger solution than today ingress filtering which is a BCP, i.e. something like a SHOULD. - A restriction can be relaxed easier than tightened... => this doesn't work in practice because this is a security issue. In the functionality vs security tradeoff, networking people always choose the security, especially when they get no direct benefit from the functionality. There are only a few counter examples (ingress filtering is one of them). - As a general rule, I'd like the Internet to use end-to-end mechanisms more than network assistance. => ingress filtering is network assistance and is enough. If we try a strong solution we'll get more security (i.e. a reply to a minor improvement to an attack) and we'll weaken the functionality (i.e. we'll lose the triangular routing). This isn't just an architectural principle, but it will also ensure that we can deploy our things without waiting for providers to catch up. => clearly you don't believe in current ingress filtering. - The different solutions have different impacts on various use cases of MIPv6. Some benefit regular MNs, some those that use RO with a CN, for instance. => HAO is not MIPv6 only (i.e. be prepared to relax it :-). So, my proposal is as follows: 1. We will not use the alternative (c), because it is not an end-to-end mechanism, because multi-hop ingress filtering could generate delays, and because scalability of intermediate routers with ingress filtering feature might become a question mark if there's a lot of state to hold. As a tradeoff, we have to carry HAOs in our packets. => I agree: (c) is unrealistic. 2. We will have a two-phased approach to the MIPv6 spec and => no, a two phase approach won't work because we'll stay at the first phase. And you put the burden on the wrong people: this is an ingress filtering problem, not a MIPv6 one, so the solution should be in an ingress filtering improvement, not in a new restriction for MIPv6. its treatment of reflection attacks: the first phase uses method (a) and the second phase relaxes the rules to allow also (b). The first phase will be put to the MIPv6 RFC. => if there is a consensus to do that, I propose to split the MIPv6 document into a basic one about bidirectional tunneling with the home agent and a special one about routing optimization, i.e. the lost of the triangular routing should not have only drawbacks. When and if experience shows that we can have AAA-based filtering in access routers and firewalls, an extension can be defined to allow the more relaxed use of HAOs. => this won't have interest, as soon as the use of HAOs will be marginal, it will no more be considered as a real world security threat. Today firewall people have the choice between to ignore HAOs (easy way for them because they have nothing to do) and to filter them out (easy too but they are reluctant to kill HAO). My proposal is to give a third solution (how to do an intelligent filtering), your solution is to kill the HAO for them (so they won't complain :-). Of course your proposal is safe, but I believe the price is a bit too high. Frankly MIPv6 has already enough problems... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 02:06:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EA692Q028153 for ; Mon, 14 Jan 2002 02:06:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EA69sA028152 for ipng-dist; Mon, 14 Jan 2002 02:06:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EA622Q028137; Mon, 14 Jan 2002 02:06:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09257; Mon, 14 Jan 2002 02:06:08 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01090; Mon, 14 Jan 2002 03:06:07 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0EA62507088; Mon, 14 Jan 2002 11:06:02 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA03241; Mon, 14 Jan 2002 11:06:02 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0EA62Q45746; Mon, 14 Jan 2002 11:06:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201141006.g0EA62Q45746@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Pekka Nikander , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 13 Jan 2002 18:22:47 +0200. <3C41B457.6080604@kolumbus.fi> Date: Mon, 14 Jan 2002 11:06:02 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > and that your home agent must be part of the > still-not-existing global AAA infrastructure so that you could use HAO. > > => as I've said, this *recommendation* is for your protection: > without remote network access control you can be a target... Ah, but I think the issue is who the victims are. If *I* add protection in my network, that does *not* guarantee I won't => there is *no* guarantee with ingress filtering: its purpose is not to make source address spoofing impossible, it is to make it enough unattractive. be hit by reflection attacks from someone's network that only has regular ingress filtering (without the stateful and AAA patches). => you have forgotten the purpose of ingress filtering. To get the level of security you seems to want, AH should be mandatory (its use, not its implementation). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 02:17:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EAH52Q028266 for ; Mon, 14 Jan 2002 02:17:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EAH5HA028265 for ipng-dist; Mon, 14 Jan 2002 02:17:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EAGw2Q028250; Mon, 14 Jan 2002 02:16:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10110; Mon, 14 Jan 2002 02:17:04 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03102; Mon, 14 Jan 2002 03:17:03 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0EAGj508937; Mon, 14 Jan 2002 11:16:49 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA03510; Mon, 14 Jan 2002 11:16:45 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0EAGhQ45796; Mon, 14 Jan 2002 11:16:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201141016.g0EAGhQ45796@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: Pekka Nikander , ipng@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 13 Jan 2002 17:27:13 +0200. <3C41A751.7010003@piuha.net> Date: Mon, 14 Jan 2002 11:16:43 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I don't think it matters whether the acronym for this > infrastructure was PKI, DNS, or AAA? > > => I agree but it is not forbidden to get advantages of it, only to rely > on it. As we don't rely on ingress filtering for defense against DDoS, > I can't see a problem to propose to use AAA in order to improve ingress > filtering. => I should have added that there are two possible improvements to ingress filtering: network access control and full AAA. The first one keeps the status quo, the second gives more. Yes, it's no problem to improve something. However, improving ingress filting with AAA is not the *whole* picture of what we are doing. You have to remember that by introducing HAO our first step is punching a mile wide hole to the ingress filtering system. And, in fact, you are not improving things by having a smart treatment of the HAO -- you're basically keeping the status quo that we already have with v4. => this is about (any kind of) network access control. So, in some areas that have both ingress filtering and aaa, you may keep the current status, if the aaa fix to ingress filtering is deployed fast enough. However, on other areas you are nuking an existing security measure some people are using. In this sense you are relying on AAA all over the place, => please replace AAA by network access control. just to keep things as they were before. => I don't see a problem: we have *not* ingress filtering performed everywhere today. We don't need an absolute solution, we need only to make HAO spoofing enough unattractive as we did need to make source address spoofing enough unattractive... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 06:03:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EE302Q028652 for ; Mon, 14 Jan 2002 06:03:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EE30ga028649 for ipng-dist; Mon, 14 Jan 2002 06:03:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EE2s2Q028637 for ; Mon, 14 Jan 2002 06:02:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03654 for ; Mon, 14 Jan 2002 06:03:01 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17094 for ; Mon, 14 Jan 2002 06:03:00 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0EE3C105849; Mon, 14 Jan 2002 21:03:15 +0700 (ICT) From: Robert Elz To: "Steven M. Bellovin" cc: Brian E Carpenter , Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <20020111150246.D34077B4B@berkshire.research.att.com> References: <20020111150246.D34077B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jan 2002 21:03:12 +0700 Message-ID: <5847.1011016992@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Jan 2002 10:02:46 -0500 From: "Steven M. Bellovin" Message-ID: <20020111150246.D34077B4B@berkshire.research.att.com> | But dropping the packet means that flow | labels can only be used for flows that stay within a particular flow | label domain, No, you have accepted one of Margaret's arguments, taken that to its logical conclusion, and reached absurdity, so obviously, something has to be wrong. But it isn't the immutability that's wrong, it is the assumption that different QoS mechanisms can redefine the flow label field in different incompatible ways. That simply cannot be allowed to happen, or any kind of usable QoS is even less likely to ever get deployed than the small chance there seems to be at the minute. There has to be (absolutely) one fixed consistent definition for the field, that all QoS mechanisms (now or in the future) can live with. If anyone needs some extra data that doesn't fit, they simply have to put that data elsewhere. If after doing that the flow label is useless to them, then they just don't use it. Exactly what the one fixed definition should be, I'll leave it to others to sort out, but there has to be exactly one - your analysis of what happens if things are allowed to become inconsistent shows that. Allowing routers to change the flow label to make it "legal" doesn't help - apart from simply making it say "unclassified" (which they could do just as easily by putting a magic value defined by them in the DCSP) from where would they get the information to install any other value. But if you can assume they can invent it from somewhere, then you need to work out how to handle the case where my packets flow through 3 independent ISPs, A B and C. I deal directly with A, so I can easily provide a flow label that suits A's requirements. If B doesn't like that, and changed it to something that fits B's requirements, what on earth happens when the packet reaches C? At that point, C has no idea what the flow label might mean - it could be something I put there, or it could be something local of B's. That's simply impossible to support. C has to know what the value represents (whether that then results in any special handling or not is up to whatever agreements exist among the various parties, and what they say - but regardless of that, if there's no way for C to interpret the request, then agreements would be useless). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 10:38:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EIcX2Q029604 for ; Mon, 14 Jan 2002 10:38:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EIcXNP029603 for ipng-dist; Mon, 14 Jan 2002 10:38:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EIcQ2Q029588; Mon, 14 Jan 2002 10:38:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27339; Mon, 14 Jan 2002 10:38:34 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01525; Mon, 14 Jan 2002 10:38:33 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA07152; Mon, 14 Jan 2002 10:38:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0EIcWH32679; Mon, 14 Jan 2002 10:38:32 -0800 X-mProtect: Mon, 14 Jan 2002 10:38:32 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8KBd7c; Mon, 14 Jan 2002 10:38:31 PST Message-ID: <3C4325A7.D3EE2E73@iprg.nokia.com> Date: Mon, 14 Jan 2002 10:38:31 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> <3C41B457.6080604@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > > Francis writes: > > > and that your home agent must be part of the > > still-not-existing global AAA infrastructure so that you could use HAO. > > > > => as I've said, this *recommendation* is for your protection: > > without remote network access control you can be a target... > > Ah, but I think the issue is who the victims are. If *I* add > protection in my network, that does *not* guarantee I won't > be hit by reflection attacks from someone's network that only > has regular ingress filtering (without the stateful and AAA > patches). you mean stateful or AAA patches, right? Vijay > > Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 10:49:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EInG2Q029786 for ; Mon, 14 Jan 2002 10:49:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EInGGJ029785 for ipng-dist; Mon, 14 Jan 2002 10:49:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EIn82Q029770; Mon, 14 Jan 2002 10:49:08 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28360; Mon, 14 Jan 2002 10:49:16 -0800 (PST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26965; Mon, 14 Jan 2002 10:49:14 -0800 (PST) Received: from jariws1 ([62.248.239.228]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020114184913.DDWE12197.fep06-app.kolumbus.fi@jariws1>; Mon, 14 Jan 2002 20:49:13 +0200 Message-ID: <003601c19d2c$2b3ca0c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> <3C41B457.6080604@kolumbus.fi> <3C4325A7.D3EE2E73@iprg.nokia.com> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Mon, 14 Jan 2002 20:49:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Ah, but I think the issue is who the victims are. If *I* add > > protection in my network, that does *not* guarantee I won't > > be hit by reflection attacks from someone's network that only > > has regular ingress filtering (without the stateful and AAA > > patches). > > you mean stateful or AAA patches, right? I believe the AAA-assisted ingress filtering has to be stateful, or? Otherwise you'd be asking for the right home address per packet. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 11:24:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EJOG2Q029924 for ; Mon, 14 Jan 2002 11:24:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EJOGLN029923 for ipng-dist; Mon, 14 Jan 2002 11:24:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EJOD2Q029916 for ; Mon, 14 Jan 2002 11:24:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06760 for ; Mon, 14 Jan 2002 11:24:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09898 for ; Mon, 14 Jan 2002 12:24:18 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA10964; Mon, 14 Jan 2002 11:24:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0EJOHr24287; Mon, 14 Jan 2002 11:24:17 -0800 X-mProtect: Mon, 14 Jan 2002 11:24:17 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdW2Kgrt; Mon, 14 Jan 2002 11:24:16 PST Message-Id: <4.3.2.7.2.20020114112109.0249e730@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 11:23:04 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : IPv6 Host to Router Load Sharing Author(s) : B. Hinden Filename : draft-ietf-ipv6-host-load-sharing-00.txt Pages : 4 Date : 10-Jan-02 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two weeks from today on January 28, 2002. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 12:12:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EKCg2Q000311 for ; Mon, 14 Jan 2002 12:12:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EKCfN0000310 for ipng-dist; Mon, 14 Jan 2002 12:12:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EKCZ2Q000291; Mon, 14 Jan 2002 12:12:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29754; Mon, 14 Jan 2002 12:12:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11623; Mon, 14 Jan 2002 12:12:31 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA14719; Mon, 14 Jan 2002 12:12:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0EKCPI11477; Mon, 14 Jan 2002 12:12:25 -0800 X-mProtect: Mon, 14 Jan 2002 12:12:25 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRJq23M; Mon, 14 Jan 2002 12:12:24 PST Message-ID: <3C433BA8.9785AE7A@iprg.nokia.com> Date: Mon, 14 Jan 2002 12:12:24 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> <3C41B457.6080604@kolumbus.fi> <3C4325A7.D3EE2E73@iprg.nokia.com> <003601c19d2c$2b3ca0c0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > > > > Ah, but I think the issue is who the victims are. If *I* add > > > protection in my network, that does *not* guarantee I won't > > > be hit by reflection attacks from someone's network that only > > > has regular ingress filtering (without the stateful and AAA > > > patches). > > > > you mean stateful or AAA patches, right? > > I believe the AAA-assisted ingress filtering has to be > stateful, or? Otherwise you'd be asking for the right home > address per packet. Actually I was trying to say AAA or 'some kind of network access control'. ofcourse both are stateful. sorry about that. Vijay > > Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 14 14:32:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EMWR2Q000555 for ; Mon, 14 Jan 2002 14:32:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EMWRVJ000554 for ipng-dist; Mon, 14 Jan 2002 14:32:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EMWM2Q000547 for ; Mon, 14 Jan 2002 14:32:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28755 for ; Mon, 14 Jan 2002 14:32:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06367 for ; Mon, 14 Jan 2002 14:32:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22568; Mon, 14 Jan 2002 17:32:25 -0500 (EST) Message-Id: <200201142232.RAA22568@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: IP Version 6 Addressing Architecture to Draft Standard Reply-to: iesg@ietf.org Date: Mon, 14 Jan 2002 17:32:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IP Version 6 Working Group to consider 'IP Version 6 Addressing Architecture' as a Draft Standard, replacing RFC2373, currently a Proposed Standard. The WG originally asked to advance this document to Draft standard in 1998, but the IESG pushed back on advancement pending more implementation experience on some aspects of multicast scoping and on concerns over the readiness of advancing the companion "Aggregatable Global Unicast Address Format" document with which it had been paired. Since that time, additional interoperability has been demonstrated, and the document is being advanced independent of the other document. There was continued support in the WG for advancement of this document. A new IETF Last Call was held in Decemeber, 2000. Comments and IESG discussion resulting from the Last Call resulted in a number of document changes. Those changes included: - removing the Format Prefix (to clarify that implementations should not build in knowledge about any prefixes except ones that are explicitly listed in the specification), - making it clear that all address space was to be treated as global unicast, except in those specific cases where other definitions already existed, - making it clear that reference to RFC 2374 (An Aggregatable Global Unicast Address Format) was an example, as address assignment policy is under the domain of the RIRs A full list of changes can be found in the changes section of the document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 28, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt Imnplementation Report can be viewed at http://www.ietf.cnri.reston.va.us/IESG/Implementations/address-architecture.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 00:24:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F8OT2Q000922 for ; Tue, 15 Jan 2002 00:24:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0F8OTfP000921 for ipng-dist; Tue, 15 Jan 2002 00:24:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F8OK2Q000906; Tue, 15 Jan 2002 00:24:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0F8OL312717; Tue, 15 Jan 2002 09:24:22 +0100 (MET) Date: Mon, 14 Jan 2002 20:44:18 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: jari.arkko@kolumbus.fi Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C41C1D7.4070509@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - As a general rule, I'd like the Internet to use end-to-end > mechanisms more than network assistance. This isn't just > an architectural principle, but it will also ensure that > we can deploy our things without waiting for providers to > catch up. I agree. But I would personally make a stronger statement since I'm concerned with the direction of piling more and more requirements and dependencies on AAA. Thus I think the AAA approach is the wrong one - if we collectively can make AAA/Diameter do the things needed to make Radius more usable (reliabiliy, security, some extensibility) I think we've collectively have been successful. Keep piling more stuff on the AAA system and it might very well get too heavy to be able to fly... Also, waiting for AAA solutions to be available (specified, implemeted, and deployed) before MIPv6 can be used seems to be counter to our desire to finish up MIPv6 soon. > 1. We will not use the alternative (c), because it is not > an end-to-end mechanism, because multi-hop ingress > filtering could generate delays, and because scalability > of intermediate routers with ingress filtering feature > might become a question mark if there's a lot of state to > hold. As a tradeoff, we have to carry HAOs in our packets. > > 2. We will have a two-phased approach to the MIPv6 spec and > its treatment of reflection attacks: the first phase uses > method (a) and the second phase relaxes the rules to allow > also (b). The first phase will be put to the MIPv6 RFC. > When and if experience shows that we can have AAA-based > filtering in access routers and firewalls, an extension > can be defined to allow the more relaxed use of HAOs. While I have concerns with using the AAA per above I think the phased approach (where the AAA approach continues to be discussed and further understood) makes sense to me. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 00:59:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F8x92Q001023 for ; Tue, 15 Jan 2002 00:59:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0F8x9IM001022 for ipng-dist; Tue, 15 Jan 2002 00:59:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F8x62Q001015; Tue, 15 Jan 2002 00:59:06 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27678; Tue, 15 Jan 2002 00:59:12 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22950; Tue, 15 Jan 2002 00:59:11 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0F8x9Z01846; Tue, 15 Jan 2002 10:59:09 +0200 Date: Tue, 15 Jan 2002 10:59:09 +0200 (EET) From: Pekka Savola To: cc: Jari Arkko , Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201140959.g0E9xXQ45670@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 14 Jan 2002, Francis Dupont wrote: [snip] > 2. We will have a two-phased approach to the MIPv6 spec and > > => no, a two phase approach won't work because we'll stay at > the first phase. [snip] If we'd stay at the first phase, that'd probably mean that the stateful network access control mechanism wasn't attractive and wide-spread enough? -- Which is one of the points here. If one would want to differentiate between "network access controlled (no checks in end-nodes)" and "in god we trust, others must be checked", perhaps Home Address Option sub-options could be used? (or identically defined another HAO.) > And you put the burden on the wrong people: > this is an ingress filtering problem, not a MIPv6 one, so > the solution should be in an ingress filtering improvement, > not in a new restriction for MIPv6. (a bit tongue-in-cheek) If QWERTY working group would define a new mechanism for storing effective source address in a varying location of IP header chain, under some destination option's freshly defined fourth option's third sub-option (padded to 2n+x), would digging that out and just coping with it be "ingress filtering problem" too? If AZERTY working group would make new requirements (caused by said working group's new proposal) for ingress filtering, so that it could not be done in practise, would finding new ways to do ingress filtering befall ingress filtering people too? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 01:22:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F9M02Q001161 for ; Tue, 15 Jan 2002 01:22:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0F9M01f001160 for ipng-dist; Tue, 15 Jan 2002 01:22:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F9Lu2Q001153; Tue, 15 Jan 2002 01:21:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22968; Tue, 15 Jan 2002 01:22:02 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00277; Tue, 15 Jan 2002 02:22:02 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0F9M0531215; Tue, 15 Jan 2002 10:22:00 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA26908; Tue, 15 Jan 2002 10:22:00 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0F9LxQ50432; Tue, 15 Jan 2002 10:21:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201150921.g0F9LxQ50432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 14 Jan 2002 10:38:31 PST. <3C4325A7.D3EE2E73@iprg.nokia.com> Date: Tue, 15 Jan 2002 10:21:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Ah, but I think the issue is who the victims are. If *I* add > protection in my network, that does *not* guarantee I won't > be hit by reflection attacks from someone's network that only > has regular ingress filtering (without the stateful and AAA > patches). you mean stateful or AAA patches, right? => Jari meant stateful and network access control patches (the state is the knowledge of active bindings, network access control patches give this knowledge). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 02:46:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FAk12Q001426 for ; Tue, 15 Jan 2002 02:46:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FAk0EC001425 for ipng-dist; Tue, 15 Jan 2002 02:46:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FAjv2Q001418; Tue, 15 Jan 2002 02:45:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24680; Tue, 15 Jan 2002 02:46:04 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23405; Tue, 15 Jan 2002 03:46:03 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0FAk1513864; Tue, 15 Jan 2002 11:46:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA29207; Tue, 15 Jan 2002 11:46:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0FAk1Q50869; Tue, 15 Jan 2002 11:46:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151046.g0FAk1Q50869@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Mon, 14 Jan 2002 20:44:18 +0100. Date: Tue, 15 Jan 2002 11:46:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => first I have submitted the draft, second I tried to make clear that my proposal relies only on (any kind of) network access control (i.e. anything more that just plug and play). AAA is an implementation option which has extra benefits. > - As a general rule, I'd like the Internet to use end-to-end > mechanisms more than network assistance. This isn't just > an architectural principle, but it will also ensure that > we can deploy our things without waiting for providers to > catch up. I agree. But I would personally make a stronger statement since I'm concerned with the direction of piling more and more requirements and dependencies on AAA. Thus I think the AAA approach is the wrong one - if we collectively can make AAA/Diameter do the things needed to make Radius more usable => for my purpose Radius is enough (only a new attribute is needed for the home address, a new version of RFC 3162 ?) (reliabiliy, security, some extensibility) I think we've collectively have been successful. Keep piling more stuff on the AAA system and it might very well get too heavy to be able to fly... => I agree but AAA is the only way to provide (one day) remote network access control (*not* necessary but fine). Also, waiting for AAA solutions to be available (specified, implemeted, and deployed) before MIPv6 can be used seems to be counter to our desire to finish up MIPv6 soon. => I never proposed to wait for AAA solutions (as I ask only for network access control, not everywhere but enough to make HAO spoofing unattractive). While I have concerns with using the AAA per above I think the phased approach (where the AAA approach continues to be discussed and further understood) makes sense to me. => have you still concerns with using network access control in a BCP? Regards Francis.Dupont@enst-bretagne.fr PS (for the IPv6 WG list): my draft is about HAO vs ingress filtering, I assume there is a consensus about traditional ingress filtering, i.e. RFC 2827 is applicable to IPv6 (i.e. we don't need another document and we'll get tradition IPv6 ingress filtering (access lists and unicast RPF) support in the next router software version (I apologize if this is already available)). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 03:22:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FBMu2Q001556 for ; Tue, 15 Jan 2002 03:22:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FBMuN1001555 for ipng-dist; Tue, 15 Jan 2002 03:22:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FBMr2Q001548; Tue, 15 Jan 2002 03:22:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09083; Tue, 15 Jan 2002 03:22:58 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20177; Tue, 15 Jan 2002 04:22:57 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0FBMt520060; Tue, 15 Jan 2002 12:22:55 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA00193; Tue, 15 Jan 2002 12:22:55 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0FBMsQ51007; Tue, 15 Jan 2002 12:22:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151122.g0FBMsQ51007@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 10:59:09 +0200. Date: Tue, 15 Jan 2002 12:22:54 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: On Mon, 14 Jan 2002, Francis Dupont wrote: [snip] > 2. We will have a two-phased approach to the MIPv6 spec and > > => no, a two phase approach won't work because we'll stay at > the first phase. [snip] If we'd stay at the first phase, that'd probably mean that the stateful network access control mechanism wasn't attractive and wide-spread enough? -- Which is one of the points here. => no, you haven't understood. The problem is not technical, it is psychological: you can't have this kind of two phase approach for a security device, you won't be able to relax something, in fact it will be hard to get the first phase not be hardened. For instance RFC 2401 explains that in tunnel mode the outer source address should not be checked, most implementers do the check just because it seems a bit more secure... If one would want to differentiate between "network access controlled (no checks in end-nodes)" and "in god we trust, others must be checked", perhaps Home Address Option sub-options could be used? (or identically defined another HAO.) => I have no concern about "in god we trust"... This is already the case for ingress filtering and this is effective, i.e. random source address spoofing is no more heavily used in DDoS attacks. This follows the same mechanism than vaccination against an epidemic. > And you put the burden on the wrong people: > this is an ingress filtering problem, not a MIPv6 one, so > the solution should be in an ingress filtering improvement, > not in a new restriction for MIPv6. (a bit tongue-in-cheek) If QWERTY working group would define a new mechanism for storing effective source address in a varying location of IP header chain, under some destination option's freshly defined fourth option's third sub-option (padded to 2n+x), would digging that out and just coping with it be "ingress filtering problem" too? => I think so (this is why I prefer the firewall based part of ingress filtering because firewalls have to be prepared to dig into packets anyway). If AZERTY working group would make new requirements (caused by said working group's new proposal) for ingress filtering, so that it could not be done in practice, would finding new ways to do ingress filtering befall ingress filtering people too? => this depends on who gets the benefits: if there are mainly global benefits (as for home address declarations in order to limit HAOs), I believe this is a topic for ingress filtering people, if there are mainly benefits for a particular population (as for HAO filtering using remote network access control, i.e. certified/verified home addresses), I believe this is not a topic for ingress filtering people (in my example this is a topic for AAA people). We can consider where are the difficulties too but in a well engineered system both should be equivalent (this is a practical problem too, if you get the difficulties and not the benefits nothing will happen, this is my concern about correspondent node based features). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 04:49:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FCnW2Q001751 for ; Tue, 15 Jan 2002 04:49:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FCnWKQ001749 for ipng-dist; Tue, 15 Jan 2002 04:49:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FCnQ2Q001737 for ; Tue, 15 Jan 2002 04:49:26 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13067 for ; Tue, 15 Jan 2002 04:49:33 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13443 for ; Tue, 15 Jan 2002 04:49:32 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FCnVJ18285 for ; Tue, 15 Jan 2002 13:49:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jan 15 13:49:10 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 13:40:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1FD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Jari Arkko Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: RE: How to move forward in the HAO & ingress filter discussion Date: Tue, 15 Jan 2002 13:49:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis > I have a proposal. But first, let me make some observations: > > - Most people do seem to agree that HAO reflection is an > issue that needs to be dealt with somehow. > > => we have to deal with it but we don't need a stronger solution > than today ingress filtering which is a BCP, i.e. something like > a SHOULD. => But how can that be true ?? Today's ingress filtering is clearly insufficient for HAO issues. Or perhaps you mean we need a solution that doesn't have to be mandated (SHOULD instead of MUST) ? If so, this is too early to discuss, we don't have an agreement on a solution yet. I haven't heard anyone answering my question as to why reverse tunnelling by the MN thru the HA is so much worse than triangular routing, that we need to develop something new to fix the HAO problem 'only sometimes'. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 05:25:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FDPY2Q001926 for ; Tue, 15 Jan 2002 05:25:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FDPYC9001925 for ipng-dist; Tue, 15 Jan 2002 05:25:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FDPR2Q001910; Tue, 15 Jan 2002 05:25:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10190; Tue, 15 Jan 2002 05:25:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03412; Tue, 15 Jan 2002 06:25:33 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0FDPR509919; Tue, 15 Jan 2002 14:25:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA03020; Tue, 15 Jan 2002 14:25:28 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0FDPRQ51519; Tue, 15 Jan 2002 14:25:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151325.g0FDPRQ51519@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 13:49:00 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C1FD@Esealnt861.al.sw.ericsson.se> Date: Tue, 15 Jan 2002 14:25:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I have a proposal. But first, let me make some observations: > > - Most people do seem to agree that HAO reflection is an > issue that needs to be dealt with somehow. > > => we have to deal with it but we don't need a stronger solution > than today ingress filtering which is a BCP, i.e. something like > a SHOULD. => But how can that be true ?? => the answer is both bad and good news: ingress filtering is effective against random source address snooping, but not against DDoS itself or source address snooping using a small variation on the last bits (i.e. staying in the same prefix). Of course the last point is very worrying for IPv6 (maximal prefix length is 64 bits, i.e. 64 bits at least are free for this kind of attacks). But this is more a threat against RFC 3041 than HAO... Today's ingress filtering is clearly insufficient for HAO issues. => do you mean we have to do more about HAO than about standard source address snooping? Or perhaps you mean we need a solution that doesn't have to be mandated (SHOULD instead of MUST) ? => exactly, we don't need something stronger than a BCP (a loose SHOULD). If so, this is too early to discuss, we don't have an agreement on a solution yet. => my concern is we have no agreement on the problem too. (I don't put a smile because this is no more funny) I haven't heard anyone answering my question as to why reverse tunnelling by the MN thru the HA is so much worse than triangular routing, => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) d(optimization) = 2 * d(MN,CN) and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) so d(optimization) <= d(triangular) <= d(bidir tunnel) and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) i.e. in my poor English the cost/performance of triangular routing is at the middle of bidirectional tunneling and routing optimization. that we need to develop something new to fix the HAO problem 'only sometimes'. => my argument is that ingress filtering is an 'only sometimes' reply to the (random) source address spoofing problem. If your question is "why not drop the draft 15 and restart from the beginning with a bidirectional tunneling (only in the first phase) solution", this is another (interesting) question (I suggest to restrict it to the mobile IP WG list). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 06:01:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FE1j2Q002106 for ; Tue, 15 Jan 2002 06:01:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FE1j97002105 for ipng-dist; Tue, 15 Jan 2002 06:01:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FE1g2Q002098 for ; Tue, 15 Jan 2002 06:01:42 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00707 for ; Tue, 15 Jan 2002 06:01:49 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09869 for ; Tue, 15 Jan 2002 06:01:48 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0FE1g517133; Tue, 15 Jan 2002 15:01:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA03811; Tue, 15 Jan 2002 15:01:42 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0FE1fQ51732; Tue, 15 Jan 2002 15:01:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151401.g0FE1fQ51732@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" In-reply-to: Your message of Mon, 14 Jan 2002 11:23:04 PST. <4.3.2.7.2.20020114112109.0249e730@mailhost.iprg.nokia.com> Date: Tue, 15 Jan 2002 15:01:41 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There was a long and not very clear discussion about the level of requirement for this proposal... The current spec (RFC 2461 6.3.6 end of 1)) says: An implementation may choose to always return the same router or cycle through the router list in a round-robin fashion as long as it always returns a reachable or a probably reachable router when one is available. i.e. there are two proposed solutions with a small may (I interpret this as an implementation hint). The new proposal is: An implementation SHOULD pick routers from the default router list in random order while making sure it always returns a reachable or a probably reachable router when one is available. I have two concerns about this: - the random order is not defined (this is a formal concern because the intention is clear) - we moved from an implementation hint to a SHOULD, this will make old implementations not conformant and in some situations there can be far better solutions. So I prefer to get a MAY (enough to get this proposal implemented in the future by everybody without harm) and an explicit reference to the default router preference draft (first because I am in favor of this from the beginning, i.e. since many years, second because this is the best reply to the "special case" argument (not so special case because 100% of the IPv6 networks I used have several routers with a better one)). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 06:24:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FEO32Q002224 for ; Tue, 15 Jan 2002 06:24:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FEO3dl002223 for ipng-dist; Tue, 15 Jan 2002 06:24:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FEO02Q002216; Tue, 15 Jan 2002 06:24:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09652; Tue, 15 Jan 2002 06:24:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26861; Tue, 15 Jan 2002 07:24:05 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0FEO4V04643; Tue, 15 Jan 2002 16:24:04 +0200 Date: Tue, 15 Jan 2002 16:24:03 +0200 (EET) From: Pekka Savola To: cc: "Hesham Soliman (ERA)" , Jari Arkko , Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201151325.g0FDPRQ51519@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Jan 2002, Francis Dupont wrote: > I haven't heard anyone answering my question as to why > reverse tunnelling by the MN thru the HA is so much > worse than triangular routing, > > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. In theory, yes. But the question is, does it really make that much of a difference as long as at least one way is "unoptimized"? Practise? I don't think there's much difference in bidir tunnel/triangular routing; I doubt e.g. TCP would be able to get much better performance from triangular than from bi-dir (and there are goals like hiding your origins that triangular cannot solve). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 07:04:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FF4O2Q002416 for ; Tue, 15 Jan 2002 07:04:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FF4OZQ002415 for ipng-dist; Tue, 15 Jan 2002 07:04:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FF4K2Q002408; Tue, 15 Jan 2002 07:04:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22449; Tue, 15 Jan 2002 07:04:26 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03073; Tue, 15 Jan 2002 08:04:25 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0FF4N500504; Tue, 15 Jan 2002 16:04:23 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA05230; Tue, 15 Jan 2002 16:04:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0FF4MQ52034; Tue, 15 Jan 2002 16:04:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151504.g0FF4MQ52034@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 16:24:03 +0200. Date: Tue, 15 Jan 2002 16:04:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. In theory, yes. But the question is, does it really make that much of a difference as long as at least one way is "unoptimized"? => the same difference than when both ways are unoptimized or optimized. Difference in distance is the same, difference in byte overhead too. This is true for all points with one exception: protocol complexity because triangular routing has roughly the same complexity than bidirectional tunneling. Practice? I don't think there's much difference in bidir tunnel/triangular routing; I doubt e.g. TCP would be able to get much better performance from triangular than from bi-dir (and there are goals like hiding your origins that triangular cannot solve). => I can't see how TCP is involved. I believe your argument is different: if the traffic is very asymmetrical (more on one way than on the other), you prefer to have it on the optimized way... I am afraid the real argument against the triangular routing is this discussion itself because the main triangular routing advantage comes from the (future) fact that HAO is supported by every IPv6 nodes. With enough FUD this shall never become true and the advantage shall vanish... I'd like to get the opinion of IPv6 implementors (if they don't filter out this boring discussion) about HAO (for it, against it, will/won't implement it, will/won't enable it by default, etc). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 07:22:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FFMv2Q002576 for ; Tue, 15 Jan 2002 07:22:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FFMvsn002575 for ipng-dist; Tue, 15 Jan 2002 07:22:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FFMs2Q002568; Tue, 15 Jan 2002 07:22:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23836; Tue, 15 Jan 2002 07:23:00 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26813; Tue, 15 Jan 2002 08:22:50 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0FFMkm05102; Tue, 15 Jan 2002 17:22:46 +0200 Date: Tue, 15 Jan 2002 17:22:46 +0200 (EET) From: Pekka Savola To: cc: "Hesham Soliman (ERA)" , Jari Arkko , Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201151504.g0FF4MQ52034@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Jan 2002, Francis Dupont wrote: > In theory, yes. But the question is, does it really make that much of a > difference as long as at least one way is "unoptimized"? > > => the same difference than when both ways are unoptimized or optimized. > Difference in distance is the same, difference in byte overhead too. > This is true for all points with one exception: protocol complexity > because triangular routing has roughly the same complexity than > bidirectional tunneling. What about latency (e.g. interactive session) detected by the user? (might be the worst of the two) Reliability is one argument too. > Practice? I don't think there's much difference in bidir > tunnel/triangular routing; I doubt e.g. TCP would be able to get much > better performance from triangular than from bi-dir (and there are goals > like hiding your origins that triangular cannot solve). > > => I can't see how TCP is involved. I believe your argument is different: > if the traffic is very asymmetrical (more on one way than on the other), > you prefer to have it on the optimized way... I think I'd prefer to have it either _completely optimized_ or _completely unoptimized_, not optimized to one direction and unoptimized to the other. > I am afraid the real argument against the triangular routing is this > discussion itself because the main triangular routing advantage comes > from the (future) fact that HAO is supported by every IPv6 nodes. > With enough FUD this shall never become true and the advantage shall vanish... Yes. But in all reality, a user who requires mobility (e.g. moving fast) would be a fool to rely that all CN's would implement this (or else the connection breaks) during the next 3 years or so.. Triangular routing relies on the existance of this feature everywhere. Bidirectional tunneling always works, and in practise *may* (I don't know) be roughly equal in user-detected latency, TCP thoughput, etc. Does it not seem Bidir is far superior to triangular routing? (As a matter of fact, bidir does not really even require MIPv6 -- I don't think there's any feature missing in current specifications that would be required :-). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 11:03:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FJ3g2Q003225 for ; Tue, 15 Jan 2002 11:03:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FJ3g2Z003224 for ipng-dist; Tue, 15 Jan 2002 11:03:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FJ3c2Q003217 for ; Tue, 15 Jan 2002 11:03:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02047 for ; Tue, 15 Jan 2002 11:03:45 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27084 for ; Tue, 15 Jan 2002 11:03:44 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA67800 for ; Tue, 15 Jan 2002 12:59:32 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0FJ3gR233950 for ; Tue, 15 Jan 2002 14:03:42 -0500 From: "Kristine Adamson" Importance: Normal Sensitivity: Subject: IPv6 MIB questions To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 15 Jan 2002 14:03:40 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 01/15/2002 02:03:42 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE1D1DFF78A9F8f9e8a93df938690918c0ABBE1D1DFF78A9F" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE1D1DFF78A9F8f9e8a93df938690918c0ABBE1D1DFF78A9F Content-type: text/plain; charset=US-ASCII We are looking into implementing the draft IPv6 MIBs in the near future and had questions about the new drafts: - I noticed that there is no current Compliance statement (ipv6Compliance??) in draft-ietf-ipngwg-rfc2011-update-00.txt. Will this be updated soon? - In the new RFC2013, there is a udpListenerTable and a udpConnectionTable. In our implementation, a UDP Listener can transition from the unconnected to the connected state, but not back again. The Listener can also change which Remote IP address/port it is connected to. When a Listener is in the connected state, would it be represented in both tables? Or should a Listener only ever be represented in one of these tables? Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com --0__=0ABBE1D1DFF78A9F8f9e8a93df938690918c0ABBE1D1DFF78A9F Content-type: text/html; charset=US-ASCII Content-Disposition: inline

We are looking into implementing the draft IPv6 MIBs in the near future and had questions about the new drafts:

    - I noticed that there is no current Compliance statement (ipv6Compliance??) in draft-ietf-ipngwg-rfc2011-update-00.txt. Will this be updated soon?

    - In the new RFC2013, there is a udpListenerTable and a udpConnectionTable. In our implementation, a UDP Listener can transition from the unconnected to the connected state, but not back again. The Listener can also change which Remote IP address/port it is connected to. When a Listener is in the connected state, would it be represented in both tables? Or should a Listener only ever be represented in one of these tables?

    Thanks!

    Kristine Adamson
    IBM Communications Server for MVS: TCP/IP Development
    Internet e-mail:adamson@us.ibm.com
--0__=0ABBE1D1DFF78A9F8f9e8a93df938690918c0ABBE1D1DFF78A9F-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 15 11:10:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FJA92Q003255 for ; Tue, 15 Jan 2002 11:10:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FJA9EX003254 for ipng-dist; Tue, 15 Jan 2002 11:10:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FJA72Q003247 for ; Tue, 15 Jan 2002 11:10:07 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0FJ9IAd013814 for ; Tue, 15 Jan 2002 11:09:18 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0FJ9I8H013813 for ipng@sunroof.eng.sun.com; Tue, 15 Jan 2002 11:09:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkTKE027074; Sun, 13 Jan 2002 09:46:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04849; Sun, 13 Jan 2002 09:46:36 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02313; Sun, 13 Jan 2002 10:46:35 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 659876A907; Sun, 13 Jan 2002 19:46:22 +0200 (EET) Message-ID: <3C41A751.7010003@piuha.net> Date: Sun, 13 Jan 2002 17:27:13 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: Pekka Nikander , ipng@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201070922.g079MAQ13141@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => not exactly, the key term is "rely on". > > I don't think it matters whether the acronym for this > infrastructure was PKI, DNS, or AAA? > > => I agree but it is not forbidden to get advantages of it, only to rely > on it. As we don't rely on ingress filtering for defense against DDoS, > I can't see a problem to propose to use AAA in order to improve ingress > filtering. Yes, it's no problem to improve something. However, improving ingress filting with AAA is not the *whole* picture of what we are doing. You have to remember that by introducing HAO our first step is punching a mile wide hole to the ingress filtering system. And, in fact, you are not improving things by having a smart treatment of the HAO -- you're basically keeping the status quo that we already have with v4. So, in some areas that have both ingress filtering and aaa, you may keep the current status, if the aaa fix to ingress filtering is deployed fast enough. However, on other areas you are nuking an existing security measure some people are using. In this sense you are relying on AAA all over the place, just to keep things as they were before. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 16 04:01:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0GC1k2Q004308 for ; Wed, 16 Jan 2002 04:01:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0GC1kx8004307 for ipng-dist; Wed, 16 Jan 2002 04:01:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0GC1g2Q004300 for ; Wed, 16 Jan 2002 04:01:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29097 for ; Wed, 16 Jan 2002 04:01:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09862 for ; Wed, 16 Jan 2002 05:01:47 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04499; Wed, 16 Jan 2002 07:01:44 -0500 (EST) Message-Id: <200201161201.HAA04499@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-04.txt Date: Wed, 16 Jan 2002 07:01:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-04.txt Pages : 79 Date : 15-Jan-02 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2292bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020115095215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020115095215.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 16 11:03:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0GJ392Q004537 for ; Wed, 16 Jan 2002 11:03:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0GJ39rZ004536 for ipng-dist; Wed, 16 Jan 2002 11:03:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0GJ362Q004529 for ; Wed, 16 Jan 2002 11:03:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03269 for ; Wed, 16 Jan 2002 11:03:11 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11431 for ; Wed, 16 Jan 2002 12:03:10 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA16793; Wed, 16 Jan 2002 11:03:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0GJ32906352; Wed, 16 Jan 2002 11:03:02 -0800 X-mProtect: Wed, 16 Jan 2002 11:03:02 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdY7a2mk; Wed, 16 Jan 2002 11:03:01 PST Message-Id: <4.3.2.7.2.20020116104249.024676b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 11:02:56 -0800 To: Francis Dupont From: Bob Hinden Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200201151401.g0FE1fQ51732@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, >I have two concerns about this: > - the random order is not defined (this is a formal concern because > the intention is clear) I think most people will understand the intent of "random order". Does anyone else think more definition is needed? If so, I could add some text. > - we moved from an implementation hint to a SHOULD, this will make > old implementations not conformant and in some situations there > can be far better solutions. So I prefer to get a MAY (enough to > get this proposal implemented in the future by everybody without > harm) and an explicit reference to the default router preference > draft (first because I am in favor of this from the beginning, > i.e. since many years, second because this is the best reply to > the "special case" argument (not so special case because 100% of > the IPv6 networks I used have several routers with a better one)). I disagree. The intent of the document is to change the behavior from a hint to a common behavior. Hence the SHOULD. Note that the current "hint" for round robin is less than perfect. I think the current implementations are covered by the SHOULD. If it was a MUST there might be a problem with current behavior. In Salt Lake City where the issue of combining this with the default router preferences was discussed, the consensus was to keep this separate. The plan was to also add this behavior to the default router preferences draft for the case where there are multiple routers at the same preference. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 16 14:40:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0GMeb2Q004695 for ; Wed, 16 Jan 2002 14:40:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0GMebML004694 for ipng-dist; Wed, 16 Jan 2002 14:40:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0GMeY2Q004687 for ; Wed, 16 Jan 2002 14:40:34 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00634 for ; Wed, 16 Jan 2002 14:40:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08985 for ; Wed, 16 Jan 2002 14:40:41 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04523; Wed, 16 Jan 2002 14:40:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0GMeet06410; Wed, 16 Jan 2002 14:40:40 -0800 X-mProtect: Wed, 16 Jan 2002 14:40:40 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTMgiJ2; Wed, 16 Jan 2002 14:40:37 PST Message-Id: <4.3.2.7.2.20020116143407.02468fa0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 14:40:11 -0800 To: Erik.Nordmark@eng.sun.com, narten@us.ibm.com From: Bob Hinden Subject: Request to Advance "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Draft Standard: Title: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s): A. Conta, S. Deering Filename: draft-ietf-ipngwg-icmp-v3-02.txt Pages: 23 Date: 29-Nov-01 This document will replace RFC2463 that is currently a Draft Standard. Appendix A in the draft summarizes the changes from RFC2463. A working group last call for this document was completed on December 26, 2001. Bob Hinden / Steve Deering IPv6 Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 16 18:31:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H2VX2Q004901 for ; Wed, 16 Jan 2002 18:31:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0H2VX3D004900 for ipng-dist; Wed, 16 Jan 2002 18:31:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H2VU2Q004893 for ; Wed, 16 Jan 2002 18:31:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28387 for ; Wed, 16 Jan 2002 18:31:38 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09708 for ; Wed, 16 Jan 2002 19:31:37 -0700 (MST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-438.cisco.com [10.82.241.182]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA20449; Wed, 16 Jan 2002 21:31:34 -0500 (EST) Message-Id: <4.3.2.7.2.20020116142534.0366bcf0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 21:32:02 -0500 To: Bernie.Volz@am1.ericsson.se From: Ralph Droms Subject: Summary of issues from DHCPv6 spec last call Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bernie - I've been in allday meetings Mon and Tue, and more meetings for a good part of today. I put together the following message to send to the dhcwg and ipng mailing lists, summarizing the comments during the last call. There is one more batch of comments from Vijay Bhaskar A K that I need to address. Would you please review this message and confirm that I've captured all of the threads from the last call? Thanks... I will be travelling Thu and Fri, but will be checking e-mail intermittently... - Ralph The following issues were raised during the last call for the DHCPv6 spec ; I will kick off separate discussion threads for each open issue later today: Open issues ----------- * Does DHCPv6 need a "default routes" option? * Does DHCPv6 need a "static routes" option? * Does DHCPv6 need an FQDN option (basically identical to proposed DHCPv4 FQDN option)? * Should the DHCPv6 option codes start at 256 to avoid overlap with DHCPv4 option codes; overlap of option codes would be an issue for the DHCID RR. * What error codes may a server send in response to an Information-Request message? * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. * Is a client required to implement the Reconfigure message - supporting Reconfigure will require that the client maintain state. Changes to be made in -23 ------------------------- * Editorial changes: - Change "Inform message" to "Information-request message" and "INFORM" to "INFORMATION-REQUEST" throughout the document - Fix redundancy between sections 18.2.5 and 18.2.8 - Change "Rebind" to "Inform" in the last paragraph of section 18.1.5 (cut-and-paste error) - Fix page 10 (which is blank in -22 draft) - In third paragraph of section 14, change "Requested Temporary Addresses Option 22.5" to "Requested Temporary Addresses Option (see section 22.5)" - Change last sentence of section 22.5 to: "A client MUST only include this option when it wants to have additional temporary address allocated; a client SHOULD NOT send this option if 'num-requested' is 0". * Remove references to "IAs" in section 19.2 * Fix chart in Appendix B to allow DSTM option in same messages as IA option -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 16 18:44:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H2i22Q004926 for ; Wed, 16 Jan 2002 18:44:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0H2i20t004925 for ipng-dist; Wed, 16 Jan 2002 18:44:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H2hx2Q004918 for ; Wed, 16 Jan 2002 18:43:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00750 for ; Wed, 16 Jan 2002 18:44:07 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02148 for ; Wed, 16 Jan 2002 18:44:06 -0800 (PST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-438.cisco.com [10.82.241.182]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA21096 for ; Wed, 16 Jan 2002 21:44:05 -0500 (EST) Message-Id: <4.3.2.7.2.20020116214207.00b4f980@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 21:43:13 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Summary of issues from DHCPv6 spec last call In-Reply-To: <4.3.2.7.2.20020116142534.0366bcf0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please ignore my previous message to this list - I'll post a complete summary of the discussion of the DHCPv6 draft tomorrow. - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 16 23:44:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H7iL2Q005165 for ; Wed, 16 Jan 2002 23:44:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0H7iK7O005164 for ipng-dist; Wed, 16 Jan 2002 23:44:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H7iH2Q005157 for ; Wed, 16 Jan 2002 23:44:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07487 for ; Wed, 16 Jan 2002 23:44:22 -0800 (PST) Received: from i2soft_web ([211.240.20.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA25935 for ; Thu, 17 Jan 2002 00:44:19 -0700 (MST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Thu, 17 Jan 2002 16:46:23 +0900 Message-ID: <014801c19f2a$b7abb190$38a5fe81@dicao> From: "Yong-Seung Bae" To: "IPng Members" Subject: Layer violation Date: Thu, 17 Jan 2002 16:43:55 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0145_01C19F76.27192080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0145_01C19F76.27192080 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIG1lbWJlcnMNCkkgaGF2ZSBiZWVuIHF1ZXN0aW9uIGFib3V0IGxheWVyIHZpb2xhdGlvbi4u Lg0KDQpXaGF0IGlzIGxheWVyIHZpb2xhdGlvbnM/DQpXaGF0IGtpbmQgb2YgbGF5ZXIgdmlvbGF0 aW9ucyB0aGF0IGlzIGludGVuZGVkIHRvIHN0b3Aocm91dGVyIG9yIGhvc3QpPw0KV2hhdCB0aGUg cHVycG9zZSBvZiB0aG9zZSBsYXllciB2aW9sYXRpb25zIGlzPw0KDQpUaGFua3MNCkplcmVtaWFo DQo= ------=_NextPart_000_0145_01C19F76.27192080 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTIuMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxG T05UIHNpemU9Mj5IaSwgbWVtYmVyczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkg aGF2ZSBiZWVuIHF1ZXN0aW9uIGFib3V0IGxheWVyIHZpb2xhdGlvbi4uLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PldoYXQgaXMgbGF5ZXIgdmlvbGF0aW9ucz88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5XaGF0IGtpbmQgb2YgbGF5ZXIgdmlvbGF0aW9ucyB0aGF0IGlzIGludGVuZGVkIHRvIHN0b3Ao cm91dGVyIA0Kb3IgaG9zdCk/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V2hhdCB0 aGUgcHVycG9zZSBvZiB0aG9zZSBsYXllciB2aW9sYXRpb25zIGlzPzwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRo YW5rczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkplcmVtaWFoPC9GT05UPjwvRElW PjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0145_01C19F76.27192080-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 01:54:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H9sb2Q005286 for ; Thu, 17 Jan 2002 01:54:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0H9sbGK005285 for ipng-dist; Thu, 17 Jan 2002 01:54:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0H9sY2Q005278 for ; Thu, 17 Jan 2002 01:54:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19603 for ; Thu, 17 Jan 2002 01:54:39 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17891 for ; Thu, 17 Jan 2002 02:54:38 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0H9sY517873; Thu, 17 Jan 2002 10:54:34 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA17643; Thu, 17 Jan 2002 10:54:34 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0H9sXQ59680; Thu, 17 Jan 2002 10:54:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201170954.g0H9sXQ59680@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" In-reply-to: Your message of Wed, 16 Jan 2002 11:02:56 PST. <4.3.2.7.2.20020116104249.024676b0@mailhost.iprg.nokia.com> Date: Thu, 17 Jan 2002 10:54:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >I have two concerns about this: > - the random order is not defined (this is a formal concern because > the intention is clear) I think most people will understand the intent of "random order". => as I've written this is a *formal* concern... (formal = on the form) > - we moved from an implementation hint to a SHOULD, this will make > old implementations not conformant and in some situations there > can be far better solutions. So I prefer to get a MAY (enough to > get this proposal implemented in the future by everybody without > harm) and an explicit reference to the default router preference > draft (first because I am in favor of this from the beginning, > i.e. since many years, second because this is the best reply to > the "special case" argument (not so special case because 100% of > the IPv6 networks I used have several routers with a better one)). I disagree. The intent of the document is to change the behavior from a hint to a common behavior. Hence the SHOULD. => if this is the intent the document is underspecified (i.e. it have to remember when the default router selection is done (this is at the beginning of 6.3.6)). There is too a real issue about the required minimal default router list length (two issues in fact: do we allow small implementations to use a short list (possibly shorter than the real number of default routers)? What is the reply to the bad guy who tries to give us 2^64 default routers?) Note there is something about this in 5.3 GC and Timeouts and 6.3.4 Processing rcvd RAs. Note that the current "hint" for round robin is less than perfect. => I agree but my concern is more about the requirement level. I think the current implementations are covered by the SHOULD. => they are not compliant with the SHOULD, not a real problem for round robin (as it can be looked at a bad random order) but implementations which keep the same router have a very different behavior (than the recommended one). If it was a MUST there might be a problem with current behavior. => I agree but a SHOULD in a draft standard (i.e. the intent) is really quite strong. In Salt Lake City where the issue of combining this with the default router preferences was discussed, the consensus was to keep this separate. => my concern is there are a lot of situations where some potential default routers are better than others. Without the default router preferences the only way to control the default router choice is to use zero router lifetimes. This is far too drastic and can't express any kind of nuance... So I'd really like to get preferences before or at the same time than random selection. The plan was to also add this behavior to the default router preferences draft for the case where there are multiple routers at the same preference. => we agree but there is clearly a problem in priorities. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 02:35:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAZc2Q005389 for ; Thu, 17 Jan 2002 02:35:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HAZcXD005388 for ipng-dist; Thu, 17 Jan 2002 02:35:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAZX2Q005381; Thu, 17 Jan 2002 02:35:33 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0HAZXx15355; Thu, 17 Jan 2002 11:35:33 +0100 (MET) Date: Thu, 17 Jan 2002 11:32:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201151046.g0FAk1Q50869@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also, waiting for AAA solutions to be available (specified, implemeted, > and deployed) before MIPv6 can be used seems to be counter to our desire > to finish up MIPv6 soon. > > => I never proposed to wait for AAA solutions (as I ask only for network > access control, not everywhere but enough to make HAO spoofing unattractive). Are you proposing to wait until network access control is available? (specified, implemented, and deployed) If not, what do you propose to do in the interim until network access control for HAO is available? Seems like this requires a two-phase approach: phase 1 before it is available and phase 2 when/if it become available. What am I missing? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 02:44:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAi22Q005479 for ; Thu, 17 Jan 2002 02:44:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HAi2Tf005478 for ipng-dist; Thu, 17 Jan 2002 02:44:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAhq2Q005463; Thu, 17 Jan 2002 02:43:53 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0HAhtx16041; Thu, 17 Jan 2002 11:43:55 +0100 (MET) Date: Thu, 17 Jan 2002 11:40:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion To: Francis.Dupont@enst-bretagne.fr Cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201151325.g0FDPRQ51519@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hesham wrote: > I haven't heard anyone answering my question as to why > reverse tunnelling by the MN thru the HA is so much > worse than triangular routing, > > Francis wrote in response: > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. Yes, but does that make any significant difference for real traffic and applications given than the traffic from CN to MN goes through the HA in the triangular case? For instance assume that the CN and MN are next to each other (delay 1 ms) and the HA is 100 ms away from them (one way delay). If you route optimize TCP will see a RTT of 2 ms. If you do triangular the rtt will be 201 ms. If you do bidirectional tunneling the rtt will be 400 ms. You can look at these numbers differently depending what you want to prove. "400/201 = 2" would make your argument. But my argument is that "201/2 = 100". Thus if you care about rtt when the CN/MN are close compared to the MN/HA delay you should route optimize. The only case I can think of where tringular makes a significant performance difference is for unidirectional and latency sensitive traffic from MN to CN. I have yet to see an application which such concerns - if latency is an issue it is because you'd like the higher level entities (transport protocols or humans e.g. on a voice/video conversation) to observe short roundtrip latency. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 02:49:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAn32Q005546 for ; Thu, 17 Jan 2002 02:49:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HAn3wt005545 for ipng-dist; Thu, 17 Jan 2002 02:49:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAmx2Q005532 for ; Thu, 17 Jan 2002 02:48:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27942 for ; Thu, 17 Jan 2002 02:49:05 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18276 for ; Thu, 17 Jan 2002 03:49:05 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HAn4J13393 for ; Thu, 17 Jan 2002 11:49:04 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 11:48:47 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 11:49:02 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C214@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , Francis.Dupont@enst-bretagne.fr Cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: How to move forward in the HAO & ingress filt er discussion Date: Thu, 17 Jan 2002 11:48:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Hesham wrote: > > I haven't heard anyone answering my question as to why > > reverse tunnelling by the MN thru the HA is so much > > worse than triangular routing, > > > > Francis wrote in response: > > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > > d(optimization) = 2 * d(MN,CN) > > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > > so d(optimization) <= d(triangular) <= d(bidir tunnel) > > and even stronger 2 * d(triangular) = d(optimization) + > d(bidir tunnel) > > i.e. in my poor English the cost/performance of triangular routing > > is at the middle of bidirectional tunneling and routing > optimization. > > Yes, but does that make any significant difference for real > traffic and > applications given than the traffic from CN to MN goes > through the HA > in the triangular case? > > For instance assume that the CN and MN are next to each > other (delay 1 ms) > and the HA is 100 ms away from them (one way delay). > If you route optimize TCP will see a RTT of 2 ms. > If you do triangular the rtt will be 201 ms. > If you do bidirectional tunneling the rtt will be 400 ms. > You can look at these numbers differently depending what you want to > prove. "400/201 = 2" would make your argument. > But my argument is that "201/2 = 100". > Thus if you care about rtt when the CN/MN are close > compared to the MN/HA > delay you should route optimize. => Exactly. So I don't see the improvement with triangular routing over bidirectional tunnelling... for real time or TCP connections. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 03:59:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HBx92Q005789 for ; Thu, 17 Jan 2002 03:59:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HBx9mC005788 for ipng-dist; Thu, 17 Jan 2002 03:59:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HBx52Q005781 for ; Thu, 17 Jan 2002 03:59:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06550 for ; Thu, 17 Jan 2002 03:58:41 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22504 for ; Thu, 17 Jan 2002 03:58:39 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA11494; Thu, 17 Jan 2002 12:58:31 +0100 Received: from lig32-225-246-178.us.lig-dial.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39276 from ; Thu, 17 Jan 2002 12:57:59 +0100 Message-Id: <3C46B954.4B0A1500@hursley.ibm.com> Date: Thu, 17 Jan 2002 12:45:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Robert Elz Cc: "Steven M. Bellovin" , Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <20020111150246.D34077B4B@berkshire.research.att.com> <5847.1011016992@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In any case, the behaviour when you see an "unknown" flow label should be the same as when you see a zero label - apply default treatment, whatever that happens to be locally. No need to either drop the packet or rewrite the label; at that point it's just a noise field. Brian Robert Elz wrote: > > Date: Fri, 11 Jan 2002 10:02:46 -0500 > From: "Steven M. Bellovin" > Message-ID: <20020111150246.D34077B4B@berkshire.research.att.com> > > | But dropping the packet means that flow > | labels can only be used for flows that stay within a particular flow > | label domain, > > No, you have accepted one of Margaret's arguments, taken that to its > logical conclusion, and reached absurdity, so obviously, something has > to be wrong. > > But it isn't the immutability that's wrong, it is the assumption that > different QoS mechanisms can redefine the flow label field in different > incompatible ways. > > That simply cannot be allowed to happen, or any kind of usable QoS is > even less likely to ever get deployed than the small chance there seems > to be at the minute. > > There has to be (absolutely) one fixed consistent definition for the > field, that all QoS mechanisms (now or in the future) can live with. > If anyone needs some extra data that doesn't fit, they simply have to > put that data elsewhere. If after doing that the flow label is useless > to them, then they just don't use it. > > Exactly what the one fixed definition should be, I'll leave it to others > to sort out, but there has to be exactly one - your analysis of what > happens if things are allowed to become inconsistent shows that. > > Allowing routers to change the flow label to make it "legal" doesn't > help - apart from simply making it say "unclassified" (which they could > do just as easily by putting a magic value defined by them in the DCSP) > from where would they get the information to install any other value. > > But if you can assume they can invent it from somewhere, then you need > to work out how to handle the case where my packets flow through 3 > independent ISPs, A B and C. I deal directly with A, so I can easily > provide a flow label that suits A's requirements. If B doesn't like that, > and changed it to something that fits B's requirements, what on earth > happens when the packet reaches C? At that point, C has no idea what > the flow label might mean - it could be something I put there, or it could > be something local of B's. > > That's simply impossible to support. C has to know what the value > represents (whether that then results in any special handling or not is > up to whatever agreements exist among the various parties, and what they > say - but regardless of that, if there's no way for C to interpret the > request, then agreements would be useless). > > kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 05:25:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HDPl2Q005860 for ; Thu, 17 Jan 2002 05:25:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HDPkH9005859 for ipng-dist; Thu, 17 Jan 2002 05:25:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HDPg2Q005852 for ; Thu, 17 Jan 2002 05:25:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22244 for ; Thu, 17 Jan 2002 05:25:49 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18006 for ; Thu, 17 Jan 2002 05:25:48 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:192e:6744:afea:97da]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g0HDPk319560 for ; Thu, 17 Jan 2002 22:25:46 +0900 (JST) Date: Thu, 17 Jan 2002 22:25:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" In-Reply-To: <200201170954.g0H9sXQ59680@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200201170954.g0H9sXQ59680@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 52 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 17 Jan 2002 10:54:33 +0100, >>>>> Francis Dupont said: > Note that the current "hint" for round robin is less than perfect. > => I agree but my concern is more about the requirement level. > I think the current implementations are covered by the SHOULD. > => they are not compliant with the SHOULD, not a real problem for round > robin (as it can be looked at a bad random order) but implementations > which keep the same router have a very different behavior (than the > recommended one). I agre with Francis. And, actually, our implementation (i.e. all *BSD variants) basically keeps the same router (of the same priority), so it will be non-compliant with the SHOULD. I believe our implementation is not the only example of this "non-compliant" behavior. If the SHOULD is really the consensus, I'll change the implementation so that it will be compliant again. However, I'm still not fully convinced that the change is worth making (perhaps many) existing applications non-compliant. As Francis pointed out, there are many cases of "several default routers with a better one." In this case, picking up random routers (without the knowledge of router preference) will just be meangless, because we'll eventually converge on the better router with redirect messages. > If it was a MUST there might be a problem with current behavior. > => I agree but a SHOULD in a draft standard (i.e. the intent) is > really quite strong. I agree, too. So, I'm okay with a MAY, instead of the SHOULD. I'll probably okay with a SHOULD if the proposal is combined with the router preference proposal, because the preferenece proposal is also a new stuff. > In Salt Lake City where the issue of combining this with the default router > preferences was discussed, the consensus was to keep this separate. Yes, but I disagree with the SHOULD as well as separating those two. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 05:35:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HDZp2Q005888 for ; Thu, 17 Jan 2002 05:35:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HDZpTv005887 for ipng-dist; Thu, 17 Jan 2002 05:35:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HDZm2Q005880; Thu, 17 Jan 2002 05:35:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09235; Thu, 17 Jan 2002 05:35:55 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20837; Thu, 17 Jan 2002 06:35:53 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0HDZn521257; Thu, 17 Jan 2002 14:35:49 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA23636; Thu, 17 Jan 2002 14:35:49 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0HDZmQ60713; Thu, 17 Jan 2002 14:35:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 11:32:33 +0100. Date: Thu, 17 Jan 2002 14:35:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Also, waiting for AAA solutions to be available (specified, implemeted, > and deployed) before MIPv6 can be used seems to be counter to our desire > to finish up MIPv6 soon. > > => I never proposed to wait for AAA solutions (as I ask only for network > access control, not everywhere but enough to make HAO spoofing unattractive). Are you proposing to wait until network access control is available? (specified, implemented, and deployed) => we don't need to wait because mobile IPv6 is not yet fully specified. IMHO the only thing we need is to be ready and the first step should be to get (traditional) ingress filtering and firewalls with IPv6 support (or do you suggest to stop IPv6 until they are implemented and deployed?) If not, what do you propose to do in the interim until network access control for HAO is available? => decide if we keep or kill the triangular routing. In parallel (because even if the triangular routing is killed there are still similar mechanisms based on tunnels with the same security issue) give this idea to network access control people (both RADIUS/DIAMETER and firewall) in order to know what concrete proposal we can/should do (for instance a new RADIUS attribute for IPv6 inner source address declaration). IMHO this second part is mainly not technical (i.e. out of the scope of IETF). Seems like this requires a two-phase approach: phase 1 before it is available and phase 2 when/if it become available. => you are acking what will happen after some kilometers in a deep fog: today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress filtering, IPv6 firewalls, ... What am I missing? => mobile IPv6 is not yet in last call, in fact we don't know if it will be this year. So we only need a paper solution against the future and potential minor security threat of HAO with ingress filtering. But I agree we have to know where we are going or we could lose more than our time in this kind of discussions (i.e. implementers don't like to follow random moving specs). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 06:17:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEHj2Q006319 for ; Thu, 17 Jan 2002 06:17:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEHiIT006318 for ipng-dist; Thu, 17 Jan 2002 06:17:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEHe2Q006304 for ; Thu, 17 Jan 2002 06:17:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01597 for ; Thu, 17 Jan 2002 06:17:47 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19430 for ; Thu, 17 Jan 2002 07:17:45 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HEHiK03002 for ; Thu, 17 Jan 2002 15:17:44 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 15:17:43 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 15:08:42 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C216@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Cc: jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] How to move forward in the HAO & ingress filter d iscussion Date: Thu, 17 Jan 2002 15:17:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Also, waiting for AAA solutions to be available > (specified, implemeted, > > and deployed) before MIPv6 can be used seems to be > counter to our desire > > to finish up MIPv6 soon. > > > > => I never proposed to wait for AAA solutions (as I > ask only for network > > access control, not everywhere but enough to make HAO > spoofing unattractive). > > Are you proposing to wait until network access control > is available? > (specified, implemented, and deployed) > > => we don't need to wait because mobile IPv6 is not yet > fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls > with IPv6 support > (or do you suggest to stop IPv6 until they are implemented > and deployed?) => Ah, now I now what you meant before by not needing a solution. But this is really scarey, are you saying we wait until last call ( or worse, proposed standard) and then bring this up again ? Some people don't like that Francis :-) How can we be sure that the 'paper solution' you refer to will be deployed by the time MIPv6 is, if ever ... Hesham > > If not, what do you propose to do in the interim until network > access control for HAO is available? > > => decide if we keep or kill the triangular routing. In > parallel (because > even if the triangular routing is killed there are still > similar mechanisms > based on tunnels with the same security issue) give this idea to > network access control people (both RADIUS/DIAMETER and firewall) in > order to know what concrete proposal we can/should do (for > instance a > new RADIUS attribute for IPv6 inner source address > declaration). IMHO > this second part is mainly not technical (i.e. out of the > scope of IETF). > > Seems like this requires a two-phase approach: phase 1 > before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in > a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, > IPv6 ingress > filtering, IPv6 firewalls, ... > > What am I missing? > > => mobile IPv6 is not yet in last call, in fact we don't > know if it will be > this year. So we only need a paper solution against the future and > potential minor security threat of HAO with ingress filtering. > But I agree we have to know where we are going or we could lose more > than our time in this kind of discussions (i.e. > implementers don't like > to follow random moving specs). > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 06:28:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HESB2Q006489 for ; Thu, 17 Jan 2002 06:28:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HESBtG006488 for ipng-dist; Thu, 17 Jan 2002 06:28:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HES82Q006481 for ; Thu, 17 Jan 2002 06:28:08 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03938 for ; Thu, 17 Jan 2002 06:28:15 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18479 for ; Thu, 17 Jan 2002 06:28:13 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0HES6928071; Thu, 17 Jan 2002 16:28:06 +0200 Date: Thu, 17 Jan 2002 16:28:06 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jan 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > I agre with Francis. And, actually, our implementation (i.e. all *BSD > variants) basically keeps the same router (of the same priority), so > it will be non-compliant with the SHOULD. I believe our > implementation is not the only example of this "non-compliant" behavior. True. > If the SHOULD is really the consensus, I'll change the implementation > so that it will be compliant again. However, I'm still not fully > convinced that the change is worth making (perhaps many) existing > applications non-compliant. > > As Francis pointed out, there are many cases of "several default > routers with a better one." In this case, picking up random routers > (without the knowledge of router preference) will just be meangless, > because we'll eventually converge on the better router with redirect > messages. I agree, as I commented on this when the draft first appeared. IMO it's _much_ better practise have predictable behaviour. Load-distribution is not that. When there are two default routes of equal weight, I want to only use one, and if the one I use fails, failover nicely to the other. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 06:32:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEWk2Q006515 for ; Thu, 17 Jan 2002 06:32:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEWjGi006514 for ipng-dist; Thu, 17 Jan 2002 06:32:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEWg2Q006507; Thu, 17 Jan 2002 06:32:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01709; Thu, 17 Jan 2002 06:32:49 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12483; Thu, 17 Jan 2002 07:32:48 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0HEWkK28133; Thu, 17 Jan 2002 16:32:46 +0200 Date: Thu, 17 Jan 2002 16:32:46 +0200 (EET) From: Pekka Savola To: cc: Erik Nordmark , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jan 2002, Francis Dupont wrote: > => we don't need to wait because mobile IPv6 is not yet fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls with IPv6 support > (or do you suggest to stop IPv6 until they are implemented and deployed?) Ingress filtering and firewalls exist already. > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You know full well that e.g. ip6fw, ipf, iptables (all free) etc. support IPv6 ingress filtering and firewalling rather nicely; they've had the support for some time now. They're still a bit raw, as is understandable, but usable. So why do you spread FUD? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 06:40:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEei2Q006622 for ; Thu, 17 Jan 2002 06:40:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEei78006621 for ipng-dist; Thu, 17 Jan 2002 06:40:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEea2Q006614; Thu, 17 Jan 2002 06:40:37 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0HEeQx04513; Thu, 17 Jan 2002 15:40:27 +0100 (MET) Date: Thu, 17 Jan 2002 15:37:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => we don't need to wait because mobile IPv6 is not yet fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls with IPv6 support > (or do you suggest to stop IPv6 until they are implemented and deployed?) No, but the specification of MIPv6 should wait until the ingress filtering part is specified. If we (the IETF) really care about security we need to make sure that we don't create holes in the set of standards track RFCs we issue. That is all the IETF need to worry about. (Others need to worry about complete security of products and a third set of folks need to worry about the security of their operational network using those products.) For the IETF I think this means that we should not issue a proposed standard (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be made aware of HAO). If we want to go this path I think we need a community supported ingress filtering RFC (BCP or standards track) that handles HAO no later than when MIPv6 becomes Proposed Standard. I don't think we should use the fact that 1) there are IPv6 products with incomplete security and/or 2) existing IPv6 operational networks have incomplete security as arguments that we can have an IPv6 story where the standards have security holes. Even if we say "we'll fill that hole really quickly by later producing an HAO aware ingress filtering RFC" or something similar. > If not, what do you propose to do in the interim until network > access control for HAO is available? > > => decide if we keep or kill the triangular routing. In parallel (because > even if the triangular routing is killed there are still similar mechanisms > based on tunnels with the same security issue) give this idea to > network access control people (both RADIUS/DIAMETER and firewall) in > order to know what concrete proposal we can/should do (for instance a > new RADIUS attribute for IPv6 inner source address declaration). IMHO > this second part is mainly not technical (i.e. out of the scope of IETF). It seems like the IETF pieces (RFCs) that need to be completed to have complete (i.e. not security holes in the combination of specs) specification for network access control is sizeable: some fireall spec (perhaps informational), some radius and diameter extensions. This sounds like more delay for MIPv6 to me. The two-phase approach removes this delay. > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You're confusing specifications, products, and deployed practise. People can build ingress filtering and firewalls for IPv6 today without waiting for a specification from the IETF. That wouldn't be true if we issue a MIPv6 specification which, in order to avoid ingress filtering, depends on some yet to be written RFCs that specify network access control for HAO. > => mobile IPv6 is not yet in last call, in fact we don't know if it will be > this year. So we only need a paper solution against the future and > potential minor security threat of HAO with ingress filtering. But we don't want to delay MIPv6 any more than we need to. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 06:39:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEdo2Q006612 for ; Thu, 17 Jan 2002 06:39:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEdo7H006611 for ipng-dist; Thu, 17 Jan 2002 06:39:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEdX2Q006604 for ; Thu, 17 Jan 2002 06:39:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14960 for ; Thu, 17 Jan 2002 06:38:59 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29587 for ; Thu, 17 Jan 2002 07:38:56 -0700 (MST) Received: from repligate (as1-50.chi.il.dial.anet.com [198.92.156.50]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0HEZY3u023745; Thu, 17 Jan 2002 08:35:34 -0600 (CST) Message-ID: <041001c19f75$16643320$0100a8c0@repligate> From: "Jim Fleming" To: "Brian E Carpenter" , "Robert Elz" Cc: "Steven M. Bellovin" , , "Subrata Goswami" , References: <20020111150246.D34077B4B@berkshire.research.att.com> <5847.1011016992@brandenburg.cs.mu.OZ.AU> <3C46B954.4B0A1500@hursley.ibm.com> Subject: One person's noise may be another person's data. Date: Thu, 17 Jan 2002 08:36:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Brian E Carpenter" To: "Robert Elz" Cc: "Steven M. Bellovin" ; ; "Subrata Goswami" ; Sent: Thursday, January 17, 2002 3:45 AM Subject: Re: Flow Label > In any case, the behaviour when you see an "unknown" flow label should be > the same as when you see a zero label - apply default treatment, whatever > that happens to be locally. No need to either drop the packet or > rewrite the label; at that point it's just a noise field. > One person's noise may be another person's data. The IPv6++ Headers use the 20 unsed bits in the first word for a 4 bit (in-Header) Data Length field. The other 16 bits are used for the StarGate, which is the Exclusive OR of the SRC and DST StarGates. Each end knows their StarGate so they can derive the other end's StarGate from the value carried in the field that may look like "noise". Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 06:58:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEwJ2Q006736 for ; Thu, 17 Jan 2002 06:58:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEwJ24006735 for ipng-dist; Thu, 17 Jan 2002 06:58:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEwG2Q006728 for ; Thu, 17 Jan 2002 06:58:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10281 for ; Thu, 17 Jan 2002 06:58:21 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03774 for ; Thu, 17 Jan 2002 07:58:20 -0700 (MST) Received: from repligate (as1-50.chi.il.dial.anet.com [198.92.156.50]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0HEw93u000480; Thu, 17 Jan 2002 08:58:09 -0600 (CST) Message-ID: <042401c19f78$3d450570$0100a8c0@repligate> From: "Jim Fleming" To: "Pekka Savola" , "JINMEI Tatuya / ????" Cc: References: Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" Date: Thu, 17 Jan 2002 08:58:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Pekka Savola" To: "JINMEI Tatuya / ????" Cc: Sent: Thursday, January 17, 2002 6:28 AM Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" > On Thu, 17 Jan 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > I agre with Francis. And, actually, our implementation (i.e. all *BSD > > variants) basically keeps the same router (of the same priority), so > > it will be non-compliant with the SHOULD. I believe our > > implementation is not the only example of this "non-compliant" behavior. > > True. > > > If the SHOULD is really the consensus, I'll change the implementation > > so that it will be compliant again. However, I'm still not fully > > convinced that the change is worth making (perhaps many) existing > > applications non-compliant. > > > > As Francis pointed out, there are many cases of "several default > > routers with a better one." In this case, picking up random routers > > (without the knowledge of router preference) will just be meangless, > > because we'll eventually converge on the better router with redirect > > messages. > > I agree, as I commented on this when the draft first appeared. > > IMO it's _much_ better practise have predictable behaviour. > Load-distribution is not that. When there are two default routes of equal > weight, I want to only use one, and if the one I use fails, failover > nicely to the other. > With RIFRAF Routing, people can use both links with 50/50 (coin-toss) selection for traffic when the links are working. If one link fails, then all of the traffic has to go to the other link. If that link fails, they are out of luck. RIFRAF could be easily extended to 3, 4, or more links, with the traffic distributed 33%, 25%, etc. Since the current implementation does a 50/50 coin toss, and selects 4 bits for the packet marking, one can also build a 50/50 system with 16 traffic flows. Couple that with the 16 QoS classes and you have lots of ways to go. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 07:07:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HF7q2Q006768 for ; Thu, 17 Jan 2002 07:07:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HF7qHn006767 for ipng-dist; Thu, 17 Jan 2002 07:07:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HF7n2Q006760 for ; Thu, 17 Jan 2002 07:07:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12048; Thu, 17 Jan 2002 07:07:55 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17046; Thu, 17 Jan 2002 08:07:54 -0700 (MST) Received: from repligate (as1-50.chi.il.dial.anet.com [198.92.156.50]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0HF7f3u003651; Thu, 17 Jan 2002 09:07:42 -0600 (CST) Message-ID: <042a01c19f79$930879f0$0100a8c0@repligate> From: "Jim Fleming" To: "Erik Nordmark" , "Francis Dupont" Cc: "Erik Nordmark" , , , References: Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Thu, 17 Jan 2002 09:08:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Erik Nordmark" > > If we (the IETF) really care about security we need to make sure that we don't > create holes in the set of standards track RFCs we issue. For some people, RFC means Request For Comment. Surely you don't think an RFC means anything with respect to real-world, operational deployment. It is easy to point to RFCs (especially IPv6 ones), that are operationally dysfunctional. Anyone writing code and making systems work sees that. Most of those people have no time or inclination to make "comments" in response to your "requests". They are busy making real networks work. RFCs do not make things work properly. They appear to mostly be resume-builders and large ISOC archive messages. It does not even appear that the people writing them have ever deployed any of the technology they write about. Take a survey of your ICANN and ISOC leaders. Most of them have never gotten near an IPv6 system. Many of them rarely even use IPv4 systems. They also do not appear to respond to your "requests" for "comments". Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 08:49:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HGnT2Q006951 for ; Thu, 17 Jan 2002 08:49:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HGnTAT006950 for ipng-dist; Thu, 17 Jan 2002 08:49:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HGnM2Q006935; Thu, 17 Jan 2002 08:49:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17537; Thu, 17 Jan 2002 08:49:29 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27337; Thu, 17 Jan 2002 08:49:27 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA23660; Thu, 17 Jan 2002 08:49:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HGnPa17204; Thu, 17 Jan 2002 08:49:25 -0800 X-mProtect: Thu, 17 Jan 2002 08:49:25 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhdSlH2; Thu, 17 Jan 2002 08:49:23 PST Message-ID: <3C470094.29B50022@iprg.nokia.com> Date: Thu, 17 Jan 2002 08:49:24 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, I'm pretty far behind on reading these voluminous e-mails, but I would at least like to express again my belief that we could go forward with the HAO as it is. If the downside is that then there is vulnerability to (single!) packets being reflected back to an unsuspecting home address, then: - This is not a completely horrible problem - It is amenable to solutions that can be deployed later, as IPv6 itself becomes more widely deployed - Solutions involving use of security associations between mobile and correspondent will be developed more rapidly if there is motivation for use with Proposed Standard Mobile IPv6 - We can be done almost immediately, and begin to productively tackle the issues more effectively with experience. I think there is a very real possibility that we are getting stalled in worrying over a problem that is not going to happen. A couple of other points: Francis Dupont wrote: > => we don't need to wait because mobile IPv6 is not yet fully specified. That is purely a matter of opinion. People have built it and tested it and it works. I think it would be far more proper to say that Mobile IPv6 is in fact fully specified, but we have identified more things to do. Those things should be in new specifications. I would compare your statement to be the same as saying "IP was not fully specified until we had CIDR". That is manifestly absurd, unless you are willing to also contend that IP and IPv6 both are not even yet fully specified. In my opinion, we are not moving forward because we are being required to boil the ocean before even being allowed to take a drink. Erik Nordmark wrote: > If not, what do you propose to do in the interim until network > access control for HAO is available? I'd say let's try it. The likely access controls are not going to affect the handling at the correspondent node anyway. The downside isn't very bad anyway. If I were a malicious hacker, why would I mess with that when there are so many other low-hanging fruits to spear? > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... Phase one is basically requiring reverse tunneling for virtually all mobility, killing route optimization, and probably along with it any hope of QoS for many years. It means that nodes will typically not receive packets containing the Home Address option, and thus the feature will rust. > => mobile IPv6 is not yet in last call, in fact we don't know if it will be > this year. Well, technically speaking, it was already in Last Call last year (and the year before). But I guess that is really a moot point. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 11:02:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HJ282Q007234 for ; Thu, 17 Jan 2002 11:02:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HJ28iF007233 for ipng-dist; Thu, 17 Jan 2002 11:02:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HJ252Q007226; Thu, 17 Jan 2002 11:02:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00502; Thu, 17 Jan 2002 11:02:11 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07311; Thu, 17 Jan 2002 11:02:11 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0HJ2AD01465; Thu, 17 Jan 2002 11:02:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAR81251; Thu, 17 Jan 2002 11:01:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA17034; Thu, 17 Jan 2002 11:01:53 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15431.8097.648763.243323@thomasm-u1.cisco.com> Date: Thu, 17 Jan 2002 11:01:53 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <3C470094.29B50022@iprg.nokia.com> References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charles E. Perkins writes: > Hello folks, > > I'm pretty far behind on reading these voluminous e-mails, but > I would at least like to express again my belief that we could > go forward with the HAO as it is. If the downside is that then > there is vulnerability to (single!) packets being reflected back > to an unsuspecting home address, then: [] That is not the only downside. The primary downsides have been discussed here ad nauseum. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 11:07:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HJ7D2Q007390 for ; Thu, 17 Jan 2002 11:07:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HJ7DA3007389 for ipng-dist; Thu, 17 Jan 2002 11:07:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HJ752Q007371; Thu, 17 Jan 2002 11:07:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02364; Thu, 17 Jan 2002 11:07:11 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00517; Thu, 17 Jan 2002 12:07:10 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0HJ74906892; Thu, 17 Jan 2002 11:07:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAR81450; Thu, 17 Jan 2002 11:06:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA17037; Thu, 17 Jan 2002 11:06:58 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15431.8402.347072.961249@thomasm-u1.cisco.com> Date: Thu, 17 Jan 2002 11:06:58 -0800 (PST) To: Erik Nordmark Cc: Francis Dupont , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > For the IETF I think this means that we should not issue a proposed standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). If we want to go this path I think we need a community > supported ingress filtering RFC (BCP or standards track) that handles HAO no > later than when MIPv6 becomes Proposed Standard. I agree 100% with Erik here, and add this: security needs to be thought of in terms of layers. Ingress filtering is a useful, but incomplete layer. Ultimately hosts need a means to defend themselves too since we can't assume that anything will have complete coverage. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 17 21:54:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0I5st2Q008468 for ; Thu, 17 Jan 2002 21:54:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0I5stL3008467 for ipng-dist; Thu, 17 Jan 2002 21:54:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0I5sq2Q008460 for ; Thu, 17 Jan 2002 21:54:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01896 for ; Thu, 17 Jan 2002 21:54:59 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25242 for ; Thu, 17 Jan 2002 22:54:55 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0I5twe03821; Fri, 18 Jan 2002 12:56:02 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: "Steven M. Bellovin" , Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <3C46B954.4B0A1500@hursley.ibm.com> References: <3C46B954.4B0A1500@hursley.ibm.com> <20020111150246.D34077B4B@berkshire.research.att.com> <5847.1011016992@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 12:55:58 +0700 Message-ID: <3819.1011333358@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Jan 2002 12:45:24 +0100 From: Brian E Carpenter Message-ID: <3C46B954.4B0A1500@hursley.ibm.com> | In any case, the behaviour when you see an "unknown" flow label should be | the same as when you see a zero label - apply default treatment, whatever | that happens to be locally. No need to either drop the packet or | rewrite the label; at that point it's just a noise field. Yes, of course. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 08:11:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGBO2Q009229 for ; Fri, 18 Jan 2002 08:11:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGBOPK009228 for ipng-dist; Fri, 18 Jan 2002 08:11:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGBL2Q009221; Fri, 18 Jan 2002 08:11:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18238; Fri, 18 Jan 2002 08:11:25 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27354; Fri, 18 Jan 2002 09:11:24 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0IGBL524834; Fri, 18 Jan 2002 17:11:21 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA06682; Fri, 18 Jan 2002 17:11:22 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0IGBLQ65767; Fri, 18 Jan 2002 17:11:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201181611.g0IGBLQ65767@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 16:32:46 +0200. Date: Fri, 18 Jan 2002 17:11:21 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Ingress filtering and firewalls exist already. => for IPv6? I'd like this is true but can you say more (which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists, which commercial firewalls have IPv6 support?) > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You know full well that e.g. ip6fw, ipf, iptables (all free) etc. => no, we talk about commercial firewalls even if I share my not-expressed opinion about them. So why do you spread FUD? => I don't want to spread FUD, I just wanted to show what is FUD... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 08:24:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGO52Q009352 for ; Fri, 18 Jan 2002 08:24:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGO5k8009351 for ipng-dist; Fri, 18 Jan 2002 08:24:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGNw2Q009336; Fri, 18 Jan 2002 08:23:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26402; Fri, 18 Jan 2002 08:24:03 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24661; Fri, 18 Jan 2002 09:24:01 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA04633; Fri, 18 Jan 2002 08:24:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0IGNxK13102; Fri, 18 Jan 2002 08:23:59 -0800 X-mProtect: Fri, 18 Jan 2002 08:23:59 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVkQa5g; Fri, 18 Jan 2002 08:23:40 PST Message-ID: <3C484BAD.9DA854FC@iprg.nokia.com> Date: Fri, 18 Jan 2002 08:22:05 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If the downside is that then > > there is vulnerability to (single!) packets being reflected back > > to an unsuspecting home address, then: [] > > That is not the only downside. The primary downsides > have been discussed here ad nauseum. I looked at a lot of stuff, but that's the only one I saw, even though it can be dressed up in different ways. What else is there? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 08:40:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGeD2Q009440 for ; Fri, 18 Jan 2002 08:40:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGeDVY009439 for ipng-dist; Fri, 18 Jan 2002 08:40:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGe62Q009424; Fri, 18 Jan 2002 08:40:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00521; Fri, 18 Jan 2002 08:40:11 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19227; Fri, 18 Jan 2002 09:40:10 -0700 (MST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118164008.EWAD27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 18:40:08 +0200 Message-ID: <002801c1a03e$cb8fcce0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" , Cc: References: <200201181611.g0IGBLQ65767@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 18:40:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ingress filtering and firewalls exist already. > > => for IPv6? I'd like this is true but can you say more > (which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists, > which commercial firewalls have IPv6 support?) > > => no, we talk about commercial firewalls even if I share my not-expressed > opinion about them. Francis, I really don't want to define the word "exists" as equivalent to "included in IOS". Nor do I equate it with "exists commercially". So, like Pekka Savola noted, there's a open source OSes that deal with both v6 packets as well as with v4 packets in their firewall and filtering functions. I also know some leading firewall and VPN vendors who are working on v6 versions of their products. But perhaps you meant that ingress filtering isn't generally applied for v6 yet. That might well be true. But I still don't want you take away my possibility to go out tomorrow and buy a linux box/product and configure it to do ingress filtering in my home! Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 08:41:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGf22Q009480 for ; Fri, 18 Jan 2002 08:41:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGf1tH009479 for ipng-dist; Fri, 18 Jan 2002 08:41:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGew2Q009471; Fri, 18 Jan 2002 08:40:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23133; Fri, 18 Jan 2002 08:41:03 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19805; Fri, 18 Jan 2002 09:41:01 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0IGf0Q12136; Fri, 18 Jan 2002 18:41:00 +0200 Date: Fri, 18 Jan 2002 18:40:59 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201181611.g0IGBLQ65767@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 18 Jan 2002, Francis Dupont wrote: > Ingress filtering and firewalls exist already. > > => for IPv6? I'd like this is true but can you say more > (which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists, > which commercial firewalls have IPv6 support?) If one vendor does not please you, you can try another (not that others would have better support for these, necessarily) or bug them and/or wait :-) RPF is not required for ingress filtering, but sure makes it much easier. > > Seems like this requires a two-phase approach: phase 1 before it is > > available and phase 2 when/if it become available. > > > > => you are acking what will happen after some kilometers in a deep fog: > > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > > filtering, IPv6 firewalls, ... > > You know full well that e.g. ip6fw, ipf, iptables (all free) etc. > > => no, we talk about commercial firewalls even if I share my not-expressed > opinion about them. Why again we should care about commerical firewalls? Apparently their interests lie elsewhere; IPv6 is not significant enough for them and no one wants to pay for the extra. Therefore those that care use free products. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 08:54:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGs42Q009609 for ; Fri, 18 Jan 2002 08:54:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGs4Wv009608 for ipng-dist; Fri, 18 Jan 2002 08:54:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGru2Q009593; Fri, 18 Jan 2002 08:53:56 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04512; Fri, 18 Jan 2002 08:54:01 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21300; Fri, 18 Jan 2002 08:53:59 -0800 (PST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118165354.EYZR27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 18:53:54 +0200 Message-ID: <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Charlie Perkins" , Cc: References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> <3C484BAD.9DA854FC@iprg.nokia.com> Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 18:53:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie wrote: > > > If the downside is that then > > > there is vulnerability to (single!) packets being reflected back > > > to an unsuspecting home address, then: [] > > > > That is not the only downside. The primary downsides > > have been discussed here ad nauseum. > > I looked at a lot of stuff, but that's the only one I saw, > even though it can be dressed up in different ways. > What else is there? I think you are right Charlie, that is the only downside. (There's a bunch of other downsides related to fixing with AAA the hole HAO leaves in ingress filtering, but that's another issue.) The primary danger of unconstrained HAO is having even a small number of attackers spoof HAOs and use a large number of CNs as reflectors to attack a specific target even if your network has ingress filtering. Basically, it voids ingress filtering. 2-way i-trace would still detect the source of these attacks, at least in some cases. However, my concern is that i-trace isn't ready, isn't deployed and frankly I don't really believe it being deployed anytime soon. A hypothetical "Care of Address Option" for MIPv6 would have the same detection power. The trouble with both of these as opposed to ingress filtering is that they act after the attack is done or over, while ingress filtering prevents attacks. In situations where you have no ingress filtering there's really no difference whether we use HAOs or not. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 09:11:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHBg2Q009719 for ; Fri, 18 Jan 2002 09:11:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHBg4b009718 for ipng-dist; Fri, 18 Jan 2002 09:11:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHBd2Q009711; Fri, 18 Jan 2002 09:11:39 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29447; Fri, 18 Jan 2002 09:11:44 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10161; Fri, 18 Jan 2002 10:11:43 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0IHBd502402; Fri, 18 Jan 2002 18:11:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA08915; Fri, 18 Jan 2002 18:11:40 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0IHBdQ66006; Fri, 18 Jan 2002 18:11:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201181711.g0IHBdQ66006@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 15:37:20 +0100. Date: Fri, 18 Jan 2002 18:11:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: No, but the specification of MIPv6 should wait until the ingress filtering part is specified. => I don't see why? Or do you argue that the ingress filtering part is impossible or very long to specify (obviously not)? The purpose to move this thread to the IPv6 WG mailing-list is just to fix it in parallel. If we (the IETF) really care about security we need to make sure that we don't create holes in the set of standards track RFCs we issue. => I agree but in this case the target is explicitely "not introduce significant new vulnerabilities that are not present in IPv4 today". The new vulnerability has not be proved to be significant and the proposed reply is designed to get back to the IPv4 situation (where the reply to the threat, I have to say it again, is a BCP). That is all the IETF need to worry about. => I disagree, the IETF need to worry about holes in the set of standards track RFCs we have already issued (the RFCs) and missed (holes). (this should not happen but we know it's happened) For the IETF I think this means that we should not issue a proposed standard (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be made aware of HAO). => I believe you'll have the same opinion about BU security too (i.e. byebye RR :-). If we want to go this path I think we need a community supported => supported = saying this is the solution or supported = have implemented it or supported = have deployed it First is fine, second is possible (MIPv6 people will put pressure on firewall people, IMHO firewall people need to be more aware of IPv6 in general). The last one is out of the scope of the IETF. ingress filtering RFC (BCP or standards track) that handles HAO no later than when MIPv6 becomes Proposed Standard. I don't think we should use the fact that 1) there are IPv6 products with incomplete security and/or 2) existing IPv6 operational networks have incomplete security as arguments that we can have an IPv6 story where the standards have security holes. Even if we say "we'll fill that hole really => I never use the "we'll fill" argument. My idea is "we can fill/we know how to fill" in order to not slow down MIPv6 specifications. To move the thread to the IPv6 WG is for the same purpose. quickly by later producing an HAO aware ingress filtering RFC" or something similar. It seems like the IETF pieces (RFCs) that need to be completed to have complete (i.e. not security holes in the combination of specs) specification for network access control is sizeable: some fireall spec (perhaps informational), some radius and diameter extensions. => we need only some radius extensions (diameter extensions already exist (as an author of one of the diameter for MIPv6 drafts, I may claim this), firewall specs are not really in the scope of the IETF). Of course if diameter for MIPv6 becomes a real AAA WG activity (this is in the charter of AAA, the AAA/mobility RFC is very well written (it makes no difference between IPv4 and IPv6), but AAA people believe MIPv6 will be ready in many months/years). This sounds like more delay for MIPv6 to me. => not if it is done in parallel. The two-phase approach removes this delay. => by dropping in practice the second phase, no thanks! > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are asking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You're confusing specifications, products, and deployed practice. => no, I just reject all arguments based on what will happen in the future at the exception that we want to get IPv6 smart ingress filtering deployed not after than mobile IPv6. The IETF has no control over deployment, its control is only over document publication, so the only thing we can ask is to provide smart ingress filtering documents before MIPv6 (we can do a bit more because we can implement them too). People can build ingress filtering and firewalls for IPv6 today without waiting for a specification from the IETF. That wouldn't be true if we issue a MIPv6 specification which, in order to avoid ingress filtering, depends on some yet to be written RFCs that specify network access control for HAO. =. can I translate your argument in the network access control for HAO documents should be available (or enough stable) before the MIPv6 one in the same state? This is unrealistic for DIAMETER (because of the AAA state), easy for RADIUS and out of the scope of the IETF for firewalls (I am not a firewall expert, I only know that many commercial firewalls have a network access control module... in fact the whole idea is from a team with some firewall persons so I know the whole thing was put in a commercial firewall more than two years ago but the @#$... people don't believe there is a market, grr...). But we don't want to delay MIPv6 any more than we need to. => my purpose was never to delay MIPv6 but we obviously disagree about what kind of stuff can be removed safely (i.e. with the possibility to put them back after) from MIPv6 in order to speed it up. Regards Francis.Dupont@enst-bretagne.fr PS: we are losing time: keep or kill the triangular routing? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 09:36:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHaS2Q009908 for ; Fri, 18 Jan 2002 09:36:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHaSFD009907 for ipng-dist; Fri, 18 Jan 2002 09:36:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHaP2Q009900; Fri, 18 Jan 2002 09:36:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17363; Fri, 18 Jan 2002 09:36:26 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03014; Fri, 18 Jan 2002 10:36:24 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0IHaCr12556; Fri, 18 Jan 2002 19:36:12 +0200 Date: Fri, 18 Jan 2002 19:36:12 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: Charlie Perkins , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 18 Jan 2002, Jari Arkko wrote: > > I looked at a lot of stuff, but that's the only one I saw, > > even though it can be dressed up in different ways. > > What else is there? > > I think you are right Charlie, that is the only downside. > (There's a bunch of other downsides related to fixing > with AAA the hole HAO leaves in ingress filtering, but > that's another issue.) > > The primary danger of unconstrained HAO is having even a small > number of attackers spoof HAOs and use a large > number of CNs as reflectors to attack a specific > target even if your network has ingress filtering. > Basically, it voids ingress filtering. [snip] There is a downside: destination site's filtering ("spoofing protection" from the direction of the Internet) is nullified! (This attack is especially nasty in "send an UDP exploit" scenarios -- not necessarily DoS.) This can be more or less partially repaired, by e.g. allow incoming HAO with local Home Address only from local MN's, or local MN's that are known to be outside, or even local MN's that match a specific binding and are outside. However, for security, that requires packet filters wanting to protect from this must have the ability to go into extension headers and match against HAO.. this is not yet implemented anywhere that I know of; requirinig this for security of HAO might be too much. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 09:41:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHfK2Q009978 for ; Fri, 18 Jan 2002 09:41:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHfK0q009977 for ipng-dist; Fri, 18 Jan 2002 09:41:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHfD2Q009962; Fri, 18 Jan 2002 09:41:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08728; Fri, 18 Jan 2002 09:41:18 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16633; Fri, 18 Jan 2002 10:41:17 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0IHf9A09749; Fri, 18 Jan 2002 09:41:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAS02923; Fri, 18 Jan 2002 09:40:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA17427; Fri, 18 Jan 2002 09:41:09 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15432.24117.377768.561852@thomasm-u1.cisco.com> Date: Fri, 18 Jan 2002 09:41:09 -0800 (PST) To: Pekka Savola Cc: Jari Arkko , Charlie Perkins , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: References: <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola writes: > On Fri, 18 Jan 2002, Jari Arkko wrote: > > > I looked at a lot of stuff, but that's the only one I saw, > > > even though it can be dressed up in different ways. > > > What else is there? > > > > I think you are right Charlie, that is the only downside. > > (There's a bunch of other downsides related to fixing > > with AAA the hole HAO leaves in ingress filtering, but > > that's another issue.) > > > > The primary danger of unconstrained HAO is having even a small > > number of attackers spoof HAOs and use a large > > number of CNs as reflectors to attack a specific > > target even if your network has ingress filtering. > > Basically, it voids ingress filtering. > [snip] > > There is a downside: destination site's filtering ("spoofing protection" > from the direction of the Internet) is nullified! Thank you. That was exactly what my point was. It's not just the reflector attack; the HAO nullifies all of the ingress filtering present on the net right now. That is distinctly worse than the status quo. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 09:45:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHjd2Q010088 for ; Fri, 18 Jan 2002 09:45:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHjd9q010087 for ipng-dist; Fri, 18 Jan 2002 09:45:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHjV2Q010069; Fri, 18 Jan 2002 09:45:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06881; Fri, 18 Jan 2002 09:45:37 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17749; Fri, 18 Jan 2002 09:45:36 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA10204; Fri, 18 Jan 2002 09:45:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0IHjVT32213; Fri, 18 Jan 2002 09:45:31 -0800 X-mProtect: Fri, 18 Jan 2002 09:45:31 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNod5Pi; Fri, 18 Jan 2002 09:45:29 PST Message-ID: <3C485F3A.2D5795C6@iprg.nokia.com> Date: Fri, 18 Jan 2002 09:45:30 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> <3C484BAD.9DA854FC@iprg.nokia.com> <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jari, Thank you very much for this clarification. Jari Arkko wrote: >> I looked at a lot of stuff, but that's the only one I saw, >> even though it can be dressed up in different ways. >> What else is there? > > I think you are right Charlie, that is the only downside. > (There's a bunch of other downsides related to fixing > with AAA the hole HAO leaves in ingress filtering, but > that's another issue.) AAA for IPv6 is, indeed, quite another problem domain, and one for which we've hardly started considering the issues. > The primary danger of unconstrained HAO is having even a small > number of attackers spoof HAOs and use a large > number of CNs as reflectors to attack a specific > target even if your network has ingress filtering. > Basically, it voids ingress filtering. Here, I disagree, although I clearly understand why you would say that. The reason I disagree, is that I can specify an augmented ingress filtering router that will work with HAOs (and, actually, have already begun to done so). I do understand that such a thing is harder to build. Furthermore, I am quite reluctant to get embroiled in a design discussion about building ingress filtering routers (notwithstanding (*) below), when what I really want to do is to move the Mobile IPv6 specification forward. > 2-way i-trace would still detect the source of these attacks, at least > in some cases. However, my concern is that i-trace isn't ready, > isn't deployed and frankly I don't really believe it being deployed > anytime soon. A hypothetical "Care of Address Option" for MIPv6 > would have the same detection power. The trouble with both of > these as opposed to ingress filtering is that they act after the attack > is done or over, while ingress filtering prevents attacks. But the larger problem is that we are being fantastically careful about avoiding a possible future problem that is: 1) solvable in a backwards compatible way 2) not so horrible, 3) delaying by years the specification, and consequently 4) causing other design dislocations in, e.g., 3G. --------------------------------- In an effort to be constructive, here are some further ideas about how to limit the damage from the packet reflection which can be caused by malicious use of unrestricted HAOs. 1) The correspondent node can strictly limit the number of care-of addresses available to any one home address (to, say, one or two). It _could_ even do so for the number of care-of addresses assignable to home addresses on a particular subnet, if we wanted to go to the trouble of putting the prefix length back into the Binding Update. 2) The ingress filtering router can strictly limit the number of HAOs transmitted from any particular subnet prefix per unit time (*). These are the first things that come to mind, and I believe they are quite simple to implement. (1) certainly is. Plus, I believe that, for the purposes of handling HAOs, we should begin to distinguish between home addresses that have security associations established with the correspondent node, and home addresses that do not. It is the latter variety that need to have the strict numerical limitations. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 09:48:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHmJ2Q010226 for ; Fri, 18 Jan 2002 09:48:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHmJ1n010225 for ipng-dist; Fri, 18 Jan 2002 09:48:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHm92Q010204; Fri, 18 Jan 2002 09:48:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01775; Fri, 18 Jan 2002 09:48:15 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19853; Fri, 18 Jan 2002 10:48:14 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0IHm4j14595; Fri, 18 Jan 2002 09:48:05 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAS03117; Fri, 18 Jan 2002 09:47:29 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA17430; Fri, 18 Jan 2002 09:48:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15432.24529.242954.233574@thomasm-u1.cisco.com> Date: Fri, 18 Jan 2002 09:48:01 -0800 (PST) To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201181711.g0IHBdQ66006@givry.rennes.enst-bretagne.fr> References: <200201181711.g0IHBdQ66006@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > If we (the IETF) really care about security we need to make sure > that we don't create holes in the set of standards track RFCs we > issue. > > => I agree but in this case the target is explicitely "not introduce > significant new vulnerabilities that are not present in IPv4 today". > The new vulnerability has not be proved to be significant and the > proposed reply is designed to get back to the IPv4 situation (where > the reply to the threat, I have to say it again, is a BCP). Positing AAA as the necessary band-aid is a non-starter. Positing the kind of fix I proposed as a "crazy idea" runs into problems with middle of the network RPF checking and will, in practice, sink any use of route optimization. HAO's cannot defeat ingress filtering. That is distinctly worse than the current net. I think we seriously need to consider whether we should sever route optimization from this draft. Sigh. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 10:04:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0II4V2Q010466 for ; Fri, 18 Jan 2002 10:04:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0II4VNc010465 for ipng-dist; Fri, 18 Jan 2002 10:04:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0II4S2Q010458; Fri, 18 Jan 2002 10:04:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12828; Fri, 18 Jan 2002 10:04:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24256; Fri, 18 Jan 2002 11:04:32 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0II4V512738; Fri, 18 Jan 2002 19:04:31 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA10325; Fri, 18 Jan 2002 19:04:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0II4VQ66490; Fri, 18 Jan 2002 19:04:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201181804.g0II4VQ66490@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 08:49:24 PST. <3C470094.29B50022@iprg.nokia.com> Date: Fri, 18 Jan 2002 19:04:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm pretty far behind on reading these voluminous e-mails, but I would at least like to express again my belief that we could go forward with the HAO as it is. If the downside is that then there is vulnerability to (single!) packets being reflected back to an unsuspecting home address, then: - This is not a completely horrible problem => I agree but it seems there is the real point... - Solutions involving use of security associations between mobile and correspondent will be developed more rapidly if there is motivation for use with Proposed Standard Mobile IPv6 => a two phase approach works never in the security domain or the triangular routing needs HAO support everywhere to make sense. - We can be done almost immediately, and begin to productively tackle the issues more effectively with experience. => I still believe the idea to send IPv6 questions to the IPv6 WG is the correct one. In fact the decision of keeping or killing the triangular routing is in the hands of IPv6 implementors (they are supposed to read the IPv6 WG list from time to time). I think there is a very real possibility that we are getting stalled in worrying over a problem that is not going to happen. => to get stalled is the worst way to get a decision. A couple of other points: Francis Dupont wrote: > => we don't need to wait because mobile IPv6 is not yet fully specified. That is purely a matter of opinion. => or of what is the meaning of fully specified. It seems I am the author of this statement so I meant "not yet ready for publication". In my opinion, we are not moving forward because we are being required to boil the ocean before even being allowed to take a drink. => this one of the drawbacks of security issues... I am not commenting other remarks because we agree. Well, technically speaking, it was already in Last Call last year (and the year before). But I guess that is really a moot point. => is a new last call after important changes due to IESG concerns required? It seems we'll get a new WG last call, and perhaps some last calls about other (than the spec) MIPv6 documents. Regards Francis.Dupont@enst-bretagne.fr PS: you are in favor of keeping the triangular routing, aren't you? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 10:38:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IIcn2Q010813 for ; Fri, 18 Jan 2002 10:38:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IIcnkB010812 for ipng-dist; Fri, 18 Jan 2002 10:38:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IIcf2Q010797; Fri, 18 Jan 2002 10:38:41 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14724; Fri, 18 Jan 2002 10:38:48 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14004; Fri, 18 Jan 2002 10:38:46 -0800 (PST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118183845.FTIJ27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 20:38:45 +0200 Message-ID: <00cb01c1a04f$5dac0660$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pekka Savola" Cc: "Charlie Perkins" , , References: Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 20:38:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is a downside: destination site's filtering ("spoofing protection" > from the direction of the Internet) is nullified! Yeah. Forgot that, sorry! Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 18 10:45:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IIjn2Q010910 for ; Fri, 18 Jan 2002 10:45:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IIjnoc010909 for ipng-dist; Fri, 18 Jan 2002 10:45:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IIjf2Q010894; Fri, 18 Jan 2002 10:45:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01958; Fri, 18 Jan 2002 10:45:47 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11880; Fri, 18 Jan 2002 11:45:46 -0700 (MST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118184545.FUWH27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 20:45:45 +0200 Message-ID: <00cc01c1a050$58618b20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Charles E. Perkins" Cc: , References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> <3C484BAD.9DA854FC@iprg.nokia.com> <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> <3C485F3A.2D5795C6@iprg.nokia.com> Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 20:45:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here, I disagree, although I clearly understand why you would say > that. Fair enough. Reading on... > The reason I disagree, is that I can specify an augmented > ingress filtering router that will work with HAOs (and, actually, > have already begun to done so). I do understand that such a thing > is harder to build. Furthermore, I am quite reluctant to get > embroiled in a design discussion about building ingress filtering > routers (notwithstanding (*) below), when what I really want to > do is to move the Mobile IPv6 specification forward. Yes. Your approach is a good one, but I think the concern people have is that they are doubtful whether a sufficiently good solution exists. I simply don't believe in the AAA approach to fix this problem, for instance (even if I'm a big fan of AAA for other purposes and even partially behind the Diameter base spec). So, if you were able to give some clue to the plan how what you intend to achieve, perhaps we could go with this approach then. However, for the moment as has appeared such a hard problem to me that I really need to see a some convincing parts of the solution at least before I'd believe this really can be done. > In an effort to be constructive, here are some further ideas about > how to limit the damage from the packet reflection which can be > caused by malicious use of unrestricted HAOs. Excellent! > 1) The correspondent node can strictly limit the number of > care-of addresses available to any one home address (to, > say, one or two). It _could_ even do so for the number > of care-of addresses assignable to home addresses on a > particular subnet, if we wanted to go to the trouble of > putting the prefix length back into the Binding Update. Unfortunately I don't think this will work. One property of the HAO reflection vulnerability is that the number of nodes offering "reflection service" is roughly the size of the IPv6 Internet. So, any rate limitation / address limitation etc will not help if the attacker chooses another CN the next time. > 2) The ingress filtering router can strictly limit the number > of HAOs transmitted from any particular subnet prefix > per unit time (*). This is better than the previous one. But I'm still not too happy with it. How do we ensure that what seems like a small bandwidth at the Nokia Research Group router isn't going to feel like a catastrophy at my home link? And what if everyone in the Nokia Research Group wanted to use HAOs at the same time, would their traffic capacity be cut down too much? What would the value be? What will it require from the router, is state involved or can you do it in stateless way? Also, if the HAO reflection would be used to hide DDoS attack clients in a number of places, rate limitation at single router might not help. > Plus, I believe that, for the purposes of handling HAOs, > we should begin to distinguish between home addresses that > have security associations established with the correspondent > node, and home addresses that do not. It is the latter > variety that need to have the strict numerical limitations. I'll treat this as the third offered solution. Like I think Pekka mentioned some time ago, there's ways of coming up with SAs that don't necessarily live up to this standard, even if such SAs would be useful for e.g. preventing passive wiretapping. But given that Opportunistic IPsec is not deployed much yet, maybe we could put that consideration aside. Perhaps we should then consider a rule that forbids HAOs if there's no SA involved? That would be a possibility. The downside is that you'd still have to provide for bidir tunneling for cleartext communications. Then I could also ask that if you bothered to do 2xRSA+1xD-H and keep at least a few hundred bytes of state at both ends, why couldn't you use RO at that time too? In conclusion I like these ideas better than the AAA approach. However, I still think we'd need something even better to start considering this alternative for real. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 19 10:06:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JI6J2Q012323 for ; Sat, 19 Jan 2002 10:06:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JI6JNj012322 for ipng-dist; Sat, 19 Jan 2002 10:06:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JI6G2Q012315; Sat, 19 Jan 2002 10:06:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26432; Sat, 19 Jan 2002 10:06:22 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05721; Sat, 19 Jan 2002 10:06:17 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0JI65513122; Sat, 19 Jan 2002 19:06:05 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA04501; Sat, 19 Jan 2002 19:06:06 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0JI65Q72882; Sat, 19 Jan 2002 19:06:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201191806.g0JI65Q72882@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Jari Arkko , Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Fri, 18 Jan 2002 19:36:12 +0200. Date: Sat, 19 Jan 2002 19:06:05 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: There is a downside: destination site's filtering ("spoofing protection" from the direction of the Internet) is nullified! (This attack is especially nasty in "send an UDP exploit" scenarios -- not necessarily DoS.) => this is 4.1 section of my draft: - the vulnerability can exist *only* if there are some home agents inside the site (this is a strong constraint) - the defense is basically the same: the filtering devices have to know the bindings (the home registrations are enough) by the way you'd like (several work, the only implementation I know uses BU/BA snooping with success). This can be more or less partially repaired, by e.g. allow incoming HAO with local Home Address only from local MN's, or local MN's that are known to be outside, or even local MN's that match a specific binding and are outside. => no, this can be fully repaired. And in most cases very easily: no home agent = no binding = just apply the anti-spoofing to everything that can be a source address. However, for security, that requires packet filters wanting to protect from this must have the ability to go into extension headers and match against HAO.. => if your packet filter doesn't already do that, change it ASAP. this is not yet implemented anywhere that I know of; => this was implemented 30 months ago somewhere I know of. (I can ask for a testimony if you really want it) requiring this for security of HAO might be too much. => if I apply your argument to the routing header it should be forbidden... I strongly disagree: stupid defects in some stupid firewalls should not be admissible arguments against a protocol feature. Regards Francis.Dupont@enst-bretagne.fr PS: the position of the HAO in packets was required by some firewall people, so I believe there are at least two firewall expert teams which already managed how to deal with HAOs... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 19 10:16:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JIGC2Q012444 for ; Sat, 19 Jan 2002 10:16:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JIGCVC012443 for ipng-dist; Sat, 19 Jan 2002 10:16:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JIG82Q012436; Sat, 19 Jan 2002 10:16:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28244; Sat, 19 Jan 2002 10:16:14 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26914; Sat, 19 Jan 2002 11:16:08 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0JIFm513482; Sat, 19 Jan 2002 19:15:48 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA04738; Sat, 19 Jan 2002 19:15:49 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0JIFmQ72917; Sat, 19 Jan 2002 19:15:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201191815.g0JIFmQ72917@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Pekka Savola , Jari Arkko , Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Fri, 18 Jan 2002 09:41:09 PST. <15432.24117.377768.561852@thomasm-u1.cisco.com> Date: Sat, 19 Jan 2002 19:15:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Thank you. That was exactly what my point was. It's not just the reflector attack; the HAO nullifies all of the ingress filtering present on the net right now. That is distinctly worse than the status quo. => if "ingress filtering" is your message is anti-spoofing, I've answered in a previous mail, so I consider this is the traditional ingress filtering. I believe you made a confusion between causes and effects. Ingress filtering itself as no value, ingress filtering is a reply to the source address spoofing threat which itself is only an option to the DDoS threat. So the HAO problem is *only* the reflector attack in this context (i.e. without anti-spoofing considerations). Regards Francis.Dupont@enst-bretagne.fr PS: we do no progress. After Monday I'll answer only comments to my draft and threads proposed by the mobile-ip WG chairs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 19 11:51:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JJpw2Q012653 for ; Sat, 19 Jan 2002 11:51:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JJpwsa012652 for ipng-dist; Sat, 19 Jan 2002 11:51:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JJpt2Q012645; Sat, 19 Jan 2002 11:51:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09902; Sat, 19 Jan 2002 11:52:00 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05239; Sat, 19 Jan 2002 12:51:59 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0JJpvT23418; Sat, 19 Jan 2002 21:51:57 +0200 Date: Sat, 19 Jan 2002 21:51:57 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , Charlie Perkins , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201191806.g0JI65Q72882@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 19 Jan 2002, Francis Dupont wrote: > There is a downside: destination site's filtering ("spoofing protection" > from the direction of the Internet) is nullified! > > (This attack is especially nasty in "send an UDP exploit" scenarios -- not > necessarily DoS.) > > => this is 4.1 section of my draft: I know. You're making assumptions here: - every packet filter in the internet can 1) recognize HAO 2) parse it, and 3) match against the address in it This does not hold *at all*. I doubt very much even a half of IPv6 packet filters, router access-lists etc. would do this in a few years' time (look how long it has taken to e.g. get anycast implemented, and to what success..). The easiest method, which *might* be deployable soonish would be a check whether HAO exists or not (1) above), and drop all packets with it. However, this would kill all the use for HAO too; not good enough. Iff 3) above holds, every site which does not have mobile nodes of its own can be protected. (If it has MN's, state/AAA or more lax security for the addresses is required.) In my opinion, this is an unrealistic requirement. > - the vulnerability can exist *only* if there are some home agents > inside the site (this is a strong constraint) > - the defense is basically the same: the filtering devices have to > know the bindings (the home registrations are enough) by the way > you'd like (several work, the only implementation I know uses > BU/BA snooping with success). > > This can be more or less partially repaired, by e.g. allow incoming HAO > with local Home Address only from local MN's, or local MN's that are known > to be outside, or even local MN's that match a specific binding and are > outside. > > => no, this can be fully repaired. And in most cases very easily: > no home agent = no binding = just apply the anti-spoofing to everything > that can be a source address. See above. > However, for security, that requires packet filters wanting to protect > from this must have the ability to go into extension headers and match > against HAO.. > > => if your packet filter doesn't already do that, change it ASAP. I don't know of any alternative. > this is not yet implemented anywhere that I know of; > > => this was implemented 30 months ago somewhere I know of. > (I can ask for a testimony if you really want it) I'm interested, sure. But really, I'm not all that interested if it was implemented just somewhere and not integrated with any firewalling products. > requiring this for security of HAO might be too much. > > => if I apply your argument to the routing header it should be forbidden... > I strongly disagree: stupid defects in some stupid firewalls should not > be admissible arguments against a protocol feature. Perhaps, perhaps not. But I was not advocating Routing Headers be filtered in firewalls; I was not advocating HAO be either (because both are difficult problems which I think will not be deployed in the real world very widely). Instead, I was advocating stronger checks in the end-nodes, thus eliminating the need for firewall security checks except for those 1% who really want to go and build the AAA system to get the extra control and security. For routing headers, it appears this issue will be clarified. For HAO, this is still open as it would require bigger modifications. > PS: the position of the HAO in packets was required by some firewall people, > so I believe there are at least two firewall expert teams which already > managed how to deal with HAOs... Wrong assumption. This means some firewall people have analyzed what it seems to be required to manage HAO at all: whether it can be checked under every circumstance (e.g. IPSEC secured data) and where it is usually located (check for the existance of the header, not necessarily the content). This speaks nothing for implementing parsing for it, or anything. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 20 05:54:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KDsr2Q013350 for ; Sun, 20 Jan 2002 05:54:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KDsqNo013349 for ipng-dist; Sun, 20 Jan 2002 05:54:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KDsn2Q013342; Sun, 20 Jan 2002 05:54:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02956; Sun, 20 Jan 2002 05:54:55 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18565; Sun, 20 Jan 2002 06:54:50 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0KDsm527188; Sun, 20 Jan 2002 14:54:48 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA22376; Sun, 20 Jan 2002 14:54:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0KDslQ74834; Sun, 20 Jan 2002 14:54:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201201354.g0KDslQ74834@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Fri, 18 Jan 2002 09:45:30 PST. <3C485F3A.2D5795C6@iprg.nokia.com> Date: Sun, 20 Jan 2002 14:54:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: AAA for IPv6 is, indeed, quite another problem domain, and one for which we've hardly started considering the issues. => Jari meant network access control, not full AAA with AAA infrastructure. Furthermore, I am quite reluctant to get embroiled in a design discussion about building ingress filtering routers (notwithstanding (*) below), when what I really want to do is to move the Mobile IPv6 specification forward. => I agree, the ingress filtering stuff should be dealt with in parallel. In an effort to be constructive, here are some further ideas about how to limit the damage from the packet reflection which can be caused by malicious use of unrestricted HAOs. 1) The correspondent node can strictly limit the number of care-of addresses available to any one home address (to, say, one or two). It _could_ even do so for the number of care-of addresses assignable to home addresses on a particular subnet, if we wanted to go to the trouble of putting the prefix length back into the Binding Update. => I don't believe in defense at CNs with triangular routing, I am afraid this will catch only buggy attacks. 2) The ingress filtering router can strictly limit the number of HAOs transmitted from any particular subnet prefix per unit time (*). => this can be useful in order to detect abnormal situations (i.e. attacks) but not to fix them (it is too hard to distinguish between legitimate and fake HAOs so the system can be itself the target of a DoS attack). The best passive protection is BU/BA snooping (all interesting parameters are in the exchange and BAs are easy to check) but if it is effective when possible (no too much ciphered fields, snooping devices in the path), I personnaly prefer more active schemes (mainly because they give far better proofs in the legal meaning... but I believe firewall people prefer snooping which is more common in their context). BTW I've interpreted your statement as the number of *different* HAOs transmitted... These are the first things that come to mind, and I believe they are quite simple to implement. (1) certainly is. Plus, I believe that, for the purposes of handling HAOs, we should begin to distinguish between home addresses that have security associations established with the correspondent node, and home addresses that do not. It is the latter variety that need to have the strict numerical limitations. => with current specs a MN must have a home registration with is always acknowledged so BU/BA snooping is the next step of your idea. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 20 07:21:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KFLD2Q013741 for ; Sun, 20 Jan 2002 07:21:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KFLDxV013740 for ipng-dist; Sun, 20 Jan 2002 07:21:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KFLA2Q013733; Sun, 20 Jan 2002 07:21:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27059; Sun, 20 Jan 2002 07:21:14 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11033; Sun, 20 Jan 2002 08:21:13 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0KFLB532350; Sun, 20 Jan 2002 16:21:11 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA23826; Sun, 20 Jan 2002 16:21:11 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0KFLBQ75609; Sun, 20 Jan 2002 16:21:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201201521.g0KFLBQ75609@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , Charlie Perkins , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Sat, 19 Jan 2002 21:51:57 +0200. Date: Sun, 20 Jan 2002 16:21:11 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: You're making assumptions here: - every packet filter in the internet can => every firewall 1) recognize HAO 2) parse it, and 3) match against the address in it This does not hold *at all*. => this holds for every decent firewalls: they do URL filtering and you are trying to say they don't know how to dig into a packet? I doubt very much even a half of IPv6 packet filters, router access-lists etc. would do this in a few years' time => I assume we'll get at least the same level of technology which is used today near everywhere for IPv4. The easiest method, which *might* be deployable soonish would be a check whether HAO exists or not (1) above), and drop all packets with it. However, this would kill all the use for HAO too; not good enough. => I agree that today situation for HAO is "ignore all" and the next step is "drop all". I expect a third step (I am optimistic (:-) and this is a problem of balance between mobility industry and firewall industry). Iff 3) above holds, every site which does not have mobile nodes of its own can be protected. => yes, to know there is no binding at all is a perfect knowledge of current bindings (:-). (If it has MN's, state/AAA or more lax security for the addresses is required.) => please use "network access control" in place of AAA because some FUD is based on the confusion between network access control and AAA infrastructure. In my opinion, this is an unrealistic requirement. => what is unrealistic is to believe firewalls are not commonly used... > anti-spoofing stuff... See above. => anti-spoofing is different because the simple case is "no HA" which should be far more common than "no MN". The way to use firewalls is more usual too and gives more freedom. > => if your packet filter doesn't already do that, change it ASAP. I don't know of any alternative. => I know at least one but it is not yet commercially available (I can privately give some pointers). I believe there are others (ready but not available). Instead, I was advocating stronger checks in the end-nodes, thus eliminating the need for firewall security checks except for those 1% who really want to go and build the AAA system to get the extra control and => a network access control please, no the AAA system security. => this doesn't work: if we kill the triangular routing following your suggestion there will be no exception at all. > so I believe there are at least two firewall expert teams which already > managed how to deal with HAOs... Wrong assumption. => please let Charly Perkins (or these persons) answer. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 01:45:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0L9jP2Q015235 for ; Mon, 21 Jan 2002 01:45:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0L9jPjJ015234 for ipng-dist; Mon, 21 Jan 2002 01:45:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0L9jK2Q015227; Mon, 21 Jan 2002 01:45:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0L9jIF06348; Mon, 21 Jan 2002 10:45:19 +0100 (MET) Date: Mon, 21 Jan 2002 10:42:08 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201181711.g0IHBdQ66006@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis wrote: > I wrote: > No, but the specification of MIPv6 should wait until the ingress > filtering > part is specified. > > => I don't see why? Or do you argue that the ingress filtering part > is impossible or very long to specify (obviously not)? The purpose > to move this thread to the IPv6 WG mailing-list is just to fix it > in parallel. It's just that I haven't seen credible solution to distributed ingress filtering of packets with HAO that doesn't resort to have a global AAA infrastructure to solve the hard problem. I personally think we need solutions that don't required additional infrastcuture. > That is all the IETF need to worry about. > > => I disagree, the IETF need to worry about holes in the set of > standards track RFCs we have already issued (the RFCs) and missed (holes). > (this should not happen but we know it's happened) Sure, in addition to make sure that new stuff doesn't have holes we either need to fix or deprecate existing stuff with security holes. I don't think I said anything to the contrary. > For the IETF I think this means that we should not issue a proposed > standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). > > => I believe you'll have the same opinion about BU security too (i.e. > byebye RR :-). I don't understand the point and I don't understand the joke. Could you be more explicit? > If we want to go this path I think we need a community supported > > => supported = saying this is the solution or > supported = have implemented it or > supported = have deployed it > First is fine, second is possible (MIPv6 people will put pressure on > firewall people, IMHO firewall people need to be more aware of IPv6 > in general). The last one is out of the scope of the IETF. If youn read the whole sentence before interjecting the comments (it's below) you'll see it was about an RFC. BCP and Proposed standards are not required to be implemented and/or deployed in order to be publishes as such. > ingress filtering RFC (BCP or standards track) that handles HAO no > later than when MIPv6 becomes Proposed Standard. > > =. can I translate your argument in the network access control for HAO > documents should be available (or enough stable) before the MIPv6 one > in the same state? Yes, this is what I said several times now. No PS for MIPv6 with a security hole in my personal opinion. Means that a PS or BCP smart ingress filtering (set of) RFC need to exist at that time as MIPv6 becomes PS. > This is unrealistic for DIAMETER (because of the > AAA state), easy for RADIUS and out of the scope of the IETF for > firewalls (I am not a firewall expert, I only know that many commercial > firewalls have a network access control module... in fact the whole > idea is from a team with some firewall persons so I know the whole > thing was put in a commercial firewall more than two years ago but > the @#$... people don't believe there is a market, grr...). Above you said it wouldn't delay MIPv6 to do this (because of it being done in parallel) but now you seem to say it would delay it because of various reaons. So you seem to agree with me about the delay? > PS: we are losing time: keep or kill the triangular routing? I say: Remove the unauthenticated and unauthorized use of HAO which has the effect that tringular routing isn't an option. The only options are bidirectional tunneling through the HA and route optimization. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 03:34:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LBYS2Q015449 for ; Mon, 21 Jan 2002 03:34:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LBYSjM015448 for ipng-dist; Mon, 21 Jan 2002 03:34:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LBYP2Q015441; Mon, 21 Jan 2002 03:34:25 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25217; Mon, 21 Jan 2002 03:34:29 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13052; Mon, 21 Jan 2002 03:34:28 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0LBYO521765; Mon, 21 Jan 2002 12:34:24 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA06946; Mon, 21 Jan 2002 12:34:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0LBYOQ84481; Mon, 21 Jan 2002 12:34:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201211134.g0LBYOQ84481@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Mon, 21 Jan 2002 10:42:08 +0100. Date: Mon, 21 Jan 2002 12:34:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: It's just that I haven't seen credible solution to distributed ingress filtering of packets with HAO that doesn't resort to have a global AAA infrastructure to solve the hard problem. => so you'll be very happy when you'll read my draft which relies only on *enough* of any kind of network access control (even passive one, aka BU/BA snooping which can have the favour of firewall folk). I personally think we need solutions that don't required additional infrastcuture. => we agree. > That is all the IETF need to worry about. > > => I disagree, the IETF need to worry about holes in the set of > standards track RFCs we have already issued (the RFCs) and missed (holes). > (this should not happen but we know it's happened) Sure, in addition to make sure that new stuff doesn't have holes we either need to fix or deprecate existing stuff with security holes. I don't think I said anything to the contrary. => your statement could suggest the IETF doesn't need to worry about holes in already published standard track RFCs (we agree this is *not* the case). > For the IETF I think this means that we should not issue a proposed > standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). > > => I believe you'll have the same opinion about BU security too (i.e. > byebye RR :-). I don't understand the point and I don't understand the joke. Could you be more explicit? => RR is known to be a bit weak from a security point of view so as a MITM vulnerability can be considered as a hole, your opinion should be in disfavour of RR, isn't it? (smile again) > If we want to go this path I think we need a community supported > > => supported = saying this is the solution or > supported = have implemented it or > supported = have deployed it > First is fine, second is possible (MIPv6 people will put pressure on > firewall people, IMHO firewall people need to be more aware of IPv6 > in general). The last one is out of the scope of the IETF. If youn read the whole sentence before interjecting the comments (it's below) you'll see it was about an RFC. BCP and Proposed standards are not required to be implemented and/or deployed in order to be publishes as such. => I apologize: I was afraid of overinterpretations of the term supported. > =< can I translate your argument in the network access control for HAO > documents should be available (or enough stable) before the MIPv6 one > in the same state? Yes, this is what I said several times now. No PS for MIPv6 with a security hole in my personal opinion. Means that a PS or BCP smart ingress filtering (set of) RFC needs to exist at that time as MIPv6 becomes PS. => thanks, now there is no possible ambiguities about your opinion. BTW I fully agree with you about this point. > This is unrealistic for DIAMETER (because of the > AAA state), easy for RADIUS and out of the scope of the IETF for > firewalls (I am not a firewall expert, I only know that many commercial > firewalls have a network access control module... in fact the whole > idea is from a team with some firewall persons so I know the whole > thing was put in a commercial firewall more than two years ago but > the @#$... people don't believe there is a market, grr...). Above you said it wouldn't delay MIPv6 to do this (because of it being done in parallel) but now you seem to say it would delay it because of various reasons. => where are the reasons (in document publication, cf above) of delays? This can only be about the connection between network access controls and firewalls: - there is no IETF protocol about this - it seems the current consensus is this is not in the IETF scope - this exists, in general in the purpose to be applied to remote and/or mobile users, for instance http://www.evidian.com/accessmaster/netwall/features.htm#Broad In many AAA and PANA drafts (including mine :-), there are references about when the terminal is authentified the firewall is opened for it (i.e. authorization is "to access to the Internet"). I can't find details about how this is done, can some firewall folk help us? (if you know some, can you forward this to them) So you seem to agree with me about the delay? => one thing we agree is we don't want delay. > PS: we are losing time: keep or kill the triangular routing? I say: Remove the unauthenticated and unauthorized use of HAO which has the effect that tringular routing isn't an option. The only options are bidirectional tunneling through the HA and route optimization. => so we disagree only about the necessity to remove the unauthenticated and unauthorized use of HAO (my argument is there is no such necessity about source address themselves). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 04:34:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LCYD2Q015672 for ; Mon, 21 Jan 2002 04:34:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LCYDA3015671 for ipng-dist; Mon, 21 Jan 2002 04:34:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LCYA2Q015664 for ; Mon, 21 Jan 2002 04:34:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23567 for ; Mon, 21 Jan 2002 04:34:15 -0800 (PST) Received: from mailFA8.rediffmail.com ([202.54.124.153]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA05723 for ; Mon, 21 Jan 2002 04:34:14 -0800 (PST) Received: (qmail 22488 invoked by uid 510); 21 Jan 2002 12:35:05 -0000 Date: 21 Jan 2002 12:35:05 -0000 Message-ID: <20020121123505.22487.qmail@mailFA8.rediffmail.com> Received: from unknown (203.196.145.150) by rediffmail.com via HTTP; 21 Jan 2002 12:35:05 -0000 MIME-Version: 1.0 From: "Ramakrishnan" Reply-To: "Ramakrishnan" To: ipng@sunroof.eng.sun.com Subject: Query About MLD Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0LCYA2Q015665 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Sir/Madam, I have some queries regarding MLD (Multicast Listener Discovery). I am a beginner in IPv6.So, my question may look very simple for you. Why MLD ( Multicast Listener Discovery) message are sent for Sloicited-Node multicast address ? Regards, Ramakrishnan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 05:31:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LDVK2Q015728 for ; Mon, 21 Jan 2002 05:31:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LDVKDh015727 for ipng-dist; Mon, 21 Jan 2002 05:31:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LDVE2Q015720; Mon, 21 Jan 2002 05:31:15 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0LDVEF25009; Mon, 21 Jan 2002 14:31:14 +0100 (MET) Date: Mon, 21 Jan 2002 14:28:02 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201211134.g0LBYOQ84481@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => so you'll be very happy when you'll read my draft which relies only > on *enough* of any kind of network access control (even passive one, > aka BU/BA snooping which can have the favour of firewall folk). I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to assume that the architecture only needs to support ingress at one place. I think we need to allow ingress filtering to take place at multiple "levels" such at each college dorm room router, between the college and the ISP, between leaf ISPs and transits, etc. I don't see any difference between saying - we can trust the access network to do ingress filtering - we can trust the host to not use bogus source addresses Fundamentally it is an issue about trust boundaries. If an ISP doesn't do ingress filtering themselves the ISPs that provide service to it might want to filter. The architecture should not prevent such flexibility. > > => I believe you'll have the same opinion about BU security too (i.e. > > byebye RR :-). > > I don't understand the point and I don't understand the joke. > Could you be more explicit? > > => RR is known to be a bit weak from a security point of view so > as a MITM vulnerability can be considered as a hole, your opinion should > be in disfavour of RR, isn't it? (smile again) I'm answering the serious underlying question/assumption: You seem to have not read the abstract in the BU3WAY document. I never claimed it was the best approach. In fact, if CGA was free (no IPR concerns and no performance concerns for the PK operations) doing CGA (in combination with RR to deal with certain DoS attacks) would be the obvious answer IMHO. > => where are the reasons (in document publication, cf above) of delays? > This can only be about the connection between network access controls > and firewalls: > - there is no IETF protocol about this > - it seems the current consensus is this is not in the IETF scope > - this exists, in general in the purpose to be applied to remote > and/or mobile users, for instance > http://www.evidian.com/accessmaster/netwall/features.htm#Broad > In many AAA and PANA drafts (including mine :-), there are references > about when the terminal is authentified the firewall is opened for it > (i.e. authorization is "to access to the Internet"). I can't find > details about how this is done, can some firewall folk help us? > (if you know some, can you forward this to them) If we feel that we (the IETF) can't produce documents that say how firewalls should behave then it would seem foolish for us to produce standards that assume certain behavior in firewalls. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 06:51:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LEpS2Q015873 for ; Mon, 21 Jan 2002 06:51:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LEpSCY015872 for ipng-dist; Mon, 21 Jan 2002 06:51:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LEpO2Q015865 for ; Mon, 21 Jan 2002 06:51:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11898 for ; Mon, 21 Jan 2002 06:51:27 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22410 for ; Mon, 21 Jan 2002 07:51:26 -0700 (MST) Received: from lutchann by marduk.litech.org with local (Exim 3.22 #1) id 16Sfn6-0000ht-00; Mon, 21 Jan 2002 09:51:20 -0500 Date: Mon, 21 Jan 2002 09:51:20 -0500 From: Nathan Lutchansky To: Ramakrishnan Cc: ipng@sunroof.eng.sun.com Subject: Re: Query About MLD Message-ID: <20020121095120.A2431@litech.org> References: <20020121123505.22487.qmail@mailFA8.rediffmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020121123505.22487.qmail@mailFA8.rediffmail.com>; from rama_krishnans@rediffmail.com on Mon, Jan 21, 2002 at 12:35:05PM -0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2002 at 12:35:05PM -0000, Ramakrishnan wrote: > Why MLD ( Multicast Listener Discovery) message are sent for Sloicited-No= de > multicast address ? Intelligent link-layer devices like Ethernet switches may snoop the MLD pac= kets to=20 learn what multicast addresses each device is listening to. In the absence= of MLD=20 packets, switches would need to flood all multicast packets to the whole ne= twork,=20 because there is no way of knowing which devices want which packets. -Nath= an --=20 +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TCroTviDkW8mhycRAgmbAKCoS9drSWPY1LaG4eNNZ0RnVA7vxwCfZPaC +8IoczXTX60ilQBOuGS/YZA= =JhlN -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 10:37:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LIbQ2Q016268 for ; Mon, 21 Jan 2002 10:37:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LIbQOo016267 for ipng-dist; Mon, 21 Jan 2002 10:37:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LIbN2Q016260; Mon, 21 Jan 2002 10:37:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09855; Mon, 21 Jan 2002 10:37:29 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28533; Mon, 21 Jan 2002 11:37:27 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0LIbM506566; Mon, 21 Jan 2002 19:37:22 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA19403; Mon, 21 Jan 2002 19:37:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0LIbMQ87908; Mon, 21 Jan 2002 19:37:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Mon, 21 Jan 2002 14:28:02 +0100. Date: Mon, 21 Jan 2002 19:37:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => so you'll be very happy when you'll read my draft which relies only > on *enough* of any kind of network access control (even passive one, > aka BU/BA snooping which can have the favour of firewall folk). I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to assume that the architecture only needs to support ingress at one place. => this is a constraint: active network access control is usually done at one place. I don't see any difference between saying - we can trust the access network to do ingress filtering - we can trust the host to not use bogus source addresses => it seems you have a very bad feeling of your ISP (:-). Fundamentally it is an issue about trust boundaries. => I fully agree: this is a trust/responsability issue so I am not surprised when this can be described with AAA terms (for instance this is about "the authorization to use this home address"). The architecture should not prevent such flexibility. => what does prevent flexibility is the only current technical concrete form of trust/responsability is network access control systems. I'm answering the serious underlying question/assumption: You seem to have not read the abstract in the BU3WAY document. => IMHO BU3WAY is an attempt to get the faster/cheaper security scheme for BUs (the opposite of IKE+AH). I never claimed it was the best approach. => so I've put again a smile. In fact, if CGA was free (no IPR concerns and no performance concerns for the PK operations) doing CGA (in combination with RR to deal with certain DoS attacks) would be the obvious answer IMHO. => if CGA was free we have a lot of better solutions to many problems (including the HAO vs ingress filtering one) but it has both IPR and performance concerns... If we feel that we (the IETF) can't produce documents that say how firewalls should behave => this is about details of communication between network access controls and firewalls, not about firewall behavior. BTW my draft is essentially a firewall behavior specification. then it would seem foolish for us to produce standards that assume certain behavior in firewalls. => firewall people were not enough (? :-) foolish to wait for us to specify how network access controls and firewalls should communicate. More seriously I've looked at what is available: - it seems a lot of firewalls support this kind of feature for remote/mobile access (all the commercial firewalls still in the market) - IPF (well known open source firewall) has the auth/preauth actions which do exactly what is needed (unfortunately the IPv6 support of IPF is questionable and has not (*yet*) HAO support.) Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 12:25:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LKPL2Q016650 for ; Mon, 21 Jan 2002 12:25:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LKPKkD016649 for ipng-dist; Mon, 21 Jan 2002 12:25:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LKPF2Q016642; Mon, 21 Jan 2002 12:25:16 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0LKP8F27454; Mon, 21 Jan 2002 21:25:09 +0100 (MET) Date: Mon, 21 Jan 2002 21:21:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to > assume > that the architecture only needs to support ingress at one place. > > => this is a constraint: active network access control is usually done > at one place. I wasn't talking about network access control - I was talking about ingress filtering. While e.g. an ISP/subscriber relationship might have some network access control that isn't the only place ingress filtering might need to be done. > I don't see any difference between saying > - we can trust the access network to do ingress filtering > - we can trust the host to not use bogus source addresses > > => it seems you have a very bad feeling of your ISP (:-) Yes I do, but I don't trust the whole edge around the whole Internet. There probably exists at least one ISP on the planet that will allow any source address in the packets sent by their subscribers. Thus it needs to be possible to ingress filtering at other places than just the ISP/subscriber boundary. > => what does prevent flexibility is the only current technical > concrete form of trust/responsability is network access control systems. Sorry, wrog subject. We were talking about ingress filtering and not network access control I think :-) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 12:44:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LKif2Q016779 for ; Mon, 21 Jan 2002 12:44:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LKifrM016778 for ipng-dist; Mon, 21 Jan 2002 12:44:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LKib2Q016771 for ; Mon, 21 Jan 2002 12:44:38 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16558; Mon, 21 Jan 2002 12:44:43 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26818; Mon, 21 Jan 2002 12:44:42 -0800 (PST) Received: from repligate (as1-163.chi.il.dial.anet.com [198.92.156.163]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0LKiQW9020200; Mon, 21 Jan 2002 14:44:30 -0600 (CST) Message-ID: <04e101c1a2bc$7cd68730$8328fea9@repligate> From: "Jim Fleming" To: "Erik Nordmark" , "Francis Dupont" Cc: "Erik Nordmark" , , , References: Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Mon, 21 Jan 2002 12:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Erik Nordmark" > > => it seems you have a very bad feeling of your ISP (:-) > > Yes I do, but I don't trust the whole edge around the whole Internet. > There probably exists at least one ISP on the planet that will > allow any source address in the packets sent by their subscribers. > where...Internet =??? "toy, legacy, IPv4 Internet" http://www.dot-biz.com/IPv8/Papers/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 14:38:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LMc62Q017270 for ; Mon, 21 Jan 2002 14:38:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LMc6pb017269 for ipng-dist; Mon, 21 Jan 2002 14:38:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LMc12Q017262; Mon, 21 Jan 2002 14:38:01 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0LMc0F02642; Mon, 21 Jan 2002 23:38:02 +0100 (MET) Date: Mon, 21 Jan 2002 23:34:38 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C470094.29B50022@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > Phase one is basically requiring reverse tunneling for virtually all > mobility, killing route optimization, and probably along with it any > hope of QoS for many years. It means that nodes will typically not > receive packets containing the Home Address option, and thus the feature > will rust. I don't understand the meaning you assign to "basically" above. Phase 1 would allow either bidirectional tunneling or route optimization (in both directions). The thing it wouldn't allow is the triangle when packets from the MN go directly to the CN, but the other path is through the HA. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 17:22:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M1Mn2Q017508 for ; Mon, 21 Jan 2002 17:22:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0M1MnUa017507 for ipng-dist; Mon, 21 Jan 2002 17:22:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M1Mk2Q017500 for ; Mon, 21 Jan 2002 17:22:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23798 for ; Mon, 21 Jan 2002 17:22:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03410 for ; Mon, 21 Jan 2002 18:22:51 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA18313; Mon, 21 Jan 2002 17:22:50 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0M1Mnc28347; Mon, 21 Jan 2002 17:22:49 -0800 X-mProtect: Mon, 21 Jan 2002 17:22:49 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXSzb4F; Mon, 21 Jan 2002 17:22:46 PST Message-Id: <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 17:22:08 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Comments to date on "IPv6 Host to Router Load Sharing" In-Reply-To: <200201170954.g0H9sXQ59680@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Instead of trying to reply each email I will attempt to summarize and respond to the comments in the last set of email. 1) Requirement level of SHOULD would make existing implementations non-compliant. I believe that the definition of SHOULD (see RFC2119) allows for alternate behavior if there is a good reason for it. I think this can cover both better algorithms for the selection of default routers and if the implementation predates this spec. I will note that the intent of the this document is to change the default behavior of implementations. That is way I think SHOULD is appropriate. Also, I think this is independent of the level of the standard (Proposed, Draft, Standard). 2) Relationship of this change to Neighbor Discovery and Default Router Preferences draft. Should they be combined? The reason why the conclusion of the w.g. in Salt Lake City was to keep the documents separate is that this document is changing the base behavior of Neighbor Discovery when there is more than one default router. The Default Router Preferences draft is an optional mechanism (see the draft). It may not always be used and/or implemented. It was agreed that the Router Preferences draft should also incorporate this behavior when there are more than one router of the same preference. Note this draft is not replacing the router preferences draft. Both are expected to go forward. This draft only changes the case when there is more than one default routers. It does not provide the optimum solution when there are multiple routers with different characteristics. That case is covered by the router preferences draft. 3) General statement load-distribution is not predictable behavior and is undesirable (e.g., using a single router until it fails is better). There is considerable current practice that disputes this. The specific case that this draft addresses (host to router traffic) is very widely deployed using protocols such as VRRP and Cisco's HSRP. The advantage of distributing the load over multiple routers is that it takes advantage of the resources that are available and insures that the backup is working when it is needed. Backup systems that are not being used have a nasty habit of not working when they are needed. Regards, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 21:03:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M5302Q017691 for ; Mon, 21 Jan 2002 21:03:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0M530pl017690 for ipng-dist; Mon, 21 Jan 2002 21:03:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M52v2Q017683 for ; Mon, 21 Jan 2002 21:02:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14818 for ; Mon, 21 Jan 2002 21:03:03 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14631 for ; Mon, 21 Jan 2002 22:03:02 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jan 2002 21:02:59 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE62@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments to date on "IPv6 Host to Router Load Sharing" Thread-Index: AcGi4+U3TZSEsb8DQ2KTB0vn6cW6TQAHNT1g From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0M52v2Q017684 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bob Hinden wrote: > There is considerable current practice that disputes this. The > specific case that this draft addresses (host to router traffic) > is very widely deployed using protocols such as VRRP and Cisco's > HSRP. The advantage of distributing the load over multiple > routers is that it takes advantage of the resources that are > available and insures that the backup is working when it is > needed. Backup systems that are not being used have a nasty > habit of not working when they are needed. As a rule of thumb, I prohibit backup systems that are not in use for the very reason mentioned above. When running a mission-critical network, the reasons behind using a load-sharing system is not to save money. If one is using HSRP, one does buy the hardware that can run a full load on a single network (and some safety net). The rationale behind running HSRP routers is NOT to run 50% of the load on two 1/2 size routers, but to make sure that the backup system will kick in real time whenever one needs it. I fully concur with Bob here in saying that: 1. Backup systems that are not being used have a nasty habit of not working when they are needed. 2. Doubling the hardware and have a load-balanced system (that will most of the time run below 50%) is small potatoes compared to "discovering" that your backup does not work when your primary fails. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 21 21:51:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M5pG2Q017803 for ; Mon, 21 Jan 2002 21:51:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0M5pGFs017802 for ipng-dist; Mon, 21 Jan 2002 21:51:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M5pC2Q017793 for ; Mon, 21 Jan 2002 21:51:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA22669 for ; Mon, 21 Jan 2002 21:51:19 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11521 for ; Mon, 21 Jan 2002 22:51:12 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0M5s3w02139; Tue, 22 Jan 2002 12:54:03 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" In-Reply-To: <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jan 2002 12:54:03 +0700 Message-ID: <2137.1011678843@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 21 Jan 2002 17:22:08 -0800 From: Bob Hinden Message-ID: <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> | The reason why the conclusion of the w.g. in Salt Lake City was to keep the | documents separate is that this document is changing the base behavior of | Neighbor Discovery when there is more than one default router. The Default | Router Preferences draft is an optional mechanism (see the draft). It may | not always be used and/or implemented. My general feeling is that without router preferences being implemented, the new load sharing stuff should not be implemented either. That is, it is fine, but only if I'm guaranteed a way to override it. Expecting everyone to implement load sharing, and making preferences just an optional add on that some can implement if they feel like it, is not acceptable. (The "some" being the hosts that receive the RA's of course, I'll simply assume that any router worth having will implement router preferences). Because of that, I'd much prefer that the two be in the same document, so they get exactly the same status. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 22 02:24:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0MAOU2Q018053 for ; Tue, 22 Jan 2002 02:24:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0MAOUF8018052 for ipng-dist; Tue, 22 Jan 2002 02:24:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0MAOR2Q018045 for ; Tue, 22 Jan 2002 02:24:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05681 for ; Tue, 22 Jan 2002 02:24:33 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04660 for ; Tue, 22 Jan 2002 03:24:32 -0700 (MST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-61.cisco.com [10.82.240.61]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA01521; Tue, 22 Jan 2002 05:24:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020122050446.036870b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 05:24:27 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Issues raised during last call for DHCPv6 specification Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following issues were raised during the last call for the DHCPv6 spec ; I will kick off separate discussion threads for each open issue later today. - Ralph Droms Open issues ----------- * We've experienced a proliferation of DHCPv6 options. Should all options *not* used in the base protocol be moved out to separate drafts? * Does DHCPv6 need a "default routes" option? * Does DHCPv6 need a "static routes" option? * Does DHCPv6 need an FQDN option (basically identical to proposed DHCPv4 FQDN option)? * Other options: - NTP servers - NIS servers - NIS+ servers - Subnet selection - NIS domain name - NIS+ domain name - IEEE 1003.1 POSIX timezone - SLP directory agent - SLP service scope * Should the DHCPv6 option codes start at 256 to avoid overlap with DHCPv4 option codes; overlap of option codes would be an issue for the DHCID RR. * What error codes may a server send in response to an Information-Request message? * Should the Decline message have error codes defining the reason for the Decline? * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. * Is a client required to implement the Reconfigure message - supporting Reconfigure will require that the client maintain state. * Do we want to allow a client to request that more normal addresses be added to an IA, perhaps through use of the equivalent of the RTA option? * DHCP/DDNS interaction * Is the text in section 17.1.3 sufficient? Changes to be made in -23 ------------------------- * Editorial changes: - Change "Inform message" to "Information-request message" and "INFORM" to "INFORMATION-REQUEST" throughout the document - In the list of DHCP messages in section 7, fix Reconfigure to start Renew/Reply or Inform/Reply sequence (not Request/Reply) - Fix page 10 (which is blank in -22 draft) - In third paragraph of section 14, change "Requested Temporary Addresses Option 22.5" to "Requested Temporary Addresses Option (see section 22.5)" - Change "Rebind" to "Inform" in the last paragraph of section 18.1.5 (cut-and-paste error) - Fix redundancy between sections 18.2.5 and 18.2.8 - Edit third paragraph of section 19.2 to delete references to IAs - In section 19.3.4, change "Rebind or Information-Request" to "Renew or Information-Request" - Change last sentence of section 22.5 to: "A client MUST only include this option when it wants to have additional temporary address allocated; a client SHOULD NOT send this option if 'num-requested' is 0". - Edit section 22.14 to indicate that the server-address field is in the fixed-format part of the DHCP message, not the unicast option - Clarify the text in section 22.19 to indicate that the 'user class data' items are carried in the data area of the 'user class option' * Clarify text in section 13 about address selection based on source of message from client * Remove references to "IAs" in section 19.2 * Fix chart in Appendix B to allow DSTM option in same messages as IA option * Modify SIP server option according to input from Henning Schulzrinne * Require that the DUID option appear before any IA options to improve processing efficiency * Require that the authentication option be first in th elist of options to reduce the work that a server must expend before discarding a message that fails authentication (reduces effect of denial of service attacks) * Clean up text specifying selection of address by server to insert into 'server-address' field * Clarify that a server MAY return fewer temporary addresses than requested by the client and MUST return AddrUnavail only if no temporary addresses are available * Clarify that a client MUST include all requested options in an ORO and MAY include suggested values by including specific options; also, the server MAY ignore suggestions from client and the client MUST use whatever the server returns * Clarify that a server MAY renew only some of the IAs sent by a client * Change DUID/VUID to have a length field to allow for longer IDs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 22 06:55:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0MEtc2Q018200 for ; Tue, 22 Jan 2002 06:55:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0MEtcjA018199 for ipng-dist; Tue, 22 Jan 2002 06:55:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0MEtZ2Q018192 for ; Tue, 22 Jan 2002 06:55:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22579 for ; Tue, 22 Jan 2002 06:55:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14602 for ; Tue, 22 Jan 2002 07:55:40 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0MEtR500399; Tue, 22 Jan 2002 15:55:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA12467; Tue, 22 Jan 2002 15:55:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0MEtQQ95681; Tue, 22 Jan 2002 15:55:26 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201221455.g0MEtQQ95681@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" In-reply-to: Your message of Mon, 21 Jan 2002 17:22:08 PST. <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> Date: Tue, 22 Jan 2002 15:55:26 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1) Requirement level of SHOULD would make existing implementations non-compliant. 2) Relationship of this change to Neighbor Discovery and Default Router Preferences draft. Should they be combined? => what we asked is not really a combinaison, it was to get the default router preference not after the load sharing. The Default Router Preferences draft is an optional mechanism (see the draft). It may not always be used and/or implemented. => I'd like to see the same argument than in (1) applied to the default router preferences! Note this draft is not replacing the router preferences draft. Both are expected to go forward. This draft only changes the case when there is more than one default routers. It does not provide the optimum solution when there are multiple routers with different characteristics. That case is covered by the router preferences draft. => you know what we'd (people who did comments) like: to get both. 3) General statement load-distribution is not predictable behavior and is undesirable (e.g., using a single router until it fails is better). There is considerable current practice that disputes this. => there are situations where load sharing is better and others where it is a disaster. The only good solution is to get load-sharing with a way to control it, i.e. the default router preferences. I sent in July 1995 a mail about default router preferences, I never changed my opinion about this... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 22 17:14:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0N1ES2Q018763 for ; Tue, 22 Jan 2002 17:14:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0N1ES7j018762 for ipng-dist; Tue, 22 Jan 2002 17:14:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0N1EP2Q018755 for ; Tue, 22 Jan 2002 17:14:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09804 for ; Tue, 22 Jan 2002 17:14:32 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18547 for ; Tue, 22 Jan 2002 18:14:31 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27326; Tue, 22 Jan 2002 17:14:30 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0N1ETN27860; Tue, 22 Jan 2002 17:14:29 -0800 X-mProtect: Tue, 22 Jan 2002 17:14:29 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMq8KQb; Tue, 22 Jan 2002 17:05:01 PST Message-Id: <4.3.2.7.2.20020122164737.025e7b78@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 17:02:47 -0800 To: Robert Elz From: Bob Hinden Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2137.1011678843@brandenburg.cs.mu.OZ.AU> References: <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, >My general feeling is that without router preferences being implemented, >the new load sharing stuff should not be implemented either. That is, >it is fine, but only if I'm guaranteed a way to override it. > >Expecting everyone to implement load sharing, and making preferences just >an optional add on that some can implement if they feel like it, is not >acceptable. (The "some" being the hosts that receive the RA's of course, >I'll simply assume that any router worth having will implement router >preferences). I think there are two cases. One is where there are two routers that provide equivalent service. The other is where the are two or more routers that have different characteristics (performance, connectivity, etc.). In the first case the proposed load sharing mechanism is fine. In the second case the router preferences is useful. I think that the first case is very common so it is worthwhile to keep the documents separate. >Because of that, I'd much prefer that the two be in the same document, so >they get exactly the same status. I think in practice both will be implemented and used as needed. Neither is very complicated. There is even a rumor that one company is already shipping router preferences :-) Bob p.s. I don't really care too much about this (one or two documents) as long as we get the mechanisms. I will continue to push the current path as it was the conclusion reached in Salt Lake City. I asked the question in my presentation and the conclusion was to continue as a separate document. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 05:21:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NDLQ2Q019403 for ; Wed, 23 Jan 2002 05:21:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NDLQZ3019402 for ipng-dist; Wed, 23 Jan 2002 05:21:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NDLN2Q019395 for ; Wed, 23 Jan 2002 05:21:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25278 for ; Wed, 23 Jan 2002 05:21:25 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25307 for ; Wed, 23 Jan 2002 06:21:24 -0700 (MST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0NDLKL07330; Wed, 23 Jan 2002 05:21:20 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAV25980; Wed, 23 Jan 2002 05:21:18 -0800 (PST) Message-ID: <3C4EB8CD.F2C83B16@stewart.chicago.il.us> Date: Wed, 23 Jan 2002 07:21:17 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "Perry E. Metzger" , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> <87d7103btc.fsf@snark.piermont.com> <15404.54703.385314.958490@thomasm-u1.cisco.com> <87lmfndp86.fsf@snark.piermont.com> <15404.59525.580362.577015@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Catching up on a real old email... Michael Thomas wrote: > Also: you seem to be under the illusion that > QoS classifiers are set in stone. They are not. > I just took a quick look at SCTP: its ports Michael: Your quick look was just that .. a very quick look :> >From RFC2960 (the first bytes in the packet look as follows and are called the common header): " 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " >From RFC793: " TCP Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " The byte postion looks pretty close to the same as far as I can tell :> R > are not in the same place as TCP/UDP; hence, > hardware change. Each new IP protocol that we > come up with will have the same problem. The > flow label has the potential to stop that > problem now and forever. > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 06:24:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NEO22Q019771 for ; Wed, 23 Jan 2002 06:24:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NEO2jE019770 for ipng-dist; Wed, 23 Jan 2002 06:24:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NENx2Q019763 for ; Wed, 23 Jan 2002 06:23:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18374 for ; Wed, 23 Jan 2002 06:24:05 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16255 for ; Wed, 23 Jan 2002 07:24:05 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09653; Wed, 23 Jan 2002 09:24:02 -0500 (EST) Message-Id: <200201231424.JAA09653@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-3gpp-recommend-00.txt Date: Wed, 23 Jan 2002 09:24:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename : draft-ietf-ipv6-3gpp-recommend-00.txt Pages : 22 Date : 22-Jan-02 This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-3gpp-recommend-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020122153312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-3gpp-recommend-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153312.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 06:33:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NEXO2Q019867 for ; Wed, 23 Jan 2002 06:33:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NEXOhN019866 for ipng-dist; Wed, 23 Jan 2002 06:33:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NEXL2Q019859 for ; Wed, 23 Jan 2002 06:33:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01866 for ; Wed, 23 Jan 2002 06:33:28 -0800 (PST) Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23933 for ; Wed, 23 Jan 2002 07:33:27 -0700 (MST) Received: from irinadayal@netscape.net by imo-m03.mx.aol.com (mail_out_v31_r1.25.) id 1.c7.1993170 (16216) for ; Wed, 23 Jan 2002 09:33:08 -0500 (EST) Received: from netscape.com (mow-m01.webmail.aol.com [64.12.184.129]) by air-in01.mx.aol.com (v82.22) with ESMTP id MAILININ14-0123093308; Wed, 23 Jan 2002 09:33:08 -0500 Date: Wed, 23 Jan 2002 09:33:08 -0500 From: irinadayal@netscape.net (Irina Dayal) To: ipng@sunroof.eng.sun.com Subject: IPv6 Addr/Prefix clarification Message-ID: <5ED04AD8.3ED557E2.0F7DF3AA@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am new here so please excuse the trivial questions. I did trawl the archives but could not find a definitive answer. 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits long? The current allocation of IPv6 prefixes seems to require Aggregatable Global Unicast Addresses, which restricts the prefixes to this range. 2) Is it possible for two hosts with the same interface ID (lower 64 bits) to have different prefixes (upper 64 bits) in their addresses? The v6 standards indicate that the interface ID does not always have global scope, so the answer appears to be yes. Thank you for reading... Irina -- __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 07:06:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NF6N2Q019939 for ; Wed, 23 Jan 2002 07:06:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NF6NLZ019938 for ipng-dist; Wed, 23 Jan 2002 07:06:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NF6J2Q019930 for ; Wed, 23 Jan 2002 07:06:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14783 for ; Wed, 23 Jan 2002 07:06:24 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28369 for ; Wed, 23 Jan 2002 08:06:24 -0700 (MST) Received: from kenawang ([192.168.1.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA08646 for ; Wed, 23 Jan 2002 07:05:03 -0800 (PST) Message-Id: <4.2.2.20020123095417.00a916a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Jan 2002 10:04:36 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: 3GPP Address Allocation Changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We recently received notice that the 3GPP has approved a change request to their GPRS architecture specification (23.060) based on the IPv6 WGs recommendations in draft-ietf-ipv6-3gpp-recommend-00.txt. The 3GPP has modified their address allocation mechanism to assign a prefix per primary PDP context, and to allow multiple identifiers to be used within that prefix. This was the most important change recommended in our document, and it eliminates the potential incompatibility between IPv6 privacy addresses and 3GPP. We believe that this change has been made retroactive to 3GPP release 99, so it will be included in all GPRS/UMTS releases that support IPv6 address autoconfiguration. I'd like to commend the 3GPP on their quick action to divert a potentially serious issue. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 07:58:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NFwJ2Q019996 for ; Wed, 23 Jan 2002 07:58:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NFwJ9W019995 for ipng-dist; Wed, 23 Jan 2002 07:58:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NFwG2Q019988 for ; Wed, 23 Jan 2002 07:58:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16106 for ; Wed, 23 Jan 2002 07:58:21 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29146 for ; Wed, 23 Jan 2002 08:58:16 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0NFw7528672; Wed, 23 Jan 2002 16:58:08 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA12302; Wed, 23 Jan 2002 16:58:08 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0NFw7g04149; Wed, 23 Jan 2002 16:58:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201231558.g0NFw7g04149@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: irinadayal@netscape.net (Irina Dayal) cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of Wed, 23 Jan 2002 09:33:08 EST. <5ED04AD8.3ED557E2.0F7DF3AA@netscape.net> Date: Wed, 23 Jan 2002 16:58:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits long? The current allocation of IPv6 prefixes seems to require Aggregatable Global Unicast Addresses, which restricts the prefixes to this range. => if this seems to be safe today you may *not* assume this will remain safe in the future, conclusion: this is not safe. 2) Is it possible for two hosts with the same interface ID (lower 64 bits) to have different prefixes (upper 64 bits) in their addresses? The v6 standards indicate that the interface ID does not always have global scope, so the answer appears to be yes. => yes, I know at least 10 boxes with the 1 interface ID and near the same number with 2. But I believe there are hundreds or thousands... (BTW only a small fraction of them are hosts (i.e. not routers)) Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 08:02:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NG2f2Q020031 for ; Wed, 23 Jan 2002 08:02:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NG2fOM020030 for ipng-dist; Wed, 23 Jan 2002 08:02:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NG2b2Q020023 for ; Wed, 23 Jan 2002 08:02:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25083 for ; Wed, 23 Jan 2002 08:02:43 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06800 for ; Wed, 23 Jan 2002 09:02:42 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0NG2er04675; Wed, 23 Jan 2002 11:02:40 -0500 (EST) Message-Id: <200201231602.g0NG2er04675@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: irinadayal@netscape.net (Irina Dayal) cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Wed, 23 Jan 2002 09:33:08 EST." <5ED04AD8.3ED557E2.0F7DF3AA@netscape.net> Date: Wed, 23 Jan 2002 11:02:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits > long? no. because nothing requires a site to use the lower 64 bits as an interface ID - a site is free to subnet that space if it wishes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 08:09:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NG9w2Q020083 for ; Wed, 23 Jan 2002 08:09:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NG9vrD020082 for ipng-dist; Wed, 23 Jan 2002 08:09:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NG9s2Q020075 for ; Wed, 23 Jan 2002 08:09:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15081 for ; Wed, 23 Jan 2002 08:10:00 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27144 for ; Wed, 23 Jan 2002 09:10:00 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 23 Jan 2002 08:09:57 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C262@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification Thread-Index: AcGkG6ecv5dByaObRAm9PkWZ/L7jMAADBv4g From: "Michel Py" To: "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0NG9t2Q020076 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Irina Dayal wrote: > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 > bits long? The current allocation of IPv6 prefixes seems to require > Aggregatable Global Unicast Addresses, which restricts the prefixes to > this range. It's not safe (even if it might be true today). Slightly more than 1/8 of the IPv6 address space has been allocated to a purpose so far. There are drafts that are mentionning allocating 0001, which is a /4. Even today, one might want to configure 2000::/3 as the default route instead of 0::/0. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 08:13:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NGDg2Q020109 for ; Wed, 23 Jan 2002 08:13:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NGDgoe020108 for ipng-dist; Wed, 23 Jan 2002 08:13:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NGDd2Q020101 for ; Wed, 23 Jan 2002 08:13:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24063 for ; Wed, 23 Jan 2002 08:13:45 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17088 for ; Wed, 23 Jan 2002 09:13:44 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 23 Jan 2002 08:13:44 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE67@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification Thread-Index: AcGkJ8419cqcn8j2RcqRRJXTewtQxwAALK6w From: "Michel Py" To: "Keith Moore" , "Irina Dayal" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0NGDd2Q020102 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Irina Dayal wrote: > 1) Is it safe to assume that all IPv6 prefixes will be between >> 16 and 64 bits long? > Keith Moore wrote: > no. because nothing requires a site to use the lower 64 bits > as an interface ID - a site is free to subnet that space if > it wishes. I have to disagree with Keith here. If a site wants to subnet, they get a /48 and use the 16 SLA bits to subnet, that is what they have been designed for. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 08:42:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NGgW2Q020170 for ; Wed, 23 Jan 2002 08:42:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NGgWx1020169 for ipng-dist; Wed, 23 Jan 2002 08:42:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NGgS2Q020162 for ; Wed, 23 Jan 2002 08:42:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22338 for ; Wed, 23 Jan 2002 08:42:34 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28972 for ; Wed, 23 Jan 2002 09:42:34 -0700 (MST) Received: from repligate (as1-163.chi.il.dial.anet.com [198.92.156.163]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0NGgPFR009009; Wed, 23 Jan 2002 10:42:25 -0600 (CST) Message-ID: <0a7e01c1a42d$084d1ec0$8328fea9@repligate> From: "Jim Fleming" To: "Keith Moore" , "Irina Dayal" Cc: References: <200201231602.g0NG2er04675@astro.cs.utk.edu> Subject: Re: IPv6 Addr/Prefix clarification Date: Wed, 23 Jan 2002 08:42:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Keith Moore" To: "Irina Dayal" Cc: Sent: Wednesday, January 23, 2002 8:02 AM Subject: Re: IPv6 Addr/Prefix clarification > > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits > > long? > > no. because nothing requires a site to use the lower 64 bits as an > interface ID - a site is free to subnet that space if it wishes. > -------------------------------------------------------------------- The right 64 bits are also useful for carrying data. That allows up to 16 bytes to be carried in the bloated 40 byte header. The length of the data can be carried in 4 bits of the unused 20-bits in the first word. This leaves 16 bits for the XOR StarGate value, which is the bit difference of the StarGate at each end of the IPv4 tunnel. Packets flowing on the legacy IPv4 Internet do not have the StarGate values of the end-points, just the bits that differ. When a packet arrives, you know your value so you and XOR it with the incoming value and derive the value at the other end. Jim Fleming http://www.RepliGate.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 08:53:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NGrT2Q020204 for ; Wed, 23 Jan 2002 08:53:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NGrTfs020203 for ipng-dist; Wed, 23 Jan 2002 08:53:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NGrQ2Q020196 for ; Wed, 23 Jan 2002 08:53:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27918 for ; Wed, 23 Jan 2002 08:53:32 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23745 for ; Wed, 23 Jan 2002 08:53:32 -0800 (PST) Received: from repligate (as1-163.chi.il.dial.anet.com [198.92.156.163]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0NGrUAM013040 for ; Wed, 23 Jan 2002 10:53:30 -0600 (CST) Message-ID: <0acd01c1a42e$94623700$8328fea9@repligate> From: "Jim Fleming" To: Subject: Fw: draft-ietf-dnsop-dontpublish-unreachable-02.txt Date: Wed, 23 Jan 2002 08:54:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Larson, Matt" To: Sent: Wednesday, January 23, 2002 7:50 AM Subject: RE: draft-ietf-dnsop-dontpublish-unreachable-02.txt > > a very rough draft for IPv6 counterpart is attached. > > please let me > > know if you want to integrate two it one, or want to handle them > > separately. > > We're in the process of adding IPv6 support to the com/net/org registry. We > are currently planning on disallowing name servers (i.e., glue AAAA records) > containing IPv4-mapped or IPv4-compatible addresses. This plan would be in > conflict with Itojun's proposed section 2.5, which allows IPv4-compatible > addresses (though I noticed the parenthetical caveat). > > I would grateful if some IPv6 experts weighed in on this issue. > > Thanks, > > Matt > -- > Matt Larson > VeriSign Global Registry Services ----- Original Message ----- From: "Jim Fleming" To: Cc: ; ; Sent: Sunday, January 20, 2002 9:27 PM Subject: http://www.opensrs.org/archives/discuss-list/0201/0806.html > http://www.opensrs.org/archives/discuss-list/0201/0806.html > Subject: RE: Re[2]: .biz Transfer Policy > From: Tindal, Richard (richard.tindal@neulevel.biz) > ---- > > You missed a key point which is that you are just contracted > for the Proof-of-Concept registry operations on the "toy", legacy, > IPv4 Internet. That just helps to develop a base of names for the > production services on the Next Generation Internet. The 8 top > TLDs are shown below. .BIZ has a ways to go before it can > compete with .COM. > > 0:201 .COM > 1:158 .CLUB > 2:143 .FAMILY > 3:219 .INFO > 4:58 .LLC > > 5:194 .INC > > 6:171 .TV > > 7:195 .CHURCH > > > > The Next Generation DNS architecture, focuses on reliability, > higher transaction rates, database driven updates and the ability > to have "flavors" of a TLD. As an example, we will be able to > have a .COM zone with or without the adult content names. > http://www.dot-biz.com/IPv8/Papers/LameDCache/ > > Keep everyone posted on your Proof-of-Concept progress. > The 8 TLDs above should be enough for now to test the > production-grade designs. > > Jim Fleming > 2002:[IPv4]:000X:03DB > http://www.IPv8.info > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 09:33:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NHXG2Q020264 for ; Wed, 23 Jan 2002 09:33:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NHXGAT020263 for ipng-dist; Wed, 23 Jan 2002 09:33:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NHXC2Q020256 for ; Wed, 23 Jan 2002 09:33:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13608 for ; Wed, 23 Jan 2002 09:33:18 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12489 for ; Wed, 23 Jan 2002 09:33:16 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0NHX3r16487; Wed, 23 Jan 2002 12:33:03 -0500 (EST) Message-Id: <200201231733.g0NHX3r16487@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Wed, 23 Jan 2002 08:13:44 PST." <2B81403386729140A3A899A8B39B046405DE67@server2000.arneill-py.sacramento.ca.us> Date: Wed, 23 Jan 2002 12:33:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have to disagree with Keith here. If a site wants to subnet, > they get a /48 and use the 16 SLA bits to subnet, that is what > they have been designed for. depends on what you mean by 'site', I suppose. Even if RFC 3177 is followed, I would not want the network to presume that a /64 net (such as might be assigned to a mobile network) should never be subnetted. there are good reasons to occasionally subnet a mobile network. and if we are not careful about how we allocate the top 64 bits we might need to allow subnetting of the lower 64 bits. In general, code and hardware should not presume much about the structure of addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 09:39:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NHdi2Q020296 for ; Wed, 23 Jan 2002 09:39:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NHdhrZ020295 for ipng-dist; Wed, 23 Jan 2002 09:39:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NHde2Q020288 for ; Wed, 23 Jan 2002 09:39:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13559 for ; Wed, 23 Jan 2002 09:39:46 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-071-214.vz.dsl.gtei.net [4.60.71.214]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02025 for ; Wed, 23 Jan 2002 10:39:42 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Jan 2002 09:40:18 -0800 From: "Tony Hain" To: "Michel Py" , "Keith Moore" , "Irina Dayal" Cc: Subject: RE: IPv6 Addr/Prefix clarification Date: Wed, 23 Jan 2002 09:39:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2B81403386729140A3A899A8B39B046405DE67@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, Keith is technically correct, a site may choose to subnet the low 64 bits. It might be unwise to do so, because they would be giving up the autoconfiguration & privacy capabilities, but that is their choice. They may also find acquiring routing hardware that works beyond the 64 bit prefix to be a challenge ... Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Michel Py > Sent: Wednesday, January 23, 2002 8:14 AM > To: Keith Moore; Irina Dayal > Cc: ipng@sunroof.eng.sun.com > Subject: RE: IPv6 Addr/Prefix clarification > > > >> Irina Dayal wrote: > > 1) Is it safe to assume that all IPv6 prefixes will be between > >> 16 and 64 bits long? > > > Keith Moore wrote: > > no. because nothing requires a site to use the lower 64 bits > > as an interface ID - a site is free to subnet that space if > > it wishes. > > I have to disagree with Keith here. If a site wants to subnet, > they get a /48 and use the 16 SLA bits to subnet, that is what > they have been designed for. > > Michel. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 09:44:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NHia2Q020325 for ; Wed, 23 Jan 2002 09:44:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NHiadS020324 for ipng-dist; Wed, 23 Jan 2002 09:44:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NHiW2Q020317 for ; Wed, 23 Jan 2002 09:44:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21700 for ; Wed, 23 Jan 2002 09:44:38 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21238 for ; Wed, 23 Jan 2002 10:44:37 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g0NHiX364413 for ; Thu, 24 Jan 2002 02:44:34 +0900 (JST) Date: Thu, 24 Jan 2002 02:44:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" In-Reply-To: <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 47 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 21 Jan 2002 17:22:08 -0800, >>>>> Bob Hinden said: > Instead of trying to reply each email I will attempt to summarize and > respond to the comments in the last set of email. > 1) Requirement level of SHOULD would make existing implementations > non-compliant. > I believe that the definition of SHOULD (see RFC2119) allows for alternate > behavior if there is a good reason for it. Yes, but the wording is not very clear at least to me. In particular it is not clear how to define the "good reason." But, > I think this can cover both > better algorithms for the selection of default routers and if the > implementation predates this spec. if this is the common interpretation of SHOULD and existing implementation (that seem to be "non-compliant" to the new spec) can just exit as is, I'm perhaps okay with it. > 2) Relationship of this change to Neighbor Discovery and Default Router > Preferences draft. Should they be combined? As for this I share the same opinion with Francis. I actually don't stick to combining the two drafts, but would like to point out that the described load-sharing can often be meaningless without the router preferences. There are of course some cases where the load-sharing is useful even without the preferences, as you mentioned in this thread. So, again, I guess my position depends on the constraint level of the SHOULD. If it is a strong constraint like I imagined, I disagree with the spec because the spec is not always useful. If it is not so strong (like you mentioned above), I'm perhaps okay because the spec is sometimes useful. > 3) General statement load-distribution is not predictable behavior and is > undesirable (e.g., using a single router until it fails is better). (just to make my position clear) I don't care about this argument.a JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 10:12:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NICV2Q020366 for ; Wed, 23 Jan 2002 10:12:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NICVO5020365 for ipng-dist; Wed, 23 Jan 2002 10:12:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NICS2Q020358 for ; Wed, 23 Jan 2002 10:12:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27635 for ; Wed, 23 Jan 2002 10:12:34 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23684 for ; Wed, 23 Jan 2002 11:12:33 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jan 2002 10:12:30 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE69@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification Thread-Index: AcGkNTmi2uVsKLygRNCjvNue3hQSdQAAVjig From: "Michel Py" To: "Tony Hain" , "Keith Moore" , "Irina Dayal" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0NICS2Q020359 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tony Hain wrote: > Keith is technically correct, a site may choose to subnet the low > 64 bits. It might be unwise to do so, because they would be giving > up the autoconfiguration & privacy capabilities, but that is their > choice. They may also find acquiring routing hardware that works > beyond the 64 bit prefix to be a challenge ... Correct. Technically, a lot is possible. However, I think we have to discourage people to subnet the IID. Doing so will also void things like EUI-64 and future 64-bit MAC addresses. Also, there are issues with link-local addresses. How good is it to have a link-local address if you can subnet it. That is why site local addresses are for, they use the 16 SLA bits. My reading of link-local addresses is that they can not be subnetted further than a /64. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 10:41:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NIf32Q020399 for ; Wed, 23 Jan 2002 10:41:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NIf3Mx020398 for ipng-dist; Wed, 23 Jan 2002 10:41:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NIf02Q020391 for ; Wed, 23 Jan 2002 10:41:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28266 for ; Wed, 23 Jan 2002 10:41:07 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23135 for ; Wed, 23 Jan 2002 11:41:06 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA09933; Wed, 23 Jan 2002 10:41:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0NIf5923494; Wed, 23 Jan 2002 10:41:05 -0800 X-mProtect: Wed, 23 Jan 2002 10:41:05 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpduBDeMD; Wed, 23 Jan 2002 10:41:03 PST Message-Id: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 10:40:49 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Informational RFC: Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-04.txt Pages : 79 Date : 15-Jan-02 This document will replace RFC2592 that is an Informational RFC. The changes from RFC2592 are listed in section 17 of the internet draft. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today on February 6, 2002. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 11:20:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NJKO2Q020499 for ; Wed, 23 Jan 2002 11:20:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NJKNfu020498 for ipng-dist; Wed, 23 Jan 2002 11:20:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NJKK2Q020491 for ; Wed, 23 Jan 2002 11:20:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26806 for ; Wed, 23 Jan 2002 11:20:25 -0800 (PST) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24445 for ; Wed, 23 Jan 2002 12:20:24 -0700 (MST) Received: from localhost (jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) with ESMTP id g0NJIIX19837; Wed, 23 Jan 2002 11:18:22 -0800 (PST) Date: Wed, 23 Jan 2002 11:18:18 -0800 (PST) From: JJ Behrens To: Tony Hain cc: Michel Py , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Tony Hain > Keith is technically correct, a site may choose to subnet the low 64 > bits. It might be unwise to do so, because they would be giving up the > autoconfiguration & privacy capabilities, but that is their choice. They > may also find acquiring routing hardware that works beyond the 64 bit > prefix to be a challenge ... Please forgive me for being a newbie, but it seems wise to allow subnetting of the lower 64 bits. Afterall, it would be terrible if my dialup ISP assigned a /64 to me, and I had to rely on some IPv6 mythical NAT to do subnetting! A /64 is really quite a lot of address space to subnet; without the ability to subnet, a /64 seems wasteful. In response to the address autoconfiguration using MAC addresses argument, address autoconfiguration can be done using something other than the MAC address in those circumstances. The fact that neighbor solicitations are used to verify the uniqueness of tentative addresses is proof enough that MAC addresses were never meant to be the end all and be all of address autoconfiguration. -jj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 14:22:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NMMK2Q020765 for ; Wed, 23 Jan 2002 14:22:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NMMKB2020764 for ipng-dist; Wed, 23 Jan 2002 14:22:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NMMH2Q020757 for ; Wed, 23 Jan 2002 14:22:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03657 for ; Wed, 23 Jan 2002 14:22:24 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-071-214.vz.dsl.gtei.net [4.60.71.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24244 for ; Wed, 23 Jan 2002 15:22:22 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Jan 2002 14:22:55 -0800 From: "Tony Hain" To: "JJ Behrens" Cc: "Michel Py" , "Keith Moore" , "Irina Dayal" , Subject: RE: IPv6 Addr/Prefix clarification Date: Wed, 23 Jan 2002 14:22:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JJ, This argument comes up frequently from people that are looking at IPv6 for the first time. First, ignore the number of bits for the moment and look at the differences between the versions. In IPv4, your ISP allocates a host address, while in IPv6 the allocation is a subnet at a minimum, and should be a block of subnets in the general case. Since the dial allocation is a subnet, there is no requirement to use NAT, when a simple layer-2 bridge will do the job. There is also a concept frequently referred to as multi-link subnets, which differs from a layer-2 bridge only in the fact that forwards based on layer-3 packets rather than layer-2 frames, but considers all interfaces to be part of the same logical layer-3 subnet. Using either of these technologies you will be able to have a substantial number of nodes connected through a dial link. Now as for the number of bits, there are several capabilities that have been built based on the availability of 64 bits for the interface id. Auto-configuration based on EUI64/48 mac is just the first. Privacy (RFC 3041) requires a large number of bits to avoid collisions; automated allocation of multicast addresses (draft-ietf-ipngwg-uni-based-mcast-03.txt) needs space to divide the group space by prefix; and ISATAP (draft-ietf-ngtrans-isatap-02.txt) uses the space to encode a tunnel endpoint for non-multicast IPv4 infrastructures. Others may show up to solve specific problems, so trying to be too conservative with bits is actually wasteful in terms of time and flexibility of deployments. I hope this helps, Tony > -----Original Message----- > From: JJ Behrens [mailto:jj@nttmcl.com] > Sent: Wednesday, January 23, 2002 11:18 AM > To: Tony Hain > Cc: Michel Py; Keith Moore; Irina Dayal; ipng@sunroof.eng.sun.com > Subject: RE: IPv6 Addr/Prefix clarification > > > > From: Tony Hain > > Keith is technically correct, a site may choose to subnet the low 64 > > bits. It might be unwise to do so, because they would be > giving up the > > autoconfiguration & privacy capabilities, but that is their > choice. They > > may also find acquiring routing hardware that works beyond > the 64 bit > > prefix to be a challenge ... > > Please forgive me for being a newbie, but it seems wise to allow > subnetting of the lower 64 bits. Afterall, it would be terrible if my > dialup ISP assigned a /64 to me, and I had to rely on some > IPv6 mythical > NAT to do subnetting! > > A /64 is really quite a lot of address space to subnet; without the > ability to subnet, a /64 seems wasteful. In response to the address > autoconfiguration using MAC addresses argument, address > autoconfiguration > can be done using something other than the MAC address in those > circumstances. The fact that neighbor solicitations are used > to verify the > uniqueness of tentative addresses is proof enough that MAC > addresses were > never meant to be the end all and be all of address autoconfiguration. > > -jj > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 14:39:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NMd52Q020800 for ; Wed, 23 Jan 2002 14:39:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NMd5PV020799 for ipng-dist; Wed, 23 Jan 2002 14:39:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NMd22Q020792 for ; Wed, 23 Jan 2002 14:39:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02559 for ; Wed, 23 Jan 2002 14:39:09 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04974 for ; Wed, 23 Jan 2002 15:39:08 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jan 2002 14:39:06 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification Thread-Index: AcGkQw5CJxOTxJSNTZSmzWO6NIbXvAAGqe4A From: "Michel Py" To: "JJ Behrens" , "Tony Hain" Cc: "Keith Moore" , "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0NMd22Q020793 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > JJ Behrens wrote: > Please forgive me for being a newbie, but it seems wise to > allow subnetting of the lower 64 bits. Afterall, it would > be terrible if my dialup ISP assigned a /64 to me, and I > had to rely on some IPv6 mythical NAT to do subnetting! I don't think this will happen. IPv6 ISPs currently assign /48 prefixes (see www.freenet6.net for example) which gives you 65536 subnets to play. Besides, doing subnets on a dial-up connection looks rather overkill to me. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 23 18:20:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0O2Ki2Q021000 for ; Wed, 23 Jan 2002 18:20:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0O2KhIb020999 for ipng-dist; Wed, 23 Jan 2002 18:20:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0O2Kd2Q020992 for ; Wed, 23 Jan 2002 18:20:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11699 for ; Wed, 23 Jan 2002 18:20:47 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03078 for ; Wed, 23 Jan 2002 19:20:45 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:d4d0:c731:c8ce:7d72]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g0O2Ki367211 for ; Thu, 24 Jan 2002 11:20:44 +0900 (JST) Date: Thu, 24 Jan 2002 11:20:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 23 Jan 2002 10:40:49 -0800, >>>>> Bob Hinden said: > This is a IPv6 working group last call for comments on advancing the > following document as an Informational RFC: Thanks for the announcement. Here is a tiny (and perhaps trivial) correction: > This document will replace RFC2592 that is an Informational RFC. The > changes from RFC2592 are listed in section 17 of the internet draft. These "RFC2592" should be "RFC2292", of course. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 24 05:08:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OD802Q021691 for ; Thu, 24 Jan 2002 05:08:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OD80Sk021690 for ipng-dist; Thu, 24 Jan 2002 05:08:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OD7u2Q021683 for ; Thu, 24 Jan 2002 05:07:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20034 for ; Thu, 24 Jan 2002 05:07:58 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25107 for ; Thu, 24 Jan 2002 05:07:52 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA04924; Thu, 24 Jan 2002 14:07:35 +0100 Received: from dhcp222-2.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32426 from ; Thu, 24 Jan 2002 14:07:29 +0100 Message-Id: <3C500710.B2025CBF@hursley.ibm.com> Date: Thu, 24 Jan 2002 14:07:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michel Py Cc: JJ Behrens , Tony Hain , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification References: <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nevertheless, it is not architecturally forbidden to subnet at /124 if you really want to - but doing so at /48 is more likely to be supported by all products. If I was an implementor, I certainly wouldn't worry if a /124 prefix kicked me onto a slow path, as long as prefixes from /3 to /64 were handled optimally. Brian Michel Py wrote: > > > JJ Behrens wrote: > > Please forgive me for being a newbie, but it seems wise to > > allow subnetting of the lower 64 bits. Afterall, it would > > be terrible if my dialup ISP assigned a /64 to me, and I > > had to rely on some IPv6 mythical NAT to do subnetting! > > I don't think this will happen. IPv6 ISPs currently assign > /48 prefixes (see www.freenet6.net for example) which gives > you 65536 subnets to play. Besides, doing subnets on a dial-up > connection looks rather overkill to me. > > Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 24 06:07:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OE7s2Q021851 for ; Thu, 24 Jan 2002 06:07:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OE7sXG021850 for ipng-dist; Thu, 24 Jan 2002 06:07:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OE7p2Q021843 for ; Thu, 24 Jan 2002 06:07:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02204 for ; Thu, 24 Jan 2002 06:07:57 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA13341 for ; Thu, 24 Jan 2002 06:07:57 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11187; Thu, 24 Jan 2002 09:07:55 -0500 Date: Thu, 24 Jan 2002 09:07:55 -0500 (EST) From: Jim Bound To: ipng@sunroof.eng.sun.com Subject: Last Issue for Base API Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, This is the last issue for the base api . We will send in final draft for INfo RFC annouce from the chairs. The only change will be to add Jack McCann as co-author to the base API current draft spec. This request is out of scope for this API. It could be an extension to the Advanced API possibly. I will send in new ID and to Steve and Bob to send ton IESG for INFO RFC Last Call. Thanks to the entire working group and the hard work and collaboration of the IEEE . This has been a longgggggggggggggg process. /jim > > >Date: Mon, 17 Dec 2001 09:08:32 -1000 (HST) > > >From: Antonio Querubin > > >To: Bob Hinden > > >cc: > > >Subject: Re: IPv6 w.g. Last Call on "Basic Socket Interface > > Extensions for > > > IPv6" > > >Sender: owner-ipng@sunroof.eng.sun.com > > > > > >On Tue, 11 Dec 2001, Bob Hinden wrote: > > > > > > > This is a IPv6 working group last call for comments on > > advancing the > > > > following document as an Informational RFC: > > > > > > > > Title : Basic Socket Interface Extensions for IPv6 > > > > Author(s) : R. Gilligan, S. Thomson, J. > > Bound, W. Stevens > > > > Filename : draft-ietf-ipngwg-rfc2553bis-04.txt > > > > Pages : 32 > > > > Date : 27-Nov-01 > > > > > > > > This document will replace RFC2553 that is currently an > > Informational > > > > RFC. The changes from RFC2553 are listed on pages 29 and > > 30 of the draft. > > > > > > > > Please send substantive comments to the ipng mailing > > list, and minor > > > > editorial comments to the authors. This last call period > > will end two > > > > weeks from today on December 26, 2001. > > > > > > > > Bob Hinden / Steve Deering > > > > > >This may be a bit late but I do think that the API should > > address better > > >compatibility with IPv4 multicast. There was some > > discussion earlier this > > >year about this but no consensus was reached other than that > > it should be > > >fixed. > > > > > >The problem I think would be helped if, for the purposes of this API, > > >section 3.7 was extended to optionally allow for a pseudo IPv4-mapped > > >multicast address. I'm suggesting adding two sentences to > > paragraph 2 of > > >section 3.7: > > > > > >"These addresses can be generated automatically by the getaddrinfo() > > >function, when the specified host has only IPv4 addresses > > (as described in > > >Section 6.1 and 6.2). For the purposes of this API, the > > allowed range of > > > may be extended beyond that defined in RFC > > 2373 to also > > >include multicast addresses. The resulting mapped address should be > > >treated as a multicast address." > > > > > >This addition is motivated by one of the design > > considerations of the API: > > > > > >" - Where possible, applications should be able to use this > > > API to interoperate with both IPv6 and IPv4 hosts. > > Applications > > > should not need to know which type of host they are > > > communicating with." > > > > > >And further down we have: > > > > > >"Because of the importance of providing IPv4 compatibility > > in the API, > > >these extensions are explicitly designed to operate on machines that > > >provide complete support for both IPv4 and IPv6." > > > > > > > > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 24 09:08:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OH8D2Q023007 for ; Thu, 24 Jan 2002 09:08:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OH8CpT023006 for ipng-dist; Thu, 24 Jan 2002 09:08:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OH892Q022999 for ; Thu, 24 Jan 2002 09:08:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04188 for ; Thu, 24 Jan 2002 09:08:15 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28253 for ; Thu, 24 Jan 2002 09:08:14 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0OH7a531864; Thu, 24 Jan 2002 18:07:36 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA09303; Thu, 24 Jan 2002 18:07:36 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0OH7ag09770; Thu, 24 Jan 2002 18:07:36 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201241707.g0OH7ag09770@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Last Issue for Base API In-reply-to: Your message of Thu, 24 Jan 2002 09:07:55 EST. Date: Thu, 24 Jan 2002 18:07:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: This is the last issue for the base api .... => so This shan't be considered as unfair to ask that the base API document is published "not after" the advanced API document? (there is a current WG last call on the advanced API, basic API seems to be ready for an IETF last call) Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 24 16:47:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0P0kx2Q023593 for ; Thu, 24 Jan 2002 16:46:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0P0kxoN023592 for ipng-dist; Thu, 24 Jan 2002 16:46:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0P0ku2Q023585 for ; Thu, 24 Jan 2002 16:46:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24787 for ; Thu, 24 Jan 2002 16:47:02 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12813 for ; Thu, 24 Jan 2002 17:47:00 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA13251; Thu, 24 Jan 2002 16:47:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0P0kx423923; Thu, 24 Jan 2002 16:46:59 -0800 X-mProtect: Thu, 24 Jan 2002 16:46:59 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGB4CqE; Thu, 24 Jan 2002 16:46:57 PST Message-Id: <4.3.2.7.2.20020124164024.02e17e00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 16:45:51 -0800 To: "Jim Fleming" From: Bob Hinden Subject: Jim Fleming's off topic postings to ipng mailing list Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mr. Fleming, The ipng mailing list is for the use of the IETF's IPv6 working group. The chairs of the IPv6 working group believe that many of your recent postings to the ipng mailing list have been off topic and are disruptive to the work of the working group. Your posts have included topics that are not within scope of the working group and others that provide incorrect information about IPv6. If you can not keep your postings within the scope of the working group mailing list, we will instruct the list administrator to block your posts to the mailing list. Regards, Bob Hinden & Steve Deering IPv6 working group chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 24 16:51:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0P0pI2Q023649 for ; Thu, 24 Jan 2002 16:51:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0P0pIHT023648 for ipng-dist; Thu, 24 Jan 2002 16:51:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0P0pE2Q023641 for ; Thu, 24 Jan 2002 16:51:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11472 for ; Thu, 24 Jan 2002 16:51:20 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07432 for ; Thu, 24 Jan 2002 17:51:20 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA13534; Thu, 24 Jan 2002 16:51:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0P0pIh30231; Thu, 24 Jan 2002 16:51:18 -0800 X-mProtect: Thu, 24 Jan 2002 16:51:18 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0FOPKG; Thu, 24 Jan 2002 16:51:16 PST Message-Id: <4.3.2.7.2.20020124165004.024155b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 16:50:56 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Bob Hinden Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the correction. My error in the announcement. Bob At 06:20 PM 1/23/2002, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Wed, 23 Jan 2002 10:40:49 -0800, > >>>>> Bob Hinden said: > > > This is a IPv6 working group last call for comments on advancing the > > following document as an Informational RFC: > >Thanks for the announcement. Here is a tiny (and perhaps trivial) >correction: > > > This document will replace RFC2592 that is an Informational RFC. The > > changes from RFC2592 are listed in section 17 of the internet draft. > >These "RFC2592" should be "RFC2292", of course. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 25 02:42:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PAgo2Q024502 for ; Fri, 25 Jan 2002 02:42:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PAgoeM024501 for ipng-dist; Fri, 25 Jan 2002 02:42:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PAgl2Q024494 for ; Fri, 25 Jan 2002 02:42:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02307 for ; Fri, 25 Jan 2002 02:42:53 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16946 for ; Fri, 25 Jan 2002 02:42:21 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0PAkc807448; Fri, 25 Jan 2002 17:46:38 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" In-Reply-To: <4.3.2.7.2.20020122164737.025e7b78@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020122164737.025e7b78@mailhost.iprg.nokia.com> <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2002 17:46:38 +0700 Message-ID: <7446.1011955598@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 22 Jan 2002 17:02:47 -0800 From: Bob Hinden Message-ID: <4.3.2.7.2.20020122164737.025e7b78@mailhost.iprg.nokia.com> | I think there are two cases. One is where there are two routers that | provide equivalent service. The other is where the are two or more routers | that have different characteristics (performance, connectivity, etc.). In | the first case the proposed load sharing mechanism is fine. In the second | case the router preferences is useful. Sure. | I think that the first case is very common so it is worthwhile to keep the | documents separate. Ah, I think I see the trap. You're concerned about the router end of things, I'm concerned about the hosts. There's no way a random host implementation can know which kind of environment it is about to be thrust into - it has no idea at all (without router preferences) whether the two routers sending RA's are in any way equivalent. A host that implements load sharing, and doesn't implement router preferences, is simply a disaster in your above 2nd scenario. | I think in practice both will be implemented and used as needed. Neither | is very complicated. There is even a rumor that one company is already | shipping router preferences :-) I have no doubts that router vendors will ship router preferences. That's not what I'm concerned with. I'm concerned that host implementors implement it, or that they don't implement load sharing. That is, a host that simply picks one default router, and sticks with it as long as it is functional (until NUD says go elsewhere) I can cope with. A host that implements router preferences I can cope with. A host that simply insists on picking any random router that is sending RAs and sends packets at it, and distributes its load, I cannot cope with - that combination must not be allowed to happen. | p.s. I don't really care too much about this (one or two documents) as long | as we get the mechanisms. If we get both mechanisms, actually implemented in hosts, that's just fine. If we get Router Prefs as a PS, and require its implemenation in hosts, then that's also fine. If your doc says "MUST NOT implement unless router prefs is also implemented", then that's fine as well. There are lots of ways forward here - just the one your previous message suggested, where load sharing is a PS expected to become the default on all hosts, and Router Prefs is a random option that some people might happen to choose to implement, is the worse possible scenario - worse than having neither of them. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 25 03:03:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PB312Q024550 for ; Fri, 25 Jan 2002 03:03:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PB2x90024549 for ipng-dist; Fri, 25 Jan 2002 03:02:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PB2u2Q024542 for ; Fri, 25 Jan 2002 03:02:56 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14924 for ; Fri, 25 Jan 2002 03:03:00 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11508 for ; Fri, 25 Jan 2002 03:02:54 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0PB4k807475; Fri, 25 Jan 2002 18:04:46 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Michel Py , JJ Behrens , Tony Hain , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: <3C500710.B2025CBF@hursley.ibm.com> References: <3C500710.B2025CBF@hursley.ibm.com> <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2002 18:04:46 +0700 Message-ID: <7473.1011956686@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 24 Jan 2002 14:07:28 +0100 From: Brian E Carpenter Message-ID: <3C500710.B2025CBF@hursley.ibm.com> | Nevertheless, it is not architecturally forbidden to subnet at /124 | if you really want to No, and it can be a good thing to do - if I have a lot of P2P links that I am going to number as 1 and 2 at the two ends (for lots of reasons I don't want unnumbered most times) then they're going to be 1 and 2 (a /126) whatever the length of the prefix - just a different number of padding 0's. If I have just a couple of dozen of them, then sure, burning numbers out of the subnet number space between /48 and /64 should be fine. But if I have hundreds, or perhaps even tens of thousands, then using some of those 62 padding 0's to number all of these P2P's, and consuming just one subnet number for the lot of them makes a lot of sense. | - but doing so at /48 is more likely to be | supported by all products. All lengths should be supported in some sense by all products. | If I was an implementor, I certainly | wouldn't worry if a /124 prefix kicked me onto a slow path, That would depend upon who I expected to be selling to. If the product is aimed at backbone providers, then sure - but if it is aimed at dialup access providers, who want a uniquely numbered P2P for each customer (even if only a subset are connected at once - and separate from the number actually allocated for the customer's internal use) then I think I'd be supporting long prefixes well (such things don't need to be nearly as fast as forwarding in backbones, but they shouldn't be absurdly slow either). | as long as prefixes from /3 to /64 were handled optimally. Forget that /3 as well, between /0 and /64 probably. While we currently assume that /3 is the format designator, who knows what it will be in the future - routers should not know it exists. They shouldn't actually know anything other than 128 as an address counter (other than for auto-conf, which routers will rarely do, and except as they are configured, of course). The answer to the original question is that nothing should assume anything about the internal structure of the 128 bits, except where actually required by some standard (such as auto-conf). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 25 07:04:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PF4B2Q025286 for ; Fri, 25 Jan 2002 07:04:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PF4Boj025285 for ipng-dist; Fri, 25 Jan 2002 07:04:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PF482Q025278 for ; Fri, 25 Jan 2002 07:04:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16345 for ; Fri, 25 Jan 2002 07:04:13 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04772 for ; Fri, 25 Jan 2002 07:04:12 -0800 (PST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA03518 for ; Fri, 25 Jan 2002 15:07:35 GMT Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA22884 for ; Fri, 25 Jan 2002 15:04:16 GMT Date: Fri, 25 Jan 2002 15:04:11 +0000 (GMT) From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" In-Reply-To: <7446.1011955598@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 25 Jan 2002, Robert Elz wrote: > I have no doubts that router vendors will ship router preferences. That's > not what I'm concerned with. I'm concerned that host implementors implement > it, or that they don't implement load sharing. That is, a host that simply > picks one default router, and sticks with it as long as it is functional > (until NUD says go elsewhere) I can cope with. A host that implements router > preferences I can cope with. A host that simply insists on picking any > random router that is sending RAs and sends packets at it, and distributes its > load, I cannot cope with - that combination must not be allowed to happen. I share Robert and Francis' view. There is also the possibility that misconfigured hosts will send RAs; having these targetted by load sharing hosts will only add to the pain of such events. > If we get both mechanisms, actually implemented in hosts, that's just fine. > If we get Router Prefs as a PS, and require its implemenation in hosts, then > that's also fine. If your doc says "MUST NOT implement unless router > prefs is also implemented", then that's fine as well. I would assume a reasonable mode of working is to only load share between routers of equal preference, rather than some "random" algorithm picking routers weighted by preference. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 25 14:16:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PMG92Q025769 for ; Fri, 25 Jan 2002 14:16:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PMG8w8025768 for ipng-dist; Fri, 25 Jan 2002 14:16:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PMG32Q025761 for ; Fri, 25 Jan 2002 14:16:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20934 for ; Fri, 25 Jan 2002 14:16:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18545 for ; Fri, 25 Jan 2002 15:16:09 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16063; Fri, 25 Jan 2002 17:16:05 -0500 (EST) Message-Id: <200201252216.RAA16063@ietf.org> To: IETF-Announce: ; Cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Support for IPv6 in SDP to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 25 Jan 2002 17:16:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the Multiparty Multimedia Session Control Working Group to consider Support for IPv6 in SDP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 8, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 26 11:35:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0QJZs2Q027182 for ; Sat, 26 Jan 2002 11:35:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0QJZsF3027181 for ipng-dist; Sat, 26 Jan 2002 11:35:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0QJZp2Q027174 for ; Sat, 26 Jan 2002 11:35:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10378 for ; Sat, 26 Jan 2002 11:35:54 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20763 for ; Sat, 26 Jan 2002 12:35:53 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Sat, 26 Jan 2002 11:35:51 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C27E@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGlj8D5RIfp+1LkSd28Fr5gKtuq/QBDizzQ From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 To: "Robert Elz" , "Brian E Carpenter" Cc: "JJ Behrens" , "Tony Hain" , "Keith Moore" , "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0QJZp2Q027175 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, >> Brian E Carpenter wrote: >> Nevertheless, it is not architecturally forbidden to subnet at >> /124 if you really want to > Robert Elz wrote: > No, and it can be a good thing to do No, but I am not so sure about it being a good thing. > - if I have a lot of P2P links that I am going to number as 1 and > 2 at the two ends (for lots of reasons I don't want unnumbered most > times) > If I have just a couple of dozen of them, then sure, burning numbers > out of the subnet number space between /48 and /64 should be fine. > But if I have hundreds, or perhaps even tens of thousands, then using > some of those 62 padding 0's to number all of these P2P's, and > consuming just one subnet number for the lot of them makes a lot of > sense. Id does make sense in IPv4. However, IPv6 has been designed with an explicit trade-off between simplicity and allocation efficiency. Let me make a comparison with Novell IPX: an IPX address is 80 bits, which are 32 bits for the network, and 48 bits for the host (actually, the MAC address most of the time). So, a /32 in IPX would be the equivalent of a /64 in IPv6 (vaguely). There is a Novell animal called the IPX internal network, which is basically a loopback interface that is routable. I have never heard anyone complaining that the IPX internal net, which uses an entire "subnet" for only one network address, was a problem because it was wasting address space. > The answer to the original question is that nothing should assume > anything about the internal structure of the 128 bits, except where > actually required by some standard (such as auto-conf). I concur that it would not be wise to assume anything, but saving IPv6 addresses does not strike me as good idea if it brings more complexity and does not bring anything else than allocation efficiency. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 27 09:13:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0RHDO2Q028607 for ; Sun, 27 Jan 2002 09:13:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0RHDOrg028606 for ipng-dist; Sun, 27 Jan 2002 09:13:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0RHDL2Q028599 for ; Sun, 27 Jan 2002 09:13:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06599 for ; Sun, 27 Jan 2002 09:13:34 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29540 for ; Sun, 27 Jan 2002 09:13:33 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0RHCxU07003; Sun, 27 Jan 2002 19:12:59 +0200 Date: Sun, 27 Jan 2002 19:12:59 +0200 (EET) From: Pekka Savola To: iesg@ietf.org cc: mmusic@ietf.org, , Subject: Re: Last Call: Support for IPv6 in SDP to Proposed Standard In-Reply-To: <200201252216.RAA16063@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 25 Jan 2002, The IESG wrote: > The IESG has received a request from the Multiparty Multimedia Session > Control Working Group to consider Support for IPv6 in SDP > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by February 8, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt In the draft: --8<-- 5. Example SDP description with IPv6 addresses The following is an example SDP description using the above ABNF for IPv6 addresses. In particular, the origin, URI, and connection fields contain IPv6 addresses. The URI contains an IPv4 compatible IPv6 address. v=0 o=nasa1 971731711378798081 0 IN IP6 2201:056D::112E:144A:1E24 s=(Almost) live video feed from Mars-II sattelite u=http://[::FFFF:10.2.12.126]/marsII p=+1 713 555 1234 c=IN IP6 FF00:03AD::7F2E:172A:1E24 t=3338481189 3370017201 m=audio 6000 RTP/AVP 2 a=rtpmap:2 G726-32/8000 m=video 6024 RTP/AVP 107 a=rtpmap:107 H263-1998/90000 --8<-- There are several issues with this: 1) I don't think it's good practise to use these addresses in an example, I'd rather use: - 3FFE:FFFF::112E:144A:1E24 (as 2201 TLA hasn't been assigned yet and we don't know if there would be some special meaning for it in the future) - FF0E:03AD::7F2E:172A:1E24 (global, not reserved scope) 2) s/The URI contains an IPv4 compatible IPv6 address/The URI contains an IPv4-mapped address/ in the header, or change u=. 3) IMO, it's a bit questionable to use IPv4-mapped addresses like this anyway. IPv4-mapped addresses should only be used (apart from e.g. SIIT definition) as a node's internal representation for IPv4 address; for better compatibility, the node should use: u=http://10.2.12.126/marsII (this way the receiving IPv6 node can decide the mechanism to reach the IPv4-address; that is, if u= can contain either IPv4 or IPv6 address) Also: --8<-- IP6-multicast = hexpart [ ":" IP4-multicast ] "/" ttl [ "/" integer ] ; IPv6 address starting with FF00 --8<-- 1) 'ttl' is not defined anywhere? (rather obvious though); (_TTL_ is not defined in IPv6 anyway, though.) 2) IPv6-multicast address does not need to start with FF00; anything beginning with FF is syntactically ok. 3) The full list of ABNF notations could be split to "normative" and "informative" (e.g. of the latter, in this context, IP4-address, b1, b4, perhaps others), but that's a matter of opinion/clarity I guess. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 27 15:47:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0RNlv2Q029037 for ; Sun, 27 Jan 2002 15:47:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0RNlvhR029036 for ipng-dist; Sun, 27 Jan 2002 15:47:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0RNlq2Q029026 for ; Sun, 27 Jan 2002 15:47:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19739 for ; Sun, 27 Jan 2002 15:48:04 -0800 (PST) Received: from palach.okri.hr ([213.191.152.180]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27210 for ; Sun, 27 Jan 2002 15:48:03 -0800 (PST) Received: from localhost (gandalf@localhost) by palach.okri.hr (8.11.1/8.11.1) with ESMTP id g0RNmtx77383 for ; Mon, 28 Jan 2002 00:48:56 +0100 (CET) (envelope-from gandalf@palach.okri.hr) Date: Mon, 28 Jan 2002 00:48:55 +0100 (CET) From: Vladimir Woelfl To: Subject: Addressing Space & Implementation in real world In-Reply-To: <200201200524.g0K5OuPW012962@sunroof.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At first I would like to apologizee if i'm off topic, or my question is not in accordance with the mailing list... I have been acquainted with ipng/ipv6 through BSD UNIX systems, namely FreeBSD, OpenBSD and some part Linux... If there is information on the Web concerning my question, please just direct me, so i would not waste your time. The question is: How is planned organization of IPNG addressing space, what will happen with my current IPv4 address network, and how could i start fully using IPv6 features of my server machine. As it is, probably, here in Croatia, I suspect if there are any networking-responsible people aware of IPv6, so, may I build an IPv6-in-IPv4 tunnel from my box to IPv6 Bone? Thank you, and please accept my apologies for eventual incorrect using of keywords. Vladimir Woelfl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 27 23:22:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0S7M32Q029650 for ; Sun, 27 Jan 2002 23:22:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0S7M3qJ029649 for ipng-dist; Sun, 27 Jan 2002 23:22:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0S7Lx2Q029642 for ; Sun, 27 Jan 2002 23:22:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12718 for ; Sun, 27 Jan 2002 23:22:11 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA09447 for ; Mon, 28 Jan 2002 00:22:10 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0S7M1v12898; Mon, 28 Jan 2002 09:22:02 +0200 Date: Mon, 28 Jan 2002 09:22:01 +0200 (EET) From: Pekka Savola To: Vladimir Woelfl cc: ipng@sunroof.eng.sun.com Subject: Re: Addressing Space & Implementation in real world In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Jan 2002, Vladimir Woelfl wrote: > How is planned organization of IPNG addressing space, what will happen > with my current IPv4 address network, and how could i start fully using > IPv6 features of my server machine. As it is, probably, here in Croatia, I > suspect if there are any networking-responsible people aware of IPv6, so, > may I build an IPv6-in-IPv4 tunnel from my box to IPv6 Bone? > > Thank you, and please accept my apologies for eventual incorrect using of > keywords. 6bone@isi.edu is a better place for queries like this. You may find the website http://www.6bone.net enlightening. At least, you can trivially use the mechanism "6to4" mentioned there to get IPv6 connectivity. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 28 01:05:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0S9502Q029880 for ; Mon, 28 Jan 2002 01:05:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0S94xkb029879 for ipng-dist; Mon, 28 Jan 2002 01:04:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0S94s2Q029872 for ; Mon, 28 Jan 2002 01:04:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13090 for ; Mon, 28 Jan 2002 01:05:11 -0800 (PST) From: Laurent.Thiebaut@alcatel.fr Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07270 for ; Mon, 28 Jan 2002 01:05:10 -0800 (PST) Received: from frmail14.netfr.alcatel.fr (frmail14.netfr.alcatel.fr [155.132.251.14]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA19825; Mon, 28 Jan 2002 10:04:09 +0100 (MET) Subject: Re: Last Call: Support for IPv6 in SDP to Proposed Standard To: Seancolson@yahoo.com, Gonzalo.camarillo@ericsson.com, mmusic@ietf.org, ipng@sunroof.eng.sun.com Date: Mon, 28 Jan 2002 10:04:06 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL14/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 01/28/2002 10:04:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk May be I have missed something, but does the proposal allow a DSTM node to propose an IPV4 and an IPV6 @ for the "Connection data" address? Another way of expressing my question, does the proposal cope with a host offering to its peer to dialog either in IPV4 or in IPV6 for the exchange of the media content? Thanks in advance for the clarification Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- The IESG on 25/01/2002 23:16:05 Please respond to iesg@ietf.org To: IETF-Announce: ; cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com(bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: Last Call: Support for IPv6 in SDP to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control Working Group to consider Support for IPv6 in SDP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 8, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From heartwave94@yahoo.co.kr Mon Jan 28 02:25:20 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SAPJ2Q000134 for ; Mon, 28 Jan 2002 02:25:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16826 for ; Mon, 28 Jan 2002 02:25:36 -0800 (PST) From: heartwave94@yahoo.co.kr Received: from localhost.localdomain ([128.134.65.135]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24973 for ; Mon, 28 Jan 2002 03:25:30 -0700 (MST) Received: from HOST (leto.kwangwoon.ac.kr [128.134.65.125]) by localhost.localdomain (8.11.0/8.11.0) with SMTP id c0KFuf928244 for ; Wed, 21 Jan 1998 00:56:46 +0900 Date: Wed, 21 Jan 1998 00:56:46 +0900 Message-Id: <199801201556.c0KFuf928244@localhost.localdomain> To: ipng-dist@sunroof.eng.sun.com Subject: new photos from my party! Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I``````````````````````````````````````````````````````"Y end From Postmaster@JRC.Co.Jp Mon Jan 28 02:28:51 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SASo2Q000160 for ; Mon, 28 Jan 2002 02:28:50 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04742 for ; Mon, 28 Jan 2002 02:29:08 -0800 (PST) From: Postmaster@JRC.Co.Jp Received: from inet11.jrc.co.jp (inet11.jrc.co.jp [203.180.124.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14235 for ; Mon, 28 Jan 2002 02:29:06 -0800 (PST) Received: from gate1 by inet11.jrc.co.jp (8.9.3/3.7W) id TAA22317; Mon, 28 Jan 2002 19:29:01 +0900 (JST) Received: from jrcgw1 ([10.8.1.31]) by gate1.noc.jrc.co.jp; Mon, 28 Jan 2002 19:28:45 +0000 (JST) Received: from localhost by jrcgw1.noc.jrc.co.jp (8.9.3/3.7WSaTaMa99081014) id TAA06195; Mon, 28 Jan 2002 19:28:45 +0900 (JST) Date: Mon, 28 Jan 2002 19:28:45 +0900 (JST) Message-Id: <200201281028.TAA06195@jrcgw1.noc.jrc.co.jp> To: ipng-dist@sunroof.eng.sun.com Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our virus check system has detected a virus WORM_MYPARTY.A in your mail traffic on 01/28/2002 19:28:42+09:00. (Attachment file is removed for safe) From PDBH961A-SA@pdb.sbs.de Mon Jan 28 02:29:42 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SATf2Q000170 for ; Mon, 28 Jan 2002 02:29:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09266 for ; Mon, 28 Jan 2002 02:29:59 -0800 (PST) Received: from nixpbe.pdb.sbs.de (nixpbe.pdb.sbs.de [192.109.2.33]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07022 for ; Mon, 28 Jan 2002 03:29:57 -0700 (MST) Received: from lila.pdb.sbs.de ([129.103.103.103]) by nixpbe.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g0SATv832333 for ; Mon, 28 Jan 2002 11:29:57 +0100 Received: from pdbh961a.pdb.sbs.de (pdbh961a.pdb.sbs.de [194.138.21.236]) by lila.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g0SATuj18974 for ; Mon, 28 Jan 2002 11:29:56 +0100 Received: by pdbh961a.pdb.sbs.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 11:29:55 +0100 Message-ID: From: System Attendant To: "'ipng-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 11:29:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = heartwave94@yahoo.co.kr Recipient(s) = ipng-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 11:29:51 Action on virus found: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has Deleted it. Warning to recipient. ScanMail detected a virus in an email attachment. 01/28/200211:29 AM [www.myparty.yahoo.com/Deleted] new photos from my party! heartwave94@yahoo.co.kr From owner-ipng@sunroof.eng.sun.com Mon Jan 28 09:28:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHSE2Q001819 for ; Mon, 28 Jan 2002 09:28:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SHSEnB001818 for ipng-dist; Mon, 28 Jan 2002 09:28:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHS92Q001811 for ; Mon, 28 Jan 2002 09:28:10 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24055 for ; Mon, 28 Jan 2002 09:28:27 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11260 for ; Mon, 28 Jan 2002 09:28:25 -0800 (PST) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g0SHSM398843 for ; Tue, 29 Jan 2002 02:28:22 +0900 (JST) Date: Tue, 29 Jan 2002 02:28:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: Last Issue for Base API In-Reply-To: <200201241707.g0OH7ag09770@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200201241707.g0OH7ag09770@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 24 Jan 2002 18:07:36 +0100, >>>>> Francis Dupont said: > In your previous mail you wrote: > This is the last issue for the base api .... > => so This shan't be considered as unfair to ask that the base API > document is published "not after" the advanced API document? > (there is a current WG last call on the advanced API, basic API > seems to be ready for an IETF last call) Please explain, what is your intention of this comment? 1. mapped addresses for IPv4 multicast should be described in the basic API. 2. mapped addresses for IPv4 multicast should be described in the advanced API. 3. others. In any case, I don't think (at this moment) this is an objection to the last call for the advanced API...in fact, I don't want to make the advanced API spec a kitchen sink. Though people always try to introduce a new stuff that they think useful to an API spec, we should fix the spec somehow at some point. I'm willing to fix the advanced API spec if it has a bug, but (as I said in SLC) I won't introduce a new stuff to the API. (However, I don't argue that we should deal with this issue in the basic API spec. The basic API spec should also be in the freeze stage. I don't even not sure if we really need this new stuff, but if we do this, we should make a separate document IMHO.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 07:45:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TFjs2Q007102 for ; Tue, 29 Jan 2002 07:45:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFjsgb007101 for ipng-dist; Tue, 29 Jan 2002 07:45:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TFjm2Q007094 for ; Tue, 29 Jan 2002 07:45:49 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TFjvF07923; Tue, 29 Jan 2002 16:45:57 +0100 (MET) Date: Tue, 29 Jan 2002 16:42:24 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" To: Robert Elz Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7446.1011955598@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have no doubts that router vendors will ship router preferences. That's > not what I'm concerned with. I'm concerned that host implementors implement > it, or that they don't implement load sharing. That is, a host that simply > picks one default router, and sticks with it as long as it is functional > (until NUD says go elsewhere) I can cope with. A host that implements > router preferences I can cope with. A host that simply insists on picking > any random router that is sending RAs and sends packets at it, and > distributes its load, I cannot cope with - that combination must not be > allowed to happen. Hmm - I know of a large server vendor who has been spreading the load over multiple default routes for IPv4 for about 10 years. I guess the difference is that even with ICMP router discovery (RFC 1256) there is a preference field so the admins have a knob. Is it just the absense of such a knob to the administator that is lacking? Or is there a need to have a rich set of preferences? (RFC 1256 has 256 different values vs. router preferences has only 3 values). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 07:55:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TFtB2Q007287 for ; Tue, 29 Jan 2002 07:55:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFtBki007286 for ipng-dist; Tue, 29 Jan 2002 07:55:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TFt72Q007276 for ; Tue, 29 Jan 2002 07:55:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00681 for ; Tue, 29 Jan 2002 07:55:22 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAB18748 for ; Tue, 29 Jan 2002 08:55:21 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0TFtKC24426 for ; Tue, 29 Jan 2002 16:55:20 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Jan 29 16:55:18 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 16:55:18 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A975@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , Robert Elz Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" Date: Tue, 29 Jan 2002 16:54:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is it just the absense of such a knob to the administator > that is lacking? > Or is there a need to have a rich set of preferences? (RFC > 1256 has 256 > different values vs. router preferences has only 3 values). => My 2 cents on the preference values: It's not only that there is only 3 values, but that these values may be used across different administrative domains (multihomed hosts). They need to be consistently defined so 'good' in ISP X domain is roughly the same as 'good' in ISP Y's domain. How can we do that ? Maybe some concrete definitions ? Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 09:50:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THoZ2Q008227 for ; Tue, 29 Jan 2002 09:50:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0THoY6H008226 for ipng-dist; Tue, 29 Jan 2002 09:50:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THoU2Q008216 for ; Tue, 29 Jan 2002 09:50:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11414 for ; Tue, 29 Jan 2002 09:50:46 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00780 for ; Tue, 29 Jan 2002 10:50:45 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0THoiX4017335 for ; Tue, 29 Jan 2002 18:50:44 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jan 29 18:50:43 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 18:50:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4CF1B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Pekka Savola , iesg@ietf.org Cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com, seancolson@yahoo.com Subject: RE: Last Call: Support for IPv6 in SDP to Proposed Standard Date: Tue, 29 Jan 2002 18:50:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ' > 2) s/The URI contains an IPv4 compatible IPv6 address/The > URI contains an > IPv4-mapped address/ in the header, or change u=. => I believe this should be 'IPv4-mapped' > > 3) IMO, it's a bit questionable to use IPv4-mapped > addresses like this > anyway. IPv4-mapped addresses should only be used (apart > from e.g. SIIT > definition) as a node's internal representation for IPv4 > address; for > better compatibility, the node should use: > > u=http://10.2.12.126/marsII > => But this does not look like an IPv6 address for an IPv6-only node. The SIIT case you mentioned above is an example where this would not work. > (this way the receiving IPv6 node can decide the mechanism > to reach the > IPv4-address; that is, if u= can contain either IPv4 or > IPv6 address) => The 'network' must give an indication of the mechanism to be used. If you use NAT-PT then you'll always see IPv6 addresses, if you use SIIT then you will see the mapped addresses, which will dictate certain actions by the IPv6-only device. If the device is dual stacked, the network will still give the indication of whether: - IPv4 only is allowed. - IPv6 only are allowed. - Both IP stacks are alowed. This is implicit from, say: - the knowledge you receive from your default router - Whether you can get an address (similar to the point above) and other indications. So the point is, a host can't just decide in isolation about what mechanism has to be used, it needs indications from the network, and that is why presenting the address as a mapped address is needed. Hesham > > Also: > --8<-- > IP6-multicast = hexpart [ ":" IP4-multicast ] > "/" ttl [ "/" integer ] > ; IPv6 address starting with FF00 > --8<-- > > 1) 'ttl' is not defined anywhere? (rather obvious though); > (_TTL_ is not > defined in IPv6 anyway, though.) > > 2) IPv6-multicast address does not need to start with FF00; > anything > beginning with FF is syntactically ok. > > 3) The full list of ABNF notations could be split to "normative" and > "informative" (e.g. of the latter, in this context, > IP4-address, b1, b4, > perhaps others), but that's a matter of opinion/clarity I guess. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 10:17:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TIHk2Q008600 for ; Tue, 29 Jan 2002 10:17:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TIHkEr008599 for ipng-dist; Tue, 29 Jan 2002 10:17:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TIHh2Q008592 for ; Tue, 29 Jan 2002 10:17:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05261 for ; Tue, 29 Jan 2002 10:17:59 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10107 for ; Tue, 29 Jan 2002 11:17:58 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0TIHOp29528; Tue, 29 Jan 2002 20:17:24 +0200 Date: Tue, 29 Jan 2002 20:17:23 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: iesg@ietf.org, , , Subject: RE: Last Call: Support for IPv6 in SDP to Proposed Standard In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802D4CF1B@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 29 Jan 2002, Hesham Soliman (ERA) wrote: > > 3) IMO, it's a bit questionable to use IPv4-mapped > > addresses like this > > anyway. IPv4-mapped addresses should only be used (apart > > from e.g. SIIT > > definition) as a node's internal representation for IPv4 > > address; for > > better compatibility, the node should use: > > > > u=http://10.2.12.126/marsII > > > > => But this does not look like an IPv6 address > for an IPv6-only node. The SIIT case you > mentioned above is an example where this > would not work. See below. > > (this way the receiving IPv6 node can decide the mechanism > > to reach the > > IPv4-address; that is, if u= can contain either IPv4 or > > IPv6 address) I'll restate this: this depends on the definition of u=. If 'u' can have: 1) only IPv6 addresses, using mapped address is fine 2) either iPv6 or IPv4 address, IMO IPv4 should be used when _sending_ the packet We're arguing about point 2). My point is that if address can be either, some nodes [a dual stack] can receive values with u=[ipv4] _anyway_, and must be able to cope with them. > => The 'network' must give an indication > of the mechanism to be used. If you use > NAT-PT then you'll always see IPv6 > addresses, if you use SIIT then you will > see the mapped addresses, which will dictate > certain actions by the IPv6-only device. [snip rest] Yeah, but the draft isn't about what the packet will look like after it has been mangled by NAT-PT or SIIT -- what should be best when sent by some node. It's clear that if an IPv6-only node sees a packet, u= must be an IPv6 address of _some_ form (if it's supposed to be reachable). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 11:18:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TJIv2Q008776 for ; Tue, 29 Jan 2002 11:18:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TJIvw1008775 for ipng-dist; Tue, 29 Jan 2002 11:18:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TJIt2Q008768 for ; Tue, 29 Jan 2002 11:18:56 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0TJIwBT025413 for ; Tue, 29 Jan 2002 11:18:58 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0TJIwk9025412 for ipng@sunroof.eng.sun.com; Tue, 29 Jan 2002 11:18:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHGw2Q001662 for ; Mon, 28 Jan 2002 09:16:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19769 for ; Mon, 28 Jan 2002 09:17:15 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28132 for ; Mon, 28 Jan 2002 10:17:11 -0700 (MST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0SHH4h11173; Mon, 28 Jan 2002 11:17:04 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0SHH3u08932; Mon, 28 Jan 2002 11:17:03 -0600 (CST) Received: from lmf.ericsson.se (rmt160220.am.ericsson.se [138.85.160.220]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA13236; Mon, 28 Jan 2002 11:16:59 -0600 (CST) Message-ID: <3C558E9E.A8AE4BE4@lmf.ericsson.se> Date: Mon, 28 Jan 2002 19:47:10 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Laurent.Thiebaut@alcatel.fr CC: Seancolson@yahoo.com, Gonzalo.camarillo@ericsson.com, mmusic@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: Support for IPv6 in SDP to Proposed Standard References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, the draft allow to express an IPv6 address in SDP. Then, what you want to do with that, it's up to you. If you want to offer either an IPv6 address "OR" an IPv4 address for the media flow, I would use two m lines (one IPv4 and the other IPv6) grouped using FID. Regards, Gonzalo Laurent.Thiebaut@alcatel.fr wrote: > > May be I have missed something, but does the proposal allow a DSTM node to > propose an IPV4 and an IPV6 @ for the "Connection data" address? Another > way of expressing my question, does the proposal cope with a host offering > to its peer to dialog either in IPV4 or in IPV6 for the exchange of the > media content? > Thanks in advance for the clarification > Best regards > Laurent T. > --------------------------------------------------------------------------- > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > --------------------------------------------------------------------------- > > The IESG on 25/01/2002 23:16:05 > > Please respond to iesg@ietf.org > > > > To: IETF-Announce: ; > > cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com(bcc: > Laurent THIEBAUT/FR/ALCATEL) > > > > Subject: Last Call: Support for IPv6 in SDP to Proposed > Standard > > > The IESG has received a request from the Multiparty Multimedia Session > Control Working Group to consider Support for IPv6 in SDP > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by February 8, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 11:20:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TJKD2Q008793 for ; Tue, 29 Jan 2002 11:20:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TJKD0a008792 for ipng-dist; Tue, 29 Jan 2002 11:20:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TJKB2Q008785 for ; Tue, 29 Jan 2002 11:20:11 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0TJKEBT025421 for ; Tue, 29 Jan 2002 11:20:14 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0TJKEWO025420 for ipng@sunroof.eng.sun.com; Tue, 29 Jan 2002 11:20:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0T0Hd2Q004381 for ; Mon, 28 Jan 2002 16:17:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15739 for ; Mon, 28 Jan 2002 16:17:56 -0800 (PST) Received: from mail.thinkengine.net ([65.104.155.146]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29796 for ; Mon, 28 Jan 2002 17:17:55 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: IPv6 and mandatory UDP checksum Date: Mon, 28 Jan 2002 19:17:49 -0500 Message-ID: <9BD1DBD1EBDE0D4BAB8CD58E292F5C8A05D21D@thinkboss13.bos.thinkengine.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 and mandatory UDP checksum Thread-Index: AcGoWmJckKaPcfB7QrK2PUaKeFyajw== From: "Speciner, Michael" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0T0He2Q004382 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am transporting uncompressed voice data (G.711) using RTP/UDP/IP. I really don't care about errors, and in fact would rather use damaged data than have a completely missing packet, and so am not calculating a UDP checksum, instead setting the checksum to zero, as is legal in IPv4. In addition, I don't have the compute resources to calculate and/or check the checksum (whose computation includes the entire UDP payload) for all the voice channels I'm simultaneously dealing with. So what should I do if I want to use IPv6, which mandates UDP checksums and requires receivers to discard UDP packets without checksums (i.e. with zero checksum)? I assume that there is also a mandate to discard UDP packets whose checksum is wrong, although I don't see that explicitly in either the UDP or IPv6 RFCs. --ms >From RFC 2460: Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 11:49:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TJnO2Q009157 for ; Tue, 29 Jan 2002 11:49:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TJnOSW009156 for ipng-dist; Tue, 29 Jan 2002 11:49:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TJnK2Q009149 for ; Tue, 29 Jan 2002 11:49:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20453 for ; Tue, 29 Jan 2002 11:49:35 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08653 for ; Tue, 29 Jan 2002 12:49:34 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0TJnV630299; Tue, 29 Jan 2002 21:49:31 +0200 Date: Tue, 29 Jan 2002 21:49:31 +0200 (EET) From: Pekka Savola To: "Speciner, Michael" cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 and mandatory UDP checksum In-Reply-To: <9BD1DBD1EBDE0D4BAB8CD58E292F5C8A05D21D@thinkboss13.bos.thinkengine.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Jan 2002, Speciner, Michael wrote: > So what should I do if I want to use IPv6, which mandates UDP checksums > and requires receivers to discard UDP packets without checksums (i.e. > with zero checksum)? I assume that there is also a mandate to discard > UDP packets whose checksum is wrong, although I don't see that > explicitly in either the UDP or IPv6 RFCs. I'm can tell you the reason for the change: IP header checksum was removed in IPv6, and requiring checksumming in upper layer was required to partially compensate for the fact. Most often, the cost for checksum computation is rather low and errors happen quite infrequently, but I guess that's no consolation.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 12:33:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TKXo2Q009539 for ; Tue, 29 Jan 2002 12:33:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TKXo87009538 for ipng-dist; Tue, 29 Jan 2002 12:33:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TKXj2Q009531 for ; Tue, 29 Jan 2002 12:33:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07607 for ; Tue, 29 Jan 2002 12:33:56 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02945 for ; Tue, 29 Jan 2002 12:33:55 -0800 (PST) Received: from repligate (as1-29.chi.il.dial.anet.com [198.92.156.29]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0TKXqps023869; Tue, 29 Jan 2002 14:33:53 -0600 (CST) Message-ID: <0cec01c1a904$595ff9f0$8328fea9@repligate> From: "Jim Fleming" To: "Speciner, Michael" , References: <9BD1DBD1EBDE0D4BAB8CD58E292F5C8A05D21D@thinkboss13.bos.thinkengine.net> Subject: Re: IPv6 and mandatory UDP checksum Date: Tue, 29 Jan 2002 12:34:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Speciner, Michael" > > So what should I do if I want to use IPv6, which mandates UDP checksums Note, checksums can be a confusing area because historically TCP and UDP checksums also cover part of the IP header bits. This is a layer violation, but people do not care. The IPv4 header checksum just covers the IPv4 header. Using an IPv4 Routing Header to tow the bloated IPv6 Headers around can get you a checksum. Do you use a 2002 prefix ? Jim Fleming http://www.RepliGate.net http://www.Lame-D.com http://www.dot-biz.com/IPv8/Papers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 13:40:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TLeo2Q009877 for ; Tue, 29 Jan 2002 13:40:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TLenMK009876 for ipng-dist; Tue, 29 Jan 2002 13:40:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TLei2Q009866 for ; Tue, 29 Jan 2002 13:40:45 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TLerF14814; Tue, 29 Jan 2002 22:40:53 +0100 (MET) Date: Tue, 29 Jan 2002 22:37:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 and mandatory UDP checksum To: "Speciner, Michael" Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9BD1DBD1EBDE0D4BAB8CD58E292F5C8A05D21D@thinkboss13.bos.thinkengine.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So what should I do if I want to use IPv6, which mandates UDP checksums > and requires receivers to discard UDP packets without checksums (i.e. > with zero checksum)? I assume that there is also a mandate to discard > UDP packets whose checksum is wrong, although I don't see that > explicitly in either the UDP or IPv6 RFCs. I've been told there is supposed to be work on something called UDP-lite in TSVWG - the ability to have the UDP checksum cover some number of bytes in the packet (like e.g. just the pseudo-header, UDP header, and RTP header). But I don't know how this work is progressing. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 14:02:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TM2t2Q010111 for ; Tue, 29 Jan 2002 14:02:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TM2t1H010110 for ipng-dist; Tue, 29 Jan 2002 14:02:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TM2p2Q010103 for ; Tue, 29 Jan 2002 14:02:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02685 for ; Tue, 29 Jan 2002 14:03:08 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00189 for ; Tue, 29 Jan 2002 14:03:07 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0TM35r09499 for ; Tue, 29 Jan 2002 16:03:05 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 16:03:05 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A0311A0C6@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'ipng@sunroof.eng.sun.com'" Subject: FW: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-udp-lite-00.txt Date: Tue, 29 Jan 2002 16:02:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1A910.B6FF4C80" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1A910.B6FF4C80 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A910.B6FF4C80" ------_=_NextPart_001_01C1A910.B6FF4C80 Content-Type: text/plain; charset="iso-8859-1" Hi, For status of UDP-Lite, see bottom of this e-mail. Thanks. Regards, Pete > So what should I do if I want to use IPv6, which mandates UDP checksums > and requires receivers to discard UDP packets without checksums (i.e. > with zero checksum)? I assume that there is also a mandate to discard > UDP packets whose checksum is wrong, although I don't see that > explicitly in either the UDP or IPv6 RFCs. I've been told there is supposed to be work on something called UDP-lite in TSVWG - the ability to have the UDP checksum cover some number of bytes in the packet (like e.g. just the pseudo-header, UDP header, and RTP header). But I don't know how this work is progressing. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------------------------------------------ -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, January 28, 2002 7:03 AM Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-udp-lite-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : The UDP Lite Protocol Author(s) : L. Larzon, M. Degermark Filename : draft-ietf-tsvwg-udp-lite-00.txt Pages : 8 Date : 25-Jan-02 This document describes the UDP Lite protocol, which is similar to classic UDP [RFC-768], but can also serve applications which in lossy network environments prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP Lite is semantically identical to classic UDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-lite-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-udp-lite-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-udp-lite-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C1A910.B6FF4C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-udp-lite-00.txt

Hi,

For status of UDP-Lite, see bottom of this e-mail. = Thanks.

Regards,

Pete


> So what should I do if I want to use IPv6, which = mandates UDP checksums
> and requires receivers to discard UDP packets = without checksums (i.e.
> with zero checksum)? I assume that there is = also a mandate to discard
> UDP packets whose checksum is wrong, although I = don't see that
> explicitly in either the UDP or IPv6 = RFCs.

I've been told there is supposed to be work on = something called UDP-lite
in TSVWG - the ability to have the UDP checksum = cover some number of bytes
in the packet (like e.g. just the pseudo-header, UDP = header, and RTP header).
But I don't know how this work is = progressing.

  Erik

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------------------------------------------

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Monday, January 28, 2002 7:03 AM
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D = ACTION:draft-ietf-tsvwg-udp-lite-00.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Transport Area = Working Group Working Group of the IETF.

        Title           : = The UDP Lite Protocol
        Author(s)       : L. Larzon, M. = Degermark
        Filename        : = draft-ietf-tsvwg-udp-lite-00.txt
        Pages           : = 8
        Date    =         : 25-Jan-02
       =20
This document describes the UDP Lite protocol, which = is similar to
classic UDP [RFC-768], but can also serve = applications which in lossy
network environments prefer to have partially = damaged payloads
delivered rather than discarded.  If this = feature is not used, UDP
Lite is semantically identical to classic = UDP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-u= dp-lite-00.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-ietf-tsvwg-udp-lite-00.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-tsvwg-udp-lite-00.txt".
       =20
NOTE:   The mail server at ietf.org can = return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, = insert the command "ENCODING mime" before the = "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
        exhibit = different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have = been split
        up into = multiple messages), so check your local documentation on
        how to = manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C1A910.B6FF4C80-- ------_=_NextPart_000_01C1A910.B6FF4C80 Content-Type: message/rfc822 To: Subject: Date: Mon, 28 Jan 2002 09:25:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1A910.B6FF4C80" ------_=_NextPart_002_01C1A910.B6FF4C80 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C1A910.B6FF4C80" ------_=_NextPart_003_01C1A910.B6FF4C80 Content-Type: text/plain ------_=_NextPart_003_01C1A910.B6FF4C80 Content-Type: text/html

  ------_=_NextPart_003_01C1A910.B6FF4C80-- ------_=_NextPart_002_01C1A910.B6FF4C80 Content-Type: application/octet-stream; name="ATT94075" Content-Disposition: attachment; filename="ATT94075" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020125134428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-udp-lite-00.txt ------_=_NextPart_002_01C1A910.B6FF4C80 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-tsvwg-udp-lite-00"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1A910.B6FF4C80-- ------_=_NextPart_000_01C1A910.B6FF4C80-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 29 20:18:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0U4IR2Q011124 for ; Tue, 29 Jan 2002 20:18:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0U4IR9B011123 for ipng-dist; Tue, 29 Jan 2002 20:18:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0U4IM2Q011116 for ; Tue, 29 Jan 2002 20:18:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11752 for ; Tue, 29 Jan 2002 20:18:38 -0800 (PST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02648 for ; Tue, 29 Jan 2002 20:18:38 -0800 (PST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g0U4IXR13192; Tue, 29 Jan 2002 23:18:33 -0500 Message-Id: <200201300418.g0U4IXR13192@minotaur.nge.isi.edu> To: Erik Nordmark cc: "Speciner, Michael" , ipng@sunroof.eng.sun.com Reply-To: mankin@isi.edu Subject: Re: IPv6 and mandatory UDP checksum In-reply-to: Your message of Tue, 29 Jan 2002 22:37:14 +0100. Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Jan 2002 23:18:33 -0500 From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-tsvwg-udplite-00.txt The working group agreed to a working group last call, about to start. Allison > > > > So what should I do if I want to use IPv6, which mandates UDP checksums > > and requires receivers to discard UDP packets without checksums (i.e. > > with zero checksum)? I assume that there is also a mandate to discard > > UDP packets whose checksum is wrong, although I don't see that > > explicitly in either the UDP or IPv6 RFCs. > > I've been told there is supposed to be work on something called UDP-lite > in TSVWG - the ability to have the UDP checksum cover some number of bytes > in the packet (like e.g. just the pseudo-header, UDP header, and RTP header). > But I don't know how this work is progressing. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 30 08:22:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UGLx2Q013228 for ; Wed, 30 Jan 2002 08:21:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UGLwIh013227 for ipng-dist; Wed, 30 Jan 2002 08:21:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UGLs2Q013220 for ; Wed, 30 Jan 2002 08:21:55 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08812 for ; Wed, 30 Jan 2002 08:22:13 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18310 for ; Wed, 30 Jan 2002 08:22:11 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0UGLg329696; Wed, 30 Jan 2002 17:21:43 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA28519; Wed, 30 Jan 2002 17:21:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0UGLgg39843; Wed, 30 Jan 2002 17:21:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201301621.g0UGLgg39843@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Robert Elz , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" In-reply-to: Your message of Tue, 29 Jan 2002 16:42:24 +0100. Date: Wed, 30 Jan 2002 17:21:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Is it just the absense of such a knob to the administator that is lacking? => the knob. Or is there a need to have a rich set of preferences? (RFC 1256 has 256 different values vs. router preferences has only 3 values). => no, I believe we can live with only 3 values. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 30 17:26:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V1QJ2Q014720 for ; Wed, 30 Jan 2002 17:26:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0V1QJ5p014719 for ipng-dist; Wed, 30 Jan 2002 17:26:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V1QF2Q014712 for ; Wed, 30 Jan 2002 17:26:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23094 for ; Wed, 30 Jan 2002 17:26:35 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24773 for ; Wed, 30 Jan 2002 17:26:35 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27075; Wed, 30 Jan 2002 17:26:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0V1QYw12002; Wed, 30 Jan 2002 17:26:34 -0800 X-mProtect: Wed, 30 Jan 2002 17:26:34 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOZ1FvM; Wed, 30 Jan 2002 17:26:31 PST Message-Id: <4.3.2.7.2.20020130171849.0258bcb8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jan 2002 17:25:35 -0800 To: "Hesham Soliman (ERA)" From: Bob Hinden Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6A975@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, >=> My 2 cents on the preference values: >It's not only that there is only 3 values, but >that these values may be used across different >administrative domains (multihomed hosts). They >need to be consistently defined so 'good' in >ISP X domain is roughly the same as 'good' >in ISP Y's domain. How can we do that ? >Maybe some concrete definitions ? It's a hard problem. Routing has exactly the same problem and I don't think they ever came up with an automatic way to deal with this. The best that may be possible is to have a manual mapping between domain X and domain Y. This was one of the reasons why there is a separation between intra-domain and inter-domain routing. There wasn't a good way to do an automatic mapping between metrics from one domain to another. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 00:05:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V85i2Q015290 for ; Thu, 31 Jan 2002 00:05:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0V85i2l015289 for ipng-dist; Thu, 31 Jan 2002 00:05:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V85e2Q015282 for ; Thu, 31 Jan 2002 00:05:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13515 for ; Thu, 31 Jan 2002 00:05:53 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06523 for ; Thu, 31 Jan 2002 01:05:53 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0V85qX4028664 for ; Thu, 31 Jan 2002 09:05:52 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Jan 31 09:05:50 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 09:05:50 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D0DD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Pekka Savola , "Hesham Soliman (ERA)" Cc: iesg@ietf.org, mmusic@ietf.org, ipng@sunroof.eng.sun.com, seancolson@yahoo.com Subject: RE: Last Call: Support for IPv6 in SDP to Proposed Standard Date: Thu, 31 Jan 2002 09:05:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think Gonzalo already answered this. Further clarifications are below, but we might be getting off-topic for this draft. > (this way the receiving IPv6 node can decide the mechanism > > > to reach the > > > IPv4-address; that is, if u= can contain either IPv4 or > > > IPv6 address) > > I'll restate this: this depends on the definition of u=. > > If 'u' can have: > 1) only IPv6 addresses, using mapped address is fine > 2) either iPv6 or IPv4 address, IMO IPv4 should be used > when _sending_ > the packet => See below. > > We're arguing about point 2). My point is that if address > can be either, > some nodes [a dual stack] can receive values with u=[ipv4] > _anyway_, and > must be able to cope with them. => I was not conerned about dual stacked nodes, they'll obviously understand. Some systems require IPv6 only though, Others might prefer to run IPv6 only for simplicity, so you shouldn't assume dual stacks all the time. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 00:08:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V88b2Q015445 for ; Thu, 31 Jan 2002 00:08:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0V88bEc015444 for ipng-dist; Thu, 31 Jan 2002 00:08:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V88W2Q015434 for ; Thu, 31 Jan 2002 00:08:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11791 for ; Thu, 31 Jan 2002 00:08:47 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24649 for ; Thu, 31 Jan 2002 01:08:09 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0V898W22737; Thu, 31 Jan 2002 15:09:10 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Keith Moore" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: <2B81403386729140A3A899A8B39B046406C27E@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046406C27E@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jan 2002 15:09:08 +0700 Message-ID: <22735.1012464548@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 26 Jan 2002 11:35:51 -0800 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046406C27E@server2000.arneill-py.sacramento.ca.us> | I concur that it would not be wise to assume anything, but saving IPv6 | addresses does not strike me as good idea if it brings more complexity | and does not bring anything else than allocation efficiency. I probably wouldn't either, though we don't want to totally forget allocation efficiency - the way we make sure that IPv6 never runs out is to always make sure we justify every allocation (which doesn't mean organisations need to justify their need for a /48 - but I'd certainly be making any organisation asking for a 2nd one (in the same aggregatable block, I'm not talking about multi-connecting here) justify their use of the first /48 they were allocated before giving away another. But not adding any explicit length limits doesn't add complexity, it reduces it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 02:13:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VADa2Q016102 for ; Thu, 31 Jan 2002 02:13:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VADaFi016101 for ipng-dist; Thu, 31 Jan 2002 02:13:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VADP2Q015977 for ; Thu, 31 Jan 2002 02:13:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05490 for ; Thu, 31 Jan 2002 02:06:14 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23037 for ; Thu, 31 Jan 2002 03:06:13 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0VA6CC15257 for ; Thu, 31 Jan 2002 11:06:12 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 31 11:06:11 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 10:56:56 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D12C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" Date: Thu, 31 Jan 2002 11:05:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > >=> My 2 cents on the preference values: > >It's not only that there is only 3 values, but > >that these values may be used across different > >administrative domains (multihomed hosts). They > >need to be consistently defined so 'good' in > >ISP X domain is roughly the same as 'good' > >in ISP Y's domain. How can we do that ? > >Maybe some concrete definitions ? > > It's a hard problem. Routing has exactly the same problem > and I don't > think they ever came up with an automatic way to deal with > this. The best > that may be possible is to have a manual mapping between > domain X and > domain Y. This was one of the reasons why there is a > separation between > intra-domain and inter-domain routing. There wasn't a good > way to do an > automatic mapping between metrics from one domain to another. => I agree with your analysis and conclusion with one clarification: Two domains may decide to agree on certain mappings as long as they have control over the devices that receive this information. I.e. router_x and router_y. However, in this case we have a scenario where a 'host' is receiving the equivalent of link state information from 2 different routers that happened to be geographically adjacent. The 2 different domains may not even be aware of each others existence, let alone have some agreement. This is obviously a wireless case. I haven't been giving a lot of thought to a solution, but I can think of 2 possible options: 1.Have concrete definition of preferences and increase the ranges (from 3 to 100?) so that a host can roughly compare between two preferences from 2 routers in different domains. 2. Specify clearly in the draft that this solution is only useful for a host connected to 2 routers in the same administrative domain. At least in this case the host would know whether it should rely on the preference values or ignore them (presumably the host is aware that it's connected to different admin domains...somehow) 3. Have some way of showing the host that the two domains are in agreement about the meaning of the preferences. I'm leaning towards 2 above. I think it's the easiest way. Anyhow, other groups (seamoby) are considering capability discovery for routers and I suspect that there will be many more parameters to be added. To me, 'preference' seems to aggregate several parameters (huge!) without explicityly stating them and the weight of each parameter. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 08:37:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VGbU2Q019050 for ; Thu, 31 Jan 2002 08:37:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VGbUd2019049 for ipng-dist; Thu, 31 Jan 2002 08:37:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VGWj2Q019004 for ; Thu, 31 Jan 2002 08:33:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22087 for ; Thu, 31 Jan 2002 08:32:50 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03431 for ; Thu, 31 Jan 2002 09:32:49 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0VGRUp17875; Thu, 31 Jan 2002 11:27:31 -0500 (EST) Message-Id: <200201311627.g0VGRUp17875@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Keith Moore" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Thu, 31 Jan 2002 08:16:48 PST." <2B81403386729140A3A899A8B39B046405DE7F@server2000.arneill-py.sacramento.ca.us> Date: Thu, 31 Jan 2002 11:27:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is nothing that forbids subneting into the IID (although it would > be difficult to subnet smaller than /80), but don't you think that, in the > time being, it would be wise to stick to /64 unless we have a hell of a > good reason? I think it would be much wiser to NOT impose constraints on how people orgainze their networks until we have a hell of a good reason. e.g. If an ISP gives its customers /64s they should still be able to subnet. subnetting a /64 is a lot beter than NAT. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 08:21:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VGJE2Q018927 for ; Thu, 31 Jan 2002 08:19:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VGJEET018926 for ipng-dist; Thu, 31 Jan 2002 08:19:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VGH42Q018908 for ; Thu, 31 Jan 2002 08:17:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18678 for ; Thu, 31 Jan 2002 08:16:52 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24287 for ; Thu, 31 Jan 2002 09:16:50 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 08:16:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE7F@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGqLhAlLzWn0ogWRqKxDIiazGJz9gAQOPjg From: "Michel Py" To: "Robert Elz" Cc: "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Keith Moore" , "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0VGH52Q018911 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, >> Michel Py wrote: >> I concur that it would not be wise to assume anything, but saving IPv6 >> addresses does not strike me as good idea if it brings more complexity >> and does not bring anything else than allocation efficiency. > Robert Elz wrote: > I probably wouldn't either, though we don't want to totally forget > allocation efficiency - the way we make sure that IPv6 never runs out > is to always make sure we justify every allocation (which doesn't mean > organisations need to justify their need for a /48 - but I'd certainly be > making any organisation asking for a 2nd one (in the same aggregatable > block, I'm not talking about multi-connecting here) justify their use > of the first /48 they were allocated before giving away another. Concur. But let's get back where this thread was a few postings ago, which is subneting inside the IID. In the act of balancing complexity and allocation efficiency, do we say: 1. It is ok to use a /64 for loopbacks and point to point links in the sake of simplicity. 2. It is a waste to use a /64 for a loopback or a point-to-point link and therefore we should subnet the IID. My vote goes to 1. Large address space is not new. IPX has 32 network bits, (see my previous post about the IPX internal net); IPv6 has 64 network bits. I do not think we need more. Using a /64 for a loopback or a point-to-point is perfectly compatible with efficient allocation as well as simplicity. > But not adding any explicit length limits doesn't add complexity, it > reduces it. I have to disagree with you here. Although these were different times, addressing schemes such IPX, Appletalk phII and classful IP that had fixed boundaries were a lot simpler for most. In IPv6, there already are things (autoconf, privacy, EUI-64) that assume a /64 subnet size. There is nothing that forbids subneting into the IID (although it would be difficult to subnet smaller than /80), but don't you think that, in the time being, it would be wise to stick to /64 unless we have a hell of a good reason? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 09:16:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHGN2Q019271 for ; Thu, 31 Jan 2002 09:16:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VHGNBg019270 for ipng-dist; Thu, 31 Jan 2002 09:16:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHGJ2Q019263 for ; Thu, 31 Jan 2002 09:16:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10722 for ; Thu, 31 Jan 2002 09:16:35 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04080 for ; Thu, 31 Jan 2002 10:16:35 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 09:16:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE80@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGqdEoZNXeWfb2fSLCixkKZhnPgpAABf5mA From: "Michel Py" To: "Keith Moore" Cc: "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0VHGK2Q019264 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > Keith Moore wrote: > I think it would be much wiser to NOT impose constraints on how > people orgainze their networks until we have a hell of a good > reason. e.g. If an ISP gives its customers /64s they should still > be able to subnet. subnetting a /64 is a lot beter than NAT. I think that we have a hell of a good reason here, and that good reason is simplicity. Between: 1. Telling ISPs that they should give customers that want to subnet a /48. (or tell customers that want to subnet that, if they don't get a /48 from their ISP, they'd better shop somewhere else) and 2. Getting into subnetting of the IID with all its consequences like loss of autoconfig, loss of privacy and so on I say 1. is the path we must choose because it is the responsible thing to do. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 09:56:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHu02Q019474 for ; Thu, 31 Jan 2002 09:56:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VHtxMj019473 for ipng-dist; Thu, 31 Jan 2002 09:55:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHtt2Q019466 for ; Thu, 31 Jan 2002 09:55:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04805 for ; Thu, 31 Jan 2002 09:56:11 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06324 for ; Thu, 31 Jan 2002 10:56:11 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0VHodp27937; Thu, 31 Jan 2002 12:50:39 -0500 (EST) Message-Id: <200201311750.g0VHodp27937@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Thu, 31 Jan 2002 09:16:33 PST." <2B81403386729140A3A899A8B39B046405DE80@server2000.arneill-py.sacramento.ca.us> Date: Thu, 31 Jan 2002 12:50:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith, > > > Keith Moore wrote: > > I think it would be much wiser to NOT impose constraints on how > > people orgainze their networks until we have a hell of a good > > reason. e.g. If an ISP gives its customers /64s they should still > > be able to subnet. subnetting a /64 is a lot beter than NAT. > > I think that we have a hell of a good reason here, and that good > reason is simplicity. You're not arguing for simplicity, you're arguing for complexity and lack of flexibility. > Between: > > 1. Telling ISPs that they should give customers that want to subnet > a /48. (or tell customers that want to subnet that, if they don't > get a /48 from their ISP, they'd better shop somewhere else) It's one thing for us to tell ISPs how they should allocate addresses. It's quite another thing for them to do it. We don't know yet whether ISPs will follow these recommendations. And at least in the v4 internet, telling customers to shop elsewhere doesn't work - often they don't have viable alternatives. > and > > 2. Getting into subnetting of the IID with all its consequences > like loss of autoconfig, loss of privacy and so on > > I say 1. is the path we must choose because it is the responsible > thing to do. Where in the world did you get the idea that 'the responsible thing to do' is to place constraints on how sites can use their addresses? By allowing sites to subnet /64s we aren't forcing them to give up autoconfig, private addresses, etc... We're giving them - and the Internet in general - more flexibility. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 09:59:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHx92Q019497 for ; Thu, 31 Jan 2002 09:59:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VHx95f019496 for ipng-dist; Thu, 31 Jan 2002 09:59:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHx52Q019489 for ; Thu, 31 Jan 2002 09:59:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11144 for ; Thu, 31 Jan 2002 09:59:21 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14859 for ; Thu, 31 Jan 2002 10:59:20 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Jan 2002 09:59:35 -0800 From: "Tony Hain" To: "Michel Py" , "Keith Moore" Cc: "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Irina Dayal" , Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 09:58:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2B81403386729140A3A899A8B39B046405DE80@server2000.arneill-py.sacramento.ca.us> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > 1. Telling ISPs that they should give customers that want to subnet > a /48. (or tell customers that want to subnet that, if they don't > get a /48 from their ISP, they'd better shop somewhere else) We should also not forget to point out that they already have one or more /48's from the uncooperative ISP, simply by using 6to4. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 10:09:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VI9b2Q019684 for ; Thu, 31 Jan 2002 10:09:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VI9b89019683 for ipng-dist; Thu, 31 Jan 2002 10:09:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VI9X2Q019676 for ; Thu, 31 Jan 2002 10:09:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19259 for ; Thu, 31 Jan 2002 10:09:49 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20569 for ; Thu, 31 Jan 2002 11:09:48 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0VI4ap28120; Thu, 31 Jan 2002 13:04:36 -0500 (EST) Message-Id: <200201311804.g0VI4ap28120@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Michel Py" , "Keith Moore" , "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Thu, 31 Jan 2002 09:58:46 PST." Date: Thu, 31 Jan 2002 13:04:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 1. Telling ISPs that they should give customers that want to subnet > > a /48. (or tell customers that want to subnet that, if they don't > > get a /48 from their ISP, they'd better shop somewhere else) > > We should also not forget to point out that they already have one or > more /48's from the uncooperative ISP, simply by using 6to4. presuming, of course, that IPv4 service with a stable address is available at that time, and that the ISP doesn't filter 6to4 packets. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 10:12:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VICw2Q019730 for ; Thu, 31 Jan 2002 10:12:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VICwBr019729 for ipng-dist; Thu, 31 Jan 2002 10:12:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VICs2Q019722 for ; Thu, 31 Jan 2002 10:12:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01223 for ; Thu, 31 Jan 2002 10:13:11 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19720 for ; Thu, 31 Jan 2002 11:13:10 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Jan 2002 10:13:58 -0800 From: "Tony Hain" To: Cc: "Michel Py" , "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Irina Dayal" , Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 10:13:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200201311804.g0VI4ap28120@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In those cases Shipworm is the mechansim of choice. In any case we need to be forcing the system to provide uninhibited IPv6 service to the applications. If ISPs try to prevent that it will cost them effort, and eventually customers. Tony > -----Original Message----- > From: moore@cs.utk.edu [mailto:moore@cs.utk.edu] > Sent: Thursday, January 31, 2002 10:05 AM > To: Tony Hain > Cc: Michel Py; Keith Moore; Robert Elz; Brian E Carpenter; JJ Behrens; > Irina Dayal; ipng@sunroof.eng.sun.com > Subject: Re: IPv6 Addr/Prefix clarification > > > > > 1. Telling ISPs that they should give customers that want > to subnet > > > a /48. (or tell customers that want to subnet that, if they don't > > > get a /48 from their ISP, they'd better shop somewhere else) > > > > We should also not forget to point out that they already have one or > > more /48's from the uncooperative ISP, simply by using 6to4. > > presuming, of course, that IPv4 service with a stable address > is available > at that time, and that the ISP doesn't filter 6to4 packets. > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 10:27:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VIRD2Q019794 for ; Thu, 31 Jan 2002 10:27:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VIRDax019793 for ipng-dist; Thu, 31 Jan 2002 10:27:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VIR92Q019786 for ; Thu, 31 Jan 2002 10:27:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23006 for ; Thu, 31 Jan 2002 10:27:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23425 for ; Thu, 31 Jan 2002 10:27:25 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0VIHEp28331; Thu, 31 Jan 2002 13:17:14 -0500 (EST) Message-Id: <200201311817.g0VIHEp28331@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: moore@cs.utk.edu, "Michel Py" , "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Thu, 31 Jan 2002 10:13:09 PST." Date: Thu, 31 Jan 2002 13:17:14 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > presuming, of course, that IPv4 service with a stable address > > is available at that time, and that the ISP doesn't filter 6to4 packets. > > In those cases Shipworm is the mechansim of choice. no it's not, because shipworm doesn't provide stable addresses under these conditions either. and an ISP that filters 6to4 can also filter shipworm. > In any case we need > to be forcing the system to provide uninhibited IPv6 service to the > applications. If ISPs try to prevent that it will cost them effort, and > eventually customers. I don't know how much 'forcing' we can do, but providing customers with extra flexibility in how they assign addresses won't hurt. And while I would like to believe that ISPs that impair customers' ability to use the net will suffer, current experience doesn't bear that out. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 10:59:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VIxv2Q020175 for ; Thu, 31 Jan 2002 10:59:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VIxvto020174 for ipng-dist; Thu, 31 Jan 2002 10:59:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VIxr2Q020167 for ; Thu, 31 Jan 2002 10:59:53 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05197 for ; Thu, 31 Jan 2002 11:00:07 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19080 for ; Thu, 31 Jan 2002 11:00:06 -0800 (PST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-27.cisco.com [161.44.150.27]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20463; Thu, 31 Jan 2002 13:59:33 -0500 (EST) Message-Id: <4.3.2.7.2.20020131135324.03905440@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jan 2002 13:59:55 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Pre-pub version of DHCP -23 spec Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You can find a pre-publication version of the DHCPv6 (rev -23) spec at www.dhcp.org/dhcpv6-23 This rev has fixes made in response to comments received during the WG last call. I will post a diff of the -22 and -23 (doc source) later today, along with a summary of the changes. The changes are primarily editorial - I'll highlight the substantive changes in the summary. Unless there are significant objections, I expect to send the draft to the IETF for publication tomorrow (Fri 2/1) afternoon. - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 11:55:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VJtA2Q020297 for ; Thu, 31 Jan 2002 11:55:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VJtApP020296 for ipng-dist; Thu, 31 Jan 2002 11:55:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VJt72Q020289 for ; Thu, 31 Jan 2002 11:55:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15249 for ; Thu, 31 Jan 2002 11:55:22 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA09811 for ; Thu, 31 Jan 2002 12:55:21 -0700 (MST) Received: (qmail 26865 invoked from network); 31 Jan 2002 19:55:19 -0000 Received: from p508054c6.dip.t-dialin.net (HELO worker.muc.bieringer.de) (80.128.84.198) by mail.bieringer.de with SMTP; 31 Jan 2002 19:55:19 -0000 Date: Thu, 31 Jan 2002 20:55:16 +0100 From: Peter Bieringer cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification Message-ID: <38720000.1012506916@localhost> In-Reply-To: <22735.1012464548@brandenburg.cs.mu.OZ.AU> References: <2B81403386729140A3A899A8B39B046406C27E@server2000.arneill- py.sacramento.ca.us> <22735.1012464548@brandenburg.cs.mu.OZ.AU> X-Mailer: Mulberry/2.1.2 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On Thursday, January 31, 2002 03:09:08 PM +0700 Robert Elz wrote: > | I concur that it would not be wise to assume anything, but > saving IPv6 | addresses does not strike me as good idea if it > brings more complexity | and does not bring anything else than > allocation efficiency. > > I probably wouldn't either, though we don't want to totally forget > allocation efficiency - the way we make sure that IPv6 never runs > out is to always make sure we justify every allocation (which > doesn't mean organisations need to justify their need for a /48 - > but I'd certainly be making any organisation asking for a 2nd one > (in the same aggregatable block, If this will happen, which organisation would this be? Compared with current IPv4 /48 with the 16 bits for SLA is similar to a IPv4 Class A network. Which organisation (not ISPs) uses more than one Class A network *full* at the moment internally (means > 65k subnets)? People always ask for as much as address space as possible, but in IPv4 world it was more because of the number of clients and less the number of possible subnetworks (thinking in Class A space). Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 12:33:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VKXa2Q020380 for ; Thu, 31 Jan 2002 12:33:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VKXaWd020379 for ipng-dist; Thu, 31 Jan 2002 12:33:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VKXW2Q020372 for ; Thu, 31 Jan 2002 12:33:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23982 for ; Thu, 31 Jan 2002 12:33:47 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18714 for ; Thu, 31 Jan 2002 12:33:47 -0800 (PST) Received: from repligate (as1-188.chi.il.dial.anet.com [198.92.156.188]) by zeus.anet-chi.com (8.12.1/ANET Internet Solutions) with SMTP id g0VKVWww021739; Thu, 31 Jan 2002 14:31:32 -0600 (CST) Message-ID: <039001c1aa96$5fd9f360$8328fea9@repligate> From: "Jim Fleming" To: "Keith Moore" , "Tony Hain" Cc: , "Michel Py" , "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Irina Dayal" , References: <200201311817.g0VIHEp28331@astro.cs.utk.edu> Subject: Re: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 12:32:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Keith Moore" > > I don't know how much 'forcing' we can do, but providing customers with > extra flexibility in how they assign addresses won't hurt. > It sounds like IPv6 is just a redo of the "plastic", "toy", legacy IPv4 Internet. http://www.dot-biz.com/IPv8/Papers/VirtualVault/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 14:56:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VMuY2Q021210 for ; Thu, 31 Jan 2002 14:56:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VMuYT8021209 for ipng-dist; Thu, 31 Jan 2002 14:56:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VMuV2Q021202 for ; Thu, 31 Jan 2002 14:56:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02316 for ; Thu, 31 Jan 2002 14:56:46 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28275 for ; Thu, 31 Jan 2002 14:56:45 -0800 (PST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 14:56:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE81@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGqkbHK9BqQB4rHR76QezJgZPwuQQAF5cOw From: "Michel Py" To: "Peter Bieringer" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0VMuV2Q021203 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk folks, (I did a little inline regroup) >> Michel Py wrote: >> 1. Telling ISPs that they should give customers that want to subnet a >> /48. (or tell customers that want to subnet that, if they don't get a >> /48 from their ISP, they'd better shop somewhere else) > Tony Hain wrote: > We should also not forget to point out that they already have one or > more /48's from the uncooperative ISP, simply by using 6to4. Correct. These customers will also have one or more 6bone /48 blocks, so it is unlikely, IMHO, that they would even try to deal with a /64. >> Keith Moore wrote: >> presuming, of course, that IPv4 service with a stable address is >> available at that time, and that the ISP doesn't filter 6to4 packets. > Tony Hain wrote: > In those cases Shipworm is the mechansim of choice. In any case we need > to be forcing the system to provide uninhibited IPv6 service to the > applications. If ISPs try to prevent that it will cost them effort, > and eventually customers. Concur. > Keith Moore wrote: > By allowing sites to subnet /64s we aren't forcing them to give up > autoconfig, private addresses, etc... Would you educate me on how you do autoconfig, let's say, on a /85 ? >> Robert Elz wrote: >> I probably wouldn't either, though we don't want to totally forget >> allocation efficiency - the way we make sure that IPv6 never runs out >> is to always make sure we justify every allocation (which doesn't mean >> organisations need to justify their need for a /48 - >> but I'd certainly be making any organisation asking for a 2nd one (in >> the same aggregatable block, > Peter Bieringer wrote: > If this will happen, which organisation would this be? Compared with > current IPv4 /48 with the 16 bits for SLA is similar to a IPv4 Class A > network. > Which organisation (not ISPs) uses more than one Class A network *full* > at the moment internally (means > 65k subnets)? Perter is correct here. A handful, and these will not have too much trouble getting a bigger block. And they will not be too difficult to weed out. If McDonalds come saying "we need one more /48", maybe they need it. If Joe's Burgers comes saying he needs a /32, his request can be filed directly in the trashcan. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 16:07:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1107Z2Q021426 for ; Thu, 31 Jan 2002 16:07:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1107ZE2021425 for ipng-dist; Thu, 31 Jan 2002 16:07:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1107V2Q021418 for ; Thu, 31 Jan 2002 16:07:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11573 for ; Thu, 31 Jan 2002 16:07:47 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28249 for ; Thu, 31 Jan 2002 16:07:46 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g1107d901016; Thu, 31 Jan 2002 19:07:39 -0500 (EST) Message-Id: <200202010007.g1107d901016@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Peter Bieringer" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Thu, 31 Jan 2002 14:56:42 PST." <2B81403386729140A3A899A8B39B046405DE81@server2000.arneill-py.sacramento.ca.us> Date: Thu, 31 Jan 2002 19:07:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Keith Moore wrote: > > By allowing sites to subnet /64s we aren't forcing them to give up > > autoconfig, private addresses, etc... > > Would you educate me on how you do autoconfig, let's say, on a /85 ? you don't. a site that chooses to subnet below /64 is inherently choosing not to use stateless autoconfig. but this is a choice for that site to make, not for us to make on that site's behalf. you still haven't given a single argument in favor of not allowing sites to subnet below /64. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 16:29:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g110TG2Q021630 for ; Thu, 31 Jan 2002 16:29:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g110TGhd021629 for ipng-dist; Thu, 31 Jan 2002 16:29:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g110TD2Q021622 for ; Thu, 31 Jan 2002 16:29:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16969 for ; Thu, 31 Jan 2002 16:29:28 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19808 for ; Thu, 31 Jan 2002 16:29:28 -0800 (PST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 16:29:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE84@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGqtIxtV+tkD++tQaudGVAUo8uq7AAAhOmw From: "Michel Py" To: "Keith Moore" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g110TD2Q021623 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Keith Moore wrote: >>> By allowing sites to subnet /64s we aren't forcing them to give up >>> autoconfig, private addresses, etc... >> Michel Py wrote: >> Would you educate me on how you do autoconfig, let's say, on a /85 ? > Keith Moore wrote: > you don't. a site that chooses to subnet below /64 is inherently > choosing not to use stateless autoconfig. but this is a choice for > that site to make, not for us to make on that site's behalf. This is direct contradiction with what you wrote before. > you still haven't given a single argument in favor of not allowing > sites to subnet below /64. Yes, I have. And you haven't yet given a single good reason why a site should subnet below /64, when a site should, indeed, use the SLA bits (means SITE LEVEL AGGREGATOR) which have been designed for that very purpose. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 16:57:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g110v02Q021758 for ; Thu, 31 Jan 2002 16:57:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g110v0Rr021757 for ipng-dist; Thu, 31 Jan 2002 16:57:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g110uu2Q021750 for ; Thu, 31 Jan 2002 16:56:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08107 for ; Thu, 31 Jan 2002 16:57:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28620 for ; Thu, 31 Jan 2002 16:57:12 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g110v9901281; Thu, 31 Jan 2002 19:57:09 -0500 (EST) Message-Id: <200202010057.g110v9901281@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Thu, 31 Jan 2002 16:29:27 PST." <2B81403386729140A3A899A8B39B046405DE84@server2000.arneill-py.sacramento.ca.us> Date: Thu, 31 Jan 2002 19:57:09 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>> Keith Moore wrote: > >>> By allowing sites to subnet /64s we aren't forcing them to give up > >>> autoconfig, private addresses, etc... > > >> Michel Py wrote: > >> Would you educate me on how you do autoconfig, let's say, on a /85 ? > > > Keith Moore wrote: > > you don't. a site that chooses to subnet below /64 is inherently > > choosing not to use stateless autoconfig. but this is a choice for > > that site to make, not for us to make on that site's behalf. > > This is direct contradiction with what you wrote before. no it's not. > > you still haven't given a single argument in favor of not allowing > > sites to subnet below /64. > > Yes, I have. And you haven't yet given a single good reason why a site > should subnet below /64, when a site should, indeed, use the SLA bits > (means SITE LEVEL AGGREGATOR) which have been designed for that very > purpose. A site should subnet below /64 if - for any reason - it doesn't have enough subnet bits above /64 and - for whatever reason - it can't get more address space by other means. Perhaps this will only happen if we fail to allocate prefixes efficiently, and/or if ISPs don't follow our recommendations. But if either of those does occur, it will make perfect sense to subnet below /64 - and it's certainly a lot saner than NAT. On the other hand, expecting that everything will go exactly as we've anticipated - when we don't even agree about how things will go - is utterly insane. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 17:06:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1116J2Q021783 for ; Thu, 31 Jan 2002 17:06:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1116JiS021782 for ipng-dist; Thu, 31 Jan 2002 17:06:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1116F2Q021775 for ; Thu, 31 Jan 2002 17:06:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11488 for ; Thu, 31 Jan 2002 17:06:31 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20225 for ; Thu, 31 Jan 2002 18:06:27 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Jan 2002 17:07:16 -0800 From: "Tony Hain" To: "Michel Py" , "Keith Moore" Cc: Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 17:06:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2B81403386729140A3A899A8B39B046405DE84@server2000.arneill-py.sacramento.ca.us> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You are both right and wrong... ;) We can never prevent a site from internally subnetting on any boundary it chooses, but we should be very clear about the consequences. At the same time we have to be consistent in our discussions with the rir's and providers about making sure sites have at least the options of /48 & /64, and that attempts to allocate less will result in ugly hacks that will be hard for them to maintain. The strongest reason to make this a hard architectural boundary is to simplify the dev/test/interoperability of the code for the platform vendors. Sites that accept a /64 are stuck with a single subnet, unless they have sufficient technical knowledge to break the architecture; and have the appropriate support from their platform vendors. We are not in a position to prevent architectural abuse (even in our documentation; see RFC3022), but we can set expectations and interoperability requirements. If a site receives a /64 from their provider, the simplest approach would be to bridge the environment. For those that want a more complex topology, they will be better-off to lobby their provider for more space. Given track records, this is likely to be possible for a simple matter of more money. For those who don't want to pay for address space, but do want to pay for the cost of local implementations which subnet longer than /64, they are free to do so. One might point out this is a false economy, but people don't always listen. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Michel Py > Sent: Thursday, January 31, 2002 4:29 PM > To: Keith Moore > Cc: ipng@sunroof.eng.sun.com > Subject: RE: IPv6 Addr/Prefix clarification > > > >>> Keith Moore wrote: > >>> By allowing sites to subnet /64s we aren't forcing them to give up > >>> autoconfig, private addresses, etc... > > >> Michel Py wrote: > >> Would you educate me on how you do autoconfig, let's say, > on a /85 ? > > > Keith Moore wrote: > > you don't. a site that chooses to subnet below /64 is inherently > > choosing not to use stateless autoconfig. but this is a choice for > > that site to make, not for us to make on that site's behalf. > > This is direct contradiction with what you wrote before. > > > you still haven't given a single argument in favor of not allowing > > sites to subnet below /64. > > Yes, I have. And you haven't yet given a single good reason why a site > should subnet below /64, when a site should, indeed, use the SLA bits > (means SITE LEVEL AGGREGATOR) which have been designed for that very > purpose. > > Michel. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 17:59:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g111xu2Q021850 for ; Thu, 31 Jan 2002 17:59:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g111xugW021849 for ipng-dist; Thu, 31 Jan 2002 17:59:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g111xq2Q021842 for ; Thu, 31 Jan 2002 17:59:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25296 for ; Thu, 31 Jan 2002 18:00:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29793 for ; Thu, 31 Jan 2002 19:00:07 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g11202901747; Thu, 31 Jan 2002 21:00:02 -0500 (EST) Message-Id: <200202010200.g11202901747@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: "Michel Py" , "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Thu, 31 Jan 2002 17:06:25 PST." Date: Thu, 31 Jan 2002 21:00:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We can never prevent a site from internally subnetting on any boundary > it chooses, but we should be very clear about the consequences. At the > same time we have to be consistent in our discussions with the rir's and > providers about making sure sites have at least the options of /48 & > /64, and that attempts to allocate less will result in ugly hacks that > will be hard for them to maintain. agree entirely. > The strongest reason to make this a hard architectural boundary is to > simplify the dev/test/interoperability of the code for the platform > vendors. I guess I'm arguing that we should make it clear to vendors that it's *not* reasonable to assume that nobody will ever need to subnet beyond /64. > Sites that accept a /64 are stuck with a single subnet, unless > they have sufficient technical knowledge to break the architecture and I'm arguing that the 64 bit boundary should not be a wired-in part of the architecture (just as in hindsight it turned out to be a bad idea to make class a/b/c boundaries a part of the v4 architecture) it's not just for sites - someday we may be forced to rethink allocation strategies in a way that gives sites less than /64. > If a site receives a /64 from their provider, the simplest approach > would be to bridge the environment. For those that want a more complex > topology, they will be better-off to lobby their provider for more > space. Given track records, this is likely to be possible for a simple > matter of more money. 'more money' is not always a simple matter - sometimes the difference is between being able to operate at all or not. > For those who don't want to pay for address space, > but do want to pay for the cost of local implementations which subnet > longer than /64, they are free to do so. One might point out this is a > false economy, but people don't always listen. and it's not always a false economy. it depends on the other factors. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 19:12:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g113Cg2Q022060 for ; Thu, 31 Jan 2002 19:12:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g113CgjI022059 for ipng-dist; Thu, 31 Jan 2002 19:12:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g113Cd2Q022052 for ; Thu, 31 Jan 2002 19:12:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10866 for ; Thu, 31 Jan 2002 19:12:54 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27272 for ; Thu, 31 Jan 2002 19:12:53 -0800 (PST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Thu, 31 Jan 2002 19:12:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046406C2B4@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGqvNH4/Li9blgoTPqkY6BLSHye2QAEVuMg From: "Michel Py" To: "Tony Hain" , "Keith Moore" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g113Cd2Q022053 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I fully concur with Tony and this should be the end of the thread. Michel. -----Original Message----- From: Tony Hain [SMTP:alh-ietf@tndh.net] Sent: Thursday, January 31, 2002 5:06 PM To: Michel Py; Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification You are both right and wrong... ;) We can never prevent a site from internally subnetting on any boundary it chooses, but we should be very clear about the consequences. At the same time we have to be consistent in our discussions with the rir's and providers about making sure sites have at least the options of /48 & /64, and that attempts to allocate less will result in ugly hacks that will be hard for them to maintain. The strongest reason to make this a hard architectural boundary is to simplify the dev/test/interoperability of the code for the platform vendors. Sites that accept a /64 are stuck with a single subnet, unless they have sufficient technical knowledge to break the architecture; and have the appropriate support from their platform vendors. We are not in a position to prevent architectural abuse (even in our documentation; see RFC3022), but we can set expectations and interoperability requirements. If a site receives a /64 from their provider, the simplest approach would be to bridge the environment. For those that want a more complex topology, they will be better-off to lobby their provider for more space. Given track records, this is likely to be possible for a simple matter of more money. For those who don't want to pay for address space, but do want to pay for the cost of local implementations which subnet longer than /64, they are free to do so. One might point out this is a false economy, but people don't always listen. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Michel Py > Sent: Thursday, January 31, 2002 4:29 PM > To: Keith Moore > Cc: ipng@sunroof.eng.sun.com > Subject: RE: IPv6 Addr/Prefix clarification > > > >>> Keith Moore wrote: > >>> By allowing sites to subnet /64s we aren't forcing them to give up > >>> autoconfig, private addresses, etc... > > >> Michel Py wrote: > >> Would you educate me on how you do autoconfig, let's say, > on a /85 ? > > > Keith Moore wrote: > > you don't. a site that chooses to subnet below /64 is inherently > > choosing not to use stateless autoconfig. but this is a choice for > > that site to make, not for us to make on that site's behalf. > > This is direct contradiction with what you wrote before. > > > you still haven't given a single argument in favor of not allowing > > sites to subnet below /64. > > Yes, I have. And you haven't yet given a single good reason why a site > should subnet below /64, when a site should, indeed, use the SLA bits > (means SITE LEVEL AGGREGATOR) which have been designed for that very > purpose. > > Michel. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 19:21:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g113LH2Q022148 for ; Thu, 31 Jan 2002 19:21:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g113LH0D022147 for ipng-dist; Thu, 31 Jan 2002 19:21:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g113LD2Q022140 for ; Thu, 31 Jan 2002 19:21:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23712 for ; Thu, 31 Jan 2002 19:21:29 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23642 for ; Thu, 31 Jan 2002 20:21:28 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA15162; Thu, 31 Jan 2002 19:21:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g113LR413710; Thu, 31 Jan 2002 19:21:27 -0800 X-mProtect: Thu, 31 Jan 2002 19:21:27 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt8EoLc; Thu, 31 Jan 2002 19:21:25 PST Message-Id: <4.3.2.7.2.20020131191459.024926c8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jan 2002 19:20:58 -0800 To: "Hesham Soliman (ERA)" From: Bob Hinden Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802D4D12C@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, Another approach is add text to make it clear that when there are multiple administrative domains involved that the preferences can only be compared it they are being set in the same manner. I don't think there is any simple automatic way of doing this (and I think we would want to avoid some sort of policy certificates....). This is probably another reason why only a few preference values are needed. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 22:16:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g116GN2Q022388 for ; Thu, 31 Jan 2002 22:16:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g116GNoL022387 for ipng-dist; Thu, 31 Jan 2002 22:16:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g116GK2Q022380 for ; Thu, 31 Jan 2002 22:16:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15633 for ; Thu, 31 Jan 2002 22:16:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA10225 for ; Thu, 31 Jan 2002 23:16:35 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g116GV523633; Fri, 1 Feb 2002 08:16:31 +0200 Date: Fri, 1 Feb 2002 08:16:30 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: "Hesham Soliman (ERA)" , Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" In-Reply-To: <4.3.2.7.2.20020131191459.024926c8@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 31 Jan 2002, Bob Hinden wrote: > Another approach is add text to make it clear that when there are multiple > administrative domains involved that the preferences can only be compared > it they are being set in the same manner. I don't think there is any > simple automatic way of doing this (and I think we would want to avoid some > sort of policy certificates....). > > This is probably another reason why only a few preference values are needed. Well, it would be possible chop off a few more reserved bits (e.g. 2), and make this "domain of applicability" preference: two preferences would only be valid inside the same "domain" class. But this relies on the advertising parties making this right.. and otherwise sounds like a bad (==unnecessary) idea too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 31 23:41:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g117fA2Q022447 for ; Thu, 31 Jan 2002 23:41:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g117f9YC022446 for ipng-dist; Thu, 31 Jan 2002 23:41:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g117f62Q022439 for ; Thu, 31 Jan 2002 23:41:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24615 for ; Thu, 31 Jan 2002 23:41:20 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06919 for ; Fri, 1 Feb 2002 00:40:46 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g117iBO02653; Fri, 1 Feb 2002 14:44:11 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Keith Moore" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: <2B81403386729140A3A899A8B39B046405DE7F@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405DE7F@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Feb 2002 14:44:11 +0700 Message-ID: <2651.1012549451@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 31 Jan 2002 08:16:48 -0800 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405DE7F@server2000.arneill-py.sacramento.ca.us> | do we say: | | 1. It is ok to use a /64 for loopbacks and point to point links in the | sake of simplicity. | | 2. It is a waste to use a /64 for a loopback or a point-to-point link | and therefore we should subnet the IID. | | My vote goes to 1. Given those two questions, so would mine. But those weren't the question, which was more like | 3. Is it ok to use longer than a /64 for links ? That is, the suggestion isn't to pressure people to use /126 or something (as your #2 would do), nor to tell people that it isn't OK to use a /64 for that purpose, which denying your #1 would do. But just to tell them that it is OK to use a longer netmask if they want to (and in the appropriate circumstances). I'm going to ignore all the IPX analogies, I don't know enough about its global hierarchically routed network to make any comments about how its 32 bits of network number are/were actually managed. But: | There is nothing that forbids subneting into the IID Good. This is all I want to achieve. Just keep it possible. As long as we don't start making it impossible, then all kinds of things remain as options for the future (perhaps far future). | (although it would be difficult to subnet smaller than /80), I find it almost impossible to work out where /80 comes from (unless you mean to find a need to do so, in which case, then yes, I'd find that pretty difficult too, though I prefer more often to have constant 0 bits in higher order positions than lower ones, so I'd tend to make the mask longer, and put 0's in the subnet section rather than shorter with 0's in the host part - but that's just aesthetics). But if there's something supposedly magic about the last 48 bits (48 now is 100% irrelevant to autoconf, so it cannot be that) it has escaped me. | but don't you think that, in the time being, | it would be wise to stick to /64 unless we have a hell of a | good reason? If you mean for numbering my own net, then no, I will explicitly use longer masks than that wherever it makes sense, just to push the technology and make sure that it remains possible. For giving advice to the population at large, I'd probably suggest using /64 for almost all nets, to lower the chances of running into limits in the technology that shouldn't be there (but bugs exist everywhere). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------