From owner-ipng@sunroof.eng.sun.com Thu Mar 1 09:27:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21HQDJ16431 for ipng-dist; Thu, 1 Mar 2001 09:26:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21HQ1V16424 for ; Thu, 1 Mar 2001 09:26:02 -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 JAA11844 for ; Thu, 1 Mar 2001 09:26:01 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23110 for ; Thu, 1 Mar 2001 09:25:59 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA19718; Thu, 1 Mar 2001 11:25:45 -0600 (CST) Message-Id: <200103011725.LAA19718@gungnir.fnal.gov> To: Christian Huitema Cc: Paul Francis , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Near-Unique Site-Local Identifier draft In-reply-to: Your message of Tue, 27 Feb 2001 09:16:08 PST. Date: Thu, 01 Mar 2001 11:25:45 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Take it one more step, Christian: > You wrote: > > The probability of a duplicate assignment somewhere is > N^2/2^38... > > which is not quite correct. ... > ... > Thus > (1-P) ~= e^-(N.N-1/2.X) ~= e^-(N^2/2.X) > P ~= 1 - e^-(N^2/2.X) if N^3 << X^2 ~= 1 - ( 1 - (N^2/2X) ) = (N^2)/2X awfully close, after all your approximations, to what was given. There's no use quibbling over a factor of 2 in these very small numbers when, as the next paragraph says, this is not at all an interesting question, and the real question of interest yields a probability far far smaller. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 1 11:29:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21JRlY19434 for ipng-dist; Thu, 1 Mar 2001 11:27:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21JRZV19427 for ; Thu, 1 Mar 2001 11:27:36 -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 LAA00020 for ; Thu, 1 Mar 2001 11:27:35 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10646 for ; Thu, 1 Mar 2001 11:27:34 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 4B4C94CE0A; Thu, 1 Mar 2001 14:27:30 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA17234; Thu, 1 Mar 2001 14:27:29 -0500 (EST) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 3FF2F35C42; Thu, 1 Mar 2001 14:27:29 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Kais Belgaied Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 14:27:24 -0500 Message-Id: <20010301192729.3FF2F35C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <200103011857.KAA10956@domus.ebay.sun.com>, Kais Belgaied writes: >It mandates a guarantee that the label on the IPv6 is authentic before trustin >g >it. In a link-local scope, where the label is proposed to be carried in the >destination header, ESP is mandatory and sufficient. >On a wider scope, AH is necessary. Or it could be bound to the certificate and recreated at the far end. > >Kais. > > > >This sounds like it mandates the use of AH, is that correct? > > > >Best Regards, > >Joseph D. Harwood > >jharwood@vesta-corp.com > >www.vesta-corp.com > > > >> -----Original Message----- > >> From: owner-ipsec@lists.tislabs.com > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied > >> Sent: Wednesday, February 28, 2001 7:18 PM > >> To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > >> Subject: Internet Draft for explicit security labels in IPv6. > >> > >> > >> Greetings, > >> > >> IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating > >> within the premises of a trusted infrastructure. > >> IPv6 only has the implicit labeling by having different IPsec SAs convey > >> different labels. > >> We think there is a need to have explicit labels in IPv6, whether or not > >> IPsec is used. > >> > >> Please see draft-belgaied-ipv6-lsopt-00.txt > >> > >> http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt > >> > >> > >> Regards, > >> Kais. > >> > >> > >> > > > --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 1 11:52:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21Jp3G19562 for ipng-dist; Thu, 1 Mar 2001 11:51:03 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21JopV19555 for ; Thu, 1 Mar 2001 11:50: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 LAA22179 for ; Thu, 1 Mar 2001 11:50:50 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11479 for ; Thu, 1 Mar 2001 12:50:49 -0700 (MST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 34BDE4CE61; Thu, 1 Mar 2001 14:50:49 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA17717; Thu, 1 Mar 2001 14:50:48 -0500 (EST) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id B681435C42; Thu, 1 Mar 2001 14:50:47 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Joseph D. Harwood" Cc: "Kais Belgaied" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 14:50:47 -0500 Message-Id: <20010301195047.B681435C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , "Joseph D. H arwood" writes: >This is a multi-part message in MIME format. > >------=_NextPart_000_0022_01C0A245.80C7E140 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit > >My understanding of the draft was that, one of the goals is for intervening >routers to be able to make routing decisions based on the contents of the >security label (Section 3.4): > > A router needs to trust the authenticity and integrity of a > packet before making routing decision based on the content of its > label. > >The proposal is to permit security labels in Hop-By-Hop Extension Headers, >which (if I remember correctly) are only protected by AH. > >This would seem to require AH. But intermediate routers don't have the keys to verify the AH header. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 1 13:20:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21LHlE19972 for ipng-dist; Thu, 1 Mar 2001 13:17:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21LHZV19965 for ; Thu, 1 Mar 2001 13:17:35 -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 NAA00057 for ; Thu, 1 Mar 2001 13:17:34 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16572; Thu, 1 Mar 2001 13:17:33 -0800 (PST) Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA07437; Thu, 1 Mar 2001 16:17:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103010317.TAA06305@domus.ebay.sun.com> References: <200103010317.TAA06305@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 16:15:09 -0500 To: Kais Belgaied From: Stephen Kent Subject: Re: Internet Draft for explicit security labels in IPv6. Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kais, >Greetings, > >IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating >within the premises of a trusted infrastructure. >IPv6 only has the implicit labeling by having different IPsec SAs convey >different labels. >We think there is a need to have explicit labels in IPv6, whether or not >IPsec is used. > Ipsec allows for both implicit and explicit labelling, according to RFC 2401. If one wishes to carry explicit security labels in the IP header, and to protect the integrity and authenticity of these labels, there are two options: use AH or use tunnel mode ESP and have the labels appear only in the inner IP header. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 1 13:46:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21Lj0c20183 for ipng-dist; Thu, 1 Mar 2001 13:45:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21LimV20176 for ; Thu, 1 Mar 2001 13:44:48 -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 NAA28650 for ; Thu, 1 Mar 2001 13:44:47 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28528 for ; Thu, 1 Mar 2001 13:44:46 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id F0CAE1E077; Thu, 1 Mar 2001 16:44:45 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id QAA20176; Thu, 1 Mar 2001 16:44:44 -0500 (EST) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id AA30435C42; Thu, 1 Mar 2001 16:44:44 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Kais Belgaied Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 16:44:44 -0500 Message-Id: <20010301214444.AA30435C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <200103012137.NAA12627@domus.ebay.sun.com>, Kais Belgaied writes: >>>It mandates a guarantee that the label on the IPv6 is authentic before trust >in >>>g >>>it. In a link-local scope, where the label is proposed to be carried in the >>>destination header, ESP is mandatory and sufficient. >>>On a wider scope, AH is necessary. >> >>Or it could be bound to the certificate and recreated at the far end. > >It could, with the scalability limitation of implicit labeling. > I'm afraid I don't see the limitation. The certificate itself could contain the label. There are two cases, transport mode IPsec and tunnel mode. In tunnel mode, as Kent pointed out, there is an inner IP header, option fields, etc.; in this case, the receiving gateway may wish to verify the labels in the inner header, but need do nothing. Transport mode is end-to-end, in which case the machine receiving the packet is either the ultimate end point -- in which case it can extract the label from the certificate and pass them up to TCP together -- or it's a bump-in-the-{wire,stack} on that machine. In such cases, it should be quite straightforward to add the certificate's label -- if nothing else, it's already reassembling the packet to combine the IP header and the body, which were separated by the IPsec header. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 1 19:20:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f223HrL25770 for ipng-dist; Thu, 1 Mar 2001 19:17:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f22373V25498 for ; Thu, 1 Mar 2001 19:07: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 TAA05452 for ; Thu, 1 Mar 2001 19:06:59 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05106 for ; Thu, 1 Mar 2001 19:06:57 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:9c32:b21f:7622:382e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA13680 for ; Fri, 2 Mar 2001 12:06:57 +0900 (JST) Date: Fri, 02 Mar 2001 12:05:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Unicast-Prefix-based IPv6 Multicast Addresses" In-Reply-To: In your message of "Tue, 27 Feb 2001 07:35:22 -0800" <4.3.2.7.2.20010227073317.02358588@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20010227073317.02358588@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 27 Feb 2001 07:35:22 -0800, >>>>> Bob Hinden said: > Title : Unicast-Prefix-based IPv6 Multicast Addresses > Author(s) : B. Haberman, D. Thaler > Filename : draft-ietf-ipngwg-uni-based-mcast-01.txt > Pages : 5 > Date : 26-Jan-01 > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on March 13, 2001. (Although this may have been discussed...,) I think the document should clearly specify what the network prefix part should be when the prefix length is larger than 64. I know the draft has the following text With the network prefix-based architecture and the current unicast address architecture [RFC 2374], the network prefix portion of the multicast address will be at most 64 bits. and I agree that we won't see a longer (standardized) prefix which is larger than 64bits in length in the near future. But I still think the draft should care about the future extensions and ill-configurations. 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 Mar 2 15:35:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f22NYHn29055 for ipng-dist; Fri, 2 Mar 2001 15:34:17 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f22NY7e29048 for ; Fri, 2 Mar 2001 15:34:07 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10585; Fri, 2 Mar 2001 18:34:05 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f22NXxj08064; Fri, 2 Mar 2001 18:34:00 -0500 (EST) Message-Id: <200103022334.f22NXxj08064@thunk.east.sun.com> From: Bill Sommerfeld To: Kais Belgaied cc: "Steven M. Bellovin" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com Subject: Re: Internet Draft for explicit security labels in IPv6. In-reply-to: Your message of "Fri, 02 Mar 2001 11:06:26 PST." <200103021906.LAA20429@domus.ebay.sun.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 02 Mar 2001 18:33:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not sure what problem you're trying to solve, but: - The assumption in the draft seems to be that SA's are heavy-weight objects. this is not the case and it is certainly my intent to ensure that they are as lightweight as possible within Sun's ipsec implementation.. - I agree with what Steve Kent's analysis -- if you are exchanging multi-level tagged data over an transport connection, the processes on both end had better be highly trusted to bypass MLS and thus you should be able to get by labelling the connection as "system high" (or some other appropriate concept) and using application-layer tagging for the data inside. I'd hate to see what you'd need to do to a TCP implementation and API to carry through security label markings on arbitrary byte boundaries within the streams on both ends. - I can see a couple different ways to handle communicating the label through IKE. As Steve Bellovin suggested, the simplest way is for the appropriate label to end up in the certificate. That clearly doesn't scale in the case of the trusted multi-level applications you described; in that case, it makes sense for the certificate to describe a range of possible labels, and for an additional attribute to show up in the IKE phase 2 exchange containing a specific label to use for the traffic. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 2 15:36:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f22NZcS29066 for ipng-dist; Fri, 2 Mar 2001 15:35:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f22NZHe29057 for ; Fri, 2 Mar 2001 15:35: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 PAA08459 for ; Fri, 2 Mar 2001 15:35:17 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18387; Fri, 2 Mar 2001 16:35:16 -0700 (MST) Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA24663; Fri, 2 Mar 2001 18:35:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103012217.OAA13178@domus.ebay.sun.com> References: <200103012217.OAA13178@domus.ebay.sun.com> Date: Fri, 2 Mar 2001 18:37:12 -0500 To: Kais Belgaied From: Stephen Kent Subject: Re: Label on the H-b-H (was Re: Internet Draft for explicit security labels in IPv6. ) Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kais, >For a router to trust a label in the hop-by-hop header, it has to either >*believe* the packet is authentic (packet coming in through an interface >connected to a highly secured network), or it is the other end (dst) of an >AH AS protecting the labeled packet. > >Here is an example: > > Secure (trusted) Unsecure network Secure network > network (non trustworthy) > /------\ //----\\ /------\ > | | | | | | >Host1 --| |-- SGW1--| | --SGW2--| |--- Host2 > | | | | | | > \------/ \\----// \------/ > >The security policy requires that data at certain labels follow certain paths >inside the secure networks, and that it is offered a certain protection when >travelling through untrusted clouds. The inside routers in the >trusted networks >will use the label for trusted routing. Edge routers SGW1 & SGW2 >MUST use an AH >SA > >If confidentiality is required, An additional AH ESP between Host1 and Host2 >can be used. I would expect SGW1 and SGW2 to establish an ESP tunnel between them, invoking integrity and authenticity for that tunnel (maybe confidentiality too) and that the security label would not be "visible" to the unsecure network. IPsec mandates that this SA be a tunnel, so the protection offered to the label by that SA, as I described above, is just right for your purpose. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 2 16:10:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2308tG29281 for ipng-dist; Fri, 2 Mar 2001 16:08:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2308j129274 for ; Fri, 2 Mar 2001 16:08:45 -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 QAA15336 for ; Fri, 2 Mar 2001 16:08:45 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28244 for ; Fri, 2 Mar 2001 16:08:44 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 2 Mar 2001 15:46:57 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Mar 2001 15:46:04 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 2 Mar 2001 15:46:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: IPv6 DNS Discovery draft updated Date: Fri, 2 Mar 2001 15:46:00 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405266DA2@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W.G. Last Call on "Unicast-Prefix-based IPv6 Multicast Addresses" Thread-Index: AcCiyLb0tqt36FjCQt2r+5ORQe+nJwAqbkZw From: "Dave Thaler" To: X-OriginalArrivalTime: 02 Mar 2001 23:46:01.0422 (UTC) FILETIME=[EFFBA6E0:01C0A372] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We just missed the I-D deadline, but a new draft is available that just adds the consensus recommendation from last IETF: to recommend site-scoped anycast, but not to recommend a payload format yet. http://www.aciri.org/dthaler/dddt/dddt.txt contains the latest draft. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 2 16:39:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f230cat29377 for ipng-dist; Fri, 2 Mar 2001 16:38:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f230cR129370 for ; Fri, 2 Mar 2001 16:38:28 -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 QAA18458 for ; Fri, 2 Mar 2001 16:38:28 -0800 (PST) Received: from web12605.mail.yahoo.com (web12605.mail.yahoo.com [216.136.173.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA19765 for ; Fri, 2 Mar 2001 17:38:27 -0700 (MST) Message-ID: <20010303003826.69346.qmail@web12605.mail.yahoo.com> Received: from [139.87.12.165] by web12605.mail.yahoo.com; Fri, 02 Mar 2001 16:38:26 PST Date: Fri, 2 Mar 2001 16:38:26 -0800 (PST) From: s tsao Subject: Telnet and ftp application To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Is anyone using telnet and ftp application in Redhat7.0 + 2.4.1 kernel + IPv6 enabled environment? I am able to 'ping6' all IPv6 node on my network, but telnet & ftp application does not work. I downloaded nkit-0.4.1 and nkit-0.5.1 as suggested in Peter Bieringer's How-To. It works great with Redhat6.2, but not with Redhat7.0. And are there other mailing groups for which my question could be posted to? I tried users@ipv6.org, but the list has been down for the past week. Greatly appreciate any pointers/suggestion. Thanks! susan __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.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 Sat Mar 3 01:58:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f239vGV29852 for ipng-dist; Sat, 3 Mar 2001 01:57:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f239v6129845 for ; Sat, 3 Mar 2001 01:57:06 -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 BAA03678 for ; Sat, 3 Mar 2001 01:57:05 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06655 for ; Sat, 3 Mar 2001 01:57:00 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA10333; Sat, 3 Mar 2001 16:42:03 +0700 (ICT) 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 X217gQ401643; Mon, 1 Mar 1993 14:42:31 +0700 (ICT) From: Robert Elz To: "Matt Crawford" cc: Christian Huitema , Paul Francis , ipng@sunroof.eng.sun.com Subject: Re: Near-Unique Site-Local Identifier draft In-reply-to: Your message of "Thu, 01 Mar 2001 11:25:45 CST." <200103011725.LAA19718@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Mar 1993 14:42:26 +0700 Message-ID: <1641.730971746@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 01 Mar 2001 11:25:45 -0600 From: "Matt Crawford" Message-ID: <200103011725.LAA19718@gungnir.fnal.gov> | awfully close, after all your approximations, to what was given. I'm not going to start arguing mathematics with my betters, but ... | There's no use quibbling over a factor of 2 in these very small | numbers when, as the next paragraph says, this is not at all an | interesting question, and the real question of interest yields a | probability far far smaller. most likely yes - but I realised this morning that the analysis in that paragraph is flawed. It isn't sufficient to not have a duplicate with anyone you communicate with, you also need to not have a duplicate with anyone that any of them communicate with (or they will see duplicate site-ids at different sites). Fortunately, no further steps out are needed, or we'd end up with a requirement for global uniqueness. That is, if A communicates with B, and B communicates with C and C communicates with D, A B and C must all be different, B C and D must all be different, but it is harmless if A == D. I'll leave it for those who can do the probability theory to calculate the risks of collisions for different numbers of peers/site. But when that is done, do keep in mind that a likely potential use for this kind of thing is for "groups" of related organisations to set up a VPN - eg: (say) a fast food chain and all of its franchisees, and its suppliers - and the suppliers with everyone they supply (etc). The numbers involved there (even instantaneously, not over an extended period) can get quite large - 10K is probably not stretching the limits. 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 Sat Mar 3 08:59:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f23GwNM00146 for ipng-dist; Sat, 3 Mar 2001 08:58:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f23GwD100137 for ; Sat, 3 Mar 2001 08:58:14 -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 IAA21411 for ; Sat, 3 Mar 2001 08:58:13 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA27267 for ; Sat, 3 Mar 2001 08:58:13 -0800 (PST) Received: from 157.54.9.108 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 03 Mar 2001 08:57:41 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Sat, 3 Mar 2001 08:57:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Content-Class: urn:content-classes:message Subject: new drafts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 3 Mar 2001 08:57:41 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF357@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new drafts Thread-Index: AcCkAxIx34kdrtR3Qhmp7wUwr1C+Ow== From: "Richard Draves" To: "IPng List (E-mail)" X-OriginalArrivalTime: 03 Mar 2001 16:57:28.0812 (UTC) FILETIME=[07BDF2C0:01C0A403] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f23GwE100138 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I submitted these twelve hours before the deadline, but somehow they didn't get there in time: ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngwg-default- addr-select-03.txt ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router -selection-01.txt Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 3 10:04:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f23I3nH00236 for ipng-dist; Sat, 3 Mar 2001 10:03:49 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f23I3d100229 for ; Sat, 3 Mar 2001 10:03:40 -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 KAA24019 for ; Sat, 3 Mar 2001 10:03:38 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA16746 for ; Sat, 3 Mar 2001 11:03:37 -0700 (MST) Received: (cpmta 25013 invoked from network); 3 Mar 2001 10:03:36 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO sony) (24.5.201.140) by smtp.francis.com (209.228.32.64) with SMTP; 3 Mar 2001 10:03:36 -0800 X-Sent: 3 Mar 2001 18:03:36 GMT Message-ID: <004301c0a40c$8aa054e0$8c01a8c0@smateo1.sfba.home.com> From: "Paul Francis" To: "Robert Elz" , "Matt Crawford" Cc: "Christian Huitema" , References: <1641.730971746@brandenburg.cs.mu.OZ.AU> Subject: Re: Near-Unique Site-Local Identifier draft Date: Sat, 3 Mar 2001 10:05:33 -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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > But when that is done, do keep in mind that a likely potential use for > this kind of thing is for "groups" of related organisations to set up > a VPN - eg: (say) a fast food chain and all of its franchisees, and its > suppliers - and the suppliers with everyone they supply (etc). The > numbers involved there (even instantaneously, not over an extended period) > can get quite large - 10K is probably not stretching the limits. > Keep in mind that communicating sites can also use globally aggregateable addresses as well. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 3 10:17:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f23IG7A00279 for ipng-dist; Sat, 3 Mar 2001 10:16:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f23IFv100272 for ; Sat, 3 Mar 2001 10:15:57 -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 KAA24842 for ; Sat, 3 Mar 2001 10:15:57 -0800 (PST) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA13007 for ; Sat, 3 Mar 2001 10:15:56 -0800 (PST) Received: (cpmta 19329 invoked from network); 3 Mar 2001 10:15:55 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO sony) (24.5.201.140) by smtp.francis.com (209.228.32.65) with SMTP; 3 Mar 2001 10:15:55 -0800 X-Sent: 3 Mar 2001 18:15:55 GMT Message-ID: <005b01c0a40e$431dd5a0$8c01a8c0@smateo1.sfba.home.com> From: "Paul Francis" To: "Robert Moskowitz" , , Cc: , Subject: hip and multi6 BOFs --- bad schedule conflict Date: Sat, 3 Mar 2001 10:17: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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't know if it is too late to make changes in the agenda, but I would like to strongly encourage the chairs of the hip and multi6 BOFs to request that they be scheduled at different time slots. Given that hip represents one class of solution to the multi-homing problem, I would think that anyone interested in multi-homing would want to attend hip. It is certainly the case with me. (This also goes for anyone interested in mobility). Thanks, PF ps. I should also encourage the chair of hip to get the BOF agenda posted :-) TUESDAY, March 20, 2001 1415-1515 Afternoon Sessions II APP simple SIP for Instant Messaging and Presence Leveraging Extensions BOF INT multi6 How Should We Multihome In IPv6 BOF OPS hubmib Ethernet Interfaces and Hub MIB WG RTG idmr Inter-Domain Multicast Routing WG SEC openpgp An Open Specification for Pretty Good Privacy WG SEC hip Host Identity Payload BOF TSV ippm IP Performance WG -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 3 22:25:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f246Omn01118 for ipng-dist; Sat, 3 Mar 2001 22:24:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f246Oa101111 for ; Sat, 3 Mar 2001 22:24:36 -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 WAA23446 for ; Sat, 3 Mar 2001 22:24:34 -0800 (PST) Received: from starfruit.itojun.org (nat-kuma.camp.wide.ad.jp [203.178.140.115]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19947 for ; Sat, 3 Mar 2001 22:24:31 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E89037E0E; Sun, 4 Mar 2001 15:24:06 +0900 (JST) To: haberman@nortelnetworks.com, jrm@nortelnetworks.com Cc: ipng@sunroof.eng.sun.com Subject: draft-haberman-ipngwg-auto-prefix-00.txt: header field X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Sun, 04 Mar 2001 15:24:06 +0900 Message-Id: <20010304062407.E89037E0E@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello, if you don't have specific reasons, could you swap header fields as follows? the new one should be easier for people to implement... yes, i'm planning to implement and test this. hope this is not too late. itojun 5.1 Prefix Request 00 draft: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|Prefix Length| Routing Capabilities | Reserved | my proposed order: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|Prefix Length| Reserved | Routing Capabilities | 5.2 Prefix Delegation 00 draft: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|Prefix Length| Lifetime | Rt Proto | my proposed order: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|Prefix Length| Rt Proto | Lifetime | -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 00:22:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f258LKG17481 for ipng-dist; Mon, 5 Mar 2001 00:21:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f258L6117466 for ; Mon, 5 Mar 2001 00:21: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 AAA06272 for ; Mon, 5 Mar 2001 00:21:06 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05872 for ; Mon, 5 Mar 2001 00:21:05 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id RAA20536; Mon, 5 Mar 2001 17:20:58 +0900 (JST) To: "James Martin" cc: "Brian Haberman" , ipng@sunroof.eng.sun.com In-reply-to: jrm's message of Sun, 04 Mar 2001 23:56:28 PST. <5.1.0.10.0.20010304235228.00a949c0@zbl6c002.corpeast.baynetworks.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-haberman-ipngwg-auto-prefix-00.txt: header field From: itojun@iijlab.net Date: Mon, 05 Mar 2001 17:20:57 +0900 Message-ID: <20534.983780457@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> hello, if you don't have specific reasons, could you swap header >> fields as follows? the new one should be easier for people to >> implement... yes, i'm planning to implement and test this. >> hope this is not too late. > The change seems entirely reasonable. I'll make the change in the >next draft. thanks! (hope i did not break exisitng 00 implementations...) > Glad to hear you're planning on implementing! I'm anxious to hear >how it goes.... I would like to see official ICMPv6 type #s :-) I hope to send some "how we plan to use" document later. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 01:43:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f259gNJ17889 for ipng-dist; Mon, 5 Mar 2001 01:42:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f259gE117882 for ; Mon, 5 Mar 2001 01:42: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 BAA25455 for ; Mon, 5 Mar 2001 01:42:13 -0800 (PST) Received: from ms.chtn.com.tw ([202.39.167.73]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13288 for ; Mon, 5 Mar 2001 01:42:12 -0800 (PST) Received: from clustersrv1.chtn.com.tw ([10.16.1.81]) by ms.chtn.com.tw (8.10.2/8.10.2) with SMTP id f259gAA29749 for ; Mon, 5 Mar 2001 17:42:10 +0800 Received: from cht.com.tw ([10.16.11.9]) by ms.chtn.com.tw (8.10.2/8.10.2) with ESMTP id f259gAA29745 for ; Mon, 5 Mar 2001 17:42:10 +0800 Message-ID: <3AA35F71.AF14ACE@cht.com.tw> Date: Mon, 05 Mar 2001 17:42:09 +0800 From: Hong-Bin Chiou Organization: Chunghwa Telecommunication Co., Ltd. X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en,zh-TW MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Illustrate how to allocate address for CNIC Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As well known, the IPv6 aggregatable global unicast address format has been defined in RFC2373. The lengths of TLA, NLA and SLA are also defined in RFC2373. I don't know whether there are any example to illustrate the allocation of address space for their CNIC (country NIC) . -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 01:54:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f259rdR17959 for ipng-dist; Mon, 5 Mar 2001 01:53:39 -0800 (PST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f259rQ117952; Mon, 5 Mar 2001 01:53:27 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA14129; Mon, 5 Mar 2001 10:53:17 +0100 (MET) Date: Mon, 5 Mar 2001 10:52:04 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types To: "T.J. Kniveton" Cc: Erik Nordmark , Mattias Pettersson , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, 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 > >> 1. The TTL of RS is < 255, which tells the HA it is from off-link. > > > > Or a spoofed RS. When a router receives a spoofed RS it would presumbly > > log an event and/or increase a counter. > > With your overloading proposal it can't tell the difference > > between a spoofed one and a mobile node using an RA. > > Enlighten me, how exactly does creating a new message type solve this > problem? It seems to me that it just shifts it to a different ICMP #. It doesn't make the spooing issue go away (I didn't claim it did) but allows the current rules for the current ICMP types to stay unchanged including any logging of ttl < 255 packets. The new message types need to have rules that deal with spoofing one way or another. But this might e.g. be to mandate some IP level security mechanism for all messages having the new types. 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 Mar 5 17:41:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f261eFZ22030 for ipng-dist; Mon, 5 Mar 2001 17:40:15 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f261di122010; Mon, 5 Mar 2001 17:39:45 -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 RAA02686; Mon, 5 Mar 2001 17:39:44 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar3-182-130.dsl.gtei.net [4.33.182.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24775; Mon, 5 Mar 2001 17:39:42 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 05 Mar 2001 17:40:17 -0800 Received: from eagleswings [4.33.178.101] by smtp.tndh.net [4.33.182.130] (SLmail 3.2.3113) with SMTP id 8CBA9259A7E84DD597C9818DC4757E3F for plus 5 more; Mon, 05 Mar 2001 17:40:17 -0800 Reply-To: From: "Tony Hain" To: "Erik Nordmark" , "T.J. Kniveton" Cc: "Mattias Pettersson" , "Powell, Ken" , , Subject: RE: New idea for Router Sol/Adv and Mobility - NO new types Date: Mon, 5 Mar 2001 17:40:16 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: 3592BB7F-87704BCF-B1D3840E-30FB1A79 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On one hand I agree with Erik that new types are better than overloading the semantics unnecessarily. The basic problem I am having with this thread is understanding the problem it is trying to solve. Since the HA is required to be in all possible routing paths to my home subnet (else some parts of the world will never contact the node when it is mobile), it has to be a function of the last hop router. The premise of this proposal was that the MN would need to ask the HA for a prefix so it could configure its home address. Since it knows (presumably via configuration) the address of the HA, (and given the HA has to be in the routing path) it already has a useable prefix. I have always assumed that the MN is configured with its home prefix, then it would use the all-routers anycast address to find the HA. In this case the proposed messages are unnecessary. Clearly I need a picture to understand why the MN would know its HA, but not its home prefix. Tony -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Erik Nordmark Sent: Monday, March 05, 2001 1:52 AM To: T.J. Kniveton Cc: Erik Nordmark; Mattias Pettersson; Powell, Ken; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types > >> 1. The TTL of RS is < 255, which tells the HA it is from off-link. > > > > Or a spoofed RS. When a router receives a spoofed RS it would presumbly > > log an event and/or increase a counter. > > With your overloading proposal it can't tell the difference > > between a spoofed one and a mobile node using an RA. > > Enlighten me, how exactly does creating a new message type solve this > problem? It seems to me that it just shifts it to a different ICMP #. It doesn't make the spooing issue go away (I didn't claim it did) but allows the current rules for the current ICMP types to stay unchanged including any logging of ttl < 255 packets. The new message types need to have rules that deal with spoofing one way or another. But this might e.g. be to mandate some IP level security mechanism for all messages having the new types. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:19:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262Ik822405 for ipng-dist; Mon, 5 Mar 2001 18:18:46 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262Ie122398 for ; Mon, 5 Mar 2001 18:18:41 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262G4U01359 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:16:04 -0800 (PST) Received: from ebaymail1.EBay.Sun.COM (ebaymail1.EBay.Sun.COM [129.150.111.99]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f213HYV09333 for ; Wed, 28 Feb 2001 19:17:36 -0800 (PST) Received: from domus.ebay.sun.com (domus.EBay.Sun.COM [129.150.113.143]) by ebaymail1.EBay.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01867; Wed, 28 Feb 2001 19:17:32 -0800 (PST) Received: from amal (amal [129.150.113.131]) by domus.ebay.sun.com (Trusted Solaris (8.9.3)/8.9.3) with SMTP id TAA06305; Wed, 28 Feb 2001 19:17:28 -0800 (PST) Message-Id: <200103010317.TAA06305@domus.ebay.sun.com> Date: Wed, 28 Feb 2001 19:17:30 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: Internet Draft for explicit security labels in IPv6. To: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9jHUCWwDSMzmNjSZbSM0eQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings, IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating within the premises of a trusted infrastructure. IPv6 only has the implicit labeling by having different IPsec SAs convey different labels. We think there is a need to have explicit labels in IPv6, whether or not IPsec is used. Please see draft-belgaied-ipv6-lsopt-00.txt http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt Regards, Kais. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:21:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262KKT22432 for ipng-dist; Mon, 5 Mar 2001 18:20:20 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262KD122425 for ; Mon, 5 Mar 2001 18:20:13 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262Hax01389 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:17:36 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21H9cV16328 for ; Thu, 1 Mar 2001 09:09:38 -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 JAA08335 for ; Thu, 1 Mar 2001 09:09:38 -0800 (PST) Received: from mail15a.boca15-verio.com ([208.55.91.57]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA10935 for ; Thu, 1 Mar 2001 09:09:35 -0800 (PST) Received: from www1509.boca15-verio.com (208.55.91.90) by mail15a.boca15-verio.com (RS ver 1.0.58s) with SMTP id 0196037; Thu, 1 Mar 2001 12:09:23 -0500 (EST) From: "Joseph D. Harwood" To: "Kais Belgaied" , , Subject: RE: Internet Draft for explicit security labels in IPv6. Date: Thu, 1 Mar 2001 09:11:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C0A22F.8DBCD7E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200103010317.TAA06305@domus.ebay.sun.com> X-Loop-Detect: 1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C0A22F.8DBCD7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This sounds like it mandates the use of AH, is that correct? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied > Sent: Wednesday, February 28, 2001 7:18 PM > To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > Subject: Internet Draft for explicit security labels in IPv6. > > > Greetings, > > IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating > within the premises of a trusted infrastructure. > IPv6 only has the implicit labeling by having different IPsec SAs convey > different labels. > We think there is a need to have explicit labels in IPv6, whether or not > IPsec is used. > > Please see draft-belgaied-ipv6-lsopt-00.txt > > http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt > > > Regards, > Kais. > > > ------=_NextPart_000_0016_01C0A22F.8DBCD7E0 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0016_01C0A22F.8DBCD7E0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:22:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262L2a22453 for ipng-dist; Mon, 5 Mar 2001 18:21:02 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262Ko122442 for ; Mon, 5 Mar 2001 18:20:50 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262IDx01419 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:18:13 -0800 (PST) Received: from ebaymail2.EBay.Sun.COM (ebaymail2.EBay.Sun.COM [129.150.111.20]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21Iw4V19231 for ; Thu, 1 Mar 2001 10:58:04 -0800 (PST) Received: from domus.ebay.sun.com (domus.EBay.Sun.COM [129.150.113.143]) by ebaymail2.EBay.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28607; Thu, 1 Mar 2001 10:58:03 -0800 (PST) Received: from amal (amal [129.150.113.131]) by domus.ebay.sun.com (Trusted Solaris (8.9.3)/8.9.3) with SMTP id KAA10956; Thu, 1 Mar 2001 10:57:58 -0800 (PST) Message-Id: <200103011857.KAA10956@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 10:57:59 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: RE: Internet Draft for explicit security labels in IPv6. To: kais@domus.ebay.sun.com, ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QBDv7AE1DqT5f59x+U7jjA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It mandates a guarantee that the label on the IPv6 is authentic before trusting it. In a link-local scope, where the label is proposed to be carried in the destination header, ESP is mandatory and sufficient. On a wider scope, AH is necessary. Kais. > >This sounds like it mandates the use of AH, is that correct? > >Best Regards, >Joseph D. Harwood >jharwood@vesta-corp.com >www.vesta-corp.com > >> -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied >> Sent: Wednesday, February 28, 2001 7:18 PM >> To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com >> Subject: Internet Draft for explicit security labels in IPv6. >> >> >> Greetings, >> >> IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating >> within the premises of a trusted infrastructure. >> IPv6 only has the implicit labeling by having different IPsec SAs convey >> different labels. >> We think there is a need to have explicit labels in IPv6, whether or not >> IPsec is used. >> >> Please see draft-belgaied-ipv6-lsopt-00.txt >> >> http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt >> >> >> Regards, >> Kais. >> >> >> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:23:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262LWF22462 for ipng-dist; Mon, 5 Mar 2001 18:21:32 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262LH122455 for ; Mon, 5 Mar 2001 18:21:18 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262IeX01449 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:18:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21JkjV19526 for ; Thu, 1 Mar 2001 11:46:45 -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 LAA00231 for ; Thu, 1 Mar 2001 11:46:44 -0800 (PST) Received: from mail15a.boca15-verio.com ([208.55.91.57]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA09329 for ; Thu, 1 Mar 2001 12:46:43 -0700 (MST) Received: from www1509.boca15-verio.com (208.55.91.90) by mail15a.boca15-verio.com (RS ver 1.0.58s) with SMTP id 0233461; Thu, 1 Mar 2001 14:46:34 -0500 (EST) From: "Joseph D. Harwood" To: , "Kais Belgaied" Cc: , Subject: RE: Internet Draft for explicit security labels in IPv6. Date: Thu, 1 Mar 2001 11:48:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C0A245.80C7E140" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20010301192729.3FF2F35C42@berkshire.research.att.com> X-Loop-Detect: 1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0A245.80C7E140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My understanding of the draft was that, one of the goals is for intervening routers to be able to make routing decisions based on the contents of the security label (Section 3.4): A router needs to trust the authenticity and integrity of a packet before making routing decision based on the content of its label. The proposal is to permit security labels in Hop-By-Hop Extension Headers, which (if I remember correctly) are only protected by AH. This would seem to require AH. Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: smb@research.att.com [mailto:smb@research.att.com] > Sent: Thursday, March 01, 2001 11:27 AM > To: Kais Belgaied > Cc: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com; > jharwood@vesta-corp.com > Subject: Re: Internet Draft for explicit security labels in IPv6. > > > In message <200103011857.KAA10956@domus.ebay.sun.com>, Kais > Belgaied writes: > >It mandates a guarantee that the label on the IPv6 is authentic > before trustin > >g > >it. In a link-local scope, where the label is proposed to be > carried in the > >destination header, ESP is mandatory and sufficient. > >On a wider scope, AH is necessary. > > Or it could be bound to the certificate and recreated at the far end. > > > >Kais. > > > > > >This sounds like it mandates the use of AH, is that correct? > > > > > >Best Regards, > > >Joseph D. Harwood > > >jharwood@vesta-corp.com > > >www.vesta-corp.com > > > > > >> -----Original Message----- > > >> From: owner-ipsec@lists.tislabs.com > > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied > > >> Sent: Wednesday, February 28, 2001 7:18 PM > > >> To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > > >> Subject: Internet Draft for explicit security labels in IPv6. > > >> > > >> > > >> Greetings, > > >> > > >> IPv4 had IPSO and CIPSO for labeling of packets assuming > we're operating > > >> within the premises of a trusted infrastructure. > > >> IPv6 only has the implicit labeling by having different > IPsec SAs convey > > >> different labels. > > >> We think there is a need to have explicit labels in IPv6, > whether or not > > >> IPsec is used. > > >> > > >> Please see draft-belgaied-ipv6-lsopt-00.txt > > >> > > >> http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt > > >> > > >> > > >> Regards, > > >> Kais. > > >> > > >> > > >> > > > > > > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > ------=_NextPart_000_0022_01C0A245.80C7E140 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0022_01C0A245.80C7E140-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:24:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262McL22474 for ipng-dist; Mon, 5 Mar 2001 18:22:38 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262MP122467 for ; Mon, 5 Mar 2001 18:22:25 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262JmK01480 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:19:48 -0800 (PST) Received: from ebaymail1.EBay.Sun.COM (ebaymail1.EBay.Sun.COM [129.150.111.99]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21LbgV20130 for ; Thu, 1 Mar 2001 13:37:43 -0800 (PST) Received: from domus.ebay.sun.com (domus.EBay.Sun.COM [129.150.113.143]) by ebaymail1.EBay.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07342; Thu, 1 Mar 2001 13:37:41 -0800 (PST) Received: from amal (amal [129.150.113.131]) by domus.ebay.sun.com (Trusted Solaris (8.9.3)/8.9.3) with SMTP id NAA12627; Thu, 1 Mar 2001 13:37:37 -0800 (PST) Message-Id: <200103012137.NAA12627@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 13:37:37 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: Re: Internet Draft for explicit security labels in IPv6. To: smb@research.att.com Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KyOl8DuklPNmtzrvB+nCQg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>It mandates a guarantee that the label on the IPv6 is authentic before trustin >>g >>it. In a link-local scope, where the label is proposed to be carried in the >>destination header, ESP is mandatory and sufficient. >>On a wider scope, AH is necessary. > >Or it could be bound to the certificate and recreated at the far end. It could, with the scalability limitation of implicit labeling. Kais. >> >> > >> >This sounds like it mandates the use of AH, is that correct? >> > >> >Best Regards, >> >Joseph D. Harwood >> >jharwood@vesta-corp.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 Mar 5 18:25:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262NUc22514 for ipng-dist; Mon, 5 Mar 2001 18:23:30 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262NE122499 for ; Mon, 5 Mar 2001 18:23:15 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262KbI01510 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:20:37 -0800 (PST) Received: from ebaymail2.EBay.Sun.COM (ebaymail2.EBay.Sun.COM [129.150.111.20]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21MHsV20432 for ; Thu, 1 Mar 2001 14:17:54 -0800 (PST) Received: from domus.ebay.sun.com (domus.EBay.Sun.COM [129.150.113.143]) by ebaymail2.EBay.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23048; Thu, 1 Mar 2001 14:17:55 -0800 (PST) Received: from amal (amal [129.150.113.131]) by domus.ebay.sun.com (Trusted Solaris (8.9.3)/8.9.3) with SMTP id OAA13178; Thu, 1 Mar 2001 14:17:51 -0800 (PST) Message-Id: <200103012217.OAA13178@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 14:17:51 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: Label on the H-b-H (was Re: Internet Draft for explicit security labels in IPv6. ) To: jharwood@vesta-corp.com, smb@research.att.com Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ewZT/G6IUA/GlJEWEZO9jw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For a router to trust a label in the hop-by-hop header, it has to either *believe* the packet is authentic (packet coming in through an interface connected to a highly secured network), or it is the other end (dst) of an AH AS protecting the labeled packet. Here is an example: Secure (trusted) Unsecure network Secure network network (non trustworthy) /------\ //----\\ /------\ | | | | | | Host1 --| |-- SGW1--| | --SGW2--| |--- Host2 | | | | | | \------/ \\----// \------/ The security policy requires that data at certain labels follow certain paths inside the secure networks, and that it is offered a certain protection when travelling through untrusted clouds. The inside routers in the trusted networks will use the label for trusted routing. Edge routers SGW1 & SGW2 MUST use an AH SA If confidentiality is required, An additional AH ESP between Host1 and Host2 can be used. Kais. >> >>My understanding of the draft was that, one of the goals is for intervening >>routers to be able to make routing decisions based on the contents of the >>security label (Section 3.4): >> >> A router needs to trust the authenticity and integrity of a >> packet before making routing decision based on the content of its >> label. >> >>The proposal is to permit security labels in Hop-By-Hop Extension Headers, >>which (if I remember correctly) are only protected by AH. >> >>This would seem to require AH. > >But intermediate routers don't have the keys to verify the AH header. > > --Steve Bellovin, http://www.research.att.com/~smb > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:26:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262OgI22567 for ipng-dist; Mon, 5 Mar 2001 18:24:42 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262OK122541 for ; Mon, 5 Mar 2001 18:24:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262Lhx01540 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:21:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21MWIV20681 for ; Thu, 1 Mar 2001 14:32:18 -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 OAA20351 for ; Thu, 1 Mar 2001 14:32:19 -0800 (PST) Received: from mail15b.boca15-verio.com ([208.55.91.59]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA25002 for ; Thu, 1 Mar 2001 14:32:18 -0800 (PST) Received: from www1509.boca15-verio.com (208.55.91.90) by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id 0206019; Thu, 1 Mar 2001 17:32:13 -0500 (EST) From: "Joseph D. Harwood" To: "Kais Belgaied" , Cc: , Subject: RE: Label on the H-b-H (was Re: Internet Draft for explicit security labels in IPv6. ) Date: Thu, 1 Mar 2001 14:33:50 -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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200103012217.OAA13178@domus.ebay.sun.com> X-Loop-Detect: 1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you, that clarifies the situation a great deal. Since the packet must be tunneled between SG1 and SG2 (it's transit traffic, Tunnel Mode is required), ESP could be used as well as AH and this would also protect the security label of the inner packet. Perhaps this option could be included in the draft. Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: Kais Belgaied [mailto:kais@domus.ebay.sun.com] > Sent: Thursday, March 01, 2001 2:18 PM > To: jharwood@vesta-corp.com; smb@research.att.com > Cc: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > Subject: Label on the H-b-H (was Re: Internet Draft for explicit > security labels in IPv6. ) > > > For a router to trust a label in the hop-by-hop header, it has to either > *believe* the packet is authentic (packet coming in through an interface > connected to a highly secured network), or it is the other end (dst) of an > AH AS protecting the labeled packet. > > Here is an example: > > Secure (trusted) Unsecure network Secure network > network (non trustworthy) > /------\ //----\\ /------\ > | | | | | | > Host1 --| |-- SGW1--| | --SGW2--| |--- Host2 > | | | | | | > \------/ \\----// \------/ > > The security policy requires that data at certain labels follow > certain paths > inside the secure networks, and that it is offered a certain > protection when > travelling through untrusted clouds. The inside routers in the > trusted networks > will use the label for trusted routing. Edge routers SGW1 & SGW2 > MUST use an AH > SA > > If confidentiality is required, An additional AH ESP between > Host1 and Host2 > can be used. > > Kais. > > >> > >>My understanding of the draft was that, one of the goals is for > intervening > >>routers to be able to make routing decisions based on the > contents of the > >>security label (Section 3.4): > >> > >> A router needs to trust the authenticity and integrity of a > >> packet before making routing decision based on the content of its > >> label. > >> > >>The proposal is to permit security labels in Hop-By-Hop > Extension Headers, > >>which (if I remember correctly) are only protected by AH. > >> > >>This would seem to require AH. > > > >But intermediate routers don't have the keys to verify the AH header. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:26:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262PCJ22579 for ipng-dist; Mon, 5 Mar 2001 18:25:12 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262Ov122572 for ; Mon, 5 Mar 2001 18:24:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262MKx01570 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:22:20 -0800 (PST) Received: from ebaymail2.EBay.Sun.COM (ebaymail2.EBay.Sun.COM [129.150.111.20]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f22J6We28785 for ; Fri, 2 Mar 2001 11:06:32 -0800 (PST) Received: from domus.ebay.sun.com (domus.EBay.Sun.COM [129.150.113.143]) by ebaymail2.EBay.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28937; Fri, 2 Mar 2001 11:06:31 -0800 (PST) Received: (from kais@localhost) by domus.ebay.sun.com (Trusted Solaris (8.9.3)/8.9.3) id LAA20429; Fri, 2 Mar 2001 11:06:27 -0800 (PST) From: Kais Belgaied Message-Id: <200103021906.LAA20429@domus.ebay.sun.com> Subject: Re: Internet Draft for explicit security labels in IPv6. In-Reply-To: <20010301214444.AA30435C42@berkshire.research.att.com> from "Steven M. Bellovin" at "Mar 1, 2001 04:44:44 pm" To: "Steven M. Bellovin" Date: Fri, 2 Mar 2001 11:06:26 -0800 (PST) CC: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First, I a gree with S Kent, J. Hardwood and S. Bellovin on the ESP tunnel mode (Thank y'all). I shall update the draft to reflect the the 2 possibilities, AH (+ESP) in transport mode, and tunnel mode ESP with the label on the h-b-h of the inner header. > >>>it. In a link-local scope, where the label is proposed to be carried in the > >>>destination header, ESP is mandatory and sufficient. > >>>On a wider scope, AH is necessary. > >> > >>Or it could be bound to the certificate and recreated at the far end. > > > >It could, with the scalability limitation of implicit labeling. > > > I'm afraid I don't see the limitation. The certificate itself could > contain the label. > > There are two cases, transport mode IPsec and tunnel mode. In tunnel > mode, as Kent pointed out, there is an inner IP header, option fields, > etc.; in this case, the receiving gateway may wish to verify the labels > in the inner header, but need do nothing. > > Transport mode is end-to-end, in which case the machine receiving the > packet is either the ultimate end point -- in which case it can extract > the label from the certificate and pass them up to TCP together -- or > it's a bump-in-the-{wire,stack} on that machine. In such cases, it > should be quite straightforward to add the certificate's label -- if > nothing else, it's already reassembling the packet to combine the IP > header and the body, which were separated by the IPsec header. > Yes, it is feasable, but my understanding is that the certificate attributes cannot be easily changed without re-negotiating it. The limitation is regarding situations like the following example: A backup server being accessed from remote multilevel secure hosts using an NFS mount. The client (system being backed up) will be using one TCP connection to the server, and the filesystems on both sides will be using the services of an RPC layer that share the use of that single connection. The data in the client packets can come from files at a very wide range of labels, and need to be preserved at the backup file system. We can have one instance of the NFS daemon per possible label, and one tcp connection at each label between the client and server. The label is retreived from the certificate, so one certificate per sensitivity is needed. A typical sensitivity label has a classification 16-bits wide, and 240 category bits, that can combine to a big number. I'm afraid maintaining that number of contexts, or switching back and forth between them can be too costly. Kais. > --Steve Bellovin, http://www.research.att.com/~smb > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:29:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262SJp22641 for ipng-dist; Mon, 5 Mar 2001 18:28:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262S2122634 for ; Mon, 5 Mar 2001 18:28:03 -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 SAA06662 for ; Mon, 5 Mar 2001 18:28:01 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12235 for ; Mon, 5 Mar 2001 18:28:01 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 9AC811E048; Mon, 5 Mar 2001 21:27:52 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id VAA25969; Mon, 5 Mar 2001 21:27:46 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 7F69435C42; Mon, 5 Mar 2001 21:27:45 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Joseph D. Harwood" Cc: "Kais Belgaied" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Mar 2001 21:27:41 -0500 Message-Id: <20010306022745.7F69435C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , "Joseph D. H arwood" writes: >This is a multi-part message in MIME format. > >------=_NextPart_000_0022_01C0A245.80C7E140 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit > >My understanding of the draft was that, one of the goals is for intervening >routers to be able to make routing decisions based on the contents of the >security label (Section 3.4): > > A router needs to trust the authenticity and integrity of a > packet before making routing decision based on the content of its > label. > >The proposal is to permit security labels in Hop-By-Hop Extension Headers, >which (if I remember correctly) are only protected by AH. > >This would seem to require AH. As I noted earlier, the intervening routers don't have the key to verify the AH protection. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 18:33:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262Vlv22703 for ipng-dist; Mon, 5 Mar 2001 18:31:47 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262Vh122696 for ; Mon, 5 Mar 2001 18:31:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262T6a01611 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:29:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f257ug117330 for ; Sun, 4 Mar 2001 23:56: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 XAA03616 for ; Sun, 4 Mar 2001 23:56:43 -0800 (PST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06877 for ; Sun, 4 Mar 2001 23:56:42 -0800 (PST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Mon, 5 Mar 2001 02:56:31 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFKF63ST; Mon, 5 Mar 2001 02:56:30 -0500 Received: from balrog.nortelnetworks.com (asc4t23a.us.nortel.com [47.81.7.202]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GG2P57FB; Mon, 5 Mar 2001 02:56:29 -0500 Message-Id: <5.1.0.10.0.20010304235228.00a949c0@zbl6c002.corpeast.baynetworks.com> X-Sender: jrm@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.10 (Beta) Date: Sun, 04 Mar 2001 23:56:28 -0800 To: Jun-ichiro itojun Hagino , "Brian Haberman" , "James Martin" From: "James Martin" Subject: Re: draft-haberman-ipngwg-auto-prefix-00.txt: header field Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20010304062407.E89037E0E@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:24 PM 3/4/2001 +0900, Jun-ichiro itojun Hagino wrote: > hello, if you don't have specific reasons, could you swap header > fields as follows? the new one should be easier for people to > implement... yes, i'm planning to implement and test this. > hope this is not too late. The change seems entirely reasonable. I'll make the change in the next draft. Glad to hear you're planning on implementing! I'm anxious to hear how it goes.... - 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 Mon Mar 5 18:50:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f262nbL22885 for ipng-dist; Mon, 5 Mar 2001 18:49:37 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262nX122878 for ; Mon, 5 Mar 2001 18:49:33 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f262kuN01657 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 18:46:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f262KO122434 for ; Mon, 5 Mar 2001 18:20:24 -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 SAA10879 for ; Mon, 5 Mar 2001 18:20:24 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09843 for ; Mon, 5 Mar 2001 18:20:22 -0800 (PST) Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id LAA11122 for ; Tue, 6 Mar 2001 11:20:21 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id LAA27010; Tue, 6 Mar 2001 11:20:21 +0900 (JST) Received: by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id LAA20645; Tue, 6 Mar 2001 11:20:18 +0900 (JST) X-Lotus-FromDomain: TOSHIBA From: "yoshikazu oda" To: ipng@sunroof.eng.sun.com Message-Id: <200103060220.LAA20645@toshiba.co.jp> Date: Tue, 6 Mar 2001 11:19:17 +0900 Subject: Patent Statement Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Toshiba Corporation hereby declares that if its technology defined in the draft proposed by Sony and Toshiba as "draft-teraoka-ipng-lin6-00.txt" is included in a specification agreed by the IETF, it is prepared to license its Japanese Patent Application No.2000-036693 to any applicants for use in products which are in compliance with the specification under reasonable terms and conditions that are demonstrably free of any unfair competition, provided that such applicant obtaining such license from Toshiba agrees to license to Toshiba its patents necessary for Toshiba to practice the above mentioned specification, if any, on a reciprocal basis. Yoshikazu Oda Group Manager Intellectual Property Group Research Planning Office Corporate Research & Development Center Toshiba Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 19:19:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f263Hxk23074 for ipng-dist; Mon, 5 Mar 2001 19:17:59 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f263Hn123067 for ; Mon, 5 Mar 2001 19:17:49 -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 TAA12284 for ; Mon, 5 Mar 2001 19:17:49 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar3-182-130.dsl.gtei.net [4.33.182.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA28809 for ; Mon, 5 Mar 2001 19:17:48 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 05 Mar 2001 19:18:23 -0800 Received: from eagleswings [4.33.178.101] by smtp.tndh.net [4.33.182.130] (SLmail 3.2.3113) with SMTP id 74B24617E55B4FAF81BA883271EECF3C for plus 1 more; Mon, 05 Mar 2001 19:18:22 -0800 Reply-To: From: "Tony Hain" To: "yoshikazu oda" , Subject: RE: Patent Statement Date: Mon, 5 Mar 2001 19:18:22 -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: <200103060220.LAA20645@toshiba.co.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: FB18FAB6-63134EAB-9A9EA1FF-CE8BBB49 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This note should be sent to Steve Coya so it can be posted according to RFC2026. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of yoshikazu oda Sent: Monday, March 05, 2001 6:19 PM To: ipng@sunroof.eng.sun.com Subject: Patent Statement Toshiba Corporation hereby declares that if its technology defined in the draft proposed by Sony and Toshiba as "draft-teraoka-ipng-lin6-00.txt" is included in a specification agreed by the IETF, it is prepared to license its Japanese Patent Application No.2000-036693 to any applicants for use in products which are in compliance with the specification under reasonable terms and conditions that are demonstrably free of any unfair competition, provided that such applicant obtaining such license from Toshiba agrees to license to Toshiba its patents necessary for Toshiba to practice the above mentioned specification, if any, on a reciprocal basis. Yoshikazu Oda Group Manager Intellectual Property Group Research Planning Office Corporate Research & Development Center Toshiba Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mar 5 20:04:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2643kJ23247 for ipng-dist; Mon, 5 Mar 2001 20:03:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2643c123240 for ; Mon, 5 Mar 2001 20:03:38 -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 UAA16486 for ; Mon, 5 Mar 2001 20:03:37 -0800 (PST) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16657 for ; Mon, 5 Mar 2001 20:03:36 -0800 (PST) Received: from gigue.eas.harvard.edu (gigue.eas.harvard.edu [140.247.51.194]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id XAA16936 for ; Mon, 5 Mar 2001 23:03:35 -0500 (EST) From: Dan Lanciani Received: (from ddl@localhost) by gigue.eas.harvard.edu (8.9.1/8.9.1) id XAA14858 for ipng@sunroof.eng.sun.com; Mon, 5 Mar 2001 23:03:35 -0500 (EST) Date: Mon, 5 Mar 2001 23:03:35 -0500 (EST) Message-Id: <200103060403.XAA14858@gigue.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: Patent Statement Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |Toshiba Corporation hereby declares that if its technology defined in the draft proposed |by Sony and Toshiba as "draft-teraoka-ipng-lin6-00.txt" is included |in a specification agreed by the IETF, it is prepared to license |its Japanese Patent Application No.2000-036693 to any applicants |for use in products which are in compliance with the specification |under reasonable terms and conditions that are demonstrably |free of any unfair competition, provided that such applicant |obtaining such license from Toshiba agrees to license to Toshiba |its patents necessary for Toshiba to practice the above mentioned |specification, if any, on a reciprocal basis. If the IETF would like to use the similar "technology" that I described on this list back in 1999 (refer to portable identifier thread), I'll put it in the public domain. :) Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 00:19:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f268IWi24012 for ipng-dist; Tue, 6 Mar 2001 00:18:32 -0800 (PST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f268IJ124005; Tue, 6 Mar 2001 00:18:20 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA00163; Tue, 6 Mar 2001 09:18:12 +0100 (MET) Date: Tue, 6 Mar 2001 09:16:57 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: New idea for Router Sol/Adv and Mobility - NO new types To: alh-ietf@tndh.net Cc: Erik Nordmark , "T.J. Kniveton" , Mattias Pettersson , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, 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 > Clearly I need a > picture to understand why the MN would know its HA, but not its home prefix. While the MN must know at least one home prefix it might not know all of them in particular it might not know about any new prefixes that have been introduced while the MN was away from home. So it needs to be able to get the complete list including the current lifetimes for the prefixes. Of course, if all the home prefixes that the MN knows expire due to renumbering then the MN is in deep trouble. 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 Mar 6 00:26:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f268Q6N24081 for ipng-dist; Tue, 6 Mar 2001 00:26:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f268Pw124074 for ; Tue, 6 Mar 2001 00:25:58 -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 AAA12104 for ; Tue, 6 Mar 2001 00:25:58 -0800 (PST) Received: from web1604.mail.yahoo.com (web1604.mail.yahoo.com [128.11.23.204]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA27797 for ; Tue, 6 Mar 2001 00:25:58 -0800 (PST) Received: (qmail 2871 invoked by uid 60001); 6 Mar 2001 08:25:58 -0000 Message-ID: <20010306082558.2870.qmail@web1604.mail.yahoo.com> Received: from [164.99.143.100] by web1604.mail.yahoo.com; Tue, 06 Mar 2001 00:25:58 PST Date: Tue, 6 Mar 2001 00:25:58 -0800 (PST) From: alex r Subject: Question on scopes involving IPv6 addresses To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is the following a valid configuration in IPv6. The addresses represented in as (L) are either all site local or all link local addresses A(L1)---------(L2)B(L1)----------(L2)C B is connected to two different links / sites. The addresses are unique within their respective scopes. Thanks Alex __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.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 Mar 6 00:38:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f268bL824127 for ipng-dist; Tue, 6 Mar 2001 00:37:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f268bC124120 for ; Tue, 6 Mar 2001 00:37:12 -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 AAA14305 for ; Tue, 6 Mar 2001 00:37:12 -0800 (PST) Received: from givenchy (mailhost.6wind.com [212.234.238.114]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA22739 for ; Tue, 6 Mar 2001 01:37:11 -0700 (MST) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id 8575E887; Tue, 6 Mar 2001 09:35:24 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.123]) by intranet.6wind.com (Postfix) with ESMTP id 00E3EB470; Tue, 6 Mar 2001 09:37:26 +0100 (CET) Message-ID: <3AA4A210.1C3CC982@6wind.com> Date: Tue, 06 Mar 2001 09:38:40 +0100 From: Alain Ritoux X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: alex r Cc: ipng@sunroof.eng.sun.com Subject: Re: Question on scopes involving IPv6 addresses References: <20010306082558.2870.qmail@web1604.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is the following a valid configuration in IPv6. The > addresses represented in as (L) are either all site > local or all link local addresses > > A(L1)---------(L2)B(L1)----------(L2)C > > B is connected to two different links / sites. The > addresses are unique within their respective scopes. For me this seems correct But I wonder if we can push as far as : A(L1)---------(L2)B(L2)----------(L1)C the assumptions being the same. Alain. -------------------------------------------------------- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 Address : 6WIND 1 place Charles de Gaulle Immeuble Central Gare 78180 MONTIGNY LE BRETONNEUX FRANCE web site : www.6wind.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 Mar 6 01:50:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f269nUN24370 for ipng-dist; Tue, 6 Mar 2001 01:49:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f269nK124363; Tue, 6 Mar 2001 01:49:20 -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 BAA25747; Tue, 6 Mar 2001 01:49:07 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25045; Tue, 6 Mar 2001 01:49:06 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f269mjd38107; Tue, 6 Mar 2001 10:48: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 KAA13602; Tue, 6 Mar 2001 10:48:45 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f269mhA55544; Tue, 6 Mar 2001 10:48:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103060948.f269mhA55544@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: alh-ietf@tndh.net cc: "Erik Nordmark" , "T.J. Kniveton" , "Mattias Pettersson" , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types In-reply-to: Your message of Mon, 05 Mar 2001 17:40:16 PST. Date: Tue, 06 Mar 2001 10:48:43 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => this thread was completely messed by the mobile-ip mailing list bug: I believe a summary is needed in order to understand ideas and their chain. On one hand I agree with Erik that new types are better than overloading the semantics unnecessarily. The basic problem I am having with this thread is understanding the problem it is trying to solve. => look at my intro (:-). Since the HA is required to be in all possible routing paths to my home subnet (else some parts of the world will never contact the node when it is mobile), it has to be a function of the last hop router. => not exactly. The Home Agent (HA) must be attached to the home link. If the home link doesn't physically exist then (and only then) your statement applies. The premise of this proposal was that the MN would need to ask the HA for a prefix so it could configure its home address. => the issue is home link renumbering, in particular when the Mobile Node (MN) is down for a very long period. This is a real problem but there are far more important problems, for instance the abyssal performance of secure mobile IPv6 when a MN is booted in visit (of course having to learn the HA address and the home address will not improve this). This thread assumes that: - the home link is often renumbered - DNS is not available in the visit network (if it is available then you need only to configure a name as proposed by Compaq folks) - home AAA is not available (if it is available then HA and home address allocation may/should be done by AAA) - statefull autoconfig will never be available! Since it knows (presumably via configuration) the address of the HA, (and given the HA has to be in the routing path) it already has a useable prefix. I have always assumed that the MN is configured with its home prefix, then it would use the all-routers anycast address to find the HA. In this case the proposed messages are unnecessary. Clearly I need a picture to understand why the MN would know its HA, but not its home prefix. => there is a dedicated anycast address for HAs (because if HAs are routers, not all routers are HAs). I agree this topic is a secondary one and we should throw it into the for further studies stuff. Of course, I'll strongly object if this is slowing down the mobile IPv6 draft (BTW, is there an I-D 14?). 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 Tue Mar 6 02:51:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26AogY24627 for ipng-dist; Tue, 6 Mar 2001 02:50:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26AoX124620 for ; Tue, 6 Mar 2001 02:50:33 -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 CAA06419 for ; Tue, 6 Mar 2001 02:50:32 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14869 for ; Tue, 6 Mar 2001 02:50:32 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id CAA15762; Tue, 6 Mar 2001 02:50:28 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <20010306082558.2870.qmail@web1604.mail.yahoo.com> References: <20010306082558.2870.qmail@web1604.mail.yahoo.com> Date: Tue, 6 Mar 2001 02:50:29 -0800 To: alex r , Alain Ritoux From: Steve Deering Subject: Re: Question on scopes involving IPv6 addresses Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:25 AM -0800 3/6/01, alex r wrote: >Is the following a valid configuration in IPv6. The >addresses represented in as (L) are either all site >local or all link local addresses > > > A(L1)---------(L2)B(L1)----------(L2)C > >B is connected to two different links / sites. The >addresses are unique within their respective scopes. Yes, that is a valid configuration. At 9:38 AM +0100 3/6/01, Alain Ritoux wrote: >But I wonder if we can push as far as : > A(L1)---------(L2)B(L2)----------(L1)C > the assumptions being the same. Yes, that one is valid too. By the way, an updated version of the IPv6 Scoped Address Architecture draft was submitted by the ID deadline and should appear in the ID directories Any Day Now. It can also be fetched now from: ftp://standards.nortelnetworks.com/ipv6/draft-ietf-ipngwg-scoping-arch-02.txt Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 02:56:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26Au7524675 for ipng-dist; Tue, 6 Mar 2001 02:56:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26Atw124668 for ; Tue, 6 Mar 2001 02:55:58 -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 CAA23858 for ; Tue, 6 Mar 2001 02:55:57 -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 CAA16042 for ; Tue, 6 Mar 2001 02:55:55 -0800 (PST) Received: from localhost ([2001:200:0:ff51:3da4:90e8:841b:c5a1]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id TAA18819; Tue, 6 Mar 2001 19:55:46 +0900 (JST) Date: Tue, 06 Mar 2001 19:54:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Ritoux Cc: alex r , ipng@sunroof.eng.sun.com Subject: Re: Question on scopes involving IPv6 addresses In-Reply-To: In your message of "Tue, 06 Mar 2001 09:38:40 +0100" <3AA4A210.1C3CC982@6wind.com> References: <20010306082558.2870.qmail@web1604.mail.yahoo.com> <3AA4A210.1C3CC982@6wind.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 06 Mar 2001 09:38:40 +0100, >>>>> Alain Ritoux said: >> Is the following a valid configuration in IPv6. The >> addresses represented in as (L) are either all site >> local or all link local addresses >> A(L1)---------(L2)B(L1)----------(L2)C >> >> B is connected to two different links / sites. The >> addresses are unique within their respective scopes. > For me this seems correct Yes, this is correct. > But I wonder if we can push as far as : > A(L1)---------(L2)B(L2)----------(L1)C > the assumptions being the same. This is correct, too, provided that the B's two interfaces belong to different links. For more details about the scoped addresses (including link-local and site-local ones) architecture, see draft-ietf-ipngwg-scoping-arch-xx.txt (the 01 version is the latest one, which has already expired, but the 02 version has been submitted and will soon be out.) 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 Mar 6 05:14:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26DD1Y25164 for ipng-dist; Tue, 6 Mar 2001 05:13:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26DCq125157 for ; Tue, 6 Mar 2001 05:12:52 -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 FAA17614 for ; Tue, 6 Mar 2001 05:12:51 -0800 (PST) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA28647 for ; Tue, 6 Mar 2001 05:12:50 -0800 (PST) Received: from INET-PRV1-Message_Server by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 06 Mar 2001 06:11:54 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 06 Mar 2001 05:07:34 -0700 From: "Alex R n" To: , , Cc: Subject: Re: Question on scopes involving IPv6 addresses Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1E458D0A.B3D23DB3" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_1E458D0A.B3D23DB3 Content-Type: text/plain; charset=SHIFT_JIS Content-Transfer-Encoding: quoted-printable >>> JINMEI Tatuya / =F8~_=FB~*=F9~B** = 03/06/01 04:24PM >>> >>>>> On Tue, 06 Mar 2001 09:38:40 +0100,=20 >>>>> Alain Ritoux said: >> Is the following a valid configuration in IPv6. The >> addresses represented in as (L) are either all site >> local or all link local addresses >> A(L1)---------(L2)B(L1)----------(L2)C >>=20 >> B is connected to two different links / sites. The >> addresses are unique within their respective scopes. > For me this seems correct Yes, this is correct. > But I wonder if we can push as far as : > A(L1)---------(L2)B(L2)----------(L1)C > the assumptions being the same. This is correct, too, provided that the B's two interfaces belong to different links. For more details about the scoped addresses (including link-local and site-local ones) architecture, see=20 draft-ietf-ipngwg-scoping-arch-xx.txt (the 01 version is the latest one, which has already expired, but the 02 version has been submitted and will soon be out.) Going through scoped address architecture it provides a mechanism to = distinguing the same address belonging to different scopes. What I am = wondering is that=20 a) Couldnt the scope index have been part of the IPv6 address. b) For upper layers like UDP which identifes a connection based on = addresses wouldnt it be better to put the scope index into the address = itself. One scenario is that we could have the same [source src port destination = dst port ] pairs from different scopes as in the scenario earlier seen. = Is the upper layer suppose to handle this in a different manner like = having scoped tables. Thanks Alex --=_1E458D0A.B3D23DB3 Content-Type: text/html; charset=SHIFT_JIS Content-Transfer-Encoding: quoted-printable

>>> JINMEI Tatuya / =1B$(B=90_–¾’B=8D&= AElig;=20 <jinmei@isl.rdc.toshiba.co.jp> 03/06/01 04:24PM=20 >>>
>>>>> On Tue, 06 Mar 2001 09:38:40 = +0100,=20
>>>>> Alain Ritoux <alain.ritoux@6wind.com>=20 said:

>> Is the following a valid configuration in IPv6.=20 The
>> addresses represented in as (L) are either all site
>= >=20 local or all link local addresses

>>=20 A(L1)---------(L2)B(L1)----------(L2)C
>>
>> B is = connected=20 to two different links / sites. The
>> addresses are unique = within=20 their respective scopes.

> For me this seems correct

Yes, = this=20 is correct.

> But I wonder if we can push as far as=20 :
>    =20 A(L1)---------(L2)B(L2)----------(L1)C
>     = the=20 assumptions being the same.

This is correct, too, provided that the = B's=20 two interfaces belong to
different links.  For more details about = the=20 scoped addresses
(including link-local and site-local ones) architecture= , see=20
draft-ietf-ipngwg-scoping-arch-xx.txt
(the 01 version is the latest = one,=20 which has already expired, but the
02 version has been submitted and = will=20 soon be out.)
 
Going through scoped address architecture it provides a mechanism = to=20 distinguing the same address belonging to different scopes. What I am = wondering=20 is that
 
a) Couldnt the scope index have been part of the IPv6 address.
b) For upper layers like UDP which identifes a connection based on=20 addresses wouldnt it be better to put the scope index into the address=20 itself.
  One scenario is that we could have the same [source src = port=20 destination dst port ]  pairs from different scopes as in the = scenario=20 earlier seen. Is the upper layer suppose to handle this in a different = manner=20 like having scoped tables.
 
Thanks
Alex
 
 
--=_1E458D0A.B3D23DB3-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 05:58:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26DvRT25299 for ipng-dist; Tue, 6 Mar 2001 05:57:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26DvI125292 for ; Tue, 6 Mar 2001 05:57:18 -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 FAA21171 for ; Tue, 6 Mar 2001 05:57:18 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12304 for ; Tue, 6 Mar 2001 05:57:17 -0800 (PST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA28548; Tue, 6 Mar 2001 08:48:11 -0500 (EST) Message-Id: <4.3.2.7.2.20010306084100.0352dd40@loopback> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Mar 2001 08:48:02 -0500 To: Steve Deering From: Ralph Droms Subject: Re: Question on scopes involving IPv6 addresses Cc: alex r , Alain Ritoux , ipng@sunroof.eng.sun.com In-Reply-To: References: <20010306082558.2870.qmail@web1604.mail.yahoo.com> <20010306082558.2870.qmail@web1604.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the case where L1 and L2 are site local addresses, I think B must be configured so that it doesn't forward site local addresses between its two interfaces (the behavior of B w.r.t. site local addresses wasn't specified in the original message). That is, A and the left-hand interface of B are part of one site while C and the right-hand interface of B are part of a different site. I'll ask for confirmation of this hypothesis, as thinking about site local addresses generally makes my head hurt. - Ralph At 02:50 AM 3/6/2001 -0800, Steve Deering wrote: >At 12:25 AM -0800 3/6/01, alex r wrote: > >Is the following a valid configuration in IPv6. The > >addresses represented in as (L) are either all site > >local or all link local addresses > > > > > > A(L1)---------(L2)B(L1)----------(L2)C > > > >B is connected to two different links / sites. The > >addresses are unique within their respective scopes. > >Yes, that is a valid configuration. > >At 9:38 AM +0100 3/6/01, Alain Ritoux wrote: > >But I wonder if we can push as far as : > > A(L1)---------(L2)B(L2)----------(L1)C > > the assumptions being the same. > >Yes, that one is valid too. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 06:13:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26ECKp25379 for ipng-dist; Tue, 6 Mar 2001 06:12:20 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26ECA125372 for ; Tue, 6 Mar 2001 06:12:10 -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 GAA12007 for ; Tue, 6 Mar 2001 06:12:11 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13002 for ; Tue, 6 Mar 2001 06:12:08 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id VAA10332; Tue, 6 Mar 2001 21:12:02 +0700 (ICT) 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 f26EBvL03930; Tue, 6 Mar 2001 21:11:57 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: Steve Deering , alex r , Alain Ritoux , ipng@sunroof.eng.sun.com Subject: Re: Question on scopes involving IPv6 addresses In-reply-to: Your message of "Tue, 06 Mar 2001 08:48:02 EST." <4.3.2.7.2.20010306084100.0352dd40@loopback> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Mar 2001 21:11:57 +0700 Message-ID: <3928.983887917@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 06 Mar 2001 08:48:02 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20010306084100.0352dd40@loopback> | I'll ask for confirmation of this hypothesis, as thinking about site local | addresses generally makes my head hurt. To be legal yes, that's how it would have to be - B would need to be at a site boundary, and not forwarding site local from one to the other. The comment from the original message "The addresses are unique within their respective scopes." suggests that must be the intent. 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 Mar 6 06:54:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26EqPW25558 for ipng-dist; Tue, 6 Mar 2001 06:52:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26EqF125551 for ; Tue, 6 Mar 2001 06:52:15 -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 GAA26519 for ; Tue, 6 Mar 2001 06:52:15 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22220 for ; Tue, 6 Mar 2001 07:52:11 -0700 (MST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26EqAg06842 for ; Tue, 6 Mar 2001 08:52:10 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 08:52:08 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 08:52:08 -0600 Message-ID: To: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: RE: Question on scopes involving IPv6 addresses Date: Tue, 6 Mar 2001 08:52:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A64D.0304C230" 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_01C0A64D.0304C230 Content-Type: text/plain; charset="iso-2022-jp" Having the scope be part of the IPv6 address or having other distinguishing attribute in the NLA (which is null now) was discussed and rejected. I was supportive of this idea. But it does add an entire address space management part to IPv6 site local addresses. My input is don't go there. Implementations will have to have scoping code following the scope-arch-02 draft architecture. How that is done is and should be implementation specific. I think maintaining tables in an implementation is a question of the type of implementation. I think its better to extend existing OS kernel protocol control block structures and search algorithms to be scope aware. This also means that information can be extracted by user space applications for management of scopes and for source/destination address selection. But all should use the assumption that FF05 prefixes will only exist within a site and will not overlap sites, because they can be duplicated. /jim Going through scoped address architecture it provides a mechanism to distinguing the same address belonging to different scopes. What I am wondering is that a) Couldnt the scope index have been part of the IPv6 address. b) For upper layers like UDP which identifes a connection based on addresses wouldnt it be better to put the scope index into the address itself. One scenario is that we could have the same [source src port destination dst port ] pairs from different scopes as in the scenario earlier seen. Is the upper layer suppose to handle this in a different manner like having scoped tables. Thanks Alex ------_=_NextPart_001_01C0A64D.0304C230 Content-Type: text/html; charset="iso-2022-jp"
 
Having the scope be part of the IPv6 address or having other distinguishing attribute in the NLA (which is null now) was discussed and rejected.
I was supportive of this idea.   But it does add an entire address space management part to IPv6 site local addresses.  My input is don't go there.
Implementations will have to have scoping code following the scope-arch-02 draft architecture.  How that is done is and should be implementation specific.  I think maintaining tables in an implementation is a question of the type of implementation.  I think its better to extend existing OS kernel protocol control block structures and search algorithms to be scope aware.  This also means that information can be extracted by user space applications for management of scopes and for source/destination address selection.  But all should use the assumption that FF05 prefixes will only exist within a site and will not overlap sites, because they can be duplicated.
 
/jim
 
 
 
Going through scoped address architecture it provides a mechanism to distinguing the same address belonging to different scopes. What I am wondering is that
 
a) Couldnt the scope index have been part of the IPv6 address.
b) For upper layers like UDP which identifes a connection based on addresses wouldnt it be better to put the scope index into the address itself.
  One scenario is that we could have the same [source src port destination dst port ]  pairs from different scopes as in the scenario earlier seen. Is the upper layer suppose to handle this in a different manner like having scoped tables.
 
Thanks
Alex
 
 
------_=_NextPart_001_01C0A64D.0304C230-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 07:39:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26Fcsd25744 for ipng-dist; Tue, 6 Mar 2001 07:38:54 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26Fcj125737 for ; Tue, 6 Mar 2001 07:38:45 -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 HAA29516 for ; Tue, 6 Mar 2001 07:38:45 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10774 for ; Tue, 6 Mar 2001 07:38:43 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA26644; Tue, 6 Mar 2001 07:34:25 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <4.3.2.7.2.20010306084100.0352dd40@loopback> References: <20010306082558.2870.qmail@web1604.mail.yahoo.com> <20010306082558.2870.qmail@web1604.mail.yahoo.com> <4.3.2.7.2.20010306084100.0352dd40@loopback> Date: Tue, 6 Mar 2001 07:34:23 -0800 To: Ralph Droms From: Steve Deering Subject: Re: Question on scopes involving IPv6 addresses Cc: alex r , Alain Ritoux , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:48 AM -0500 3/6/01, Ralph Droms wrote: >In the case where L1 and L2 are site local addresses, I think B must >be configured so that it doesn't forward site local addresses between >its two interfaces (the behavior of B w.r.t. site local addresses wasn't >specified in the original message). That is, A and the left-hand >interface of B are part of one site while C and the right-hand >interface of B are part of a different site. That's correct. This is all covered in the aforementioned Scoped Address Architecture draft. >I'll ask for confirmation of this hypothesis, as thinking about site >local addresses generally makes my head hurt. If it helps your head at all, you can analogize this to what an IPv4 router has to do if it is attached to more than one "private" address space (e.g., more than one hunk of real or virtual [as in VPN] topology that reuses the same "net 10" address space). If that just makes your head hurt worse, then forget I suggested it. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:11:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26IAqa26453 for ipng-dist; Tue, 6 Mar 2001 10:10:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26IAg126442 for ; Tue, 6 Mar 2001 10:10: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 KAA01516 for ; Tue, 6 Mar 2001 10:10:42 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18047 for ; Tue, 6 Mar 2001 10:10:41 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26IAeg03021 for ; Tue, 6 Mar 2001 12:10:40 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 12:10:40 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 12:10:39 -0600 Message-ID: To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-scoping-arch-02.txt Date: Tue, 6 Mar 2001 12:10:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, et al (authors), This draft is very good. No issues from me. >From the draft: Authors' note to selves: The Working Group seemed to be in favor of allowing all zone indices for all scopes to have unique values in a sin6 scope id field, e.g., by using the first four bits of the scope id to identify the scope [using the same encoding as the scop field in multicast addresses], and placing the zone id in the remaining 28 bits. This would probably be best specified the advanced API spec, rather than here.) I agree this was consensus. I am ok if its specified here, in the Advanced API, or if you give me the exact words on the mailing list I can put it in the Base API which will be going to IESG for new Info RFC number. That way its a done deal. I can put it in the final edit for the IESG. THen it will also end up in the IEEE 1003.1 std for Base IPv6 API too. 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 Tue Mar 6 10:17:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26IGh226507 for ipng-dist; Tue, 6 Mar 2001 10:16:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26IGX126496 for ; Tue, 6 Mar 2001 10:16:33 -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 KAA02850 for ; Tue, 6 Mar 2001 10:16:33 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20335 for ; Tue, 6 Mar 2001 11:16:32 -0700 (MST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26IIGw14019 for ; Tue, 6 Mar 2001 12:18:16 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 12:16:31 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 12:16:30 -0600 Message-ID: To: paul@francis.com Cc: ipng@sunroof.eng.sun.com Subject: draft-francis-ipngwg-unique-site-local-00.txt Date: Tue, 6 Mar 2001 12:16:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, This is good work and I hope we can revisit this issue now that you have so eloquently documented a proposed solution. I would support this if we must have the beasts. This should be part of IPng agenda IMHO. 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 Tue Mar 6 10:20:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26IJuo26557 for ipng-dist; Tue, 6 Mar 2001 10:19:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26IJl126550 for ; Tue, 6 Mar 2001 10:19:47 -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 KAA28989 for ; Tue, 6 Mar 2001 10:19:46 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22085 for ; Tue, 6 Mar 2001 11:19:45 -0700 (MST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26ILUw14131 for ; Tue, 6 Mar 2001 12:21:30 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 12:19:44 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 12:19:43 -0600 Message-ID: To: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: RE: Question on scopes involving IPv6 addresses Date: Tue, 6 Mar 2001 12:19:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A66A.045B9970" 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_01C0A66A.045B9970 Content-Type: text/plain; charset="iso-2022-jp" Alex, I spoke to quickly I just read Paul Francis's new spec. Could be this may get revisited after all. see: draft-francis-ipngwg-unique-site-local-00.txt regards /jim -----Original Message----- From: Bound Jim (NET/Boston) Sent: Tuesday,March 06,2001 9:52 AM To: 'ext Alex R n'; alain.ritoux@6wind.com; deering@cisco.com; jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: RE: Question on scopes involving IPv6 addresses Having the scope be part of the IPv6 address or having other distinguishing attribute in the NLA (which is null now) was discussed and rejected. I was supportive of this idea. But it does add an entire address space management part to IPv6 site local addresses. My input is don't go there. Implementations will have to have scoping code following the scope-arch-02 draft architecture. How that is done is and should be implementation specific. I think maintaining tables in an implementation is a question of the type of implementation. I think its better to extend existing OS kernel protocol control block structures and search algorithms to be scope aware. This also means that information can be extracted by user space applications for management of scopes and for source/destination address selection. But all should use the assumption that FF05 prefixes will only exist within a site and will not overlap sites, because they can be duplicated. /jim Going through scoped address architecture it provides a mechanism to distinguing the same address belonging to different scopes. What I am wondering is that a) Couldnt the scope index have been part of the IPv6 address. b) For upper layers like UDP which identifes a connection based on addresses wouldnt it be better to put the scope index into the address itself. One scenario is that we could have the same [source src port destination dst port ] pairs from different scopes as in the scenario earlier seen. Is the upper layer suppose to handle this in a different manner like having scoped tables. Thanks Alex ------_=_NextPart_001_01C0A66A.045B9970 Content-Type: text/html; charset="iso-2022-jp"
Alex,
 
I spoke to quickly I just read Paul Francis's new spec.  Could be this may get revisited after all.
see: 

draft-francis-ipngwg-unique-site-local-00.txt

regards

/jim

-----Original Message-----
From: Bound Jim (NET/Boston)
Sent: Tuesday,March 06,2001 9:52 AM
To: 'ext Alex R n'; alain.ritoux@6wind.com; deering@cisco.com; jinmei@isl.rdc.toshiba.co.jp
Cc: ipng@sunroof.eng.sun.com
Subject: RE: Question on scopes involving IPv6 addresses

 
Having the scope be part of the IPv6 address or having other distinguishing attribute in the NLA (which is null now) was discussed and rejected.
I was supportive of this idea.   But it does add an entire address space management part to IPv6 site local addresses.  My input is don't go there.
Implementations will have to have scoping code following the scope-arch-02 draft architecture.  How that is done is and should be implementation specific.  I think maintaining tables in an implementation is a question of the type of implementation.  I think its better to extend existing OS kernel protocol control block structures and search algorithms to be scope aware.  This also means that information can be extracted by user space applications for management of scopes and for source/destination address selection.  But all should use the assumption that FF05 prefixes will only exist within a site and will not overlap sites, because they can be duplicated.
 
/jim
 
 
 
Going through scoped address architecture it provides a mechanism to distinguing the same address belonging to different scopes. What I am wondering is that
 
a) Couldnt the scope index have been part of the IPv6 address.
b) For upper layers like UDP which identifes a connection based on addresses wouldnt it be better to put the scope index into the address itself.
  One scenario is that we could have the same [source src port destination dst port ]  pairs from different scopes as in the scenario earlier seen. Is the upper layer suppose to handle this in a different manner like having scoped tables.
 
Thanks
Alex
 
 
------_=_NextPart_001_01C0A66A.045B9970-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:24:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26INoY26607 for ipng-dist; Tue, 6 Mar 2001 10:23:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26INf126600 for ; Tue, 6 Mar 2001 10:23:41 -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 KAA04668 for ; Tue, 6 Mar 2001 10:23:41 -0800 (PST) Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA09110 for ; Tue, 6 Mar 2001 10:23:40 -0800 (PST) Received: (cpmta 22857 invoked from network); 6 Mar 2001 10:23:36 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.72) with SMTP; 6 Mar 2001 10:23:36 -0800 X-Sent: 6 Mar 2001 18:23:36 GMT Message-ID: <019601c0a66a$7b9e73e0$6601a8c0@smateo1.sfba.home.com> From: "Paul Francis" To: Cc: References: Subject: Re: draft-francis-ipngwg-unique-site-local-00.txt Date: Tue, 6 Mar 2001 10:23:03 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Jim, I already asked Bob to put me on the agenda. PF ----- Original Message ----- From: To: Cc: Sent: Tuesday, March 06, 2001 10:16 AM Subject: draft-francis-ipngwg-unique-site-local-00.txt > Paul, > > This is good work and I hope we can revisit this issue now that you have so > eloquently documented a proposed solution. > I would support this if we must have the beasts. > > This should be part of IPng agenda IMHO. > > 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 Tue Mar 6 10:31:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26IUkq26678 for ipng-dist; Tue, 6 Mar 2001 10:30:46 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26IUb126671 for ; Tue, 6 Mar 2001 10:30:38 -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 KAA09839 for ; Tue, 6 Mar 2001 10:30:33 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04409 for ; Tue, 6 Mar 2001 10:30:22 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26IUFg05447 for ; Tue, 6 Mar 2001 12:30:15 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 12:30:11 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 12:30:10 -0600 Message-ID: To: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: RE: Question on scopes involving IPv6 addresses Date: Tue, 6 Mar 2001 12:30:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A66B.7A321D30" 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_01C0A66B.7A321D30 Content-Type: text/plain; charset="iso-2022-jp" whoops FF05 below should have been FF05 and FEC0. the new addr-scope-arch-02 draft takes care of this too nicely. I am not sure in that draft using different routing tables for each zone is best in ALL iimplementation cases. I can think of several where it is not. /jim Having the scope be part of the IPv6 address or having other distinguishing attribute in the NLA (which is null now) was discussed and rejected. I was supportive of this idea. But it does add an entire address space management part to IPv6 site local addresses. My input is don't go there. Implementations will have to have scoping code following the scope-arch-02 draft architecture. How that is done is and should be implementation specific. I think maintaining tables in an implementation is a question of the type of implementation. I think its better to extend existing OS kernel protocol control block structures and search algorithms to be scope aware. This also means that information can be extracted by user space applications for management of scopes and for source/destination address selection. But all should use the assumption that FF05 prefixes will only exist within a site and will not overlap sites, because they can be duplicated. ------_=_NextPart_001_01C0A66B.7A321D30 Content-Type: text/html; charset="iso-2022-jp"
whoops FF05 below should have been FF05 and FEC0.  the new addr-scope-arch-02 draft takes care of this too nicely.  I am not sure in that draft using different routing tables for each zone is best in ALL iimplementation cases.  I can think of several where it is not.
/jim
 
Having the scope be part of the IPv6 address or having other distinguishing attribute in the NLA (which is null now) was discussed and rejected.
I was supportive of this idea.   But it does add an entire address space management part to IPv6 site local addresses.  My input is don't go there.
Implementations will have to have scoping code following the scope-arch-02 draft architecture.  How that is done is and should be implementation specific.  I think maintaining tables in an implementation is a question of the type of implementation.  I think its better to extend existing OS kernel protocol control block structures and search algorithms to be scope aware.  This also means that information can be extracted by user space applications for management of scopes and for source/destination address selection.  But all should use the assumption that FF05 prefixes will only exist within a site and will not overlap sites, because they can be duplicated.
 
------_=_NextPart_001_01C0A66B.7A321D30-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:48:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26IkuK26784 for ipng-dist; Tue, 6 Mar 2001 10:46:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26Ikj126773 for ; Tue, 6 Mar 2001 10:46:46 -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 KAA14187 for ; Tue, 6 Mar 2001 10:46:42 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12638 for ; Tue, 6 Mar 2001 10:46:25 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id BAA21869; Wed, 7 Mar 2001 01:46:16 +0700 (ICT) 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 f26Ik5L17935; Wed, 7 Mar 2001 01:46:09 +0700 (ICT) From: Robert Elz To: Jim.Bound@nokia.com cc: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: Question on scopes involving IPv6 addresses In-reply-to: Your message of "Tue, 06 Mar 2001 12:19:43 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Mar 2001 01:46:05 +0700 Message-ID: <17933.983904365@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Mar 2001 12:19:43 -0600 From: Jim.Bound@nokia.com Message-ID: | I spoke to quickly I just read Paul Francis's new spec. Could be this may | get revisited after all. They're actually two different issues - though perhaps related. Paul's draft won't do a thing towards allowing the address scope to not be a separate parameter (one way or another), which is what Alex was asking about I think. In fact, if anything, it finally removes that possibility completely. The only way the two could co-exist would be to remove the default site local (the current one) as a possible address completely, and to insist that all site local addresses be unique (not just nearly unique). As things are, there's still the (strong because of the default case) possibility that site local addresses aren't unique in two links out of a site border node. And in any case, there would be link locals to deal with. There was a proposal way back to simply embed the (local) scope identifier in the address, as an API mechanism, so applications would have one less thing to worry about. At the application level that could have worked (before Paul's draft - now there are no bits left in site locals to steak (borrow) for the purpose). As an interface from the transport protocols it wouldn't have worked however - the transport protocol needs to know the actual address bits so it can correctly compute its header checksum. Trying to specify how the transport protocol should mask out some bits of the addresses (in some cases) would be a bit on the hairy side. That is, unless the extra bits were carried on the wire - which seems like (but isn't) what Paul is proposing for site locals - where it actually could be done reasonably easily, but for link locals it turns out to be a non-trivial problem. 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 Mar 6 11:10:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26J94v26901 for ipng-dist; Tue, 6 Mar 2001 11:09:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26J8t126894 for ; Tue, 6 Mar 2001 11:08:55 -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 LAA19715 for ; Tue, 6 Mar 2001 11:08:55 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29402 for ; Tue, 6 Mar 2001 11:08:55 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26J8sg10414 for ; Tue, 6 Mar 2001 13:08:54 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 13:08:54 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 13:08:54 -0600 Message-ID: To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-site-prefixes-05.txt Date: Tue, 6 Mar 2001 13:08:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Hi Erik, This is looking good. I like the middle ground you adopted. Need to read again to check the Mobile node implications. I don't see away around it but I hate to see us encapsulate yet another new protocol for COA in MIPv6. I might suggest some wording in this spec that using Global Addresses avoids all the management and performance costs in the router (HA) if a mobile node at home using site-local address when moving gets a Global address and sends binding updates to all before it leaves home. This type of policy will benefit greatly operation of MIPv6 IMO. But the draft looks good. Seems like you should be on the IPng agenda. If we nail down: scope-arch near-unique-sitelocal-addresses your site prefix draft src addr selection We will have enough as implementors to begin adding robust scoping to the code base to support this in the IPv6 architecture. 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 Tue Mar 6 11:27:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26JQFl26983 for ipng-dist; Tue, 6 Mar 2001 11:26:15 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26JQ5126976 for ; Tue, 6 Mar 2001 11:26:06 -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 LAA22021 for ; Tue, 6 Mar 2001 11:26:05 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07778 for ; Tue, 6 Mar 2001 11:26:02 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f26JMNd43694; Tue, 6 Mar 2001 20:22: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 UAA01382; Tue, 6 Mar 2001 20:22:23 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f26JMLA59835; Tue, 6 Mar 2001 20:22:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103061922.f26JMLA59835@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Jim.Bound@nokia.com, RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: Question on scopes involving IPv6 addresses In-reply-to: Your message of Wed, 07 Mar 2001 01:46:05 +0700. <17933.983904365@brandenburg.cs.mu.OZ.AU> Date: Tue, 06 Mar 2001 20:22:21 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: There was a proposal way back to simply embed the (local) scope identifier in the address, as an API mechanism, so applications => this was already proposed and rejected. Some of us still use this internally in their kernel and should be able to explain why this is not a so good idea... would have one less thing to worry about. At the application level that could have worked (before Paul's draft - now there are no bits left in site locals to steak (borrow) for the purpose). => PS: I don't believe this is the Paul's idea which is more a new version of Christian's one (i.e. a new attempt to make site-local addresses live again, periodic discussion like the ASCII/last-smart format of RFCs, with same conclusions (too difficult, keep them where they are, and keep the ASCII format :-)). 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 Mar 6 12:23:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26KMcN27174 for ipng-dist; Tue, 6 Mar 2001 12:22:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26KMS127167; Tue, 6 Mar 2001 12:22:29 -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 MAA06615; Tue, 6 Mar 2001 12:22:27 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03768; Tue, 6 Mar 2001 12:22:26 -0800 (PST) Received: from Kniveton.com (nokia-3.Connectathon.ORG [130.128.65.3]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f26KKnb43793; Tue, 6 Mar 2001 12:20:49 -0800 (PST) Message-ID: <3AA5464C.C65029C1@Kniveton.com> Date: Tue, 06 Mar 2001 12:19:24 -0800 From: root Organization: NOKIA Research X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-1-mip i686) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: alh-ietf@tndh.net, Erik Nordmark , Mattias Pettersson , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types References: <200103060948.f269mhA55544@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 Francis Dupont wrote: > In your previous mail you wrote: > > => this thread was completely messed by the mobile-ip mailing list bug: > I believe a summary is needed in order to understand ideas and > their chain. You might be able to find the thread on the IPng group since I crossposted there. My message which describes the problem is "New idea for Router Sol/Adv and Mobility," which should fill you in. If you can't find that, let me know and I will forward some of the messages to you. > On one hand I agree with Erik that new types are better than overloading the > semantics unnecessarily. The basic problem I am having with this thread is > understanding the problem it is trying to solve. > > => look at my intro (:-). > > Since the HA is required to be in all possible routing paths to my > home subnet (else some parts of the world will never contact the node > when it is mobile), it has to be a function of the last hop router. > > => not exactly. The Home Agent (HA) must be attached to the home link. > If the home link doesn't physically exist then (and only then) your > statement applies. > > The premise of this proposal was that the MN would need to ask the > HA for a prefix so it could configure its home address. Although you might be able to configure *an* home address using the router's prefix, you are supposed to be able to configure *all* home addresses while away from home. The value of this flexibility is debatable, but it certainly seems like a good thing to be able to configure at least more than one address. > > > => the issue is home link renumbering, in particular when the Mobile > Node (MN) is down for a very long period. This is a real problem > but there are far more important problems, for instance the abyssal > performance of secure mobile IPv6 when a MN is booted in visit > (of course having to learn the HA address and the home address will > not improve this). There is a couple of issues. The home link being renumbered while the MN is off, is a subject that I have filed into "for future study" under the rubrick "Mobile Node Bootstrap Problem." However, this thread addresses a more specific problem, which is that Tunneled Router Advertisements, as currently defined in the draft, a. Will *not *work when a MN does not yet have its Home Address b. Add an IPv6-in-IPv6 encapsulation header which is unnecessary There may be more reasons, but these two, especially (a), are probably sufficient to merit solving this problem now (IMHO). > > This thread assumes that: > - the home link is often renumbered > - DNS is not available in the visit network (if it is available > then you need only to configure a name as proposed by Compaq folks) > - home AAA is not available (if it is available then HA and home address > allocation may/should be done by AAA) > - statefull autoconfig will never be available! Sorry, I may have mixed the discussion of these two issues -- mobile bootstrap (for which you did a good job of describing the assumptions), and fleshing out the Tunneled Router Adv/Sol as my original message in this thread describes. It is also noteworthy that the latter does not solve the former, though they are connected; future work is necessary to come up with a general, palatable solution to bootstrapping. > > Since it knows (presumably via configuration) the address of the > HA, (and given the HA has to be in the routing path) it already has a > useable prefix. I have always assumed that the MN is configured with its > home prefix, then it would use the all-routers anycast address to find the > HA. In this case the proposed messages are unnecessary. Clearly I need a > picture to understand why the MN would know its HA, but not its home prefix. > > => there is a dedicated anycast address for HAs (because if HAs are routers, > not all routers are HAs). > I agree this topic is a secondary one and we should throw it into the > for further studies stuff. Of course, I'll strongly object if this is > slowing down the mobile IPv6 draft (BTW, is there an I-D 14?). > > 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 Tue Mar 6 12:49:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f26Km2W27308 for ipng-dist; Tue, 6 Mar 2001 12:48:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26Klr127301 for ; Tue, 6 Mar 2001 12:47:53 -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 MAA11544 for ; Tue, 6 Mar 2001 12:47:52 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12903 for ; Tue, 6 Mar 2001 13:47:49 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26Klmg28513 for ; Tue, 6 Mar 2001 14:47:48 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 14:47:48 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 14:47:46 -0600 Message-ID: To: kre@munnari.OZ.AU Cc: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: RE: Question on scopes involving IPv6 addresses Date: Tue, 6 Mar 2001 14:47:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Paul's draft won't do a thing towards allowing the address scope to > not be a separate parameter (one way or another), which is what Alex > was asking about I think. In fact, if anything, it finally removes > that possibility completely. The only way the two could co-exist > would be to remove the default site local (the current one) as a > possible address completely, and to insist that all site local > addresses be unique (not just nearly unique). As things are, there's > still the (strong because of the default case) possibility that > site local addresses aren't unique in two links out of a site border > node. It extends bits to the left of the SLA to be used to differentiate one site from the other and it does solve Alex's problem in a different way. Thats all I mean't. > > And in any case, there would be link locals to deal with. > That has nothing to do with site locals FE80 vs FEC0 is pretty easy to parse. /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 Tue Mar 6 23:04:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2773Cr28957 for ipng-dist; Tue, 6 Mar 2001 23:03:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27732128946 for ; Tue, 6 Mar 2001 23:03:02 -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 XAA15643 for ; Tue, 6 Mar 2001 23:03:02 -0800 (PST) Received: from ratree.psu.ac.th (ratree.psu.ac.th [192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA18857 for ; Tue, 6 Mar 2001 23:02:45 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id OAA09839; Wed, 7 Mar 2001 14:02:31 +0700 (ICT) 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 f2772IX01633; Wed, 7 Mar 2001 14:02:18 +0700 (ICT) From: Robert Elz To: Jim.Bound@nokia.com cc: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: Question on scopes involving IPv6 addresses In-reply-to: Your message of "Tue, 06 Mar 2001 14:47:47 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Mar 2001 14:02:18 +0700 Message-ID: <1631.983948538@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Mar 2001 14:47:47 -0600 From: Jim.Bound@nokia.com Message-ID: | It extends bits to the left of the SLA to be used to differentiate one site | from the other No, it can't, because the addresses aren't guaranteed to be unique. What it does is mean that sites are less likely (much much less likely) to need to renumber their site local addresses when they merge (or choose to use their site locals to implement a VPN, so they're immune from global address renumbering as a unit - which is close to the same thing as a merger though the sites probably wouldn't want to use that word). Site differentiation still has to be done using the procedures that are in place now for site locals that aren't even slightly unique. so... | and it does solve Alex's problem in a different way. it doesn't - and I think for rational discussion of Paul's draft, that needs to be very clearly understood. All that draft really does is says "These MBZ bits in site local addresses, well, they no longer MBZ" - and then goes on to give a sane procedure for picking the value to put in those bits to minimise the chances of a collision (it probably goes slightly overboard in the way that is mandated, but that is perhaps a good thing). Please, no-one read more into it than that - as it is, I see no reason why the proposal shouldn't be accepted without even a lot of discussion (the draft needs a good fraction of its content ripped out - I have been discussing that with Paul off the list, but that doesn't affect the basic idea or point). | That has nothing to do with site locals FE80 vs FEC0 is pretty easy to | pars. Yes .. but if we were using bits in the address to distinguish scopes as Alex asked about (and you may remember I proposed years ago), then it should certainly be done for both link local and site local. Doing just one of those wouldn't make any sense at all (it doesn't reduce the API complexity, which is the only point). 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 Mar 7 02:11:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27AA4129726 for ipng-dist; Wed, 7 Mar 2001 02:10:04 -0800 (PST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27A9q129719 for ; Wed, 7 Mar 2001 02:09:52 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA22773; Wed, 7 Mar 2001 11:09:44 +0100 (MET) Date: Wed, 7 Mar 2001 11:08:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-site-prefixes-05.txt To: Jim.Bound@nokia.com Cc: Erik.Nordmark@eng.sun.com, 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 There is one known problem in the draft that kre discovered. The tweak to the rules to allow an isolated site to work causes problems. The rules say that if the RRset only contains site-local addresses then the RRset is accepted as is i.e. the site-local addresses are used. This causes problems if there are hosts in connected sites which only list site-local addresses in the DNS. For instance, if you have a node in site A which never communicates outside site A it would list one (or more) site-local addresses in the global DNS. The above rule would make all hosts in the internet assume that the host in site A is in fact in their own site. A possible way to fix this is to 1) remove the special rule 2 in section 8.1 and 2) configure the routers to send a site-prefix of fec0::/10 if and only if the site is isolated. (This also implies adding some special rules for the semantics of fec0::0/10 being advertised as a site-prefix.) But, ... kre also pointed out that it would be cleaner to not store the site-local addresses in the DNS but instead have a mechanism to discover them using e.g. the ICMP name lookups exchanges. It would be good to flush out such a proposal and compare it with what is currently in site-prefixes-05. This is a rough straw-man of how such a proposal would work. 1. Only global addresses are stored in DNS. 2. A mechanism (such as the prefix advertisements in site-prefix-05) is used to provide a hint of which global addresses are in the same site. 3. When the hint indicates that an address is in the same site a message exchange is used to verify site-local connectivity and retrieve the peer's site-local address. This can be done by sending an ICMP name lookup with a site-local source address asking for the site-local address(es) of the peer. If there is a reply to the ICMP name lookup site-local communication is possible (since the source of the query was a site-local address) And if the ICMP name lookup returns a site-local address, that address can be used when communicating with the peer. Pro's of such a scheme: - no need to have site-local addresses in the DNS - smaller DNS replies - no transition problem due to nodes accidentally using site-local addresses returned from the DNS without implementing the rules in site-prefixes-05.txt Cons - additional roundtrip to discover site-local addresses. - if the ICMP name lookup fails (after timeout and retransmit) due to temporary failures then communication within a site would use global addresses. Such communication would not be isolated from site renumbering events. - the implementation (getaddrinfo?) would need some code to send the icmp name lookup packets and wait for replies. Same as site-prefix-05.txt - a mobile node can choose whether or not it will have a site-local address or just global addresses. Open issues for such a scheme: - assuming DNS is secured using DNSsec, how do we easily get the same security for the site-local address(es) returned by ICMP name lookup? - if the peer has multiple global addresses should an ICMP name lookup be sent to each global address that is part of the site? Some NICs on the peer might have failed thus sending to all seems more robust. Does anybody want to flush out the details of such a scheme? Or should we try to do this in Minneapolis? 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 Mar 7 08:03:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27G2hi00666 for ipng-dist; Wed, 7 Mar 2001 08:02:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27G2Y100659 for ; Wed, 7 Mar 2001 08:02:34 -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 IAA28718 for ; Wed, 7 Mar 2001 08:02:33 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08559 for ; Wed, 7 Mar 2001 08:02:32 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f27G2Ug23677 for ; Wed, 7 Mar 2001 10:02:30 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Mar 2001 10:02:30 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 7 Mar 2001 10:02:30 -0600 Message-ID: To: kre@munnari.OZ.AU, Jim.Bound@nokia.com Cc: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: RE: Question on scopes involving IPv6 addresses Date: Wed, 7 Mar 2001 10:02:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I interpret the spec completely different than you and discussing it now is a waste of both our time and the mail list. Also this should have nothing to do with link local. Paul can you shed some light on this conversation as Robert and I see your draft solving different problems : thanks........... /jim > -----Original Message----- > From: ext Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Wednesday,March 07,2001 2:02 AM > To: Jim.Bound@nokia.com > Cc: RNalex@novell.com; alain.ritoux@6wind.com; deering@cisco.com; > jinmei@isl.rdc.toshiba.co.jp; ipng@sunroof.eng.sun.com > Subject: Re: Question on scopes involving IPv6 addresses > > > Date: Tue, 6 Mar 2001 14:47:47 -0600 > From: Jim.Bound@nokia.com > Message-ID: > > | It extends bits to the left of the SLA to be used to > differentiate one site > | from the other > > No, it can't, because the addresses aren't guaranteed to be unique. > > What it does is mean that sites are less likely (much much > less likely) > to need to renumber their site local addresses when they merge (or > choose to use their site locals to implement a VPN, so they're immune > from global address renumbering as a unit - which is close to the same > thing as a merger though the sites probably wouldn't want to > use that word). > > Site differentiation still has to be done using the > procedures that are > in place now for site locals that aren't even slightly unique. > > so... > > | and it does solve Alex's problem in a different way. > > it doesn't - and I think for rational discussion of Paul's draft, > that needs to be very clearly understood. All that draft really > does is says "These MBZ bits in site local addresses, well, they > no longer MBZ" - and then goes on to give a sane procedure for > picking the value to put in those bits to minimise the chances of > a collision (it probably goes slightly overboard in the way that > is mandated, but that is perhaps a good thing). > > Please, no-one read more into it than that - as it is, I see no > reason why the proposal shouldn't be accepted without even a lot > of discussion (the draft needs a good fraction of its content > ripped out - I have been discussing that with Paul off the list, > but that doesn't affect the basic idea or point). > > | That has nothing to do with site locals FE80 vs FEC0 is > pretty easy to > | pars. > > Yes .. but if we were using bits in the address to distinguish scopes > as Alex asked about (and you may remember I proposed years ago), then > it should certainly be done for both link local and site local. Doing > just one of those wouldn't make any sense at all (it doesn't > reduce the > API complexity, which is the only point). > > 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 Mar 7 14:35:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27MYQp02054 for ipng-dist; Wed, 7 Mar 2001 14:34:26 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27MYG102047 for ; Wed, 7 Mar 2001 14:34:17 -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 OAA16045 for ; Wed, 7 Mar 2001 14:34:17 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA21239 for ; Wed, 7 Mar 2001 14:34:16 -0800 (PST) Received: (cpmta 16877 invoked from network); 7 Mar 2001 14:34:15 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.71) with SMTP; 7 Mar 2001 14:34:15 -0800 X-Sent: 7 Mar 2001 22:34:15 GMT Message-ID: <009301c0a756$b5da9100$1500a8c0@dellchan> From: "Paul Francis" To: , Cc: , , , , References: Subject: Re: Question on scopes involving IPv6 addresses Date: Wed, 7 Mar 2001 14:34:01 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I interpret the spec completely different than you and discussing it now is > a waste of both our time and the mail list. Also this should have nothing > to do with link local. > > Paul can you shed some light on this conversation as Robert and I see your > draft solving different problems : thanks........... > I don't undestand the first thing about scoped addresses. Robert's interpretation is correct. All my draft says is that a site can reduce the probability of prefix collisions with other sites by unilaterally sticking a random number in the "zeros" field. In no way does it intend to change the semantics or handling of the site local address (with the exception that it reduces the frequency of renumbering events and/or allows two sites to interconnect more easily). Having said that, it is a well-known fact that if an IETFian finds a hammer lying on the gound, he/she will use it to do almost anything, except perhaps hammer nails. So I suppose there is some danger in making site-locals near unique. PF ps. Dupont's comments (can't call him Francis, can I...sort of a scoping problem) that this is Christian's idea not mine is 100% true. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 03:56:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28Btaf08598 for ipng-dist; Thu, 8 Mar 2001 03:55:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28BtI108587 for ; Thu, 8 Mar 2001 03:55:18 -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 DAA15741 for ; Thu, 8 Mar 2001 03:55:18 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21505 for ; Thu, 8 Mar 2001 03:55:17 -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 GAA22066; Thu, 8 Mar 2001 06:55:16 -0500 (EST) Message-Id: <200103081155.GAA22066@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-ipaddressassign-02.txt Date: Thu, 08 Mar 2001 06:55:16 -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 IPNG Working Group of the IETF. Title : A flexible method for managing the assignment of bites of an IPv6 address block Author(s) : M. Blanchet Filename : draft-ietf-ipngwg-ipaddressassign-02.txt Pages : 13 Date : 07-Mar-01 This document presents a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for allocating address ranges to its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC1219 and can be used for IPv6 assignments based on RFC2373 and RFC2374. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipaddressassign-02.txt 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-ipaddressassign-02.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-ipaddressassign-02.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: <20010307141834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipaddressassign-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipaddressassign-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307141834.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 Thu Mar 8 07:35:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28FXxF09190 for ipng-dist; Thu, 8 Mar 2001 07:34:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28FXo109183 for ; Thu, 8 Mar 2001 07:33:50 -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 HAA08748 for ; Thu, 8 Mar 2001 07:33:50 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10859 for ; Thu, 8 Mar 2001 07:33:00 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f28FWpg03421 for ; Thu, 8 Mar 2001 09:33:01 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 8 Mar 2001 09:32:49 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 8 Mar 2001 09:32:49 -0600 Message-ID: To: paul@francis.com, Jim.Bound@nokia.com, kre@munnari.OZ.AU Cc: RNalex@novell.com, alain.ritoux@6wind.com, deering@cisco.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: RE: Question on scopes involving IPv6 addresses Date: Thu, 8 Mar 2001 09:32:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Paul. OK. I would not use it to alter the boundaries imposed by scoped site architecture which is a good set of boundaries. I may have used the hammer to avoid 2 faced DNS though. Seems like now I should not do that. /jim > -----Original Message----- > From: ext Paul Francis [mailto:paul@francis.com] > Sent: Wednesday,March 07,2001 5:34 PM > To: Jim.Bound@nokia.com; kre@munnari.OZ.AU > Cc: RNalex@novell.com; alain.ritoux@6wind.com; deering@cisco.com; > jinmei@isl.rdc.toshiba.co.jp; ipng@sunroof.eng.sun.com > Subject: Re: Question on scopes involving IPv6 addresses > > > > > > I interpret the spec completely different than you and > discussing it now > is > > a waste of both our time and the mail list. Also this > should have nothing > > to do with link local. > > > > Paul can you shed some light on this conversation as Robert > and I see your > > draft solving different problems : thanks........... > > > > I don't undestand the first thing about scoped addresses. Robert's > interpretation is correct. All my draft says is that a site > can reduce the > probability of prefix collisions with other sites by > unilaterally sticking a > random number in the "zeros" field. In no way does it intend > to change the > semantics or handling of the site local address (with the > exception that it > reduces the frequency of renumbering events and/or allows two sites to > interconnect more easily). > > Having said that, it is a well-known fact that if an IETFian > finds a hammer > lying on the gound, he/she will use it to do almost anything, > except perhaps > hammer nails. So I suppose there is some danger in making > site-locals near > unique. > > PF > > ps. Dupont's comments (can't call him Francis, can I...sort > of a scoping > problem) that this is Christian's idea not mine is 100% true. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 09:38:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28HbaF09642 for ipng-dist; Thu, 8 Mar 2001 09:37:36 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28HbQ109635 for ; Thu, 8 Mar 2001 09:37:26 -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 JAA24051 for ; Thu, 8 Mar 2001 09:37:25 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA11046 for ; Thu, 8 Mar 2001 09:37:23 -0800 (PST) Received: (cpmta 8211 invoked from network); 8 Mar 2001 09:37:15 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.71) with SMTP; 8 Mar 2001 09:37:15 -0800 X-Sent: 8 Mar 2001 17:37:15 GMT Message-ID: <080001c0a7f6$63d0de00$1500a8c0@dellchan> From: "Paul Francis" To: , Cc: , , , , References: Subject: Re: Question on scopes involving IPv6 addresses Date: Thu, 8 Mar 2001 09:29:36 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > thanks Paul. OK. I would not use it to alter the boundaries imposed by > scoped site architecture which is a good set of boundaries. I may have used > the hammer to avoid 2 faced DNS though. Seems like now I should not do > that. > My comment about the hammer was stupid. What I said about not knowing anything about scoped addresses is true. I don't know the issues there, so I don't know whether trying to take extend near-uniques, or at least read more into them than I meant, is a good idea or not. But I do believe that trying to do make site-locals absolutely 100% guarenteed unique is not practical, so any mechanisms that depend on that have a big strike against them. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 9 04:35:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29CYnm15531 for ipng-dist; Fri, 9 Mar 2001 04:34:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29CYT115521 for ; Fri, 9 Mar 2001 04:34: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 EAA05335 for ; Fri, 9 Mar 2001 04:34:28 -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 EAA06121 for ; Fri, 9 Mar 2001 04:34:28 -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 HAA11518; Fri, 9 Mar 2001 07:34:26 -0500 (EST) Message-Id: <200103091234.HAA11518@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-scoping-arch-02.txt Date: Fri, 09 Mar 2001 07:34:25 -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 IPNG Working Group of the IETF. Title : IP Version 6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe, B. Zill Filename : draft-ietf-ipngwg-scoping-arch-02.txt Pages : 19 Date : 08-Mar-01 This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-02.txt 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-scoping-arch-02.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-scoping-arch-02.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: <20010308110746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoping-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110746.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 Mar 9 04:36:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29CYj815530 for ipng-dist; Fri, 9 Mar 2001 04:34:45 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29CYP115509 for ; Fri, 9 Mar 2001 04:34:25 -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 EAA05907 for ; Fri, 9 Mar 2001 04:34:24 -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 EAA27629 for ; Fri, 9 Mar 2001 04:34:23 -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 HAA11506; Fri, 9 Mar 2001 07:34:21 -0500 (EST) Message-Id: <200103091234.HAA11506@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-addr-arch-v3-05.txt Date: Fri, 09 Mar 2001 07:34:21 -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 IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-05.txt Pages : 25 Date : 08-Mar-01 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-05.txt 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-addr-arch-v3-05.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-addr-arch-v3-05.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: <20010308110737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110737.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 Mar 9 09:41:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29He2q16755 for ipng-dist; Fri, 9 Mar 2001 09:40:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29Hdr116748 for ; Fri, 9 Mar 2001 09:39:54 -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 JAA27507 for ; Fri, 9 Mar 2001 09:39:53 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22607 for ; Fri, 9 Mar 2001 09:39:52 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29Hdhg24913 for ; Fri, 9 Mar 2001 11:39:53 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Mar 2001 11:39:41 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 9 Mar 2001 11:39:41 -0600 Message-ID: To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-default-addr-select-03.txt Date: Fri, 9 Mar 2001 11:39:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I strongly object to Temporary Addresses being preferred over Public Addresses in source address selection. The reason is that most communications of IPv6 will not be on the Internet but on Intranets. The default should reflect that reality. And a web server should be using a public address that can last for weeks. I also object to the notion that temporary addresses and why they exist is the norm. 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 Fri Mar 9 10:29:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29ISgJ17071 for ipng-dist; Fri, 9 Mar 2001 10:28:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29IRm117049; Fri, 9 Mar 2001 10:27:48 -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 KAA27896; Fri, 9 Mar 2001 10:27:48 -0800 (PST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18444; Fri, 9 Mar 2001 10:27:47 -0800 (PST) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f29IXI150556; Fri, 9 Mar 2001 13:33:18 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010309131857.02e619b0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 09 Mar 2001 13:27:56 -0500 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Marc Blanchet Subject: ipv6 on the ietf network Cc: itojun@iijlab.net Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Itojun and us have been providing IPv6 connectivity since Chicago IETF to the ietf network during ietf events. But, this was always aside, having no or very minimal support from the host. This situation was acceptable two years ago. I don't think it is still acceptable. If you believe in IPv6 and are using it daily as many of us do, we need REAL commitment from the IETF organisation: IPv6 connectivity on the ietf network should be on the same support level and same commitment from the host and secretariat. And, if, for the ietf own use (ietf events network), ipv6 is second class compared to IPv4, how could we clearly convince outsiders about the benefits of IPv6? This message is asking for support from you, specially the ones that have direct seats on the iesg/iab or have influence on the ietf organisation to get IPv6 being not an "accident" on the ietf network, but a standard, supported, announced at the same time, at the same level as IPv4. Sorry, this is not a technical mail. Marc, who is still happy to help and provide IPv6 connectivity, but is looking for commitment from the organisation that designed IPv6... PS. please understand that this message is not targetted to any individual or any specific event. It is a general comment. Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 9 10:33:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29IWGx17112 for ipng-dist; Fri, 9 Mar 2001 10:32:16 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29IW4117101 for ; Fri, 9 Mar 2001 10:32: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 KAA07525 for ; Fri, 9 Mar 2001 10:32:04 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20514 for ; Fri, 9 Mar 2001 10:32:01 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id NAA12201; Fri, 9 Mar 2001 13:31:28 -0500 (EST) Date: Fri, 9 Mar 2001 13:31:28 -0500 (EST) From: Scott Bradner Message-Id: <200103091831.NAA12201@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, Jim.Bound@nokia.com Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd say that if someone is using Temporary Addresses then they mean them to be the ones chosen - if they are in an Intranet I would not expect them to be using Temporary Addresses in teh 1st place 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 Fri Mar 9 10:58:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29IvZc17211 for ipng-dist; Fri, 9 Mar 2001 10:57:35 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29IvV117204 for ; Fri, 9 Mar 2001 10:57:31 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f29IspL05524 for ipng@sunroof.eng.sun.com; Fri, 9 Mar 2001 10:54:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f297gq114592 for ; Thu, 8 Mar 2001 23:42:52 -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 XAA11522 for ; Thu, 8 Mar 2001 23:42:53 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA15207 for ; Thu, 8 Mar 2001 23:42:52 -0800 (PST) Received: from rufsun5.ffm.fgan.de (mailhost.ffm.fgan.de [128.7.2.5]) by mailguard.fgan.de (8.9.3/8.9.3) with ESMTP id IAA25125 for ; Fri, 9 Mar 2001 08:42:51 +0100 Received: from unna.ffm.fgan.de (unna.ffm.fgan.de [128.7.5.14]) by rufsun5.ffm.fgan.de (8.8.6/8.8.8) with ESMTP id IAA13578 for ; Fri, 9 Mar 2001 08:42:50 +0100 (MET) Received: from unna.ffm.fgan.de (unna.ffm.fgan.de [128.7.5.14]) by unna.ffm.fgan.de (8.9.1b+Sun/8.9.1) with SMTP id IAA25041 for ; Fri, 9 Mar 2001 08:42:50 +0100 (MET) Message-Id: <200103090742.IAA25041@unna.ffm.fgan.de> Date: Fri, 9 Mar 2001 08:42:50 +0100 (MET) From: Peter Sevenich Reply-To: Peter Sevenich Subject: Switch of UDP-Checksum To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nOWnMA8Lnx+qDGDBFA/SmA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I like to switch of the UDP-checksummechanisum for realtime-data-transmission on narrowband links. This was possible in the old UDP (IPv4) definition. I think in IPv6 it's not longer possible. Is that right or is there a way to switch it of ? Peter +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Peter Sevenich + + FGAN/FKIE/KOM + + Neuenahrer Str. 20 + + D-53343 Wachtberg-Werthhoven + + Germany + + Phone +49-228-9435-317 + + Fax +49-228-9435-685 + + e-mail sevenich@fgan.de + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 9 16:29:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2A0ScF18990 for ipng-dist; Fri, 9 Mar 2001 16:28:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2A0ST118983; Fri, 9 Mar 2001 16:28:29 -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 QAA25317; Fri, 9 Mar 2001 16:28:28 -0800 (PST) From: Ronald.vanderPol@surfnet.nl Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23391; Fri, 9 Mar 2001 16:28:27 -0800 (PST) Received: from spock.ncc-1701.surfnet.nl ([192.87.111.34]) by survis.surfnet.nl with ESMTP (exPP) id 14bXFC-0000wv-00; Sat, 10 Mar 2001 01:28:26 +0100 Date: Sat, 10 Mar 2001 01:28:26 +0100 (CET) X-X-Sender: To: Marc Blanchet cc: , , Subject: Re: (ngtrans) ipv6 on the ietf network In-Reply-To: <5.0.2.1.1.20010309131857.02e619b0@mail.viagenie.qc.ca> Message-ID: Organisation: SURFnet bv Address: "Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL" Phone: +31 302 305 305 Telefax: +31 302 305 329 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 9 Mar 2001, Marc Blanchet wrote: > If you believe in IPv6 and are using it daily as many of us do, we need > REAL commitment from the IETF organisation: IPv6 connectivity on the ietf > network should be on the same support level and same commitment from the > host and secretariat. I think wireless LAN is more or less standard at IETFs now because there is a strong demand for it and many people use it. So lets all use IPv6 at the next IETF as much as possible and show there is a large demand and many people use it. I guess Itojun will provide usage numbers again. I hope those numbers show an increasing amount of IPv6 users at IETFs during the last few years. Maybe the 802.11b network in the ngtrans and ipng rooms should be IPv6 only :-) BTW, the last few years the RIPE staff have provided IPv6 connectivity at the RIPE meetings. rvdp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 9 16:38:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2A0bFd19064 for ipng-dist; Fri, 9 Mar 2001 16:37:15 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2A0aQ119042; Fri, 9 Mar 2001 16:36:27 -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 QAA23153; Fri, 9 Mar 2001 16:36:27 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24363; Fri, 9 Mar 2001 16:36:25 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA09924; Sat, 10 Mar 2001 09:36:23 +0900 (JST) to: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: Ronald.vanderPol's message of Sat, 10 Mar 2001 01:28:26 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) ipv6 on the ietf network From: itojun@iijlab.net Date: Sat, 10 Mar 2001 09:36:23 +0900 Message-ID: <9922.984184583@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think wireless LAN is more or less standard at IETFs now because there >is a strong demand for it and many people use it. > >So lets all use IPv6 at the next IETF as much as possible and show there >is a large demand and many people use it. I guess Itojun will provide >usage numbers again. I hope those numbers show an increasing amount of >IPv6 users at IETFs during the last few years. There are situations where IPv6 becomes mandatory at conferences - DHCP address pool shortage. Because there are a lot of 802.11 users, and the number of laptop/802.11 users increase, it is getting harder to estimate # of users on wireless segment (with wired ethernet we could set an upper limit by # of wires). At USENIX annual few years ago, DHCP lease time was set to too large value, and DHCP address pool went totally sold out. I was doing just fine because I used IPv6 :-) >Maybe the 802.11b network in the ngtrans and ipng rooms should be >IPv6 only :-) we should be IPv6-only at Tokyo IETF meeting, year 2002 :-) >BTW, the last few years the RIPE staff have provided IPv6 connectivity >at the RIPE meetings. great! maybe we need to supply easy-to-setup configuration for terminal room team. I'll be very happy to help. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 9 16:49:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2A0m8Y19109 for ipng-dist; Fri, 9 Mar 2001 16:48:08 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2A0ls119101 for ; Fri, 9 Mar 2001 16:47:54 -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 QAA02907 for ; Fri, 9 Mar 2001 16:47:51 -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 RAA26266 for ; Fri, 9 Mar 2001 17:47:50 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14bXXo-000DND-00; Fri, 09 Mar 2001 16:47:40 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Marc Blanchet Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, itojun@iijlab.net Subject: Re: (ngtrans) ipv6 on the ietf network References: <5.0.2.1.1.20010309131857.02e619b0@mail.viagenie.qc.ca> Message-Id: Date: Fri, 09 Mar 2001 16:47:40 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk back in '95 or so, the dhcp server for a few ietfs was my laptop, which i left plugged in for the whole meeting. eventually the ACTUAL USE of dhcp became sufficiently large that it became obvious thit this was a useful service and worth the extra pain. and so it became normal for the host to provide it. i presume that ACTUALY USE will eventually cause ipv6 to be standard fare at the meetings. i suspect that what we have here is a micro-example of our problem in the general market, the benefits of ipv6 are not perceived as sufficiently compelling. we need to change that, not by demanding, but by making the benefits significantly better and better perceived. 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 Sat Mar 10 07:12:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2AFBAN19746 for ipng-dist; Sat, 10 Mar 2001 07:11:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2AFAn119739 for ; Sat, 10 Mar 2001 07:11:01 -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 HAA19950 for ; Sat, 10 Mar 2001 07:10:49 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02160 for ; Sat, 10 Mar 2001 07:10:48 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2AFAid19504; Sat, 10 Mar 2001 16:10:45 +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 QAA04906; Sat, 10 Mar 2001 16:10:44 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2AFAhA86835; Sat, 10 Mar 2001 16:10:43 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103101510.f2AFAhA86835@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim.Bound@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt In-reply-to: Your message of Fri, 09 Mar 2001 11:39:32 CST. Date: Sat, 10 Mar 2001 16:10:43 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I strongly object to Temporary Addresses being preferred over Public Addresses in source address selection. The reason is that most communications of IPv6 will not be on the Internet but on Intranets. The default should reflect that reality. And a web server should be using a public address that can last for weeks. => there are two issues: - what are the defaults? = how to change them? Of course if the second issue is solved then the first one becomes a matter of taste/personal choice of implementers. Unfortunately if there are some nice policy hooks they don't apply to the temporary/public choice (or the home/care-of one). I strongly suggest to add in the document some reasonable hooks (reasonable = something which can be set in the context of applications, not only a setsockopt) for this kind of policies... Regards Francis.Dupont@enst-bretagne.fr BTW I share Jim's opinion about temporary addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 10 09:00:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2AGxCI19806 for ipng-dist; Sat, 10 Mar 2001 08:59:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2AGx2119799 for ; Sat, 10 Mar 2001 08:59:03 -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 IAA16227 for ; Sat, 10 Mar 2001 08:59:02 -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 IAA27628 for ; Sat, 10 Mar 2001 08:59:02 -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 IAA19139; Sat, 10 Mar 2001 08:59:02 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2AGwxj11826; Sat, 10 Mar 2001 08:58:59 -0800 X-mProtect: Sat, 10 Mar 2001 08:58: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(WTS.12.69) smtpdXmPiZn; Sat, 10 Mar 2001 08:58:50 PST Message-ID: <3AAA5D8F.6D191D8@iprg.nokia.com> Date: Sat, 10 Mar 2001 08:59:59 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt References: <200103101510.f2AFAhA86835@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, I'd like to suggest that all addresses are temporary. And I'd like further to suggest that an application should be allowed to pick some of the attributes of the IPv6 address it uses -- for instance, whether it's a "well-known" ("Public") address or one that is more evanascent and evaporates after the application is done. This application _might_ be a window manager, for instance, so that all applications running in a window inherit the "privacy" attributes (including address evanescence) of the window itself. And so on. These are not protocol attributes, but protocols can be built to impede their implementation. I am afraid that exactly such a thing is happening now. Regards, Charlie P. PS. For instance, it probably isn't any longer possible for an application to get a new IPv6 address if it feels like it needs one. Francis Dupont wrote: > In your previous mail you wrote: > > I strongly object to Temporary Addresses being preferred over Public > Addresses in source address selection. > > The reason is that most communications of IPv6 will not be on the Internet > but on Intranets. The default should reflect that reality. > > And a web server should be using a public address that can last for weeks. > > => there are two issues: > - what are the defaults? > = how to change them? > Of course if the second issue is solved then the first one becomes > a matter of taste/personal choice of implementers. Unfortunately > if there are some nice policy hooks they don't apply to the > temporary/public choice (or the home/care-of one). I strongly > suggest to add in the document some reasonable hooks (reasonable = > something which can be set in the context of applications, not > only a setsockopt) for this kind of policies... > > Regards > > Francis.Dupont@enst-bretagne.fr > > BTW I share Jim's opinion about temporary addresses. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sat Mar 10 11:22:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2AJL4Y19964 for ipng-dist; Sat, 10 Mar 2001 11:21:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2AJKr119957 for ; Sat, 10 Mar 2001 11:20:53 -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 LAA08533 for ; Sat, 10 Mar 2001 11:20:50 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19050 for ; Sat, 10 Mar 2001 11:20:50 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA03680; Sat, 10 Mar 2001 11:20:32 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <200103090742.IAA25041@unna.ffm.fgan.de> References: <200103090742.IAA25041@unna.ffm.fgan.de> Date: Sat, 10 Mar 2001 11:20:32 -0800 To: Peter Sevenich From: Steve Deering Subject: Re: Switch of UDP-Checksum Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:42 AM +0100 3/9/01, Peter Sevenich wrote: >I like to switch of the UDP-checksummechanisum for realtime-data- >transmission on narrowband links. >This was possible in the old UDP (IPv4) definition. I think in IPv6 it's >not longer possible. Is that right or is there a way to switch it of ? Peter, That's right, the UDP checksum is not optional when UDP is run over IPv6. The reason is because IPv6 does not have its own header checksum, so the upper layers (UDP, for example) must provide their own corruption-detection for any IP header fields they rely on for their correct operation. In the case of UDP, that detection is accomplished through the inclusion of the IP "pseudo-header" in the UDP checksum. By the way, it is also a bad idea to turn off UDP checksums when using IPv4, because then you lose the ability to detect corruption of the UDP port numbers and length field. (I presume you don't care about detecting corruption of the UDP payload, or else you wouldn't be asking this question.) There was a proposal called UDP-lite which allowed for checksumming of the UDP header plus IP pseudo-header only, excluding some or all of the UDP payload. I don't recall what the status of the proposal is. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 10 12:17:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2AKGec20001 for ipng-dist; Sat, 10 Mar 2001 12:16:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2AKGS119994 for ; Sat, 10 Mar 2001 12:16:29 -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 MAA25067 for ; Sat, 10 Mar 2001 12:15:37 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28847 for ; Sat, 10 Mar 2001 12:15:36 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id PAA15983; Sat, 10 Mar 2001 15:15:05 -0500 (EST) Date: Sat, 10 Mar 2001 15:15:05 -0500 (EST) From: Scott Bradner Message-Id: <200103102015.PAA15983@newdev.harvard.edu> To: deering@cisco.com, sevenich@fgan.de Subject: Re: Switch of UDP-Checksum Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There was a proposal called UDP-lite which allowed for checksumming of > the UDP header plus IP pseudo-header only, excluding some or all of the > UDP payload. I don't recall what the status of the proposal is. it is being discussed in the tsvwg working group 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 Sun Mar 11 14:26:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMQ9TL022750 for ; Sun, 11 Mar 2001 14:26:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2BMQ8dn022749 for ipng-dist; Sun, 11 Mar 2001 14:26: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMPxTL022742 for ; Sun, 11 Mar 2001 14:25:59 -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 OAA06392 for ; Sun, 11 Mar 2001 14:26:00 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24995 for ; Sun, 11 Mar 2001 14:25:30 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2BMR9w10747 for ; Sun, 11 Mar 2001 16:27:19 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 11 Mar 2001 16:25:19 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Sun, 11 Mar 2001 16:25:19 -0600 Message-ID: To: sob@harvard.edu, ipng@sunroof.eng.sun.com, Jim.Bound@nokia.com Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt Date: Sun, 11 Mar 2001 16:25:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am fine with that if and only if we all are clear and agree that is not mandatory to create them. /jim > -----Original Message----- > From: ext Scott Bradner [mailto:sob@harvard.edu] > Sent: Friday,March 09,2001 1:31 PM > To: ipng@sunroof.eng.sun.com; Jim.Bound@nokia.com > Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt > > > I'd say that if someone is using Temporary Addresses then they mean > them to be the ones chosen - if they are in an Intranet I would not > expect them to be using Temporary Addresses in teh 1st place > > 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 Sun Mar 11 14:29:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMTZTL022770 for ; Sun, 11 Mar 2001 14:29:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2BMTYAo022769 for ipng-dist; Sun, 11 Mar 2001 14: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMTPTL022762 for ; Sun, 11 Mar 2001 14:29:26 -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 OAA03023 for ; Sun, 11 Mar 2001 14:29:26 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAB26416 for ; Sun, 11 Mar 2001 14:29:26 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA29163 for ; Sun, 11 Mar 2001 15:29:25 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA22716 for ; Sun, 11 Mar 2001 15:29:25 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Sun, 11 Mar 2001 16:29:25 -0600 Message-ID: From: Boot John-AJB024 To: "'Francis Dupont'" , Jim.Bound@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt Date: Sun, 11 Mar 2001 16:29:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, with reference to your comment that most IPv6 communication will be on Intranets I am not sure this is correct. As 3G phone systems move to IPv6 then probably most traffic will be Internet not Intranet. Regards John Boot johnboot@mot.com -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] Sent: Saturday, March 10, 2001 9:11 AM To: Jim.Bound@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt In your previous mail you wrote: I strongly object to Temporary Addresses being preferred over Public Addresses in source address selection. The reason is that most communications of IPv6 will not be on the Internet but on Intranets. The default should reflect that reality. And a web server should be using a public address that can last for weeks. => there are two issues: - what are the defaults? = how to change them? Of course if the second issue is solved then the first one becomes a matter of taste/personal choice of implementers. Unfortunately if there are some nice policy hooks they don't apply to the temporary/public choice (or the home/care-of one). I strongly suggest to add in the document some reasonable hooks (reasonable = something which can be set in the context of applications, not only a setsockopt) for this kind of policies... Regards Francis.Dupont@enst-bretagne.fr BTW I share Jim's opinion about temporary addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Sun Mar 11 14:50:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMoBTL022880 for ; Sun, 11 Mar 2001 14:50:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2BMoBZR022879 for ipng-dist; Sun, 11 Mar 2001 14:50: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMo2TL022872 for ; Sun, 11 Mar 2001 14:50:02 -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 OAA19512 for ; Sun, 11 Mar 2001 14:50:03 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27968 for ; Sun, 11 Mar 2001 14:49:42 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2BMpUw10874 for ; Sun, 11 Mar 2001 16:51:30 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 11 Mar 2001 16:49:40 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Sun, 11 Mar 2001 16:49:40 -0600 Message-ID: To: johnboot@motorola.com, Francis.Dupont@enst-bretagne.fr, Jim.Bound@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt Date: Sun, 11 Mar 2001 16:49:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, That was my comment not Francis's. I agree 3GPP will cause much more use of clients on the Internet and I hope so with IPv6. My comment was much more basic. Take 3 Fortune 100 companies who have 50,000 employees each using a desktop and servers in their company. Then exponetiate that number times all the people in just all the companies and we have a lot more IP packets moving around on a daily basis than any projects for any Internet use today. Thats where I was coming from. I object to telling all these users whose packets will NEVER be seen by batman or batwoman hiding in the paranoid minds of those who may also believe my phone conversations are being listened to (and for their sake I hope they are not). I guess I can absorb that someone could take my EUI and figure out over time where and what I am on the Internet. But I believe most code that executes source address selection will be on a private Intranet on a client. So if we can all agree to make sure that no where including the privacy draft rfc 3041 does not mandate that a node MUST create temporary addresses then my issue is NULL and as Scott alluded to. I am ok with that. But even in that case we need to provide a means to denote context to a temporary address based on what is done to the preferred and valid lifetimes on the host and by the host. Thats a missing piece too. /jim > -----Original Message----- > From: ext Boot John-AJB024 [mailto:johnboot@motorola.com] > Sent: Sunday,March 11,2001 5:29 PM > To: 'Francis Dupont'; Jim.Bound@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt > > > Francis, > with reference to your comment that most IPv6 > communication will be > on Intranets I am not sure this is correct. As 3G phone > systems move to IPv6 > then probably most traffic will be Internet not Intranet. > > Regards > John Boot > johnboot@mot.com > > > > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Saturday, March 10, 2001 9:11 AM > To: Jim.Bound@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt > > > In your previous mail you wrote: > > I strongly object to Temporary Addresses being preferred > over Public > Addresses in source address selection. > > The reason is that most communications of IPv6 will not be on the > Internet > but on Intranets. The default should reflect that reality. > > And a web server should be using a public address that can last for > weeks. > > => there are two issues: > - what are the defaults? > = how to change them? > Of course if the second issue is solved then the first one becomes > a matter of taste/personal choice of implementers. Unfortunately > if there are some nice policy hooks they don't apply to the > temporary/public choice (or the home/care-of one). I strongly > suggest to add in the document some reasonable hooks (reasonable = > something which can be set in the context of applications, not > only a setsockopt) for this kind of policies... > > Regards > > Francis.Dupont@enst-bretagne.fr > > BTW I share Jim's opinion about temporary addresses. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sun Mar 11 14:53:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMrjTL022898 for ; Sun, 11 Mar 2001 14:53:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2BMriPa022897 for ipng-dist; Sun, 11 Mar 2001 14:53: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMrXTL022890 for ; Sun, 11 Mar 2001 14:53:34 -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 OAA19640 for ; Sun, 11 Mar 2001 14:53:35 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29589 for ; Sun, 11 Mar 2001 14:53:33 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id RAA19023; Sun, 11 Mar 2001 17:53:06 -0500 (EST) Date: Sun, 11 Mar 2001 17:53:06 -0500 (EST) From: Scott Bradner Message-Id: <200103112253.RAA19023@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, Jim.Bound@nokia.com, sob@harvard.edu Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am fine with that if and only if we all are clear and agree that is not > mandatory to create them. I do not think that the use of temp addresses should be mandatory 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 Sun Mar 11 14:57:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMveTL022917 for ; Sun, 11 Mar 2001 14:57:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2BMve7s022916 for ipng-dist; Sun, 11 Mar 2001 14:57:40 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2BMvVTL022909 for ; Sun, 11 Mar 2001 14:57:31 -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 OAA19806 for ; Sun, 11 Mar 2001 14:57:32 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20796 for ; Sun, 11 Mar 2001 15:57:31 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2BMvWg27421 for ; Sun, 11 Mar 2001 16:57:32 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 11 Mar 2001 16:57:30 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Sun, 11 Mar 2001 16:57:30 -0600 Message-ID: To: sob@harvard.edu, ipng@sunroof.eng.sun.com, Jim.Bound@nokia.com Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt Date: Sun, 11 Mar 2001 16:57:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk me either...I will go recheck 3041 yet again. also we are discussing the ability to provide temporary addresses from a dhcpv6 server on dhc now. if we do it we will give context to the clients that the address is in fact temporary. which is not done now in stateless and gets to what francis states we need. /jim > -----Original Message----- > From: ext Scott Bradner [mailto:sob@harvard.edu] > Sent: Sunday,March 11,2001 5:53 PM > To: ipng@sunroof.eng.sun.com; Jim.Bound@nokia.com; sob@harvard.edu > Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt > > > > I am fine with that if and only if we all are clear and > agree that is not > > mandatory to create them. > > I do not think that the use of temp addresses should be mandatory > > 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 Sun Mar 11 16:52:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C0qiTL023119 for ; Sun, 11 Mar 2001 16:52:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2C0qi68023118 for ipng-dist; Sun, 11 Mar 2001 16:52: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C0qZTL023111 for ; Sun, 11 Mar 2001 16:52:35 -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 QAA28312 for ; Sun, 11 Mar 2001 16:52:35 -0800 (PST) Received: from gate.alliedtelesyn.co.nz ([202.49.72.33]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA23670 for ; Sun, 11 Mar 2001 16:52:34 -0800 (PST) Received: (qmail 21295 invoked from network); 12 Mar 2001 03:16:12 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.72.92) by gate-int.alliedtelesyn.co.nz with SMTP; 12 Mar 2001 03:16:12 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 12 Mar 01 13:50:42 +1200 Received: from SpoolDir by ASLAN (Mercury 1.47); 12 Mar 01 13:50:36 +1200 From: "Sean Lin" Organization: Allied Telesyn Research, Chch, NZ To: contact@tahi.org, ipng@sunroof.eng.sun.com Date: Mon, 12 Mar 2001 13:50:29 +1200 (NZT) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: bug in TAHI?? Reply-to: sean.lin@alliedtelesyn.co.nz Message-ID: <3AACD3FC.20220.48B32412@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I hope someone can spare me some of their time to help me with this. The following is one of the test for the TAHI suite for Neighbour Discovery. The problem with this test is that at the final stages of this test where the TN sends a NS with different LLA, the NUT will return a NA. However, TAHI seems to pickup an unidentified NS from somewhere. Is this a bug? And this is for TAHI Conformance Test Suite 1.1 LLA of NUT = 0:90:99:a:80:7 LLA of TN = 00:00:00:00:01:04, 0:0:0:0:a9:a9 {HYPERLINK "./ncStateByNs4Probe.html"} *** PROBE vs. unicast NS w/ SLL, diff. LLA *** Initialization New LLA of TN: 00:00:00:00:01:04 updateTnDef: RemoteDebug 0 updateTnDef: RemoteLogout 0 updateTnDef: RemoteDevice cuaa0c updateTnDef: RemoteSpeed 0 updateTnDef: RemoteMethod serial updateTnDef: RemoteIntDebug 0 updateTnDef: RemoteLog 0 updateTnDef: Link0 ed1 00:00:00:00:01:04 updateTnDef: Link1 ed2 00:00:00:00:01:01 Send echo-request Got multicast NS, then INCOMPLETE state Target: INCOMPLETE state Send unicast NA(rSO) w/ TLL(but diff. LLA) Got echo-reply, then REACHABLE state Target: REACHABLE state Wait 1 second Wait 46 second Target: STALE state Send echo-request Got echo-reply, then DELAY->PROBE state Got unicast NS, then PROBE state Target: PROBE state Clear Captured Packets (Link0) Test Send unicast NS w/ SLL, diff. LLA Examine the target's state Start Capturing Packets (Link0) Wait for a NS (4 sec.) ERROR: Got unicast NS, but different LLA, it was PROBE state NG: The target was PROBE/unchanged *********tcpdump output for this test****************** 13:25:35.191700 0:0:0:0:a9:a9 0:90:99:a:80:7 86dd 78: 6000 0000 0018 3a40 fe80 0000 0000 0000 0200 00ff fe00 0104 fe80 0000 0000 0000 0290 99ff fe0a 8007 8000 ee8d 0000 0000 eeee eeee eeee eeee eeee eeee eeee eeee 13:25:35.192645 0:90:99:a:80:7 33:33:ff:0:1:4 86dd 86: 6000 0000 0020 3aff fe80 0000 0000 0000 0290 99ff fe0a 8007 ff02 0000 0000 0000 0000 0001 ff00 0104 8700 4551 0000 0000 fe80 0000 0000 0000 0200 00ff fe00 0104 0101 0090 990a 8007 13:25:36.103746 0:90:99:a:80:7 33:33:ff:0:1:4 86dd 86: 6000 0000 0020 3aff fe80 0000 0000 0000 0290 99ff fe0a 8007 ff02 0000 0000 0000 0000 0001 ff00 0104 8700 4551 0000 0000 fe80 0000 0000 0000 0200 00ff fe00 0104 0101 0090 990a 8007 13:25:37.564099 0:0:0:0:a9:a9 0:90:99:a:80:7 86dd 86: 6000 0000 0020 3aff fe80 0000 0000 0000 0200 00ff fe00 0104 fe80 0000 0000 0000 0290 99ff fe0a 8007 8800 51cd 6000 0000 fe80 0000 0000 0000 0200 00ff fe00 0104 0201 0000 0000 a9a9 13:25:37.564746 0:90:99:a:80:7 0:0:0:0:a9:a9 86dd 78: 6000 0000 0018 3a40 fe80 0000 0000 0000 0290 99ff fe0a 8007 fe80 0000 0000 0000 0200 00ff fe00 0104 8100 ed8d 0000 0000 eeee eeee eeee eeee eeee eeee eeee eeee 13:26:26.927260 0:0:0:0:a9:a9 0:90:99:a:80:7 86dd 78: 6000 0000 0018 3a40 fe80 0000 0000 0000 0200 00ff fe00 0104 fe80 0000 0000 0000 0290 99ff fe0a 8007 8000 ee8d 0000 0000 eeee eeee eeee eeee eeee eeee eeee eeee 13:26:26.927933 0:90:99:a:80:7 0:0:0:0:a9:a9 86dd 78: 6000 0000 0018 3a40 fe80 0000 0000 0000 0290 99ff fe0a 8007 fe80 0000 0000 0000 0200 00ff fe00 0104 8100 ed8d 0000 0000 eeee eeee eeee eeee eeee eeee eeee eeee 13:26:31.060210 0:90:99:a:80:7 0:0:0:0:a9:a9 86dd 86: 6000 0000 0020 3aff fe80 0000 0000 0000 0290 99ff fe0a 8007 fe80 0000 0000 0000 0200 00ff fe00 0104 8700 43d5 0000 0000 fe80 0000 0000 0000 0200 00ff fe00 0104 0101 0090 990a 8007 13:26:32.061154 0:90:99:a:80:7 0:0:0:0:a9:a9 86dd 86: 6000 0000 0020 3aff fe80 0000 0000 0000 0290 99ff fe0a 8007 fe80 0000 0000 0000 0200 00ff fe00 0104 8700 43d5 0000 0000 fe80 0000 0000 0000 0200 00ff fe00 0104 0101 0090 990a 8007 13:26:32.470533 0:0:0:0:1:4 0:90:99:a:80:7 86dd 86: 6000 0000 0020 3aff fe80 0000 0000 0000 0200 00ff fe00 0104 fe80 0000 0000 0000 0290 99ff fe0a 8007 8700 43d5 0000 0000 fe80 0000 0000 0000 0290 99ff fe0a 8007 0101 0000 0000 0104 13:26:32.471347 0:90:99:a:80:7 0:0:0:0:1:4 86dd 86: 6000 0000 0020 3aff fe80 0000 0000 0000 0290 99ff fe0a 8007 fe80 0000 0000 0000 0200 00ff fe00 0104 8800 4936 e000 0000 fe80 0000 0000 0000 0290 99ff fe0a 8007 0201 0090 990a 8007 ************** end of tcpdump capture for this test *********** ------------------------------------------------------------- Sean Lin 27 Nazareth Avenue Software Engineer PO Box 8011 Allied Telesyn Research Christchurch phone +64 3 339 3000 New Zealand fax +64 3 339 3002 email: sean.lin@alliedtelesyn.co.nz web: http://www.alliedtelesyn.co.nz/ ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 17:58:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C1waTL023193 for ; Sun, 11 Mar 2001 17:58:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2C1waIm023192 for ipng-dist; Sun, 11 Mar 2001 17:58: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C1wRTL023185 for ; Sun, 11 Mar 2001 17:58:27 -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 RAA02860 for ; Sun, 11 Mar 2001 17:58:27 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28800 for ; Sun, 11 Mar 2001 17:58:27 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id SAA24990 for ; Sun, 11 Mar 2001 18:58:26 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id SAA29110 for ; Sun, 11 Mar 2001 18:58:25 -0700 (MST)] Received: by IL35EXM01 with Internet Mail Service (5.5.2651.58) id ; Sun, 11 Mar 2001 19:58:25 -0600 Message-ID: From: Boot John-AJB024 To: "'Jim.Bound@nokia.com'" , Boot John-AJB024 , Francis.Dupont@enst-bretagne.fr Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt Date: Sun, 11 Mar 2001 19:58:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I agree this is your key statement "So if we can all agree to make sure that no where including the privacy draft rfc 3041 does not mandate that a node MUST create temporary addresses". With ref. to Internet versus Intranet volumes I wonder if anyone has any idea of the relative percentages say 5 years out in an IPv6 world ? John -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Sunday, March 11, 2001 4:50 PM To: johnboot; Francis.Dupont@enst-bretagne.fr; Jim.Bound@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt John, That was my comment not Francis's. I agree 3GPP will cause much more use of clients on the Internet and I hope so with IPv6. My comment was much more basic. Take 3 Fortune 100 companies who have 50,000 employees each using a desktop and servers in their company. Then exponetiate that number times all the people in just all the companies and we have a lot more IP packets moving around on a daily basis than any projects for any Internet use today. Thats where I was coming from. I object to telling all these users whose packets will NEVER be seen by batman or batwoman hiding in the paranoid minds of those who may also believe my phone conversations are being listened to (and for their sake I hope they are not). I guess I can absorb that someone could take my EUI and figure out over time where and what I am on the Internet. But I believe most code that executes source address selection will be on a private Intranet on a client. So if we can all agree to make sure that no where including the privacy draft rfc 3041 does not mandate that a node MUST create temporary addresses then my issue is NULL and as Scott alluded to. I am ok with that. But even in that case we need to provide a means to denote context to a temporary address based on what is done to the preferred and valid lifetimes on the host and by the host. Thats a missing piece too. /jim > -----Original Message----- > From: ext Boot John-AJB024 [mailto:johnboot@motorola.com] > Sent: Sunday,March 11,2001 5:29 PM > To: 'Francis Dupont'; Jim.Bound@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipngwg-default-addr-select-03.txt > > > Francis, > with reference to your comment that most IPv6 > communication will be > on Intranets I am not sure this is correct. As 3G phone > systems move to IPv6 > then probably most traffic will be Internet not Intranet. > > Regards > John Boot > johnboot@mot.com > > > > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Saturday, March 10, 2001 9:11 AM > To: Jim.Bound@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt > > > In your previous mail you wrote: > > I strongly object to Temporary Addresses being preferred > over Public > Addresses in source address selection. > > The reason is that most communications of IPv6 will not be on the > Internet > but on Intranets. The default should reflect that reality. > > And a web server should be using a public address that can last for > weeks. > > => there are two issues: > - what are the defaults? > = how to change them? > Of course if the second issue is solved then the first one becomes > a matter of taste/personal choice of implementers. Unfortunately > if there are some nice policy hooks they don't apply to the > temporary/public choice (or the home/care-of one). I strongly > suggest to add in the document some reasonable hooks (reasonable = > something which can be set in the context of applications, not > only a setsockopt) for this kind of policies... > > Regards > > Francis.Dupont@enst-bretagne.fr > > BTW I share Jim's opinion about temporary addresses. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 12 00:04:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C840TL023591 for ; Mon, 12 Mar 2001 00:04:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2C83xLk023590 for ipng-dist; Mon, 12 Mar 2001 00:03: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C83lTL023583 for ; Mon, 12 Mar 2001 00:03:48 -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 AAA19458 for ; Mon, 12 Mar 2001 00:03:48 -0800 (PST) Received: from mail.tsinghua.edu.cn (mail.tsinghua.edu.cn [166.111.8.18]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA09520 for ; Mon, 12 Mar 2001 00:03:39 -0800 (PST) Received: (qmail 19103 invoked by alias); 12 Mar 2001 16:03:18 +0800 Received: from unknown (HELO csnet1.cs.tsinghua.edu.cn) (166.111.68.118) by mail.tsinghua.edu.cn with SMTP; 12 Mar 2001 16:03:18 +0800 Received: from dxh (huq [166.111.69.225]) by csnet1.cs.tsinghua.edu.cn (8.9.2/8.9.2) with SMTP id PAA28505 for ; Mon, 12 Mar 2001 15:58:11 +0800 (CST) Message-Id: <200103120758.PAA28505@csnet1.cs.tsinghua.edu.cn> Date: Mon, 12 Mar 2001 16:5:25 +0800 From: idlecat Reply-To: dong.cat@263.net To: "ipng@sunroof.eng.sun.com" Organization: =?ISO-8859-1?Q?=C7=E5=BB=AA=B4=F3=D1=A7=BC=C6=CB=E3=BB=FA=CF=B5?= X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am wondering what the next generation of mobile ip will be! If there are millions of mobile ip equipments around, how can they communicate with each other and with fixed ip equipments efficiently and conveniently? I think there will be some larger carriers who provide mobile ip access service in the future. Given a block of ipv6 addresses, the carriers can build a mobile-oriented network. This MNs(mobile node) in the network should have a special TCP/IP protocol. Maybe it will be like below. Within the network, the MNs only use lower n bits, say 64 bits, to identify themselves. The remain has two part to server two functions. One is a flag showing whether the address is within the network. The other is dynamic to reflect the current location of the MN which is used for routing. When a MN communicates with a node outside the network, the engress router should replace the upper 128 - n bits of the src ip address with the actual prefix, or it should be done by MN itself. The ingress packets, I think, can use some technologies such as Routing Header Option in ipv6, stream or mpls. I am not sure yet. Every MNs have a default host(it can be a router at the same time), which can be found through their id, say the lower 64 bits. The host records the current locations of its MNs. When the outside node call in, it will get here first. Then it should be informed the actual location of its peer. I don't think tunnel/(home agent) is a good solution so I try to make the two communicate directly. If the network deals with all the differences and the outside node can not feel these, life is easier. It can be achieved by the way below, but it will leave some burden to the Ingress Router: When the incoming packet arrives the Ingress Router for the first time, the router don't know how to forward the packet to the destination because it is maybe not at home. But the router can get the location of the destination by querying the default host. Then just like label switch, the router replaces the original des ip, the ip addr seen by outside, with the query result. Then the packet can enter the network, surely it will go to the right place. Normally the query is executed only once. Above is my simple idea(can I call this idea:-). Thanks for reading it. I am newer to networking. Any comment is welcome! Dong Xiaohu dongcat@csnet1.cs.tsinghua.edu.cn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 01:43:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C9hgTL023662 for ; Mon, 12 Mar 2001 01:43:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2C9hgUw023661 for ipng-dist; Mon, 12 Mar 2001 01:43: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2C9hXTL023654 for ; Mon, 12 Mar 2001 01:43:33 -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 BAA18585 for ; Mon, 12 Mar 2001 01:43:32 -0800 (PST) Received: from givenchy (mailhost.6wind.com [212.234.238.114]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14121 for ; Mon, 12 Mar 2001 01:43:22 -0800 (PST) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id B2DBC869; Mon, 12 Mar 2001 10:41:13 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.123]) by intranet.6wind.com (Postfix) with ESMTP id 09B58B470; Mon, 12 Mar 2001 10:42:49 +0100 (CET) Message-ID: <3AAC9A88.F20BE178@6wind.com> Date: Mon, 12 Mar 2001 10:44:40 +0100 From: Alain Ritoux X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: Switch of UDP-Checksum References: <200103090742.IAA25041@unna.ffm.fgan.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > The reason is because IPv6 does not have its own > header checksum, so the upper layers (UDP, for example) must provide > their own corruption-detection for any IP header fields they rely > on for their correct operation. In the case of UDP, that detection > is accomplished through the inclusion of the IP "pseudo-header" in > the UDP checksum. IPv6 provides a next header value implying nothing is to follow (No next header). This can be used for some signalling purpose (e.g. some Destination Options). We can have the following : - IPv6 Header (next = ...) .... - Destination Option Header (next = no_next_header). But there is no upper layer, hence no checksum. Is is correct ? allowed ? Best regards. -- -------------------------------------------------------- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 Address : 6WIND 1 place Charles de Gaulle Immeuble Central Gare 78180 MONTIGNY LE BRETONNEUX FRANCE web site : www.6wind.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 Mar 12 07:47:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CFl0TL023937 for ; Mon, 12 Mar 2001 07:47:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CFkxNu023936 for ipng-dist; Mon, 12 Mar 2001 07: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CFklTL023929 for ; Mon, 12 Mar 2001 07:46:48 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA03638; Mon, 12 Mar 2001 16:46:43 +0100 (MET) Date: Mon, 12 Mar 2001 16:45:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-default-addr-select-03.txt To: Jim.Bound@nokia.com 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 > I strongly object to Temporary Addresses being preferred over Public > Addresses in source address selection. I agree but for a slightly different reason. By default preferring temporary addresses over public addresses violates the priciple of least surprise in the following example: A system on the internet which hosts services (http, whatever) which use outbound connections and assume those connections use public addresses. At this stage the system has only public addresses. Then one or more users on that system that desire to use temporary addresses e.g. for web browsing. The system admin (or single user if it is a personal machine) enables temporary addresses. Now the above services fail in interesting ways since they been automatically switched to use temporary addresses for future communication. Preferring temporary addresses over public address by default is a fine policy if we don't want folks to ever enable any temporary addresses. But since I think we want folks to be able to use temporary addresses users should be able to enable them with a minumum of ill effects. This means that the default must be to prefer public addresses and we must provide an API where applications can state that they prefer temporary addresses for e.g. a given socket. 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 Mar 12 09:33:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CHXITL024242 for ; Mon, 12 Mar 2001 09:33:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CHXIsF024241 for ipng-dist; Mon, 12 Mar 2001 09:33:18 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CHX7TL024234 for ; Mon, 12 Mar 2001 09:33: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 JAA28330 for ; Mon, 12 Mar 2001 09:33:06 -0800 (PST) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA27421 for ; Mon, 12 Mar 2001 09:33:03 -0800 (PST) Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm43aad3289; Mon, 12 Mar 2001 17:25:32 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm12e3aa94650; Fri, 9 Mar 2001 13:38:05 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA22410 for ietf-123-outbound.02@ietf.org; Fri, 9 Mar 2001 08:35:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA21816 for ; Fri, 9 Mar 2001 07:34:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11518; Fri, 9 Mar 2001 07:34:26 -0500 (EST) Message-Id: <200103091234.HAA11518@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-scoping-arch-02.txt Date: Fri, 09 Mar 2001 07:34:25 -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 IPNG Working Group of the IETF. Title : IP Version 6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe, B. Zill Filename : draft-ietf-ipngwg-scoping-arch-02.txt Pages : 19 Date : 08-Mar-01 This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-02.txt 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-scoping-arch-02.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-scoping-arch-02.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: <20010308110746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoping-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110746.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 Tue Mar 13 02:39:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DAdIIm026877 for ; Tue, 13 Mar 2001 02:39:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DAdHDK026876 for ipng-dist; Tue, 13 Mar 2001 02: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DAcvIm026861; Tue, 13 Mar 2001 02:38:58 -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 CAA05467; Tue, 13 Mar 2001 02:38:57 -0800 (PST) Received: from shaku.v6.linux.or.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06461; Tue, 13 Mar 2001 03:38:55 -0700 (MST) Received: from chiriko.linux-ipv6.org (dhcp223.nc.u-tokyo.ac.jp [130.69.251.223]) by shaku.v6.linux.or.jp (8.11.0/3.7W) with ESMTP id f2DAZKG30296; Tue, 13 Mar 2001 19:35:20 +0900 Date: Tue, 13 Mar 2001 19:38:47 +0900 Message-ID: <87lmqa3qdk.wl@chiriko.linux-ipv6.org> From: Yuji Sekiya To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: USAGI guys at minneapolis IETF User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Most of USAGI core members will join in 50th IETF meeting and attend to IPng and ngtrans sessions at least. Then we would like to meet USAGI users/developpers who join in IETF and make conversation about Linux IPv6. If you are interested in the topic, please come around the IETF terminal room after ngtrans session on Monday. If we change the meeting schdule, we will announce to IPng and ngtrans mailing lists. Thanks. -- Yuji Sekiya @ USAGI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 10:25:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DIPXIm027480 for ; Tue, 13 Mar 2001 10:25:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DIPWiJ027479 for ipng-dist; Tue, 13 Mar 2001 10: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DIPNIm027472 for ; Tue, 13 Mar 2001 10:25:24 -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 KAA09221 for ; Tue, 13 Mar 2001 10:25:24 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19276 for ; Tue, 13 Mar 2001 10:25:23 -0800 (PST) Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f2DIUfe12839 for ; Tue, 13 Mar 2001 10:30:41 -0800 (PST) Date: Tue, 13 Mar 2001 10:30:41 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com Reply-To: Youngjune Lee Gwon To: ipng@sunroof.eng.sun.com Subject: IPNG WG Agenda?? In-Reply-To: <87lmqa3qdk.wl@chiriko.linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can anybody tell me what the agenda for IPNG WG Meeting on Monday, 3-19-01 at the 50th IETF? Thanks in advance, ---------------------------------------------- Youngjune Gwon gyj@dcl.docomo-usa.com Research Engineer Mobile Internet Laboratory DoCoMo Communications Laboratories USA, Inc. And, the Truth will set you free. - John 8:32 ---------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 13:02:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DL2JIm028062 for ; Tue, 13 Mar 2001 13:02:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DL2Jhk028061 for ipng-dist; Tue, 13 Mar 2001 13:02: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DL29Im028052 for ; Tue, 13 Mar 2001 13:02:09 -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 NAA01720 for ; Tue, 13 Mar 2001 13:02:08 -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 OAA12477 for ; Tue, 13 Mar 2001 14:02: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 NAA18852; Tue, 13 Mar 2001 13:02:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2DL24p10552; Tue, 13 Mar 2001 13:02:04 -0800 X-mProtect: Tue, 13 Mar 2001 13:02:04 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdOLImiD; Tue, 13 Mar 2001 13:01:46 PST Message-Id: <4.3.2.7.2.20010313125726.024bdca8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 12:57:44 -0800 To: Youngjune Lee Gwon From: Bob Hinden Subject: Re: IPNG WG Agenda?? Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <87lmqa3qdk.wl@chiriko.linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft agenda should be out tomorrow. Bob At 10:30 AM 3/13/2001 -0800, Youngjune Lee Gwon wrote: >Hi, > >Can anybody tell me what the agenda for IPNG WG Meeting on Monday, 3-19-01 >at the 50th IETF? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 20:34:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E4Y7Im000078 for ; Tue, 13 Mar 2001 20:34:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2E4Y7hr000077 for ipng-dist; Tue, 13 Mar 2001 20: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E4XwIm000070 for ; Tue, 13 Mar 2001 20:33:58 -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 UAA23486 for ; Tue, 13 Mar 2001 20:33:58 -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 VAA09818 for ; Tue, 13 Mar 2001 21:33:57 -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 UAA27514; Tue, 13 Mar 2001 20:33:50 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2E4Xmf12446; Tue, 13 Mar 2001 20:33:48 -0800 X-mProtect: Tue, 13 Mar 2001 20:33:48 -0800 Nokia Silicon Valley Messaging Protection Received: from Ihinden-5.iprg.nokia.com (205.226.22.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdRyjDn8; Tue, 13 Mar 2001 20:33:40 PST Message-Id: <4.3.2.7.2.20010313201810.01d4be70@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 20:29:38 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Agenda for Minneapolis IETF Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the draft agenda for IPng w.g. sessions at the Minneapolis IETF. We have tried to allow enough time for each talk to permit a reasonable amount of discussion. We are also including a track at the end of the second session to allow for discussing the use of the IPv6 flow label. More information on this will be sent out soon. Please send us comments, additions, and deletions. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------------- MONDAY, March 19, 2001 0900-1130 (Salon D) ------------------------------------------- Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Source/Destination Address Selection / Rich Draves (30 min) Default Router Preferences & More Specific Routes in RAs / Rich Draves (20 min) Generic Packet Tunneling in IPv6 - Bi-directional Tunneling / Alex Conta (15 min) An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min) Host-based Anycast using MLD / Brian Haberman (30 min) Site prefixes in Neighbor Discovery / Erik Nordmark (30 min) THURSDAY, March 22, 2001 1530-1730 (Salon D) -------------------------------------------- IPv6 Scoped Address Architecture / Steve Deering (10 min) IPv6 Near-Unique Site-Local Addresses / Paul Francis (20 min) DNS Server Discovery Mechanisms for IPv6 Update / Dave Thaler (15 min) Multicast Listener Discovery Version 2 (MLDv2) for IPv6 / Luis Costa (10 min) IPv6 Flow Label Track (60 min) Flow Transparent Mobility and QoS Support for IPv6-based Wireless Real-time Services / Winston Seah (10 min) [Other talks to be announced] ----------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 23:24:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E7OfIm000259 for ; Tue, 13 Mar 2001 23:24:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2E7Oftn000258 for ipng-dist; Tue, 13 Mar 2001 23:24: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E7OWIm000248 for ; Tue, 13 Mar 2001 23:24: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 XAA25242 for ; Tue, 13 Mar 2001 23:24:33 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19048 for ; Tue, 13 Mar 2001 23:24:33 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA03684; Tue, 13 Mar 2001 23:24:33 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <4.3.2.7.2.20010313201810.01d4be70@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20010313201810.01d4be70@mailhost.iprg.nokia.com> Date: Tue, 13 Mar 2001 23:24:34 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Flow Label discussion Cc: Bob Hinden Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As Bob mentioned, we have set aside a chunk of time in the Minneapolis agenda to discuss the various proposals for what to do with the IPv6 Flow Label field. This was a hot topic here on the list just before the San Diego IETF, and then we ended up with an agenda that was too full to allow in-depth face-to-face discussion, so we said we would defer it to the proposed interim meeting, which never happened. Therefore, we have made time next week for this topic. At the moment, we have one scheduled presentation on Flow Label issues, by Winston Seah (draft-shen-ipv6-flow-trans-00.txt), and we would like to offer the opportunity for others who were arguing for alternative semantics for the Flow Label field to summarize their proposals. If I recall correctly, the debate came to down to basically three different choices for Flow Label semantics: (1) a non-mutable value that, when concatenated with the source address, can be used by routers to identify flows. (This was the original design, described in pre-RFC2460 versions of the IPv6 spec.) (2) a mutable value that can be or will be modified hop-by-hop, like an ATM virtual circuit identifier or an MPLS label. (3) a hybrid of (1) and (2) in which, say, one bit of the Flow Label field indicates whether or not the rest of the field is mutable. It would be best if we had one presenter for each of those choices (assuming my list of the different choices is right), with 10 minutes provided for each speaker to make their case. I.e., if, for example, five people all volunteer to make the case for choice (2), we will ask them to choose one presenter among themselves to summarize all the arguments. The goal is to quickly lay out all the issues, and then allow some time for interactive discussion and trying to see if any sort of consensus might emerge. (Of course, any results will be written up in the minutes and subject to further discussion/ratification here on the list and in Last Calls, etc.) So, if anyone would like to make a summary presentation of a Flow Label proposal, please send a message to Bob and me (you may also cc it to the list if you wish, or not), saying in a sentence or two what your specific proposal is. If there are multiple people proposing the same thing, we'll ask that set of people to coordinate on a single presentation. OK? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 00:14:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E8ExIm000358 for ; Wed, 14 Mar 2001 00:14:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2E8Ewkt000357 for ipng-dist; Wed, 14 Mar 2001 00:14: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E8ElIm000350 for ; Wed, 14 Mar 2001 00:14:47 -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 AAA17495 for ; Wed, 14 Mar 2001 00:14:48 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA23367 for ; Wed, 14 Mar 2001 00:14:48 -0800 (PST) Received: (qmail 18771 invoked by uid 1001); 14 Mar 2001 08:09:58 -0000 Date: 14 Mar 2001 08:09:58 -0000 Message-ID: <20010314080958.31700.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME References: <20010208043045.7364.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I propose retiring A6, DNAME, and ip6.arpa. The procedure for this is specified in RFC 2026, section 6.4: we ask the IESG to change the status of the specifications to Historic. Clients and servers will go on happily using AAAA and ip6.int. See http://cr.yp.to/djbdns/killa6.html if you missed the discussion of why A6 and DNAME are a bad idea. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 03:11:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EBBiIm000627 for ; Wed, 14 Mar 2001 03:11:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EBBidC000626 for ipng-dist; Wed, 14 Mar 2001 03:11: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.174.15]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EBBWIm000619 for ; Wed, 14 Mar 2001 03:11:32 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA17337; Wed, 14 Mar 2001 12:11:27 +0100 (MET) Date: Wed, 14 Mar 2001 12:09:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Flow Label discussion To: Steve Deering Cc: ipng@sunroof.eng.sun.com, Bob Hinden 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 > At the moment, we have one scheduled presentation on Flow Label issues, > by Winston Seah (draft-shen-ipv6-flow-trans-00.txt), and we would like > to offer the opportunity for others who were arguing for alternative > semantics for the Flow Label field to summarize their proposals. If > I recall correctly, the debate came to down to basically three > different choices for Flow Label semantics: > > (1) a non-mutable value that, when concatenated with the source > address, can be used by routers to identify flows. (This was > the original design, described in pre-RFC2460 versions of > the IPv6 spec.) > > (2) a mutable value that can be or will be modified hop-by-hop, > like an ATM virtual circuit identifier or an MPLS label. > > (3) a hybrid of (1) and (2) in which, say, one bit of the Flow > Label field indicates whether or not the rest of the field > is mutable. I understand that the above 3 are the currently understood alternatives for what the flow label semantics could be. I think that I could construct arguments for either one of them being the best; it all depends on what problem I think the 20 bits could be used to solve. So while it might be useful to get arguments for and against the various semantics on the table, there is a risk that this isn't productive is folks have very different views of what problem they can solve using the flow label field. Thus before the WG can actually make any decisions about flow label semantics I think we need to have folks write up the different problem statements for which they see the flow label as a potential solution. Then the WG can decide which problem(s) are the most important to solve and whether or not using the flow label is the best solution. That would then hopefully lead to nailing down the semantics of the flow label. So having the discussion you propose is fine, but please keep the problem statements in mind. 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 Mar 14 07:17:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFHpIm000896 for ; Wed, 14 Mar 2001 07:17:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EFHoQ6000895 for ipng-dist; Wed, 14 Mar 2001 07:17: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFHfIm000888 for ; Wed, 14 Mar 2001 07:17: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 HAA03822 for ; Wed, 14 Mar 2001 07:17:41 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07738 for ; Wed, 14 Mar 2001 07:17:41 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EFHgg26843 for ; Wed, 14 Mar 2001 09:17:42 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 09:17:39 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 09:17:39 -0600 Message-ID: To: deering@cisco.com, ipng@sunroof.eng.sun.com Cc: hinden@iprg.nokia.com Subject: RE: Flow Label discussion Date: Wed, 14 Mar 2001 09:17:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I would like to present the case for the hybrid. the limitations that should be imposed when one is not using the immutable form. and a conceptual model how it can be used for RIB and FIB processes in software to support fast path in hardware. I would assume any of us would only have 10 minutes on the stage? cc the list if folks want to connect with me on this. thanks /jim > -----Original Message----- > From: ext Steve Deering [mailto:deering@cisco.com] > Sent: Wednesday,March 14,2001 2:25 AM > To: ipng@sunroof.eng.sun.com > Cc: Bob Hinden > Subject: Flow Label discussion > > > As Bob mentioned, we have set aside a chunk of time in the Minneapolis > agenda to discuss the various proposals for what to do with the IPv6 > Flow Label field. This was a hot topic here on the list just before > the San Diego IETF, and then we ended up with an agenda that was too > full to allow in-depth face-to-face discussion, so we said we would > defer it to the proposed interim meeting, which never happened. > Therefore, we have made time next week for this topic. > > At the moment, we have one scheduled presentation on Flow > Label issues, > by Winston Seah (draft-shen-ipv6-flow-trans-00.txt), and we would like > to offer the opportunity for others who were arguing for alternative > semantics for the Flow Label field to summarize their proposals. If > I recall correctly, the debate came to down to basically three > different choices for Flow Label semantics: > > (1) a non-mutable value that, when concatenated with the source > address, can be used by routers to identify flows. (This was > the original design, described in pre-RFC2460 versions of > the IPv6 spec.) > > (2) a mutable value that can be or will be modified hop-by-hop, > like an ATM virtual circuit identifier or an MPLS label. > > (3) a hybrid of (1) and (2) in which, say, one bit of the Flow > Label field indicates whether or not the rest of the field > is mutable. > > It would be best if we had one presenter for each of those choices > (assuming my list of the different choices is right), with 10 minutes > provided for each speaker to make their case. I.e., if, for example, > five people all volunteer to make the case for choice (2), we will > ask them to choose one presenter among themselves to summarize all > the arguments. The goal is to quickly lay out all the issues, and > then allow some time for interactive discussion and trying to see if > any sort of consensus might emerge. (Of course, any results will be > written up in the minutes and subject to further > discussion/ratification > here on the list and in Last Calls, etc.) > > So, if anyone would like to make a summary presentation of a > Flow Label > proposal, please send a message to Bob and me (you may also cc it to > the list if you wish, or not), saying in a sentence or two what your > specific proposal is. If there are multiple people proposing the same > thing, we'll ask that set of people to coordinate on a single > presentation. > > OK? > > Steve > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 14 07:22:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFMEIm000932 for ; Wed, 14 Mar 2001 07:22:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EFMDPk000931 for ipng-dist; Wed, 14 Mar 2001 07:22: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFM5Im000924 for ; Wed, 14 Mar 2001 07:22:05 -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 HAA04347 for ; Wed, 14 Mar 2001 07:22:05 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05670 for ; Wed, 14 Mar 2001 08:21:54 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EFLug27444 for ; Wed, 14 Mar 2001 09:21:56 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 09:21:53 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 09:21:53 -0600 Message-ID: To: djb@cr.yp.to, ipng@sunroof.eng.sun.com Subject: RE: The case against A6 and DNAME Date: Wed, 14 Mar 2001 09:21:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this is premature because consensus is still split. but I do think it needs to be on someones agenda to discuss to see what happens when we are all face to face and in person. I think this issue will also spill over to a potential interim meeting. /jim > -----Original Message----- > From: ext D. J. Bernstein [mailto:djb@cr.yp.to] > Sent: Wednesday,March 14,2001 3:10 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: The case against A6 and DNAME > > > I propose retiring A6, DNAME, and ip6.arpa. The procedure for this is > specified in RFC 2026, section 6.4: we ask the IESG to change > the status > of the specifications to Historic. Clients and servers will go on > happily using AAAA and ip6.int. > > See http://cr.yp.to/djbdns/killa6.html if you missed the discussion of > why A6 and DNAME are a bad idea. > > ---Dan > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 14 07:25:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFP2Im000955 for ; Wed, 14 Mar 2001 07:25:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EFP1cV000954 for ipng-dist; Wed, 14 Mar 2001 07:25:01 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFOrIm000947 for ; Wed, 14 Mar 2001 07:24: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 HAA15292 for ; Wed, 14 Mar 2001 07:24:53 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07426 for ; Wed, 14 Mar 2001 08:24:52 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EFOrg27905 for ; Wed, 14 Mar 2001 09:24:53 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 09:24:50 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 09:24:50 -0600 Message-ID: To: Erik.Nordmark@eng.sun.com, deering@cisco.com Cc: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Subject: RE: Flow Label discussion Date: Wed, 14 Mar 2001 09:24:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Erik. If I were given time to discuss the hybrid I could do both the technical quick resultant from such a choice but define why I think it solves the problem that the others do not. /jim > -----Original Message----- > From: ext Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Wednesday,March 14,2001 6:10 AM > To: Steve Deering > Cc: ipng@sunroof.eng.sun.com; Bob Hinden > Subject: Re: Flow Label discussion > > > > > At the moment, we have one scheduled presentation on Flow > Label issues, > > by Winston Seah (draft-shen-ipv6-flow-trans-00.txt), and we > would like > > to offer the opportunity for others who were arguing for alternative > > semantics for the Flow Label field to summarize their proposals. If > > I recall correctly, the debate came to down to basically three > > different choices for Flow Label semantics: > > > > (1) a non-mutable value that, when concatenated with the source > > address, can be used by routers to identify flows. (This was > > the original design, described in pre-RFC2460 versions of > > the IPv6 spec.) > > > > (2) a mutable value that can be or will be modified hop-by-hop, > > like an ATM virtual circuit identifier or an MPLS label. > > > > (3) a hybrid of (1) and (2) in which, say, one bit of the Flow > > Label field indicates whether or not the rest of the field > > is mutable. > > I understand that the above 3 are the currently understood > alternatives > for what the flow label semantics could be. > > I think that I could construct arguments for either one of them > being the best; it all depends on what problem I think the 20 > bits could be > used to solve. So while it might be useful to get arguments > for and against the > various semantics on the table, there is a risk that this > isn't productive is > folks have very different views of what problem they can > solve using the flow > label field. > > Thus before the WG can actually make any decisions about flow label > semantics I think we need to have folks write up the different > problem statements for which they see the flow label as a > potential solution. > Then the WG can decide which problem(s) are the most > important to solve > and whether or not using the flow label is the best solution. > That would > then hopefully lead to nailing down the semantics of the flow label. > > So having the discussion you propose is fine, but please keep > the problem > statements in mind. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 08:18:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGIuIm001121 for ; Wed, 14 Mar 2001 08:18:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EGItdn001120 for ipng-dist; Wed, 14 Mar 2001 08:18: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGIkIm001113 for ; Wed, 14 Mar 2001 08:18: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 IAA12552 for ; Wed, 14 Mar 2001 08:18:35 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12351 for ; Wed, 14 Mar 2001 09:18:33 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA25056; Wed, 14 Mar 2001 08:18:30 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: Date: Wed, 14 Mar 2001 08:18:31 -0800 To: Jim.Bound@nokia.com From: Steve Deering Subject: RE: Flow Label discussion Cc: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:17 AM -0600 3/14/01, Jim.Bound@nokia.com wrote: >I would assume any of us would only have 10 minutes on the stage? Yes, give or take a minute or two. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 08:16:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGGcIm001108 for ; Wed, 14 Mar 2001 08:16:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EGGbwH001107 for ipng-dist; Wed, 14 Mar 2001 08:16:37 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGGTIm001100 for ; Wed, 14 Mar 2001 08:16:29 -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 IAA25707; Wed, 14 Mar 2001 08:16:28 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28889; Wed, 14 Mar 2001 08:16:28 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA24749; Wed, 14 Mar 2001 08:16:27 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: Date: Wed, 14 Mar 2001 08:16:28 -0800 To: Erik Nordmark From: Steve Deering Subject: Re: Flow Label discussion Cc: ipng@sunroof.eng.sun.com, Bob Hinden Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:09 PM +0100 3/14/01, Erik Nordmark wrote: >Thus before the WG can actually make any decisions about flow label >semantics I think we need to have folks write up the different >problem statements for which they see the flow label as a potential solution. >Then the WG can decide which problem(s) are the most important to solve >and whether or not using the flow label is the best solution. That would >then hopefully lead to nailing down the semantics of the flow label. > >So having the discussion you propose is fine, but please keep the problem >statements in mind. Excellent point, Erik. Clearly, we don't have time for much writing up before the meeting, but those of you who wish to make presentations should include a description of what problems you are trying to solve, why those are essential problems to solve, and why using the IPv6 Flow Label is the best or only way to solve them. It would be good if our discussion helps to focus the problem space and the set of potential solutions, so there will be fewer drafts that need to be written and argued about afterwards. (Well, one can hope... :-) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 08:31:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGVoIm001182 for ; Wed, 14 Mar 2001 08:31:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EGVoIL001181 for ipng-dist; Wed, 14 Mar 2001 08:31:50 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGVfIm001174 for ; Wed, 14 Mar 2001 08:31:41 -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 IAA26415 for ; Wed, 14 Mar 2001 08:31:41 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21369 for ; Wed, 14 Mar 2001 09:31:28 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA27450; Wed, 14 Mar 2001 08:31:08 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: Date: Wed, 14 Mar 2001 08:31:10 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Re: Flow Label discussion Cc: Bob Hinden Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:16 AM -0800 3/14/01, I wrote: >...those of you who wish to make presentations should include a >description of what problems you are trying to solve, why those are >essential problems to solve, and why using the IPv6 Flow Label is >the best or only way to solve them. Just to clarify: that information should be included in the presentation; I'm not asking you to include all that in the email you send to Bob and me requesting a presentation slot. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 08:33:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGX7Im001203 for ; Wed, 14 Mar 2001 08:33:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EGX7Ku001202 for ipng-dist; Wed, 14 Mar 2001 08:33:07 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGWrIm001195 for ; Wed, 14 Mar 2001 08:32:54 -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 IAA26621 for ; Wed, 14 Mar 2001 08:32:54 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02666 for ; Wed, 14 Mar 2001 08:32:52 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 14 Mar 2001 10:15:28 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 10:15:26 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43018547EE@crchy271.us.nortel.com> From: "Glenn Morrow" To: ipng@sunroof.eng.sun.com Cc: iab@isi.edu Subject: DDoS Work Date: Wed, 14 Mar 2001 10:15:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ACA1.F99CF860" 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_01C0ACA1.F99CF860 Content-Type: text/plain; charset="iso-8859-1" Hello, Is this the appropriate group to discuss possible improvements to detection, prevention, reporting and action against DoS and DDoS attack for IPv6? It seems to me that perhaps a less constrained set of mechanisms could be put in place to more effectively deal with the issue than in IPv4. It may also be possible to better harmonize these solutions with proposed node mobility, renumbering and multihoming solutions. Would people recommend a new WG to deal with these particulars or do people feel that this or another existing WG is sufficient? Has there been any AS drafts on this problem set and desired goals with the IPv6 malleability in mind? Thanks, Glenn ------_=_NextPart_001_01C0ACA1.F99CF860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DDoS Work

Hello,

Is this the appropriate group to = discuss possible improvements to detection, prevention, reporting and = action against DoS and DDoS attack for IPv6?

It seems to me that perhaps a less = constrained set of mechanisms could be put in place to more effectively = deal with the issue than in IPv4. It may also be possible to better = harmonize these solutions with proposed node mobility, renumbering and = multihoming solutions.

Would people recommend a new WG to = deal with these particulars or do people feel that this or another = existing WG is sufficient?

Has there been any AS drafts on this = problem set and desired goals with the IPv6 malleability in = mind?


Thanks,

Glenn

------_=_NextPart_001_01C0ACA1.F99CF860-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 08:56:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGu2Im001374 for ; Wed, 14 Mar 2001 08:56:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EGu1WU001373 for ipng-dist; Wed, 14 Mar 2001 08:56: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGtqIm001366 for ; Wed, 14 Mar 2001 08:55:53 -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 IAA28958 for ; Wed, 14 Mar 2001 08:55:52 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06711 for ; Wed, 14 Mar 2001 08:55:52 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EGtsg14274 for ; Wed, 14 Mar 2001 10:55:54 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 10:55:48 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 10:55:48 -0600 Message-ID: To: deering@cisco.com, Jim.Bound@nokia.com Cc: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Subject: RE: Flow Label discussion Date: Wed, 14 Mar 2001 10:55:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think I can do it in 10. 2 slides. but will assume follow up discussion elswhere. I would try to do it in 8 minutes!!! /jim > -----Original Message----- > From: ext Steve Deering [mailto:deering@cisco.com] > Sent: Wednesday,March 14,2001 11:19 AM > To: Jim.Bound@nokia.com > Cc: ipng@sunroof.eng.sun.com; hinden@iprg.nokia.com > Subject: RE: Flow Label discussion > > > At 9:17 AM -0600 3/14/01, Jim.Bound@nokia.com wrote: > >I would assume any of us would only have 10 minutes on the stage? > > Yes, give or take a minute or two. > > Steve > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 08:57:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGvZIm001387 for ; Wed, 14 Mar 2001 08:57:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EGvYhw001386 for ipng-dist; Wed, 14 Mar 2001 08:57: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EGvNIm001379 for ; Wed, 14 Mar 2001 08:57:23 -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 IAA29266 for ; Wed, 14 Mar 2001 08:57:23 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07967 for ; Wed, 14 Mar 2001 08:57:22 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EGvNg14556 for ; Wed, 14 Mar 2001 10:57:23 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 10:57:21 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 10:57:21 -0600 Message-ID: To: deering@cisco.com, Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Subject: RE: Flow Label discussion Date: Wed, 14 Mar 2001 10:57:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good idea. how about each person write short abstract and send to the list not more than two paragraphs and one is better? I for one may not be able to do that till end of week or on sunday night from hotel? thx /jim > -----Original Message----- > From: ext Steve Deering [mailto:deering@cisco.com] > Sent: Wednesday,March 14,2001 11:16 AM > To: Erik Nordmark > Cc: ipng@sunroof.eng.sun.com; Bob Hinden > Subject: Re: Flow Label discussion > > > At 12:09 PM +0100 3/14/01, Erik Nordmark wrote: > >Thus before the WG can actually make any decisions about flow label > >semantics I think we need to have folks write up the different > >problem statements for which they see the flow label as a > potential solution. > >Then the WG can decide which problem(s) are the most > important to solve > >and whether or not using the flow label is the best > solution. That would > >then hopefully lead to nailing down the semantics of the flow label. > > > >So having the discussion you propose is fine, but please > keep the problem > >statements in mind. > > Excellent point, Erik. Clearly, we don't have time for much > writing up > before the meeting, but those of you who wish to make presentations > should include a description of what problems you are trying to solve, > why those are essential problems to solve, and why using the IPv6 Flow > Label is the best or only way to solve them. It would be good if our > discussion helps to focus the problem space and the set of potential > solutions, so there will be fewer drafts that need to be written and > argued about afterwards. (Well, one can hope... :-) > > Steve > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 14 10:08:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EI8NIm001799 for ; Wed, 14 Mar 2001 10:08:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EI8Mlx001798 for ipng-dist; Wed, 14 Mar 2001 10:08: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EI8DIm001791 for ; Wed, 14 Mar 2001 10:08: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 KAA04378 for ; Wed, 14 Mar 2001 10:08:10 -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 LAA17723 for ; Wed, 14 Mar 2001 11:03:58 -0700 (MST) Received: from vaio (as1-86.chi.il.dial.anet.com [198.92.156.86]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA27340; Wed, 14 Mar 2001 12:03:51 -0600 (CST) Message-ID: <01d701c0acb0$d59c8480$df00a8c0@vaio> From: "JIM FLEMING" To: , , References: Subject: Re: The case against A6 and DNAME Date: Wed, 14 Mar 2001 12:01:44 -0600 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 I believe that the free world and free markets will decide these matters. Fortunately, parts of planet Earth are still a democracy with capitalism. Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: To: ; Sent: Wednesday, March 14, 2001 9:21 AM Subject: RE: The case against A6 and DNAME > this is premature because consensus is still split. but I do think it needs > to be on someones agenda to discuss to see what happens when we are all face > to face and in person. I think this issue will also spill over to a > potential interim meeting. > > /jim > > > -----Original Message----- > > From: ext D. J. Bernstein [mailto:djb@cr.yp.to] > > Sent: Wednesday,March 14,2001 3:10 AM > > To: ipng@sunroof.eng.sun.com > > Subject: Re: The case against A6 and DNAME > > > > > > I propose retiring A6, DNAME, and ip6.arpa. The procedure for this is > > specified in RFC 2026, section 6.4: we ask the IESG to change > > the status > > of the specifications to Historic. Clients and servers will go on > > happily using AAAA and ip6.int. > > > > See http://cr.yp.to/djbdns/killa6.html if you missed the discussion of > > why A6 and DNAME are a bad idea. > > > > ---Dan > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Wed Mar 14 09:58:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHwaIm001787 for ; Wed, 14 Mar 2001 09:58:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EHwZLP001786 for ipng-dist; Wed, 14 Mar 2001 09:58:35 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHwQIm001779 for ; Wed, 14 Mar 2001 09:58:26 -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 JAA12199 for ; Wed, 14 Mar 2001 09:58:26 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03662 for ; Wed, 14 Mar 2001 09:58:25 -0800 (PST) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id 7C27F31918; Wed, 14 Mar 2001 09:58:24 -0800 (PST) Message-Id: <5.0.2.1.2.20010314094031.03337cb8@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 14 Mar 2001 09:58:24 -0800 To: Jim.Bound@nokia.com, djb@cr.yp.to, ipng@sunroof.eng.sun.com From: "David R. Conrad" Subject: RE: The case against A6 and DNAME In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Having been involved in the first implementation of these features, I am no fan of A6, DNAME, or bitstring labels. However, I agree with Jim -- it is premature for 2026 to be moved to historic. The functionality these features can provide would be useful and could be made to work reliably if suitably constrained, even if it doesn't quite fit into Bernstein's DNS implementation. More operational experience is required before we have sufficient information to decide if the pain of A6, DNAME, and bitstring labels outweigh their benefits. Rgds, -drc At 09:21 AM 3/14/2001 -0600, Jim.Bound@nokia.com wrote: >this is premature because consensus is still split. but I do think it needs >to be on someones agenda to discuss to see what happens when we are all face >to face and in person. I think this issue will also spill over to a >potential interim meeting. > >/jim > > > -----Original Message----- > > From: ext D. J. Bernstein [mailto:djb@cr.yp.to] > > Sent: Wednesday,March 14,2001 3:10 AM > > To: ipng@sunroof.eng.sun.com > > Subject: Re: The case against A6 and DNAME > > > > > > I propose retiring A6, DNAME, and ip6.arpa. The procedure for this is > > specified in RFC 2026, section 6.4: we ask the IESG to change > > the status > > of the specifications to Historic. Clients and servers will go on > > happily using AAAA and ip6.int. > > > > See http://cr.yp.to/djbdns/killa6.html if you missed the discussion of > > why A6 and DNAME are a bad idea. > > > > ---Dan > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Mar 15 01:28:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F9SGIm004891 for ; Thu, 15 Mar 2001 01:28:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F9SGfi004890 for ipng-dist; Thu, 15 Mar 2001 01: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F9S5Im004883 for ; Thu, 15 Mar 2001 01:28:06 -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 BAA04591; Thu, 15 Mar 2001 01:28:03 -0800 (PST) Received: from anago.fumi.net (inet30.aist-nara.ac.jp [163.221.52.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA24761; Thu, 15 Mar 2001 01:27:54 -0800 (PST) Received: (from masa@localhost) by anago.fumi.net (8.11.1/8.10.2) id f2F9Pv800473; Thu, 15 Mar 2001 09:25:57 GMT Date: Thu, 15 Mar 2001 18:25:56 +0900 From: Masafumi OE To: Jim.Bound@nokia.com Cc: deering@cisco.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Subject: Re: Flow Label discussion Message-ID: <20010315182556.C230%masa@fumi.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i-ja0 In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Could do you give me 10 minutes to talk and discuss about my IPv6 traceback idea? This technique is routers mark own address and previous hop's address that is divided on flow label. Nodes can make paths from a lot of IPv6 packets with the flow label. I guess this idea is effective for finding DDoS attacker using faked source address. Because I am a newcomer person, I leave the judgment whether to giving valuable time for me to the chair. As a judgment material, my proposal will be uploaded in webpage by Saturday. Thank you. -- Masafumi Oe, NAIST, WIDE, JAPAN. On Wed, Mar 14, 2001 at 10:57:18AM -0600, Jim.Bound@nokia.com wrote: > good idea. how about each person write short abstract and send to the list > not more than two paragraphs and one is better? I for one may not be able > to do that till end of week or on sunday night from hotel? > > thx > /jim > > > -----Original Message----- > > From: ext Steve Deering [mailto:deering@cisco.com] > > Sent: Wednesday,March 14,2001 11:16 AM > > To: Erik Nordmark > > Cc: ipng@sunroof.eng.sun.com; Bob Hinden > > Subject: Re: Flow Label discussion > > > > > > At 12:09 PM +0100 3/14/01, Erik Nordmark wrote: > > >Thus before the WG can actually make any decisions about flow label > > >semantics I think we need to have folks write up the different > > >problem statements for which they see the flow label as a > > potential solution. > > >Then the WG can decide which problem(s) are the most > > important to solve > > >and whether or not using the flow label is the best > > solution. That would > > >then hopefully lead to nailing down the semantics of the flow label. > > > > > >So having the discussion you propose is fine, but please > > keep the problem > > >statements in mind. > > > > Excellent point, Erik. Clearly, we don't have time for much > > writing up > > before the meeting, but those of you who wish to make presentations > > should include a description of what problems you are trying to solve, > > why those are essential problems to solve, and why using the IPv6 Flow > > Label is the best or only way to solve them. It would be good if our > > discussion helps to focus the problem space and the set of potential > > solutions, so there will be fewer drafts that need to be written and > > argued about afterwards. (Well, one can hope... :-) > > > > Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 01:54:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F9sbIm004932 for ; Thu, 15 Mar 2001 01:54:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F9sbMS004931 for ipng-dist; Thu, 15 Mar 2001 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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F9sOIm004924 for ; Thu, 15 Mar 2001 01:54:25 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA00406; Thu, 15 Mar 2001 10:54:14 +0100 (MET) Date: Thu, 15 Mar 2001 10:52:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Flow Label discussion To: Masafumi OE Cc: Jim.Bound@nokia.com, deering@cisco.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com In-Reply-To: "Your message with ID" <20010315182556.C230%masa@fumi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This would seem to fall under the ITRACE WG as far as I can tell. Erik >----- Begin Included Message -----< Date: Thu, 15 Mar 2001 18:25:56 +0900 From: "Masafumi OE" Subject: Re: Flow Label discussion To: Jim.Bound@nokia.com Cc: deering@cisco.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Hello, Could do you give me 10 minutes to talk and discuss about my IPv6 traceback idea? This technique is routers mark own address and previous hop's address that is divided on flow label. Nodes can make paths from a lot of IPv6 packets with the flow label. I guess this idea is effective for finding DDoS attacker using faked source address. Because I am a newcomer person, I leave the judgment whether to giving valuable time for me to the chair. As a judgment material, my proposal will be uploaded in webpage by Saturday. Thank you. -- Masafumi Oe, NAIST, WIDE, JAPAN. On Wed, Mar 14, 2001 at 10:57:18AM -0600, Jim.Bound@nokia.com wrote: > good idea. how about each person write short abstract and send to the list > not more than two paragraphs and one is better? I for one may not be able > to do that till end of week or on sunday night from hotel? > > thx > /jim > > > -----Original Message----- > > From: ext Steve Deering [mailto:deering@cisco.com] > > Sent: Wednesday,March 14,2001 11:16 AM > > To: Erik Nordmark > > Cc: ipng@sunroof.eng.sun.com; Bob Hinden > > Subject: Re: Flow Label discussion > > > > > > At 12:09 PM +0100 3/14/01, Erik Nordmark wrote: > > >Thus before the WG can actually make any decisions about flow label > > >semantics I think we need to have folks write up the different > > >problem statements for which they see the flow label as a > > potential solution. > > >Then the WG can decide which problem(s) are the most > > important to solve > > >and whether or not using the flow label is the best > > solution. That would > > >then hopefully lead to nailing down the semantics of the flow label. > > > > > >So having the discussion you propose is fine, but please > > keep the problem > > >statements in mind. > > > > Excellent point, Erik. Clearly, we don't have time for much > > writing up > > before the meeting, but those of you who wish to make presentations > > should include a description of what problems you are trying to solve, > > why those are essential problems to solve, and why using the IPv6 Flow > > Label is the best or only way to solve them. It would be good if our > > discussion helps to focus the problem space and the set of potential > > solutions, so there will be fewer drafts that need to be written and > > argued about afterwards. (Well, one can hope... :-) > > > > Steve >----- End Included 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 Thu Mar 15 03:33:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FBXLIm005040 for ; Thu, 15 Mar 2001 03:33:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FBXKF4005039 for ipng-dist; Thu, 15 Mar 2001 03:33: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FBX9Im005032 for ; Thu, 15 Mar 2001 03:33:09 -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 DAA18566 for ; Thu, 15 Mar 2001 03:33:08 -0800 (PST) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15643 for ; Thu, 15 Mar 2001 03:33:06 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id F28417E72; Thu, 15 Mar 2001 20:32:25 +0900 (JST) To: Erik Nordmark Cc: Masafumi OE , Jim.Bound@nokia.com, deering@cisco.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com In-reply-to: Erik.Nordmark's message of Thu, 15 Mar 2001 10:52:37 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Flow Label discussion From: Jun-ichiro itojun Hagino Date: Thu, 15 Mar 2001 20:32:25 +0900 Message-Id: <20010315113225.F28417E72@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This would seem to fall under the ITRACE WG as far as I can tell. his way uses flowlabel as hop-by-hop modifiable field. what kind of proposals should be presented in flowlabel special session then? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 06:06:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FE6sIm005147 for ; Thu, 15 Mar 2001 06:06:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FE6rf6005146 for ipng-dist; Thu, 15 Mar 2001 06:06:53 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FE6gIm005139 for ; Thu, 15 Mar 2001 06:06:42 -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 GAA25593 for ; Thu, 15 Mar 2001 06:06:43 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA03808 for ; Thu, 15 Mar 2001 07:06:40 -0700 (MST) Received: (qmail 18251 invoked by uid 1001); 15 Mar 2001 14:06:57 -0000 Date: 15 Mar 2001 14:06:57 -0000 Message-ID: <20010315140657.31476.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME References: <5.0.2.1.2.20010314094031.03337cb8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David R. Conrad writes: > would be useful and could be made to work reliably if suitably constrained I don't believe you. Please say for the record exactly what constraints you have in mind, so that we can see whether the constrained mechanism is (1) reliable and (2) useful. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 10:38:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FIchIm005801 for ; Thu, 15 Mar 2001 10:38:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FIchZK005800 for ipng-dist; Thu, 15 Mar 2001 10:38: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FIcYIm005793 for ; Thu, 15 Mar 2001 10:38:34 -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 KAA29337 for ; Thu, 15 Mar 2001 10:38:33 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02222 for ; Thu, 15 Mar 2001 11:38:32 -0700 (MST) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id 5A13C31918; Thu, 15 Mar 2001 10:38:31 -0800 (PST) Message-Id: <5.0.2.1.2.20010315082617.0306d680@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 Mar 2001 10:38:30 -0800 To: "D. J. Bernstein" , ipng@sunroof.eng.sun.com From: "David R. Conrad" Subject: Re: The case against A6 and DNAME In-Reply-To: <20010315140657.31476.qmail@cr.yp.to> References: <5.0.2.1.2.20010314094031.03337cb8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:06 PM 3/15/2001 +0000, D. J. Bernstein wrote: >David R. Conrad writes: > > would be useful and could be made to work reliably if suitably constrained >I don't believe you. I care? >Please say for the record exactly what constraints >you have in mind, so that we can see whether the constrained mechanism >is (1) reliable and (2) useful. A6 can be seen as a generalization of AAAA. It provides a means within the DNS to separate the routing prefix from the endpoint identifier thereby providing hooks to simplify renumbering. I'd consider that a useful feature. However in the trivial case, A6 can be made to work exactly like AAAA. Constrain the depth of the A6 chain or constrain how the delegations are done and you can gain whatever level of reliability or usefulness you desire. Are you saying A6 cannot be made as reliable as AAAA? Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 17:16:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G1GrIm008668 for ; Thu, 15 Mar 2001 17:16:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G1GqLm008667 for ipng-dist; Thu, 15 Mar 2001 17:16: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G1GfIm008660 for ; Thu, 15 Mar 2001 17:16:41 -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 RAA21470 for ; Thu, 15 Mar 2001 17:16:37 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA09442 for ; Thu, 15 Mar 2001 17:16:36 -0800 (PST) Received: (qmail 18610 invoked by uid 1001); 16 Mar 2001 01:16:57 -0000 Date: 16 Mar 2001 01:16:57 -0000 Message-ID: <20010316011657.17822.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME References: <5.0.2.1.2.20010314094031.03337cb8@localhost> <20010315140657.31476.qmail@cr.yp.to> <5.0.2.1.2.20010315082617.0306d680@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David R. Conrad writes: > Constrain the depth of the A6 chain How? Exactly what constraint do you have in mind? If you mean that the depth is at most 0---i.e., A6 is used just like AAAA---then you're right that the reliability problems disappear. But A6 with this constraint is completely pointless. We should simply use AAAA. If you mean that the depth is at most 1---i.e., A6 is used just like AAAA, except that A6 is allowed to point to a prefix.* name if the owner is _not_ a prefix.* name---then you're wrong about reliability. The aol.com A6 suicide example follows this constraint. You claimed that these features ``would be useful and could be made to work reliably if suitably constrained.'' The features are useless with the first constraint, and unreliable with the second constraint. If you have some other constraint in mind, please say exactly what it is, so that we can see whether the constrained feature is reliable and useful. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 00:21:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G8LTIm009500 for ; Fri, 16 Mar 2001 00:21:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G8LShO009499 for ipng-dist; Fri, 16 Mar 2001 00:21: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G8LJIm009492 for ; Fri, 16 Mar 2001 00:21: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 AAA23210; Fri, 16 Mar 2001 00:21:19 -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 AAA06392; Fri, 16 Mar 2001 00:21:18 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id AAA14863; Fri, 16 Mar 2001 00:20:03 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAG17533; Fri, 16 Mar 2001 00:21:13 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: <20010315113225.F28417E72@starfruit.itojun.org> References: <20010315113225.F28417E72@starfruit.itojun.org> Date: Fri, 16 Mar 2001 00:21:15 -0800 To: Jun-ichiro itojun Hagino From: Steve Deering Subject: Re: Flow Label discussion Cc: Erik Nordmark , Masafumi OE , Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:32 PM +0900 3/15/01, Jun-ichiro itojun Hagino wrote: > his way uses flowlabel as hop-by-hop modifiable field. what kind of > proposals should be presented in flowlabel special session then? One possible answer: only proposals that use the flow label field to label flows. If we open it up to a discussion of all possible uses for a spare 20 bits in the header, we'll never reach any useful conclusions. Note, however, that we may possibly conclude that it's not very important to have an IPv6 header field that labels flows after all, in which case the field would then become reserved and subject to alternative proposals (though in my personal opinion, spare bits are just an invitation to unnecessary featuritis). If you don't like that answer, please let us know. We aim to serve. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 00:29:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G8TGIm009526 for ; Fri, 16 Mar 2001 00:29:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G8TFmh009525 for ipng-dist; Fri, 16 Mar 2001 00:29:15 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G8T4Im009518 for ; Fri, 16 Mar 2001 00:29:05 -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 AAA08710 for ; Fri, 16 Mar 2001 00:29:04 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14277 for ; Fri, 16 Mar 2001 01:29:03 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id RAA22180; Fri, 16 Mar 2001 17:28:52 +0900 (JST) To: Steve Deering cc: Erik Nordmark , Masafumi OE , Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com In-reply-to: deering's message of Fri, 16 Mar 2001 00:21:15 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Flow Label discussion From: itojun@iijlab.net Date: Fri, 16 Mar 2001 17:28:52 +0900 Message-ID: <22178.984731332@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> his way uses flowlabel as hop-by-hop modifiable field. what kind of >> proposals should be presented in flowlabel special session then? >One possible answer: only proposals that use the flow label field to >label flows. If we open it up to a discussion of all possible uses for >a spare 20 bits in the header, we'll never reach any useful conclusions. >Note, however, that we may possibly conclude that it's not very important >to have an IPv6 header field that labels flows after all, in which case >the field would then become reserved and subject to alternative proposals >(though in my personal opinion, spare bits are just an invitation to >unnecessary featuritis). >If you don't like that answer, please let us know. We aim to serve. I'm okay with the above answer, and I understand the timing constraints (of course I would like to hear from masa about it). but now I have other questions - (1) what is "flow" here, and (2) if people agree with the definition of "flow" in RFC2460 appendix A (first paragraph), why would people want the field to be hop-by-hop modifyable? the following does not seem like an "identification of flow" to me. > (2) a mutable value that can be or will be modified hop-by-hop, > like an ATM virtual circuit identifier or an MPLS label. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 01:21:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9LOIm009607 for ; Fri, 16 Mar 2001 01:21:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G9LNBH009606 for ipng-dist; Fri, 16 Mar 2001 01:21:23 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9LCIm009599 for ; Fri, 16 Mar 2001 01:21:12 -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 BAA04820 for ; Fri, 16 Mar 2001 01:21:12 -0800 (PST) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16825 for ; Fri, 16 Mar 2001 02:21:10 -0700 (MST) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id LAA07436; Fri, 16 Mar 2001 11:23:06 +0200 Date: Fri, 16 Mar 2001 11:23:06 +0200 Message-Id: <200103160923.LAA07436@burp> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: Dealing with fe80:xx:, when xx != :: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While looking at the IPv6 code, I notice that I have two options in recognizing my link local address as my own: 1) only fe80::my-id 2) or fe80:x:my-id, where x can be anything. What should I do with incoming packet that has destination fe80:x:my-id and 'x' != ::? a) drop it b) accept it as addressed to me c) something else? Maybe some RFC actually tells this, but I don't remember seeing it directly mentioned ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 01:27:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9R8Im009648 for ; Fri, 16 Mar 2001 01:27:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G9R8M5009647 for ipng-dist; Fri, 16 Mar 2001 01:27: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9QxIm009640 for ; Fri, 16 Mar 2001 01:26:59 -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 BAA28826 for ; Fri, 16 Mar 2001 01:26:59 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (jasmine.home.cs.mu.OZ.AU [128.250.38.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01217 for ; Fri, 16 Mar 2001 01:26:56 -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 f2G9Qjb00604; Fri, 16 Mar 2001 20:26:45 +1100 (EST) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME In-reply-to: Your message of "16 Mar 2001 01:16:57 -0000." <20010316011657.17822.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Mar 2001 20:26:45 +1100 Message-ID: <602.984734805@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 16 Mar 2001 01:16:57 -0000 From: "D. J. Bernstein" Message-ID: <20010316011657.17822.qmail@cr.yp.to> | If you | have some other constraint in mind, please say exactly what it is, so | that we can see whether the constrained feature is reliable and useful. I suspect this is a pointless discussion, as neither A6 nor DNAME is going to be made historic before there's ever been any realistic chance to experiment with them and discover whether they are workable or not. But if one were forced to add a constraint to A6, it may be that it would only be legal to refer to names in the same zone (servers can enforce that trivially when loading the zone, resolvers could ignore any responses that didn't include the complete chain in one packet). But until we see how well it works in practice, we won't know whether there is even any point discussing any of this - this is the kind of thing that should be being discussed when the doc is ready to be considered to be advanced to DS status, and we're certainly not there yet. 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 Mar 16 01:30:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9UHIm009661 for ; Fri, 16 Mar 2001 01:30:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G9UH1Z009660 for ipng-dist; Fri, 16 Mar 2001 01:30: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9U5Im009653 for ; Fri, 16 Mar 2001 01:30:06 -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 BAA03296 for ; Fri, 16 Mar 2001 01:30:05 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10492 for ; Fri, 16 Mar 2001 01:30:04 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA23269; Fri, 16 Mar 2001 18:29:50 +0900 (JST) To: Markku Savela cc: ipng@sunroof.eng.sun.com In-reply-to: msa's message of Fri, 16 Mar 2001 11:23:06 +0200. <200103160923.LAA07436@burp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Dealing with fe80:xx:, when xx != :: From: itojun@iijlab.net Date: Fri, 16 Mar 2001 18:29:50 +0900 Message-ID: <23267.984734990@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >While looking at the IPv6 code, I notice that I have two options in >recognizing my link local address as my own: > 1) only fe80::my-id > 2) or fe80:x:my-id, where x can be anything. I guess you are looking at KAME code. if so, please read through the following URL, section 1.3. (1) is the legal one, (2) is used in KAME kernel internally and should never appear on wire nor userland API. http://www.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION?rev=1.198 itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 02:07:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GA7kIm009788 for ; Fri, 16 Mar 2001 02:07:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GA7jtb009787 for ipng-dist; Fri, 16 Mar 2001 02:07:45 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GA7aIm009780 for ; Fri, 16 Mar 2001 02:07:36 -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 CAA06057 for ; Fri, 16 Mar 2001 02:07:36 -0800 (PST) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26027 for ; Fri, 16 Mar 2001 02:07:35 -0800 (PST) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id MAA07495; Fri, 16 Mar 2001 12:09:31 +0200 Date: Fri, 16 Mar 2001 12:09:31 +0200 Message-Id: <200103161009.MAA07495@burp> From: Markku Savela To: itojun@iijlab.net CC: ipng@sunroof.eng.sun.com In-reply-to: <23267.984734990@coconut.itojun.org> Subject: Re: Dealing with fe80:xx:, when xx != :: Reply-to: Markku.Savela@iki.fi References: <23267.984734990@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 1) only fe80::my-id > > 2) or fe80:x:my-id, where x can be anything. > > I guess you are looking at KAME code. if so, please read through > the following URL, section 1.3. (1) is the legal one, (2) is > used in KAME kernel internally and should never appear on wire > nor userland API. Yes, I know (1) is the legal. To rephrase: what should I do with the illegal (2) variant? [stack must handle any incoming stuff, even if illegal]. The address obviously belongs to my host, there cannot be any other host having such address. To drop it, I have to do the additional check for x=0 specially. Could also just leave the test out, and treat is as legal packet. The choice in here fixes possible future uses of those bits. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 03:07:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GB7mIm009900 for ; Fri, 16 Mar 2001 03:07:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GB7msW009899 for ipng-dist; Fri, 16 Mar 2001 03:07: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GB7bIm009892 for ; Fri, 16 Mar 2001 03:07: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 DAA06456 for ; Fri, 16 Mar 2001 03:07:36 -0800 (PST) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA22723 for ; Fri, 16 Mar 2001 04:07:33 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C49417E73; Fri, 16 Mar 2001 20:06:28 +0900 (JST) To: Markku.Savela@iki.fi Cc: ipng@sunroof.eng.sun.com In-reply-to: msa's message of Fri, 16 Mar 2001 12:09:31 +0200. <200103161009.MAA07495@burp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Dealing with fe80:xx:, when xx != :: From: Jun-ichiro itojun Hagino Date: Fri, 16 Mar 2001 20:06:28 +0900 Message-Id: <20010316110628.C49417E73@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Yes, I know (1) is the legal. To rephrase: what should I do with the >illegal (2) variant? [stack must handle any incoming stuff, even if >illegal]. if you are writing some other kernel code, drop them. KAME ip6_input() should make it sure to drop those - i'll check if we already do it or not. if you are writing userland applications, you need not to worry about it. scoped IP addresses will come up as fe80::foobar, with sin6_scope_id filled in. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 05:23:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GDNdIm010081 for ; Fri, 16 Mar 2001 05:23:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GDNdp3010080 for ipng-dist; Fri, 16 Mar 2001 05:23: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GDNUIm010073 for ; Fri, 16 Mar 2001 05:23:30 -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 FAA29237 for ; Fri, 16 Mar 2001 05:23:29 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22273 for ; Fri, 16 Mar 2001 05:23:29 -0800 (PST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 5BB5182F525; Fri, 16 Mar 2001 14:23:26 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA00134; Fri, 16 Mar 2001 14:23:26 +0100 (MET) To: Robert Elz Cc: "D. J. Bernstein" , ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME References: <602.984734805@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 16 Mar 2001 14:23:25 +0100 In-Reply-To: Robert Elz's message of "Fri, 16 Mar 2001 20:26:45 +1100" Message-ID: Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > But if one were forced to add a constraint to A6, it may be that it > would only be legal to refer to names in the same zone (servers can > enforce that trivially when loading the zone, resolvers could ignore > any responses that didn't include the complete chain in one packet). Another reasonable constraint might be to require that each link in an A6 chain add at least one bit to the prefix. If nothing else, it lets clients and resolvers get away without special hacks to detect cycles. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 06:35:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEZZIm010322 for ; Fri, 16 Mar 2001 06:35:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GEZZUB010321 for ipng-dist; Fri, 16 Mar 2001 06:35:35 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEZQIm010314 for ; Fri, 16 Mar 2001 06:35:26 -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 GAA24600 for ; Fri, 16 Mar 2001 06:35:26 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06823 for ; Fri, 16 Mar 2001 07:35:25 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2GEYqd44306; Fri, 16 Mar 2001 15:34:53 +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 PAA26690; Fri, 16 Mar 2001 15:34:52 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2GEYpA21092; Fri, 16 Mar 2001 15:34:51 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103161434.f2GEYpA21092@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: Dealing with fe80:xx:, when xx != :: In-reply-to: Your message of Fri, 16 Mar 2001 11:23:06 +0200. <200103160923.LAA07436@burp> Date: Fri, 16 Mar 2001 15:34:51 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: While looking at the IPv6 code, I notice that I have two options in recognizing my link local address as my own: => no, there is only one! 1) only fe80::my-id => this one. 2) or fe80:x:my-id, where x can be anything. => this is internally used by some implementations: - you must not use it - implementers should not use it What should I do with incoming packet that has destination fe80:x:my-id and 'x' != ::? a) drop it b) accept it as addressed to me c) something else? => drop it (a) and send a bug report to implementers of the source. Maybe some RFC actually tells this, but I don't remember seeing it directly mentioned ... => RFC 1884 2.4.8 (on all types of interfaces where IPv6 transport have been defined the n is 64): | 10 | | bits | n bits | 118-n bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ 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 Mar 16 06:42:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEgkIm010358 for ; Fri, 16 Mar 2001 06:42:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GEgjRg010357 for ipng-dist; Fri, 16 Mar 2001 06:42:45 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEgZIm010350 for ; Fri, 16 Mar 2001 06:42: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 GAA02255 for ; Fri, 16 Mar 2001 06:42:36 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12184 for ; Fri, 16 Mar 2001 06:42:35 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2GEfmd27068; Fri, 16 Mar 2001 15:41: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 PAA26904; Fri, 16 Mar 2001 15:41:48 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2GEfkA21168; Fri, 16 Mar 2001 15:41:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103161441.f2GEfkA21168@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku.Savela@iki.fi cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Dealing with fe80:xx:, when xx != :: In-reply-to: Your message of Fri, 16 Mar 2001 12:09:31 +0200. <200103161009.MAA07495@burp> Date: Fri, 16 Mar 2001 15:41:46 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The choice in here fixes possible future uses of those bits. => don't worry, there is no future use of those bits (in the past there were some proposals which were rejected for many strong reasons). But please don't apply this advice to site-local addresses. 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 Mar 16 08:21:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGLMIm010647 for ; Fri, 16 Mar 2001 08:21:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGLMiC010646 for ipng-dist; Fri, 16 Mar 2001 08:21:22 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGLDIm010639 for ; Fri, 16 Mar 2001 08:21:13 -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 IAA20078; Fri, 16 Mar 2001 08:21:13 -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 IAA19850; Fri, 16 Mar 2001 08:21:12 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA15088; Fri, 16 Mar 2001 08:20:59 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAG20111; Fri, 16 Mar 2001 08:20:57 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: <22178.984731332@coconut.itojun.org> References: <22178.984731332@coconut.itojun.org> Date: Fri, 16 Mar 2001 08:21:01 -0800 To: itojun@iijlab.net From: Steve Deering Subject: Re: Flow Label discussion Cc: Erik Nordmark , Masafumi OE , Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:28 PM +0900 3/16/01, itojun@iijlab.net wrote: > the following does not seem like an "identification of flow" to me. > > > (2) a mutable value that can be or will be modified hop-by-hop, > > like an ATM virtual circuit identifier or an MPLS label. That's the kind of thing ATM/MPLS switches use to identify which packets belong to which flows (circuits, streams, whatever you want to call them). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 08:31:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGVMIm010669 for ; Fri, 16 Mar 2001 08:31:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGVMvV010668 for ipng-dist; Fri, 16 Mar 2001 08:31:22 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGVDIm010661 for ; Fri, 16 Mar 2001 08:31: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 IAA17798 for ; Fri, 16 Mar 2001 08:31:12 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01609 for ; Fri, 16 Mar 2001 09:31:11 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id IAA16877; Fri, 16 Mar 2001 08:29:56 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAG20237; Fri, 16 Mar 2001 08:31:09 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: <200103161009.MAA07495@burp> References: <23267.984734990@coconut.itojun.org> <200103161009.MAA07495@burp> Date: Fri, 16 Mar 2001 08:31:12 -0800 To: Markku.Savela@iki.fi From: Steve Deering Subject: Re: Dealing with fe80:xx:, when xx != :: Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:09 PM +0200 3/16/01, Markku Savela wrote: >The address obviously belongs to my host, there cannot be any other >host having such address. To drop it, I have to do the additional >check for x=0 specially. Could also just leave the test out, and treat >is as legal packet. To recognize your own addresses, you should be doing a full 128-bit compare, not examining individual fields. Just put all of your own addresses in your routing table, with a prefix length of 128 bits and a "self" indicator, and let normal longest-match lookup do its thing. Embedding unnecessary knowledge of address structure or address allocation policy in your code is Bad Practice. >The choice in here fixes possible future uses of those bits. Yes, if you start making assumptions about address formats or contents beyond what the specifications require, and if your implementation gets widely deployed, that may well become a major inhibitor to future evolution of the protocol. Please don't do that. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 08:33:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGXxIm010682 for ; Fri, 16 Mar 2001 08:33:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGXwtk010681 for ipng-dist; Fri, 16 Mar 2001 08:33: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGXmIm010674 for ; Fri, 16 Mar 2001 08:33:48 -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 IAA10476 for ; Fri, 16 Mar 2001 08:33:49 -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 JAA03070 for ; Fri, 16 Mar 2001 09:33:38 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23291; Fri, 16 Mar 2001 08:33:22 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAG20257; Fri, 16 Mar 2001 08:33:21 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: <200103161441.f2GEfkA21168@givry.rennes.enst-bretagne.fr> References: <200103161441.f2GEfkA21168@givry.rennes.enst-bretagne.fr> Date: Fri, 16 Mar 2001 08:33:25 -0800 To: Francis Dupont From: Steve Deering Subject: Re: Dealing with fe80:xx:, when xx != :: Cc: Markku.Savela@iki.fi, itojun@iijlab.net, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:41 PM +0100 3/16/01, Francis Dupont wrote: >=> don't worry, there is no future use of those bits (in the past >there were some proposals which were rejected for many strong reasons). >But please don't apply this advice to site-local addresses. My advice is the same for link-locals and site-locals: use a full 128-bit compare to recognize your own addresses. That will continue to work, whether or not sites end up using non-zero values in the high-order part of their site-locals. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 08:45:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGjXIm010801 for ; Fri, 16 Mar 2001 08:45:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGjWug010800 for ipng-dist; Fri, 16 Mar 2001 08:45: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGjJIm010793 for ; Fri, 16 Mar 2001 08:45:20 -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 IAA13589 for ; Fri, 16 Mar 2001 08:45:20 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09910 for ; Fri, 16 Mar 2001 08:45:14 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id CDBDF1E030; Fri, 16 Mar 2001 11:44:40 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA13267; Fri, 16 Mar 2001 11:44:39 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 1F5C835C44; Fri, 16 Mar 2001 11:44:38 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Erik Nordmark Cc: Masafumi OE , Jim.Bound@nokia.com, deering@cisco.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Subject: Re: Flow Label discussion Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Mar 2001 11:44:36 -0500 Message-Id: <20010316164438.1F5C835C44@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Erik Nordma rk writes: > >This would seem to fall under the ITRACE WG as far as I can tell. Although the topic fits, it's out of charter for ITRACE -- we're working on an ICMP message for traceback. > > Erik > >>----- Begin Included Message -----< > >Date: Thu, 15 Mar 2001 18:25:56 +0900 >From: "Masafumi OE" >Subject: Re: Flow Label discussion >To: Jim.Bound@nokia.com >Cc: deering@cisco.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, >hinden@iprg.nokia.com > >Hello, > >Could do you give me 10 minutes to talk and discuss about my IPv6 >traceback idea? >This technique is routers mark own address and previous hop's address >that is divided on flow label. > >Nodes can make paths from a lot of IPv6 packets with the flow label. >I guess this idea is effective for finding DDoS attacker using faked >source address. > >Because I am a newcomer person, I leave the judgment whether to giving >valuable time for me to the chair. > >As a judgment material, my proposal will be uploaded in webpage by Saturday. > >Thank you. > >-- >Masafumi Oe, NAIST, WIDE, JAPAN. > >On Wed, Mar 14, 2001 at 10:57:18AM -0600, > Jim.Bound@nokia.com wrote: > >> good idea. how about each person write short abstract and send to the list >> not more than two paragraphs and one is better? I for one may not be able >> to do that till end of week or on sunday night from hotel? >> >> thx >> /jim >> >> > -----Original Message----- >> > From: ext Steve Deering [mailto:deering@cisco.com] >> > Sent: Wednesday,March 14,2001 11:16 AM >> > To: Erik Nordmark >> > Cc: ipng@sunroof.eng.sun.com; Bob Hinden >> > Subject: Re: Flow Label discussion >> > >> > >> > At 12:09 PM +0100 3/14/01, Erik Nordmark wrote: >> > >Thus before the WG can actually make any decisions about flow label >> > >semantics I think we need to have folks write up the different >> > >problem statements for which they see the flow label as a >> > potential solution. >> > >Then the WG can decide which problem(s) are the most >> > important to solve >> > >and whether or not using the flow label is the best >> > solution. That would >> > >then hopefully lead to nailing down the semantics of the flow label. >> > > >> > >So having the discussion you propose is fine, but please >> > keep the problem >> > >statements in mind. >> > >> > Excellent point, Erik. Clearly, we don't have time for much >> > writing up >> > before the meeting, but those of you who wish to make presentations >> > should include a description of what problems you are trying to solve, >> > why those are essential problems to solve, and why using the IPv6 Flow >> > Label is the best or only way to solve them. It would be good if our >> > discussion helps to focus the problem space and the set of potential >> > solutions, so there will be fewer drafts that need to be written and >> > argued about afterwards. (Well, one can hope... :-) >> > >> > Steve > >>----- End Included 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 >-------------------------------------------------------------------- > --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 08:52:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGqbIm010839 for ; Fri, 16 Mar 2001 08:52:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGqbeC010838 for ipng-dist; Fri, 16 Mar 2001 08:52: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGqQIm010828 for ; Fri, 16 Mar 2001 08:52:27 -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 IAA13742 for ; Fri, 16 Mar 2001 08:52:27 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28072 for ; Fri, 16 Mar 2001 08:52:26 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2GGpgd26810; Fri, 16 Mar 2001 17:51: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 RAA00905; Fri, 16 Mar 2001 17:51:42 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2GGpfA22065; Fri, 16 Mar 2001 17:51:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103161651.f2GGpfA22065@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: Markku.Savela@iki.fi, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Dealing with fe80:xx:, when xx != :: In-reply-to: Your message of Fri, 16 Mar 2001 08:33:25 PST. Date: Fri, 16 Mar 2001 17:51:41 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: At 3:41 PM +0100 3/16/01, Francis Dupont wrote: >=> don't worry, there is no future use of those bits (in the past >there were some proposals which were rejected for many strong reasons). >But please don't apply this advice to site-local addresses. My advice is the same for link-locals and site-locals: use a full 128-bit compare to recognize your own addresses. That will continue to work, whether or not sites end up using non-zero values in the high-order part of their site-locals. => I believe the initial issue was a bit different: check or not check that the must-be-zero bits are zero or not. Usually you should not check them (ie. only do what you advice) but if you suspect some bugs you may add a check in order to track them, in such a case if MBZ bits become no more MBZ you'll be in trouble. My advice was this should not happen for link-local addresses (so a check may safely be added and forgotten) but not for site-local addresses (so if a check is added then it must not be forgotten, usually it will be forgotten so it should not be added)... 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 Mar 16 11:16:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJGWIm011364 for ; Fri, 16 Mar 2001 11:16:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GJGVab011363 for ipng-dist; Fri, 16 Mar 2001 11:16:31 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJFhIm011356 for ; Fri, 16 Mar 2001 11:16:03 -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 LAA27418 for ; Fri, 16 Mar 2001 11:15:43 -0800 (PST) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10286 for ; Fri, 16 Mar 2001 11:15:39 -0800 (PST) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id VAA07948; Fri, 16 Mar 2001 21:17:23 +0200 Date: Fri, 16 Mar 2001 21:17:23 +0200 Message-Id: <200103161917.VAA07948@burp> From: Markku Savela To: deering@cisco.com CC: Markku.Savela@iki.fi, itojun@iijlab.net, ipng@sunroof.eng.sun.com In-reply-to: (message from Steve Deering on Fri, 16 Mar 2001 08:31:12 -0800) Subject: Re: Dealing with fe80:xx:, when xx != :: References: <23267.984734990@coconut.itojun.org> <200103161009.MAA07495@burp> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To recognize your own addresses, you should be doing a full 128-bit > compare, not examining individual fields. Just put all of your > own addresses in your routing table, with a prefix length of 128 > bits and a "self" indicator, and let normal longest-match lookup > do its thing. That is obviously doable, when an interface has single id. However, the issue came up when I started to explore the possibilities of implementing the "privacy option", which could be interpreted (?) in such way that an interface can have N different id's. And if, you see a router avertising M new prefixes, you will have to add N x M addresses to your routing list. And when an id or a prefix expires, you have to rip off the matching addressess. I was just looking, what would happen if I kept two lists: one for prefixes and one for id's, and allowed any combination to be used and recognized as own address. [For new id's I would do the DAD using the link local address combined with the generated id]. -- Markku Savela -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 14:00:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GM09Im011832 for ; Fri, 16 Mar 2001 14:00:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GM09DF011831 for ipng-dist; Fri, 16 Mar 2001 14:00: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GM00Im011824 for ; Fri, 16 Mar 2001 14:00:00 -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 NAA03308; Fri, 16 Mar 2001 13:59:55 -0800 (PST) Received: from relay1.ne.smtp.psi.net (relay1.ne.smtp.psi.net [38.9.153.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14408; Fri, 16 Mar 2001 13:59:53 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.ne.smtp.psi.net with smtp (Exim 3.13 #3) id 14e2GH-00057T-00; Fri, 16 Mar 2001 16:59:53 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA29462; Fri, 16 Mar 01 16:52:52 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id RAA19925; Fri, 16 Mar 2001 17:00:58 -0500 Message-Id: <3AB28D17.54FCD3B3@txc.com> Date: Fri, 16 Mar 2001 17:00:56 -0500 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en Mime-Version: 1.0 To: Erik Nordmark Cc: Steve Deering , ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: Flow Label discussion References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms9D0C1A3977DC35369BAF1CE7" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms9D0C1A3977DC35369BAF1CE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Very good, in fact, essential point. Reserving the time on the agenda is very welcome. Given the somewhat short notice - I was on travel and could not see the note until Friday afternoon - I am hoping that all ideas or points will be formulated and expressed, but in case not, the topic should be kept open for discussion on the mailing list, for a while, before taking decisions. Regards, Alex Erik Nordmark wrote: > > > At the moment, we have one scheduled presentation on Flow Label issues, > > by Winston Seah (draft-shen-ipv6-flow-trans-00.txt), and we would like > > to offer the opportunity for others who were arguing for alternative > > semantics for the Flow Label field to summarize their proposals. If > > I recall correctly, the debate came to down to basically three > > different choices for Flow Label semantics: > > > > (1) a non-mutable value that, when concatenated with the source > > address, can be used by routers to identify flows. (This was > > the original design, described in pre-RFC2460 versions of > > the IPv6 spec.) > > > > (2) a mutable value that can be or will be modified hop-by-hop, > > like an ATM virtual circuit identifier or an MPLS label. > > > > (3) a hybrid of (1) and (2) in which, say, one bit of the Flow > > Label field indicates whether or not the rest of the field > > is mutable. > > I understand that the above 3 are the currently understood alternatives > for what the flow label semantics could be. > > I think that I could construct arguments for either one of them > being the best; it all depends on what problem I think the 20 bits could be > used to solve. So while it might be useful to get arguments for and against the > various semantics on the table, there is a risk that this isn't productive is > folks have very different views of what problem they can solve using the flow > label field. > > Thus before the WG can actually make any decisions about flow label > semantics I think we need to have folks write up the different > problem statements for which they see the flow label as a potential solution. > Then the WG can decide which problem(s) are the most important to solve > and whether or not using the flow label is the best solution. That would > then hopefully lead to nailing down the semantics of the flow label. > > So having the discussion you propose is fine, but please keep the problem > statements in mind. > > 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 > -------------------------------------------------------------------- --------------ms9D0C1A3977DC35369BAF1CE7 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 MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTAzMTYyMjAwNThaMCMGCSqGSIb3DQEJBDEWBBTPcfuvwsY5GwYi4MIJ pFNJwUI5yjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gLl7J94CTNeXFnAQdGghjuMG8AfIymQrWyNFBLWdu6Xb9gx0yphKp7H0NzIyLnc6DEHo9lG+ FQPOZU2irjj/a2QB8kML+qGo6zczcyvg2oeBlyP1eCfpXXU+/9xnxqbIExXOop+sJdfKybwf bkMtFmKwmtkcoIFLn1UElY9NtYme --------------ms9D0C1A3977DC35369BAF1CE7-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 17:38:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2H1caIm012486 for ; Fri, 16 Mar 2001 17:38:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2H1caBn012485 for ipng-dist; Fri, 16 Mar 2001 17:38:36 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2H1cWIm012478 for ; Fri, 16 Mar 2001 17:38:32 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2H1Zlx16076 for ipng@sunroof.eng.sun.com; Fri, 16 Mar 2001 17:35:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GMWsIm011958 for ; Fri, 16 Mar 2001 14:32: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 OAA10094 for ; Fri, 16 Mar 2001 14:32:56 -0800 (PST) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA06720 for ; Fri, 16 Mar 2001 14:32:51 -0800 (PST) Received: (qmail 29834 invoked from network); 16 Mar 2001 22:32:50 -0000 Received: from ninelives.chek.com (208.197.227.14) by mailrelay1.chek.com with SMTP; 16 Mar 2001 22:32:50 -0000 Received: (qmail 6489 invoked by uid 99); 16 Mar 2001 22:28:28 -0000 Date: 16 Mar 2001 22:28:28 -0000 Message-ID: <20010316222828.6488.qmail@ninelives.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [213.228.132.18] Subject: NAPT - Microsoft Implementation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've installed NAPT on my PC,like it says on the NAPT INstallation Configuration paper, but the route "::ffff:0:0/96 -> 4 "was not created, can anyone tell me why? _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 18:43:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2H2hZIm012608 for ; Fri, 16 Mar 2001 18:43:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2H2hYxs012607 for ipng-dist; Fri, 16 Mar 2001 18:43: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2H2hNIm012600 for ; Fri, 16 Mar 2001 18:43:23 -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 SAA23171 for ; Fri, 16 Mar 2001 18:43:20 -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 SAA12232 for ; Fri, 16 Mar 2001 18:43:20 -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 SAA23363; Fri, 16 Mar 2001 18:43:13 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2H2hBB30334; Fri, 16 Mar 2001 18:43:11 -0800 X-mProtect: Fri, 16 Mar 2001 18:43:11 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (192.103.16.65, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdgJcoUo; Fri, 16 Mar 2001 18:43:07 PST Message-Id: <4.3.2.7.2.20010316165151.02655570@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 17:02:35 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Updated IPng Agenda for Minneapolis IETF Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the updated agenda for IPng w.g. sessions at the Minneapolis IETF. Note: Links are include for the two drafts that were delayed in the mail and didn't arrive at the ID folks in time. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------------- MONDAY, March 19, 2001 0900-1130 (Salon D) ------------------------------------------- Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) IPv6 Addressing Documents Issues and Status / Thomas Narten (10 min) Source/Destination Address Selection / Rich Draves (30 min) ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngwg-default-addr-select-03.txt Default Router Preferences & More Specific Routes in RAs / Rich Draves (20 min) ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router-selection-01.txt Generic Packet Tunneling in IPv6 - Bi-directional Tunneling / Alex Conta (15 min) An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min) Host-based Anycast using MLD / Brian Haberman (30 min) Site prefixes in Neighbor Discovery / Erik Nordmark (30 min) THURSDAY, March 22, 2001 1530-1730 (Salon D) -------------------------------------------- MIB Design Team Report / Bill Fenner (10 min) IPv6 Scoped Address Architecture / Steve Deering (10 min) IPv6 Near-Unique Site-Local Addresses / Paul Francis (20 min) DNS Server Discovery Mechanisms for IPv6 Update / Dave Thaler (15 min) Multicast Listener Discovery Version 2 (MLDv2) for IPv6 / Luis Costa (10 min) IPv6 Flow Label Track (60 min) Flow Transparent Mobility and QoS Support for IPv6-based Wireless Real-time Services / Winston Seah (10 min) [Other talks to be announced] ----------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 17 04:48:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HCm3Im013083 for ; Sat, 17 Mar 2001 04:48:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2HCm3wK013082 for ipng-dist; Sat, 17 Mar 2001 04:48: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HClrIm013075 for ; Sat, 17 Mar 2001 04:47:54 -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 EAA18839 for ; Sat, 17 Mar 2001 04:47:52 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (jasmine.home.cs.mu.OZ.AU [128.250.38.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08626 for ; Sat, 17 Mar 2001 04:47:49 -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 f2HCkub04157; Sat, 17 Mar 2001 23:46:58 +1100 (EST) From: Robert Elz To: Markku Savela cc: deering@cisco.com, Markku.Savela@iki.fi, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Dealing with fe80:xx:, when xx != :: In-reply-to: Your message of "Fri, 16 Mar 2001 21:17:23 +0200." <200103161917.VAA07948@burp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Mar 2001 23:46:56 +1100 Message-ID: <4155.984833216@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 16 Mar 2001 21:17:23 +0200 From: Markku Savela Message-ID: <200103161917.VAA07948@burp> | I was just looking, what would happen if I kept two lists: one for | prefixes and one for id's, and allowed any combination to be used | and recognized as own address. Don't do that. For autoconfigured addresses it will probably work (probably) but for assigned addresses, things will break badly. There's no reason that on a link with prefixes A::/64 abd B::/64 I can't assign A::1 and B::2 to node X, and A::2 and B::1 to node Y. Your scheme would break that totally. 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 Sat Mar 17 05:06:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HD65Im013104 for ; Sat, 17 Mar 2001 05:06:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2HD65o0013103 for ipng-dist; Sat, 17 Mar 2001 05:06: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HD5uIm013096 for ; Sat, 17 Mar 2001 05:05:56 -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 FAA01107 for ; Sat, 17 Mar 2001 05:05:54 -0800 (PST) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16066 for ; Sat, 17 Mar 2001 05:05:53 -0800 (PST) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id PAA08609; Sat, 17 Mar 2001 15:06:01 +0200 Date: Sat, 17 Mar 2001 15:06:01 +0200 Message-Id: <200103171306.PAA08609@burp> From: Markku Savela To: kre@munnari.OZ.AU CC: deering@cisco.com, itojun@iijlab.net, ipng@sunroof.eng.sun.com In-reply-to: <4155.984833216@brandenburg.cs.mu.OZ.AU> (message from Robert Elz on Sat, 17 Mar 2001 23:46:56 +1100) Subject: Re: Dealing with fe80:xx:, when xx != :: References: <4155.984833216@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Don't do that. For autoconfigured addresses it will probably work > (probably) but for assigned addresses, things will break badly. > There's no reason that on a link with prefixes A::/64 abd B::/64 > I can't assign A::1 and B::2 to node X, and A::2 and B::1 to node Y. Yes, I was talking about autoconfigured addresses. I did have in mind allowing the full addresses being configured as an option. But, it does raise a question: if you configure "A::1", and then some host happens to autoconfigure "fe80::1" and performs DAD on this (ADDRCONF specially mentions that you can do DAD on link-local, as id should be unique, and can freely assume that A::1 is also usable. You don't need to do DAD on every combination!). This is messy. Either you allow all id/prefix combinations and require that plain "id" part is always unique on link, or you forget the prefix/id split and treat all combinations as independent addresses, which *ALL* require DAD to be usable. My interpretation of related RFC's (Neighbor Discovery, ADDRCONF) is that they speak of id/prefix combinations. If this isn't true, some text needs revision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 17 09:46:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HHkaIm013231 for ; Sat, 17 Mar 2001 09:46:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2HHkaxm013230 for ipng-dist; Sat, 17 Mar 2001 09:46: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HHkOIm013223 for ; Sat, 17 Mar 2001 09:46:25 -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 JAA10775 for ; Sat, 17 Mar 2001 09:46:19 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp013.iij-us.net [216.98.99.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18156 for ; Sat, 17 Mar 2001 10:46:16 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 069AC7E73; Sun, 18 Mar 2001 02:45:59 +0900 (JST) To: Markku Savela Cc: kre@munnari.OZ.AU, deering@cisco.com, ipng@sunroof.eng.sun.com In-reply-to: msa's message of Sat, 17 Mar 2001 15:06:01 +0200. <200103171306.PAA08609@burp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Dealing with fe80:xx:, when xx != :: From: Jun-ichiro itojun Hagino Date: Sun, 18 Mar 2001 02:45:58 +0900 Message-Id: <20010317174559.069AC7E73@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Don't do that. For autoconfigured addresses it will probably work >> (probably) but for assigned addresses, things will break badly. >> There's no reason that on a link with prefixes A::/64 abd B::/64 >> I can't assign A::1 and B::2 to node X, and A::2 and B::1 to node Y. > >Yes, I was talking about autoconfigured addresses. I did have in mind >allowing the full addresses being configured as an option. > >But, it does raise a question: if you configure "A::1", and then some >host happens to autoconfigure "fe80::1" and performs DAD on this >(ADDRCONF specially mentions that you can do DAD on link-local, as id >should be unique, and can freely assume that A::1 is also usable. You >don't need to do DAD on every combination!). I suggest you to rnu DAD for every address you have (so run DAD for A::1). the following fragment is from RFC2462 5.4. I believe it works only if all the neighbors are using autoconfigured address only. as we are not sure about how the neighbors would behave, it is safer to run DAD for eveyr addresses you have. in the past, KAME omitted DAD for A::id, when A::id is autoconfigured from fe80::id. with the latest code we run DAD for A::id as well. itojun - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 01:23:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2I9NqIm014149 for ; Sun, 18 Mar 2001 01:23:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2I9NqRq014148 for ipng-dist; Sun, 18 Mar 2001 01:23: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2I9NdIm014141 for ; Sun, 18 Mar 2001 01:23:41 -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 BAA02380 for ; Sun, 18 Mar 2001 01:23:29 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08769 for ; Sun, 18 Mar 2001 01:23:27 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id DB87372543; Sun, 18 Mar 2001 11:23:25 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id EC01FBA08; Sun, 18 Mar 2001 11:23:24 +0200 (EET) Message-ID: <3AB47F98.A5CFEC6C@nomadiclab.com> Date: Sun, 18 Mar 2001 11:27:52 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: IPSEC Mailing List , IPNG Mailing List Subject: A method to prevent DoS in IPv6 DAD and Mobile IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A number of recent ID:s have shown a number of potential security deficiencies in the way IPsec is used in a number of IPv6 signalling functions, including Duplicate Address Detection (DAD) and Mobile IPv6 Binding Updates (BUs). The relevant drafts include the following. draft-arkko-icmpv6-ike-effects-00.txt draft-nikander-ipng-address-ownership-00.txt The so called PBK-keys (draft-bradner-pbk-frame-00.txt) attemts to solve the Mobile IPv6 related problem by proposing a new class of identifiers, EIDs. In some respects that approach is similar to the HIP approach. While thinking about the problem, an idea of using the IPv6 interface identifier as a cryptographic token appeared to me. That is, by generating the interface identifier from components using a cryptographic one-way function, one can "bind" the interface identifier to the components, and the base security on the components. The idea is very new, and comments are solicited. Currently a working copy of the forthcoming -00 drafts is available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt I'll be working with the draft during my flights to Minneapolis, posting is as soon as drafts are accepted again. There is currently a plan to discuss related issues at the Mobile IP WG meeting and the SAAG session on Thursday. --Pekka Nikander Ericsson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 12:03:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2IK3kIm014482 for ; Sun, 18 Mar 2001 12:03:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2IK3kb6014481 for ipng-dist; Sun, 18 Mar 2001 12:03:46 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2IK3bIm014474 for ; Sun, 18 Mar 2001 12:03:37 -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 MAA28384 for ; Sun, 18 Mar 2001 12:03:36 -0800 (PST) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15807 for ; Sun, 18 Mar 2001 12:03:34 -0800 (PST) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id WAA22497; Sun, 18 Mar 2001 22:05:49 +0200 Date: Sun, 18 Mar 2001 22:05:49 +0200 Message-Id: <200103182005.WAA22497@burp> From: Markku Savela To: itojun@iijlab.net CC: kre@munnari.OZ.AU, deering@cisco.com, ipng@sunroof.eng.sun.com In-reply-to: <20010317174559.069AC7E73@starfruit.itojun.org> (message from Jun-ichiro itojun Hagino on Sun, 18 Mar 2001 02:45:58 +0900) Subject: Re: Dealing with fe80:xx:, when xx != :: References: <20010317174559.069AC7E73@starfruit.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I suggest you to rnu DAD for every address you have (so run > DAD for A::1). the following fragment is from RFC2462 5.4. I > believe it works only if all the neighbors are using > autoconfigured address only. as we are not sure about how the > neighbors would behave, it is safer to run DAD for eveyr > addresses you have. Why cannot id's on link be simply defined as: - Any active normal id on the link can be assigned only to one host at at a time. - in ADDRCOF, DAD would simply reduce to a question: is the id part of the address same as one of my assigned ids? It would not matter which prefix you use to do the DAD. - neighbor discovery would not need any changes. That would still use full addresses. What are the objections against above simple fix? What breaks? As it is now, and from the messages on this thread I deduce, that my implementation must do the following things: - at interface startup obtain id(s) and do DAD on it/them using link local address - do DAD on each manually configured address - on receiving RA, if it has M new prefixes (with A=1), and I have currently N id's, start M*N DAD processes, one for each combination. (at least TAHI seems to expect to see DAD on RA). Must handle situations where some combinations pass DAD and some not. => if I need some failed prefix, I have to generate a new id before I can use it - any time I generate a id (privacy), and if I have M prefixes, do start M+1 DAD processes, one for each prefix and one for link local. Of course, one could delay generating id and testing DAD until one has a packet to send. I don't much like this, as it either requires buffering packets at IP layer or dropping them, until situation gets cleared. [yes, I already have to do it for ND, but I still don't like it .. :-] -- Markku Savela -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 15:18:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2INItIm014948 for ; Sun, 18 Mar 2001 15:18:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2INIthP014947 for ipng-dist; Sun, 18 Mar 2001 15:18: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2INIkIm014940 for ; Sun, 18 Mar 2001 15:18:46 -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 PAA08800 for ; Sun, 18 Mar 2001 15:18:47 -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 PAA02273 for ; Sun, 18 Mar 2001 15:18:46 -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 PAA07864; Sun, 18 Mar 2001 15:18:46 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2INIjV19199; Sun, 18 Mar 2001 15:18:45 -0800 X-mProtect: Sun, 18 Mar 2001 15:18:45 -0800 Nokia Silicon Valley Messaging Protection Received: from pcp000693pcs.wireless.meeting.ietf.org (135.222.64.193, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdZMnjzx; Sun, 18 Mar 2001 15:18:38 PST Message-Id: <4.3.2.7.2.20010318150835.0260e710@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 18 Mar 2001 15:14:29 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: Updated IPng Agenda for Minneapolis IETF In-Reply-To: <4.3.2.7.2.20010316165151.02655570@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 I would like to request that all speakers send me a copy of your slides. If you can do it prior to your presentation it would be very helpful. 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 Sun Mar 18 18:53:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2J2rtIm015509 for ; Sun, 18 Mar 2001 18:53:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2J2rsYP015508 for ipng-dist; Sun, 18 Mar 2001 18:53: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2J2rgIm015501 for ; Sun, 18 Mar 2001 18:53:43 -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 SAA12311 for ; Sun, 18 Mar 2001 18:53:42 -0800 (PST) Received: from hygro.adsl.duke.edu (pcp000811pcs.wireless.meeting.ietf.org [135.222.65.55]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04389 for ; Sun, 18 Mar 2001 18:53:41 -0800 (PST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f2J2s8C14928 for ; Sun, 18 Mar 2001 21:54:08 -0500 Message-Id: <200103190254.f2J2s8C14928@hygro.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: status of IPng addressing documents Date: Sun, 18 Mar 2001 21:54:08 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This note is to summarize some recent discussions concerning a number of IPv6 documents and bring the WG up-to-date on a suggested plan of action. First, the IESG is currently discussing whether to advance draft-ietf-ipngwg-addr-arch-v3-04.txt (the original ID submitted to the IESG) to draft standard. IESG discussions have resulted in requests for two changes to the document: a) Section 2.5.6 "Aggregatable Global Unicast Addresses" contains text and a diagram excerpted from a separate document, RFC 2374. That text is deemed inappropriate in a Draft Standard document because: - the described fields and their widths are not a fundamental part of the IPv6 architecture. Implementations do not (and should not) need to know the format of any of the fields, their widths, etc. - Putting them in the document can lead people to believe they are fundamental part of the architecture - The topic of RFC 2374 deals with that portion of address space that is managed by the RIRs, rather than the IETF (more on this below). IESG request: rework the discussion in Section 2.5.6 to make the reference to RFC 2374 an example, to make it clear that the address allocations and formats in RFC 2374 are not a part of the IPv6 architecture (i.e., have no implications for implementations). b) The document makes reference to the format prefix (FP). There have been concerns raised that implementations may take the FP into consideration and treat addresses differently depending on their FP (i.e., FP 1 is assigned, while others are unassigned). But for future flexibility, it is important that all implementations process global unicast addresses consistently and predictably, regardless of what the FP is. IESG request: strengthen/clarify wording in the document to make it clear that all unassigned FPs are to be treated as global unicast addresses. These requests are editorial in nature and are not expected to affect the document in a way that impacts implementations. Once these changes are made, the document is expected to be approved as a Draft Standard. Note that version -05 appeared recently; it addresses most of the issues raised. A -06 version, under preparation, is expected to resolve the remaining issues. While discussing the addressing architecture document, the IESG also discussed RFC 2374. The WG originally asked that this document also be advanced to Draft Standard a couple of years ago, but the IESG pushed back wanting to see more experience. While the IPng WG has not formally asked the IESG to advance this document at this time, there is an assumption that such a request might come once the addressing architecture document had been successfully advanced. Hence, the preliminary discussion on RFC 2374. The IESG has in previous discussion not had consensus on advancing RFC RFC 2374 ("An IPv6 Aggregatable Global Unicast Address Format"). Over time the specific issues have evolved, as the community has gained more experience from IPv6 testbeds, the RIRs have begun handing out addresses, etc. Some of the current issues that have been raised include: - there is a lack of clear consensus in the community regarding the exact size of the various fields (TLA vs. NLA, etc.), how permanent the boundaries will be over time, etc. Boundaries that seem appropriate today, may be different in ten or twenty years. As an example, while the limitation of 8192 TLAs is viewed as a laudable goal, it is also not viewed as a hard architectural limit that can/will never change. If the boundaries are subject to change in the future, that argues against the document being advanced on the Standards Track to Draft status. - there is concern that it does not reflect the current practice of what the addressing registries (RIRs) are doing or will be doing over the next few years (again an argument against advancement to Draft Standard). For example, sub-TLAs are not defined in RFC 2374. - on matters of address allocations and assignments, the RIRs (and not the IETF) have responsibility for managing and assigning unicast address space to ISPs and end sites. Note that on issues of address boundaries, the further one moves from the right to the left within an address, the greater the role of the RIRs, and lesser the impact on the overall IPv6 architecture. For example, the IPv6 architecture clearly defines the /64 boundary. But the /48 boundary is less clearly required by the architecture, though there are many technical reasons for having it. While the IETF can (and should) provide technical input to the RIRs on how to manage the IPv6 address space, it is the RIRs that ultimately adopt and execute allocation policies. Consequently, the topic of RFC 2374 (specifically, the assignment and usage of the "routing part" of IPv6 addresses) is not really an appropriate Standards Track activity of the IETF. A more appropriate role for the IETF would be to provide input/advice to the registries, that focuses on technical aspects, especially those related to the overall IPv6 architecture. This could be done through an informational RFC, or possibly through some other means. - Because the RIRs are are the ones that carry out any recommendations the IETF might make, they need to be in agreement with those policies and incorporate them into their own formal policies. This argues for engaging the RIRs on the topic of address assignments and encouraging them to develop such policies in a cooperative manner with appropriate input from the IETF. Summary: the IESG is unlikely to advance RFC 2374 on the standards track in its current form, and recommends that the RIRs be approached for their views on this topic and on what recommendations they have for how best to cooperate on reaching a common goal -- that of assigning addresses in a way that encourages deployment and supports the IPv6 vision and architecture. Should the RIRs be willing to formally take up this topic, it is expected (and imperative!) that the IETF provide technical input. Note that moving the policy component to the RIRs is not expected to result in any change in current assignments and operations in the short term, but one can expect assignment policy to evolve over time. Any such changes would be the subject of extensive review by the IETF and RIR communities. The exact details of how to do this need to be worked out through discussions between the IETF and RIRs. A third document, draft-iesg-ipv6-addressing-recommendations-00.txt recently appeared. This document is a revised version of a statement issued by the IESG/IAB in September, 2000. The focus of the document is to provide a strong case that that the default IPv6 address allocation to end sites should be a /48. The reason for publishing the document is to refine and clarify the statement and eventually publish it as an informational RFC (i.e., for the historical record). The purpose of this statement is to provide input to the RIRs, as they formulate their IPv6 address assignment policies. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 08:10:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGAEIm016485 for ; Mon, 19 Mar 2001 08:10:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JGAE9U016484 for ipng-dist; Mon, 19 Mar 2001 08:10:14 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGA2Im016477 for ; Mon, 19 Mar 2001 08:10:02 -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 IAA27133 for ; Mon, 19 Mar 2001 08:10:01 -0800 (PST) Received: from starfruit.itojun.org (pcp000911pcs.wireless.meeting.ietf.org [135.222.65.155]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25333 for ; Mon, 19 Mar 2001 09:09:58 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 3B33C7E73; Tue, 20 Mar 2001 01:09:36 +0900 (JST) To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: comment to draft-draves-ipngwg-router-selection-00.txt From: Jun-ichiro itojun Hagino Date: Tue, 20 Mar 2001 01:09:36 +0900 Message-Id: <20010319160936.3B33C7E73@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RA preference is very useful in the following very simple situations. your slide did not cover this, i believe this scenario is the most popular case. itojun a host is on a non-leaf network. - if we throw RA from router A only, we will lose connectivity to "leaf" if router A goes down. - if we throw RA from both router A and B, we have lots of icmp6 redirect if router B is picked as the default outgoing router for host C. so what you will want to do is: - set RA preference as router A > router B, advert from both. upstream | router A | ==+===============+== | | router B host C | leaf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 13:37:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JLbpIm017473 for ; Mon, 19 Mar 2001 13:37:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JLbo1N017472 for ipng-dist; Mon, 19 Mar 2001 13:37: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JLbYIm017465 for ; Mon, 19 Mar 2001 13:37:35 -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 NAA00750 for ; Mon, 19 Mar 2001 13:37:33 -0800 (PST) Received: from eos-f.sr.unh.edu (eos.sr.unh.edu [132.177.246.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05077 for ; Mon, 19 Mar 2001 14:37:30 -0700 (MST) Received: from billsvaio (intrepid-ppp.sr.unh.edu [132.177.240.195]) by eos-f.sr.unh.edu (SGI-8.9.3/8.9.3) with ESMTP id QAA67746 for ; Mon, 19 Mar 2001 16:37:22 -0500 (EST) Message-Id: <4.2.0.58.20010319161308.00a3c528@bluemoon.sr.unh.edu> X-Sender: whl@bluemoon.sr.unh.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 19 Mar 2001 16:34:00 -0500 To: ipng@sunroof.eng.sun.com From: William Lenharth Subject: UNH IPv6 Testing at Connectathon2001 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is transmitted to the IPng list at the request of the Area Director for IPv6 Working group. *********************************************************************** A report on the IPv6 Testing at Connectaton2001 *********************************************************************** Three full days of testing in the areas, General Spec. testing , RIPng, and Mobility for IPv6. Companies that participated: SUN Microsystems, HP, SGI, Matsushita, Ericsson, Nokia, Microsoft, Ericsson-Telebit, Helsinki University of Technology, Compaq, and Tahi / Kame. Most base spec. testing was executed without a serious problem being noted. The RIPng testing was also executed without serious problem. The mobility testing consisted of conformance testing against the IETF specification. All vendors had some minor issues, the following issue / problems were also noted. It was unclear in some cases that an ICMP message should be sent when a bad packet was encountered. Also, if you try to remove a binding update that was previously removed in some cases implementations would acknowledge it with a reject status. It was felt that it should be accepted so that the status was clear. For more info contact: jfl@iol.unh.edu, schultz@iol.unh.edu *********************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 07:53:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KFr8Im019487 for ; Tue, 20 Mar 2001 07:53:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KFr7lg019486 for ipng-dist; Tue, 20 Mar 2001 07:53: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KFqwIm019479 for ; Tue, 20 Mar 2001 07:52:58 -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 HAA23447; Tue, 20 Mar 2001 07:52:57 -0800 (PST) Received: from anago.fumi.net (pcp001274pcs.wireless.meeting.ietf.org [135.222.67.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04113; Tue, 20 Mar 2001 08:52:49 -0700 (MST) Received: (from masa@localhost) by anago.fumi.net (8.11.1/8.10.2) id f2KFqRF00374; Tue, 20 Mar 2001 15:52:27 GMT Date: Wed, 21 Mar 2001 00:52:26 +0900 From: Masafumi OE To: "Steven M. Bellovin" Cc: Erik Nordmark , Masafumi OE , Jim.Bound@nokia.com, deering@cisco.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Subject: Re: Flow Label discussion Message-ID: <20010321005226.E244%masa@fumi.org> References: <20010316164438.1F5C835C44@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i-ja0 In-Reply-To: <20010316164438.1F5C835C44@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I talked about this topic under the ITRACE WG session. Thank you for all. -- Masafumi OE, http://iplab.aist-nara.ac.jp/research/itrace/ On Fri, Mar 16, 2001 at 11:44:36AM -0500, Steven M. Bellovin wrote: > In message , Erik Nordma > rk writes: > > > >This would seem to fall under the ITRACE WG as far as I can tell. > > Although the topic fits, it's out of charter for ITRACE -- we're > working on an ICMP message for traceback. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 09:55:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHtsIm019770 for ; Tue, 20 Mar 2001 09:55:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KHtr0a019769 for ipng-dist; Tue, 20 Mar 2001 09:55:53 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHtnIm019762 for ; Tue, 20 Mar 2001 09:55:49 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2KHr0C22410 for ipng@sunroof.eng.sun.com; Tue, 20 Mar 2001 09:53:00 -0800 (PST) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2IDbNIm014228 for ; Sun, 18 Mar 2001 05:37:23 -0800 (PST) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id GAA18624; Sun, 18 Mar 2001 06:37:23 -0700 (MST) Received: from sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id GAA09370; Sun, 18 Mar 2001 06:39:33 -0700 Message-ID: <3AB4B8EC.8791167A@sun.com> Date: Sun, 18 Mar 2001 14:32:28 +0100 From: gabriel montenegro X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: IPSEC Mailing List , IPNG Mailing List Subject: Re: A method to prevent DoS in IPv6 DAD and Mobile IPv6 References: <3AB47F98.A5CFEC6C@nomadiclab.com> Content-Type: multipart/mixed; boundary="------------6671185CAB32645A5EC3C3B5" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------6671185CAB32645A5EC3C3B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Wow! I came up with the same scheme, although as part of a slightly more general mechanism. I've only been discussing with a couple of folks including Claude Castellucia and Erik Nordmark. But your message prompts me to send my stuff in as well. We should talk in Minneapolis. I had to name these things something, and based on the fact that what's important about them is the fact that they are: statistically unique and cryptographically verifiable, I just called them SUCV's. So we have SUCV identifiers and SUCV addresses. The latter are the ones you mentioned in your previous note. I attach my notes, although they are not yet complete nor in internet draft format. The attachments are: 1. my notes on pekka's address ownership, PBK and claude's privacy extension drafts 2. proposal and thoughts on SUCV's -gabriel -- Gabriel Montenegro (Sun Microsystems Laboratories, Europe) 29, chemin du Vieux Chene Email: gab@sun.com 38240 Meylan, FRANCE Mobile: +33 673 99 56 62 Office: +33 476 18 80 45 (sun internal: x38045) Fax: +33 476 18 88 88 --------------6671185CAB32645A5EC3C3B5 Content-Type: text/html; charset=us-ascii; name="AddressOwnershipAndPrivacyForMipV6.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="AddressOwnershipAndPrivacyForMipV6.htm" TWiki . Main . AddressOwnershipAndPrivacyForMipV6

Notes on V6 address ownership problems

http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt
  • protection against hijacking of valid addresses requires cryptographic authorization for operations that modify routing (BU's, source routing, etc)
  • quoting from above draft: "Currently there exists no specified mechanism for proving address ownership in Internet-wide scale."
Mini Proposal:
  • remaining use of redirect operations: they are only allowed with non-global addresses which are bound (via a cryptographically sound binding) to anonymous or pseudonymous addresses
  • the above constitues perhaps the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms

Notes on PBK

http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt
  • temporary public/private pair
  • EID = hash(publicComponent)
    1. Initiator sends EID to Responder
    2. Initiator sends publicComponent to Responder
Note
 This exchange must be secure, but it is an improvement over cookies.
  • Initiator sends (BU, EID)Priv to Responder
Problems:
  • does NOT really address the address ownership problem of any publicly routable addresses
  • it is not specified how the EID and public component of the PK are sent by the initiator to the responder
  • preventing hijacking and MIM attacks depend on this sequence if not clearly specified
  • might as well make it secure: use HIP and its sequence

Notes on simple privacy extension for Mobile IP v6

http://search.ietf.org/internet-drafts/draft-castelluccia-mobileip-privacy-00.txt What it hides: home address in the following two situations:
  1. MN initiated traffic: hides home address from CN (a server?) and eavesdroppers
  2. CN initiated traffic: hides home addr from eavesdropper (not from CN) What it does not hide: home address from initiating CN's when the MN is a server/responder
Basics:
  • MN's instead of their home address use a 128 bit identifier called TMI
    • digest for TMI' = MD5 ( Home address | digest of TMI )
    • define a new TLA (16 bits) for TMI address space
    • [why not SHA-1 (also required by IPSEC) given the collision resistance issues with MD5?]
Works as follows:
  1. mobile initiator
    • uses TMI as home address.
    • CN sends to TMI@COA (where the addr before the @ is carried within the home address option
  2. mobile responder
    • "CN knows the MN's identity by definition" (?)
    • [Maybe not, if the CN can initiate to a HIP (or TMI) entity and resolve the COA by some other means.]
    • In this case, the MN can still hide its location (COA) by using a bi-directional tunnel with its HA and not sending any BU's to the CN.
    • traffic MN to CN would be of the form: homeAddr@TMI@COA
    • requires a new destination option to carry the real homeAddr
    • subsequent packets have just the TMI (essentially an SA), [so why not just use IPSEC]?
Still has problems
  • TMI does not prevent hijacking as explained in the nikander draft on addr ownership
  • this is the problem our new default trust rule addresses (in conjunction with HIP)
  • There may be issues with its use of MD5: WeaknessInMd5

Proposal

Given that:
  • The addr ownership problem is real. BU's and other exchanges which alter routing or tunneling open up DOS attacks. PBK attempts to solve these, but does not succeed for globally routable addresses.
  • Privacy concerns are also real, and the privacy extensions aim to solve this.
  • Neither of the above solves both at the same time, yet independently, both require non-trivial changes to BU's and other formats, as well as to the handling of SA's and IPSEC.
The obvious solution is to address both:
  • Privacy
  • Address ownership
In one common mechanism.

I suggest it be based on HIP:

  • For all the cases at hand (v6 based) the HIP handshake provides for a very good and DOS-resistant sequence.
  • For new application layer cases (hinted at by PBK, and applicable to P2P, for example), the sequence must not be left up to the application. This may be easier to do with TCP in which existing frameworks could be extended (BEEP, TLS), but not immediately obvious how to accomplish it for UDP traffic. SCTP is another matter.
-- GabrielMontenegro - 18 Mar, 2001 - 12:40:30
  --------------6671185CAB32645A5EC3C3B5 Content-Type: text/html; charset=us-ascii; name="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html" TWiki . Main . ProposalToSolveAddressOwnershipAndPrivacyForMipV6

Statistical Uniqueness and Cryptographic Verifiability

The Need for a Common Solution

The idea is to propose one common mechanism that can solve two problems dealt with in AddressOwnershipAndPrivacyForMipV6:
  • address ownership: Given the different ways of altering routing information, and in particular, binding updates received at a correspondent node, how does this CN decide if it should heed it?
  • privacy for MIPv6: Mobile IP allows a node to keep the same home address as it changes its point of attachment to the network (care-of address or COA).
There are proposals to solve each of the above. However, these proposals require modifying Mobile IP v6 and/or IPSEC separately. Instead, this is an attempt at using a common mechanism to achieve both of those goals.

This note does not look at the problem from the point of view of practical Mobile IPv6 deployment, as it could be applied to, say, 3G or 4G wireless networks.

Here, the assumption is that we have a network in which the nodes inherently distrust each other, and in which a global or centralized PKI or KDC will never be available. This is more akin to Peer-to-peer and to opportunistic networking.

The goal is to arrive at some fundamental assumptions about trust on top of which one can build some useful communication.

Statistically Unique Cryptographically Verifiable ID's (SUCV ID's)

How does a node preclude other parties (eavesdroppers, correspondent nodes, etc) from gleaning too much information about its identity, or its home address or its whereabouts?

The latter concern leads to ephemeral forms of addresses which typical proposals base on cryptographic hashes. These identifiers (or EID's or TMI's or HIT's) can have several interesting characteristics:

  • they are distinguishable from globally routable addresses
    • they are doled out from a separate TLA (TMI's)
    • they have a special form which may include an administrative prefix (HIT's)
  • because they are based on cryptographic hashes, they are statistically unique
  • they are the hashes of a public component of a self-generated Public Key (perhaps unsigned Diffie-Hellman)
So these identifiers have a strong cryptographic binding with their public components (of their private-public keys). This is exactly the purpose that certificates have. There is a catch, as always. The name or identity must be communicated securely, otherwise there is a possibility of man-in-the-middle attack (which is reduced if the initiator also signs the source address, and if there is ingress filtering, etc).

Whereas in other applications of self-signed certificates it is possible to secure this step, in the situation at hand (opportunistic security) there is no practical way to do this. Instead, the initiator must communicate its identity/name to the responder using in-band mechanisms. Barring this detail, the initiator proves he owns this self-signed certificate by signing stuff with his private key, and given the algorithmic characteristics of the hash used, he further shows that his identity is statistically unique (within bounds set approximately by the birthday paradox).

Let's call them Statistically Unique Cryptographically Verifiable ID's, or SUCV ID's.

Because of this, once a CN obtains information about one of these identifiers, it has a strong cryptographic assurance about which entity created it. Not only that, it knows that this identifier is owned and used exclusively by only one node in the universe: its peer in the current exchange. Thus, it is safe to allow that peer to effect changes (via BU's, for example) on how this address or identifier is routed to. Notice that with publically routable addresses, this assurance is much harder to arrive at, given that the address may be 'loaned' to (not owned by) the peer in question, perhaps thanks to the good service of a friendly DHCP server, for example.

Despite the fact that currently there is no way to prove address ownership in the Internet, these considerations lead to the following fundamental assumption:

  • redirect operations are only allowed with SUCV ID's
The above constitutes perhaps the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms

SUCV ID's versus SUCV Addresses

What should one use: pure identifiers with no routing significance or addresses?

For example, in the Mobile IPv6 case, a node could just start using its current care-of address (CoA?) as if it were its home address, and issue binding updates accordingly when it moved in the future.

Of course, regular CoA?'s will not qualify under the rule above, so it would mean it might be very difficult (impossible?) for whoever sends this BU to prove that it 'owns' that CoA? address and can rightfully send redirects for it.

The most the node can do is to establish some cryptographic evidence that it is sitting on that CoA? address. And it is sitting on as opposed to owning , because the former more accurately describes what is going on (from the CN's point of view at least, and maybe also in reality).

With a CoA? that is not an SUCV ID it is never evident to the CN that whoever was sitting on that address actually owns it. At the very most, the CN's peer can prove that at some point it was sitting on CoA?, and later it can prove it is still the same node, but now sitting on another CoA?.

But it cannot prove ownership. It may have obtained the CoA? from a DHCP server, for example. Ignoring this subtle distinction leads to DOS and hijacking attacks.

Problems may also arise because of honest mistakes in configuration. For example, say node A was originally sitting on CoA?, and then moved on to CoA?'. Suppose it then asks its CN's to redirect traffic to CoA?'. In the meanwhile, the original CoA? may have been assigned to another node B, perhaps by the DHCP server that rightfully 'owns' that address. The result is that now traffic meant for B has been redirected to A at its new location.

Relying on ingress filtering may limit the risk, but essentially, the only way for a node to prove ownership of an identifier (in the absence of any other centralized or global mechanism), is for it to prove that it created this statistically unique series of bits.

Once you bite into using a 'home address' that is not really your home address, then what you're really trying to do is to use some identity instead of an address. And if you use identities that satisfy the conditions outlined above, then you suddenly gain the tremendous advantage that anybody can safely believe you when you claim you own that identity. Hence they can safely heed your redirects when you say that your identity is now available at some different CoA? (and later at another). Furthermore, you do not rely on ingress filtering to limit exposure.

The only advantage to using an address is that the data traffic need not carry extra information in the packet to guarantee proper delivery by routing. One could, perhaps try to achieve both purposes by creating CoA?'s that can serve as both an address and as an SUCV ID.

This could be accomplished by:

  • using the top 64 bits from your routing prefix (as in rfc3041)
  • defining the bottom 64 bits as an SUCV ID
Using the resultant 128 bit field gives you an identifier that is routable, avoiding the need for taking extra space in the packet by sending routing options UNTIL you move and send a BU indicating this identifier is now available at another CoA?. This would leak information as to your whereabouts (or at least where you were at some point) to eavesdroppers. The top 64 bits also tells them where that identity began to be used, which could be very important information.

On the other hand, if you use a 'pure' SUCV ID (without any routing significance), then your packets will always need extra information somewhere to assure they are routed properly. Eavesdroppers may still know where that identity is at any particular point in time. This is unavoidable. But at least they will not know where (under what prefix) that identity began to be used.

When to use SUCV ID's versus SUCV addresses

All in all, if one is more concerned about privacy then using an SUCV ID with no routing significance seems preferable.

As often (perhaps even more), nodes are not particularly interested in privacy. But they (rather their users) are definitely interested in using Mobile IP v6 such that their BU's are heeded. Since this implies proving address ownership, these nodes would want to use SUCV home addresses . If they do so, CN's can safely heed BU's for these addresses, because they have reasonable confidence that in doing so they are not unwittingly participating in some DOS or hijacking attack. This follows because of the SUCV property of the lower 64 bits within the address.

This SUCV-ness, by solving the address ownership problem, helps in both cases:

  1. applications in which routing redirects need to be heeded (of which MIPv6 BU's are but one example), and
  2. applications in which privacy is the main concern
Only that in the former(no privacy, regular use) you want a routable address for optimization as in an SUCV home address, and in the latter you want an SUCV ID.

With CoA?'s it is perhaps a little different in the sense that you nodes no not have to prove ownership, so SUCV may not be as necessary. However, if privacy is a concern then randomized CoA?'s (SU CoA?, without the CV part) are quite useful (as has been pointed out elsewhere).

Proposal for a Solution

Using these ID's or addresses depends on also communicating safely the SUCV portion, and this, in turn is dependent on the packet sequencing, etc. These concerns are not addresses at all in the PBK draft. On the other hand, HIP includes mechanisms and detailed considerations in this regard (protection against replay, DOS and MITM attacks). This is why this note proposes that a solution be drafted based heavily on HIP: We assume MIPv6
  • Use HIP identities, in particular, anonymous HI's
  • since we assume v6 here, use HIT the 128 bit long operational representation of HI's
  • HIT takes the place of EID's in PBK or of TMI's in the privacy for mip6 draft
TODO: continue this entire section!

-- GabrielMontenegro - 18 Mar, 2001 - 13:22:02
  --------------6671185CAB32645A5EC3C3B5-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 09:56:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHumIm019780 for ; Tue, 20 Mar 2001 09:56:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KHum5i019779 for ipng-dist; Tue, 20 Mar 2001 09:56: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHugIm019772 for ; Tue, 20 Mar 2001 09:56:42 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2KHrrZ22440 for ipng@sunroof.eng.sun.com; Tue, 20 Mar 2001 09:53:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JCRxIm016171 for ; Mon, 19 Mar 2001 04:27:59 -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 EAA14869 for ; Mon, 19 Mar 2001 04:27:58 -0800 (PST) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA03296 for ; Mon, 19 Mar 2001 04:27:54 -0800 (PST) Received: (qmail 10162 invoked from network); 19 Mar 2001 12:27:51 -0000 Received: from meowmix.chek.com (208.197.227.10) by mailrelay1.chek.com with SMTP; 19 Mar 2001 12:27:51 -0000 Received: (qmail 22275 invoked by uid 99); 19 Mar 2001 12:27:18 -0000 Date: 19 Mar 2001 12:27:18 -0000 Message-ID: <20010319122718.22274.qmail@meowmix.chek.com> From: "Emanuel Moreira" To: bzill@microsoft.com, ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've checked and we are using MSRIPv6 1.4 stack on a Windows 2000. The translator creates the new pseudo interface but it dosen't creates the route "::ffff:0:0/96 -> IfIndex/fe80::1". In the registry I have: 192.168.0.0 192.168.0.10 How can I check if it is evrything alright with it? The result of commands is: c:\users\ipv6>ipv6 if Interface 10 (site 1): does not use Neighbor Discovery forwards packets link-level address: preferred address fe80::2, infinite/infinite link MTU 65535 (true link MTU 65535) current hop limit 255 reachable time 0ms (base 0ms) retransmission interval 0ms DAD transmits 0 Interface 4 (site 1): Local Area Connection uses Neighbor Discovery sends Router Advertisements forwards packets link-level address: 00-00-1c-00-07-71 preferred address fe80::200:1cff:fe00:771, infinite/infinite multicast address ff02::1, 1 refs, not reportable multicast address ff02::1:ff00:771, 1 refs, last reporter multicast address ff02::2, 1 refs, last reporter multicast address ff05::2, 1 refs, last reporter link MTU 1500 (true link MTU 1500) current hop limit 128 reachable time 27500ms (base 30000ms) retransmission interval 1000ms DAD transmits 1 Interface 3 (site 1): 6-over-4 Virtual Interface uses Neighbor Discovery forwards packets link-level address: 193.136.92.217 preferred address fe80::c188:5cd9, infinite/infinite multicast address ff02::1, 1 refs, not reportable multicast address ff02::1:ff88:5cd9, 1 refs, last reporter link MTU 1280 (true link MTU 65515) current hop limit 128 reachable time 15500ms (base 30000ms) retransmission interval 1000ms DAD transmits 1 Interface 2 (site 0): Tunnel Pseudo-Interface does not use Neighbor Discovery forwards packets link-level address: 0.0.0.0 preferred address ::193.136.92.217, infinite/infinite link MTU 1280 (true link MTU 65515) current hop limit 128 reachable time 0ms (base 0ms) retransmission interval 0ms DAD transmits 0 Interface 1 (site 0): Loopback Pseudo-Interface does not use Neighbor Discovery link-level address: preferred address ::1, infinite/infinite link MTU 1500 (true link MTU 1500) current hop limit 1 reachable time 0ms (base 0ms) retransmission interval 0ms DAD transmits 0 c:\users\ipv6>ipv6 rt ::ffff:0:0:0/96 -> 4 pref 0 (lifetime infinite) ::/96 -> 2 pref 0 (lifetime infinite) Thanks Emanuel _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 09:57:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHvfIm019790 for ; Tue, 20 Mar 2001 09:57:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KHvfm3019789 for ipng-dist; Tue, 20 Mar 2001 09:57:41 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHvXIm019782 for ; Tue, 20 Mar 2001 09:57:34 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2KHsiH22470 for ipng@sunroof.eng.sun.com; Tue, 20 Mar 2001 09:54:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHZvIm019704 for ; Tue, 20 Mar 2001 09:35: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 JAA25570 for ; Tue, 20 Mar 2001 09:35:57 -0800 (PST) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA15006 for ; Tue, 20 Mar 2001 10:35:55 -0700 (MST) Received: (qmail 20837 invoked from network); 20 Mar 2001 17:35:53 -0000 Received: from ninelives.chek.com (208.197.227.14) by mailrelay1.chek.com with SMTP; 20 Mar 2001 17:35:53 -0000 Received: (qmail 21778 invoked by uid 99); 20 Mar 2001 17:31:18 -0000 Date: 20 Mar 2001 17:31:18 -0000 Message-ID: <20010320173118.21777.qmail@ninelives.chek.com> From: "Emanuel Moreira" To: bzill@microsoft.com, ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: NAPT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've installed the NAPT in Microsoft Release 1.4 and it dosen't work properly. The routes have been created but when I'm doing ping from IPv4 world to Ipv6 the Echo Reply (packet from IPv6 world to IPv4 world)is constructed by the NAPT machine like having "Proto=IPv6". The IPv4 machine who made the "ping" does not understand the meaning off "Proto=IPV6" and so it says time out. Why does this happen? Is this alright, and so I'm doing something else wrong? Thanks Emanuel "IP: ID = 0x8C37; Proto = IPv6; Len: 80" _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 15:18:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KNIwIm020568 for ; Tue, 20 Mar 2001 15:18:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KNIvD0020567 for ipng-dist; Tue, 20 Mar 2001 15: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KNImIm020560 for ; Tue, 20 Mar 2001 15:18:48 -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 PAA12682 for ; Tue, 20 Mar 2001 15:18:48 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28489 for ; Tue, 20 Mar 2001 16:18:44 -0700 (MST) Received: from localhost ([3ffe:507:1ff:2:ecbd:ffaf:bf6f:ff7b]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id IAA10266; Wed, 21 Mar 2001 08:19:22 +0900 (JST) Date: Wed, 21 Mar 2001 08:17:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: comment to draft-draves-ipngwg-router-selection-00.txt In-Reply-To: <20010319160936.3B33C7E73@starfruit.itojun.org> References: <20010319160936.3B33C7E73@starfruit.itojun.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 20 Mar 2001 01:09:36 +0900, >>>>> Jun-ichiro itojun Hagino said: > RA preference is very useful in the following very simple situations. > your slide did not cover this, i believe this scenario is the most > popular case. It could also be used for a protection against misconfigured RAs. For example, even if a user mistakenly sends unauthorized RAs (and administrators cannot easily detect where the source of the RAs is located), the RAs could be overriden by authorized RAs with a higher preference. Note that I don't argue this story can be applied for DoS attacks, where the attacker would set the preference field to the highest value. However, if the unauthorized RAs are just a result of misconfiguration, we can expect that the preference value is the default value, which can be overriden by a higher value (according to the draft). 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 Mar 20 22:01:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2L61uIm020998 for ; Tue, 20 Mar 2001 22:01:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2L61trY020997 for ipng-dist; Tue, 20 Mar 2001 22:01: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2L61kIm020990 for ; Tue, 20 Mar 2001 22:01:46 -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 WAA10406 for ; Tue, 20 Mar 2001 22:01:45 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28315 for ; Tue, 20 Mar 2001 22:01:44 -0800 (PST) Received: from localhost ([3ffe:507:1ff:2:aca5:3cd0:71f3:20bc]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id PAA12421; Wed, 21 Mar 2001 15:02:27 +0900 (JST) Date: Wed, 21 Mar 2001 15:00:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: more comments (questions) about draft-draves-ipngwg-router-selection-01.txt User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a couple of questions on the draft: 1. what should a host do when it receives an RA with the preference field being set to 10 (i.e. reserved)? - ignore the entire RA. - accept the RA, but consider the preference value as another value? if so, high/medium/low? - other option? 2. if the preference value for a router changes, does/should it affect existing destination cache entries? For example, consider the following scenario: - a host H receives an RA from a router R1 with the medium preference. - H sends a packet to an off-link destination D. H uses R as the next hop, and records H in the destination cache. - a host A then receives an RA from another router R2 with the high preference. now, what should happen on the destination cache for D in H? Should it be removed once, prompting H to do next hop determination again (and to choose the more preferred router R2). Or, should H just keep the old cache and its next hop until it becomes unreachable? 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 Mar 21 08:59:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LGxkIm021569 for ; Wed, 21 Mar 2001 08:59:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LGxjHk021568 for ipng-dist; Wed, 21 Mar 2001 08:59:45 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LGxYIm021561 for ; Wed, 21 Mar 2001 08:59:34 -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 IAA03502 for ; Wed, 21 Mar 2001 08:59:29 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26262 for ; Wed, 21 Mar 2001 09:59:26 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA08444 for ; Thu, 22 Mar 2001 01:59:24 +0900 (JST) to: ipng@sunroof.eng.sun.com In-reply-to: nisse's message of 16 Mar 2001 14:23:25 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: The case against A6 and DNAME From: itojun@iijlab.net Date: Thu, 22 Mar 2001 01:59:24 +0900 Message-ID: <8442.985193964@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i guess i prefer AAAA much more than A6, because of the following logic. could someone shed some light on the following items? i don't think i'm convinced yet. i agree that we need to test A6 in the real world situation. however, for a guy who is using IPv6 in a daily basis, i cannot wait till the test gets done... so i prefer AAAA gets deployed and kept. (note: the following is separate from topics raised by DJB) itojun real dns cloud: - if we end up using "A6 0 <128bit>" everywhere, there's no benefit against AAAA. - if we are to use fragmented A6s (128bit splitted into multiple A6s), i got couple of issues/worries. (1) query delays bothers me and we don't know how the additional delays interact with various timeout parameters. also, are we sure that we have no problem with additional query/reply traffic imposed by fragmented A6? (2) some says that caches will avoid querying fragmented A6s again and again. however, most of the libc resolver implementations do not cache anything. (3) if some of the fragments are DNSSEC-signed and some are not, how should we treat that address? RFC2874 section 6 briefly talks about it, not sure if complete answer is given. (4) it is much harder to code A6 fragment reassemble code, i expect to see a lot of security-issue bugs in the future (from our experiences). (5) i don't think there's too big benefits from renumbering. query-replace over AAAA zone file is easy enough. you may need to sign zones on renumber, but given that the frequency of renumber is fairly low it shouldn't be an issue. to those who says that we can renumber frequently: from rrenum discussion it is clear that we cannot renumber more frequently than DNS TTL (or TTL*2). (6) there were some mentions about limiting # of fragments, but there's no such guarantee. resolver issues: suppose that we synthesize AAAA, or A6 0 <128bit>, at the DNS server contacted by libc resolver, to avoid some of the complexities given above (see BIND 9.2.0 snap behavior). the approach has the following drawbacks: - DNSSEC signs will get removed, making it impossible for libc resolvers - when do we decide to synthesize A6 0 <128bit>? client may be asking for raw A6 record (can be fragmented), client may be asking for synthesized A6 0 <128bit> record. - synthesized records have TTL=0. is it really okay? (most of libc resolvers do not cache, so it should not be too bad) we at least need a flag to determine when to synthesize, and when we do not. (note that if we simply use AAAA in all places, we have no such problem at all) deplyment issue: we can't wait till BIND9 gets deployed everywhere. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 21:15:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2M5FvIm022600 for ; Wed, 21 Mar 2001 21:15:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2M5FuAg022599 for ipng-dist; Wed, 21 Mar 2001 21:15:56 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2M5FfIm022592 for ; Wed, 21 Mar 2001 21:15:48 -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 VAA22445 for ; Wed, 21 Mar 2001 21:15:39 -0800 (PST) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA14955 for ; Wed, 21 Mar 2001 21:15:35 -0800 (PST) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 8B5BC196943; Thu, 22 Mar 2001 02:15:32 -0300 (ART) Date: Thu, 22 Mar 2001 02:15:32 -0300 To: ipng@sunroof.eng.sun.com Subject: code for IPv6 or for AF independence Message-ID: <20010322021532.A16607@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.15i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2M5FmIm022593 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! After some discussions in the Debian IPv6 project I'm coming here to hear this wg's opinion about what should "normal application" programmers do? By "normal application" I mean those that don't need to know what network protocol is being used in the communication (telnet, smtp, pop, etc, could run over tcp/ipv4, tcp/ipv6, tcp/ipx or any other stream protocol with no changes) Should we program for AF independence (using getaddrinfo/getnameinfo) or for IPv6 (and relying in IPv4 mapped addresses for compatibility) I don't believe IPv6 is a cure-all protocol. Porting one "normal application" between PFs is not a hard work, but porting the thousands apps we have is. We're commited to do all that work, but when the next protocol comes we won't like to do it again. That's why I'd think programming for AF independence should be preferred and programming for IPv6 be restricted to IPv6 specific apps that couldn't be written AF independent, and discouraged for "normal applications" That's my humble opinion, but before trying to convince all the other Debian IPv6 people, I'm asking for the opinion of this wg on this matters. Are my reasoning and conclusion corrects? Thanks, HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 07:14:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MFE5Im023272 for ; Thu, 22 Mar 2001 07:14:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MFE5dJ023271 for ipng-dist; Thu, 22 Mar 2001 07:14: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MFDqIm023264 for ; Thu, 22 Mar 2001 07:13: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 HAA21211 for ; Thu, 22 Mar 2001 07:13:42 -0800 (PST) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01457 for ; Thu, 22 Mar 2001 07:13:40 -0800 (PST) Received: by alfa.itea.ntnu.no id QAA0000022636; Thu, 22 Mar 2001 16:13:19 +0100 (MET) From: Stig Venås Date: Thu, 22 Mar 2001 16:13:19 +0100 To: horape@tinuviel.compendium.net.ar Cc: ipng@sunroof.eng.sun.com Subject: Re: code for IPv6 or for AF independence Message-ID: <20010322161319.A24618@itea.ntnu.no> References: <20010322021532.A16607@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010322021532.A16607@tinuviel.compendium.net.ar>; from horape@tinuviel.compendium.net.ar on Thu, Mar 22, 2001 at 02:15:32AM -0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Mar 22, 2001 at 02:15:32AM -0300, horape@tinuviel.compendium.net.ar wrote: > Should we program for AF independence (using getaddrinfo/getnameinfo) > or for IPv6 (and relying in IPv4 mapped addresses for compatibility) I would say independence, you don't want the applications to work only with IPv6-enabled kernels, right? At least basic applications are easy to do independently, and you will get binaries that work on IPv4-only kernels as well. Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 08:17:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MGHjIm023382 for ; Thu, 22 Mar 2001 08:17:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MGHj1l023381 for ipng-dist; Thu, 22 Mar 2001 08:17: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MGHXIm023374 for ; Thu, 22 Mar 2001 08:17: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 IAA11110 for ; Thu, 22 Mar 2001 08:17:32 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22112 for ; Thu, 22 Mar 2001 08:17:31 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 624261E057; Thu, 22 Mar 2001 11:17:26 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA18857; Thu, 22 Mar 2001 11:17:22 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id ACFFC35C42; Thu, 22 Mar 2001 10:17:21 -0600 (CST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: ipng From: "Steven M. Bellovin" To: jari.arkko@piuha.net Cc: gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 22 Mar 2001 10:17:21 -0600 Message-Id: <20010322161721.ACFFC35C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3ABA1FB8.9040803@piuha.net>, Jari Arkko writes: > >* In the Internet Area, there is the itrace WG which is > specifically chartered for looking into DoS, but is > looking only at a particular solution. Is this > solution sufficient for all DoS issues? We're not sure > but at least some of the individual DoS concerns such > as attacking address autoconfiguration don't really > fall on the area that i-trace can deal with. Without addressing your general question, IESG policy is that working groups should be very carefully focused. A hypothetical "Fix DDoS Working Group" would probably not meet that test -- there are no concrete deliverables. That said, an RFC that discussed DoS avoidance strategies would be a good idea. I'm agnostic about whether that should be done in a WG or as an individual submission, but BCP status would be a good one to aim for. How this process should be organized is up to the AD's and the IESG. (Also note that the next rev of draft-rescorla-sec-cons has a good section on DoS attacks.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 08:43:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MGhfIm023420 for ; Thu, 22 Mar 2001 08:43:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MGhfbl023419 for ipng-dist; Thu, 22 Mar 2001 08:43:41 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MGhWIm023412 for ; Thu, 22 Mar 2001 08:43:32 -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 IAA15731 for ; Thu, 22 Mar 2001 08:43:31 -0800 (PST) Received: from multicasttech.com (garcia.multicasttech.com [63.105.122.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05907 for ; Thu, 22 Mar 2001 08:43:31 -0800 (PST) Received: from [63.87.12.233] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 836771; Thu, 22 Mar 2001 11:43:06 -0500 Message-ID: <3ABA2BC6.9EFD750F@21rst-century.com> Date: Thu, 22 Mar 2001 11:43:50 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: jari.arkko@piuha.net, gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work References: <20010322161721.ACFFC35C42@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message <3ABA1FB8.9040803@piuha.net>, Jari Arkko writes: > > > >* In the Internet Area, there is the itrace WG which is > > specifically chartered for looking into DoS, but is > > looking only at a particular solution. Is this > > solution sufficient for all DoS issues? We're not sure > > but at least some of the individual DoS concerns such > > as attacking address autoconfiguration don't really > > fall on the area that i-trace can deal with. > > Without addressing your general question, IESG policy is that working > groups should be very carefully focused. A hypothetical "Fix DDoS Working > Group" would probably not meet that test -- there are no concrete > deliverables. > > That said, an RFC that discussed DoS avoidance strategies would be > a good idea. I'm agnostic about whether that should be done in a > WG or as an individual submission, but BCP status would be a good > one to aim for. How this process should be organized is up to the > AD's and the IESG. (Also note that the next rev of draft-rescorla-sec-cons > has a good section on DoS attacks.) Is this available? The current draft has expired, and there is no new version in the draft directory. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.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 Mar 22 08:48:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MGmfIm023440 for ; Thu, 22 Mar 2001 08:48:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MGmfbv023439 for ipng-dist; Thu, 22 Mar 2001 08:48: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MGmTIm023432 for ; Thu, 22 Mar 2001 08: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 IAA07703 for ; Thu, 22 Mar 2001 08:48:28 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09880 for ; Thu, 22 Mar 2001 08:48:26 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 633AF4CE1C; Thu, 22 Mar 2001 11:48:23 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA19640; Thu, 22 Mar 2001 11:48:20 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 8CEBD35C44; Thu, 22 Mar 2001 10:48:19 -0600 (CST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: tme@21rst-century.com Cc: jari.arkko@piuha.net, gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Mar 2001 10:48:18 -0600 Message-Id: <20010322164819.8CEBD35C44@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3ABA2BC6.9EFD750F@21rst-century.com>, Marshall Eubanks writes: > > >"Steven M. Bellovin" wrote: >> >> In message <3ABA1FB8.9040803@piuha.net>, Jari Arkko writes: >> > >> >* In the Internet Area, there is the itrace WG which is >> > specifically chartered for looking into DoS, but is >> > looking only at a particular solution. Is this >> > solution sufficient for all DoS issues? We're not sure >> > but at least some of the individual DoS concerns such >> > as attacking address autoconfiguration don't really >> > fall on the area that i-trace can deal with. >> >> Without addressing your general question, IESG policy is that working >> groups should be very carefully focused. A hypothetical "Fix DDoS Working >> Group" would probably not meet that test -- there are no concrete >> deliverables. >> >> That said, an RFC that discussed DoS avoidance strategies would be >> a good idea. I'm agnostic about whether that should be done in a >> WG or as an individual submission, but BCP status would be a good >> one to aim for. How this process should be organized is up to the >> AD's and the IESG. (Also note that the next rev of draft-rescorla-sec-cons >> has a good section on DoS attacks.) > >Is this available? The current draft has expired, and there is no new >version in the draft directory. > The DoS section was added in the -03 draft, which wasn't ready in time for the cut-off. I believe that Eric will submit it very soon. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 11:07:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ7mIm023711 for ; Thu, 22 Mar 2001 11:07:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJ7mQk023710 for ipng-dist; Thu, 22 Mar 2001 11:07: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ7hIm023703 for ; Thu, 22 Mar 2001 11:07:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2MJ4qJ26799 for ipng@sunroof.eng.sun.com; Thu, 22 Mar 2001 11:04:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2L8cbIm021203 for ; Wed, 21 Mar 2001 00:38:37 -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 AAA04607 for ; Wed, 21 Mar 2001 00:38:38 -0800 (PST) Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23382 for ; Wed, 21 Mar 2001 00:38:37 -0800 (PST) Received: by iabgfw.iabg.de; id JAA27066; Wed, 21 Mar 2001 09:38:31 +0100 (MET) Received: from iabgmh.iabg.de(10.255.255.2) by iabgfw.iabg.de via smap (V4.2) id xma026387; Wed, 21 Mar 01 09:37:06 +0100 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de for ; Wed, 21 Mar 2001 09:37:04 +0100 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id JAA03302 for ; Wed, 21 Mar 2001 09:37:03 +0100 (MET) Received: from cc31pc01 (cc31pc01.iabg.de [10.5.0.187]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id JAA12875 for ; Wed, 21 Mar 2001 09:37:04 +0100 (MET) From: "Florian Heissenhuber" Organization: IABG mbH To: ipng@sunroof.eng.sun.com Date: Wed, 21 Mar 2001 09:37:03 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: IPSec for IPv6 on Linux available !!!! Reply-to: heissenhuber@iabg.de Message-ID: <3AB8763F.23200.300C9D@localhost> X-mailer: Pegasus Mail for Win32 (v3.12cDE) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, we like to announce the availability of the first IPSec implementation for IPv6 running on Linux. This implementation is based on FreeS/WAN 1.8 (http://www.freeswan.org). The implementation of IPSec tunnel mode and the integration in FreeS/WAN was done by IABG as part of the EU project 6INIT (http://www.6init.org). There's still much work to do but this is the first running IPsec implementation for IPv6 on Linux. Currently the following features have been tested successfully: - IPv6 tunnel mode on gateways - Encryption algorithm: 3DES - Authentication algorithm: MD5 - Tested with Linux kernel 2.4.0 test 9 (others might work) - Tested with static routing - Tested with manual address configuration For detailed information, please read the README and INSTALL documents included in the distribution. You may download FreeS/WAN with IPv6 support from the following URL: http://www.ipv6.iabg.de/downloadframe/index.html If you have any problems downloading the distribution please send me an e-mail! Regards, Florian Heissenhuber __________________________________________________________________ Florian Heissenhuber IABG, Communication Networks Email: heissenhuber@iabg.de URL: www.iabg.de www.ipv6.iabg.de -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 11:09:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ9GIm023731 for ; Thu, 22 Mar 2001 11:09:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJ9FfU023730 for ipng-dist; Thu, 22 Mar 2001 11:09:15 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ97Im023723 for ; Thu, 22 Mar 2001 11:09:07 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2MJ6FG26859 for ipng@sunroof.eng.sun.com; Thu, 22 Mar 2001 11:06:15 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MBGLIm022901 for ; Thu, 22 Mar 2001 03:16: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 DAA20663 for ; Thu, 22 Mar 2001 03:16:20 -0800 (PST) Received: from hyse.grm.hia.no (hyse.grm.hia.no [128.39.202.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13166 for ; Thu, 22 Mar 2001 03:16:19 -0800 (PST) Received: from hyse.grm.hia.no ([128.39.202.21]) by hyse.grm.hia.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GQ7S67V3; Thu, 22 Mar 2001 12:20:30 +0100 Received: from malle.siving.hia.no ([128.39.202.26]) by hyse.grm.hia.no (NAVIEG 2.1 bld 63) with SMTP id M2001032212202915424 for ; Thu, 22 Mar 2001 12:20:29 +0100 content-class: urn:content-classes:message Subject: QoS in IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 22 Mar 2001 12:16:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <63AD1AC95D52D311AEB700500483F00009D547@malle.siving.hia.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QoS in IPv6 Thread-Index: AcCywYSSSAToMp5YSrqDy1LNX+rwug== From: "Frode Trydal" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2MBGMIm022902 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm currently working on a report concerning, among other, QoS in IPv6. I'm therefore wondering if any of you had some reflections concerning if IPv6 will have some additional support for QoS (other than the QoS already specified for IPv4). Links to resources are also extremely appreciated. Regards Frode Trydal -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 11:08:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ8PIm023721 for ; Thu, 22 Mar 2001 11:08:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJ8OjP023720 for ipng-dist; Thu, 22 Mar 2001 11:08:24 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ8IIm023713 for ; Thu, 22 Mar 2001 11:08:19 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2MJ5RY26829 for ipng@sunroof.eng.sun.com; Thu, 22 Mar 2001 11:05:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LH4fIm021588 for ; Wed, 21 Mar 2001 09:04: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 JAA21314 for ; Wed, 21 Mar 2001 09:04:41 -0800 (PST) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA00682 for ; Wed, 21 Mar 2001 09:04:40 -0800 (PST) Received: (qmail 30132 invoked from network); 21 Mar 2001 17:04:39 -0000 Received: from purina.chek.com (208.197.227.8) by mailrelay1.chek.com with SMTP; 21 Mar 2001 17:04:39 -0000 Received: (qmail 11118 invoked by uid 99); 21 Mar 2001 16:54:51 -0000 Date: 21 Mar 2001 16:54:51 -0000 Message-ID: <20010321165451.11117.qmail@purina.chek.com> From: "Emanuel Moreira" To: bzill@microsoft.com, ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: NAPT - STATEFULL Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NAPT NT4 MIcrosoft Research 1.4 ------------ -------------- ------------ | IPv4 |----------| NAPT |-----|IPv6 | ------------- -------------- ------------ This is the cenario. I've configured the NAPT in statefull configuration, but it doesn't work at all. I can ping from the NApt to the IPv4 machine and from the NApt to the IPV6 machine and vice-versa. But the NAPT dosen't make the translation of the packets IPv4->IPv6 or IPv6->IPv4. I've made the configuration in the key register like: 193.136.92.246 beef:feed::1234:5678 3ffe:1cff::bead:ed:cafe:deed 192.168.10.1 This are the only lines I have. I have routes for the IPv6 packets go out to the iPv6 world, but not for IPv4 because I think it's automaticaly. The NAPT has created a translator interface. So why does it not works ? Can anybody help me, please? Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 11:09:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ9gIm023741 for ; Thu, 22 Mar 2001 11:09:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJ9f0e023740 for ipng-dist; Thu, 22 Mar 2001 11:09:41 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ9WIm023733 for ; Thu, 22 Mar 2001 11:09:32 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2MJ6e426889 for ipng@sunroof.eng.sun.com; Thu, 22 Mar 2001 11:06:40 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MFnrIm023336 for ; Thu, 22 Mar 2001 07:49: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 HAA27222 for ; Thu, 22 Mar 2001 07:49:53 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27915 for ; Thu, 22 Mar 2001 07:49:50 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 90C536A901; Thu, 22 Mar 2001 17:49:45 +0200 (EET) Message-ID: <3ABA1FB8.9040803@piuha.net> Date: Thu, 22 Mar 2001 17:52:24 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com Cc: pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com Subject: Re: DDoS Work Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn Morrow wrote in the IPv6 mailing list: >Is this the appropriate group to discuss possible improvements >to detection, prevention, reporting and action against DoS >and DDoS attack for IPv6? > >It seems to me that perhaps a less constrained set of >mechanisms could be put in place to more effectively >deal with the issue than in IPv4. It may also be possible >to better harmonize these solutions with proposed node >mobility, renumbering and multihoming solutions. We believe addressing DoS and DDoS concerns should be a high priority. One idea we have played with is a general-purpose IP-layer DoS protection scheme, applicable to both existing and new protocols. For instance, servers could use a combination of additional packet roundtrips, client-stored state, and cryptographic puzzles to prevent resource starvation, requests from forged source addresses, and massive request generation from distributed clients. Today, people seem to be hoping that the application protocols do this by themselves. And, frankly, we're not doing a very good job at that. Most protocols, even security protocols, are known to have DoS problems that would have been possible to solve, had more attention be paid to them in the design work. The question is, is there something that could be done as a general support in IP (IPv6) for this? Such as ICMP mechanisms that demand puzzle solving from a client before proceeding etc. Needless to say, these mechanisms shouldn't create additional DoS possibilities. At this time we are not sure what the mechanisms in detail could be, whether they work on the IP layer or if they are reusable protocol components integrated to application protocols (a la SSL), or whether it is possible to avoid additional DoS dangers. Or if we just need a protocol designer's guide that explains how new protocols must deal with DoS attacks. >Would people recommend a new WG to deal with >these particulars or do people feel that this >or another existing WG is sufficient? Well, there are a number of potential discussion places: * The current DoS and security issues in mobile IP would call for some discussion in that group. * The current DoS issues for some of the IPv6 signaling and address autoconfiguration call for some discussion in that group. There's also some autoconfiguration issues in the zeroconf WG. * In the Internet Area, there is the itrace WG which is specifically chartered for looking into DoS, but is looking only at a particular solution. Is this solution sufficient for all DoS issues? We're not sure but at least some of the individual DoS concerns such as attacking address autoconfiguration don't really fall on the area that i-trace can deal with. * The HIP BOF on Tuesday seemed to decide that a new WG will be created to implement new identity mechanisms in IP, in order to deal better with mobility and DoS attacks. * Perhaps a completely new, separate working group might also be a possibility. In any case, we think DoS should get more attention than many of the other issues such as confidentiality and privacy that have been dealt with early. Jari Arkko Pekka Nikander Ericsson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 11:10:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJAJIm023765 for ; Thu, 22 Mar 2001 11:10:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJAJ06023764 for ipng-dist; Thu, 22 Mar 2001 11:10:19 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ9vIm023748 for ; Thu, 22 Mar 2001 11:09:58 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2MJ75o26919 for ipng@sunroof.eng.sun.com; Thu, 22 Mar 2001 11:07:05 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MGwCIm023492 for ; Thu, 22 Mar 2001 08:58:12 -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 IAA16913 for ; Thu, 22 Mar 2001 08:58:12 -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 IAA11936 for ; Thu, 22 Mar 2001 08:58:11 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id EB2FE6A901; Thu, 22 Mar 2001 18:58:07 +0200 (EET) Message-ID: <3ABA2FBE.5000603@piuha.net> Date: Thu, 22 Mar 2001 19:00:46 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" Cc: gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work References: <20010322161721.ACFFC35C42@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin wrote: > Without addressing your general question, IESG policy is that working > groups should be very carefully focused. A hypothetical "Fix DDoS Working > Group" would probably not meet that test -- there are no concrete > deliverables. You are right, and the policy is a good one! But before we go too far in this question, let's discuss more about whether there is something still to be done for DoS prevention, and what. After finding out that, we could discuss how the work is organized. Right now, at least I'm uncertain if we have done everything and how sufficient is the work on the various WGs. Do some of Pekka's ideas to protect address autoconfiguration suffice for all of IPv6 signaling? Does i-trace solve all tracing issues? Will HIP solve everything? Is there something in the mobile-IP area that hasn't and will not be solved by that WG? Is it technically possible to have some general DoS-prevention protocols or layers to applications? 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 Thu Mar 22 11:10:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJAWIm023776 for ; Thu, 22 Mar 2001 11:10:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJAVFp023771 for ipng-dist; Thu, 22 Mar 2001 11:10:31 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJ9sIm023746 for ; Thu, 22 Mar 2001 11:09:55 -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 LAA00554 for ; Thu, 22 Mar 2001 11:09:53 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA20023 for ; Thu, 22 Mar 2001 11:09:45 -0800 (PST) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Mar 2001 11:08:08 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 22 Mar 2001 11:08:08 -0800 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="iso-8859-1" Subject: RE: code for IPv6 or for AF independence Date: Thu, 22 Mar 2001 11:08:06 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8027C3506@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: code for IPv6 or for AF independence Thread-Index: AcCyj4WfmX7c6xHhT0mAmcuiSJig2wAbLPJQ From: "Richard Draves" To: , X-OriginalArrivalTime: 22 Mar 2001 19:08:08.0143 (UTC) FILETIME=[6E322DF0:01C0B303] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2MJ9vIm023747 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes. Another reason for using getaddrinfo/getnameinfo is that they support scope-ids. Rich > -----Original Message----- > From: horape@tinuviel.compendium.net.ar > [mailto:horape@tinuviel.compendium.net.ar] > Sent: Wednesday, March 21, 2001 9:16 PM > To: ipng@sunroof.eng.sun.com > Subject: code for IPv6 or for AF independence > > > ¡Hola! > > After some discussions in the Debian IPv6 project I'm coming here > to hear this wg's opinion about what should "normal application" > programmers do? > > By "normal application" I mean those that don't need to know what > network protocol is being used in the communication (telnet, smtp, > pop, etc, could run over tcp/ipv4, tcp/ipv6, tcp/ipx or any other > stream protocol with no changes) > > Should we program for AF independence (using getaddrinfo/getnameinfo) > or for IPv6 (and relying in IPv4 mapped addresses for compatibility) > > I don't believe IPv6 is a cure-all protocol. Porting one "normal > application" between PFs is not a hard work, but porting the thousands > apps we have is. We're commited to do all that work, but when the next > protocol comes we won't like to do it again. > > That's why I'd think programming for AF independence should > be preferred > and programming for IPv6 be restricted to IPv6 specific apps > that couldn't > be written AF independent, and discouraged for "normal applications" > > That's my humble opinion, but before trying to convince all the other > Debian IPv6 people, I'm asking for the opinion of this wg on > this matters. > > Are my reasoning and conclusion corrects? > > Thanks, > HoraPe > --- > Horacio J. Peña > horape@compendium.com.ar > horape@uninet.edu > bofh@puntoar.net.ar > horape@hcdn.gov.ar > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 22 11:42:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJgFIm024103 for ; Thu, 22 Mar 2001 11:42:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJgEKQ024100 for ipng-dist; Thu, 22 Mar 2001 11:42: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJgAIm024093 for ; Thu, 22 Mar 2001 11:42:10 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2MJdIR26979 for ipng@sunroof.eng.sun.com; Thu, 22 Mar 2001 11:39:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LCsbIm021390 for ; Wed, 21 Mar 2001 04:54:37 -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 EAA28534 for ; Wed, 21 Mar 2001 04:54:36 -0800 (PST) Received: from cgi.icon.co.za (cgi.icon.co.za [196.35.95.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA21658 for ; Wed, 21 Mar 2001 04:54:33 -0800 (PST) Received: from mail450.icon.co.za (ismtp.icon.co.za [196.35.95.40]) by cgi.icon.co.za (Postfix) with ESMTP id B106A4C84B for ; Wed, 21 Mar 2001 14:54:25 +0200 (SAST) Received: from ryan (c1-rba-18.dial-up.net [196.33.195.18]) by mail450.icon.co.za (8.9.3/8.9.3) with SMTP id OAA28306 for ; Wed, 21 Mar 2001 14:54:23 +0200 (GMT) Message-ID: <003901c0b206$5d8c5640$0264a8c0@ryan> From: "Ryan Strauss" To: Subject: IPv6 Data Transfer Performance Date: Wed, 21 Mar 2001 14:56:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C0B217.1CB21A40" 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 is a multi-part message in MIME format. ------=_NextPart_000_0036_01C0B217.1CB21A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am currently doing research into IPv6 at the University of the = Witwatersrand, Johannesburg, South Africa and I thought that the IPng = Mailing List would be the ideal organisation to approach on this topic. The focus of my research is on the improvements of data transfer using = IPv6, as opposed to IPv4, in conjunction with both TCP and UDP protocols = in the ISO layer 4. It would be greatly appreciated if anyone could = provide me with any information, ideas or advice regarding this matter.=20 Many thanks Ryan Strauss ------=_NextPart_000_0036_01C0B217.1CB21A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am currently doing research into = IPv6 at the=20 University of the Witwatersrand, Johannesburg, South Africa and I = thought that=20 the IPng Mailing List would be the ideal organisation to = approach=20 on this topic.
 
The focus of my research is on the improvements of = data=20 transfer using IPv6, as opposed to IPv4, in conjunction with both = TCP and=20 UDP protocols in the ISO layer 4. It = would be=20 greatly appreciated if anyone could provide me with any = information, ideas=20 or advice regarding this matter.
 
Many thanks
Ryan=20 Strauss
------=_NextPart_000_0036_01C0B217.1CB21A40-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 12:54:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MKsBIm024232 for ; Thu, 22 Mar 2001 12:54:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MKsADg024231 for ipng-dist; Thu, 22 Mar 2001 12:54: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MKs0Im024224 for ; Thu, 22 Mar 2001 12:54:00 -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 MAA15710 for ; Thu, 22 Mar 2001 12:53:59 -0800 (PST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02037 for ; Thu, 22 Mar 2001 12:53:58 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 22 Mar 2001 12:54:46 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Mar 2001 12:54:54 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 22 Mar 2001 12:54:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: DDoS Work Content-Type: text/plain; charset="US-ASCII" Date: Thu, 22 Mar 2001 12:54:53 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DDoS Work Thread-Index: AcCy7EuycGvgYge3T8K0m0GfhW0ehwAJSAkA From: "Christian Huitema" To: "Steven M. Bellovin" , Cc: , , , , , X-OriginalArrivalTime: 22 Mar 2001 20:54:53.0890 (UTC) FILETIME=[58519A20:01C0B312] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2MKs1Im024225 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Steven M. Bellovin [mailto:smb@research.att.com] > In message <3ABA1FB8.9040803@piuha.net>, Jari Arkko writes: > > > >* In the Internet Area, there is the itrace WG which is > > specifically chartered for looking into DoS, but is > > looking only at a particular solution. Is this > > solution sufficient for all DoS issues? We're not sure > > but at least some of the individual DoS concerns such > > as attacking address autoconfiguration don't really > > fall on the area that i-trace can deal with. > > Without addressing your general question, IESG policy is that working > groups should be very carefully focused. A hypothetical "Fix DDoS Working > Group" would probably not meet that test -- there are no concrete > deliverables. I would think that a study of mechanisms to trace the actual source of Internet packets would pass the charter test. After all, there have been several proposals to do this by letting the routers mark bits in packets, using a probabilistic algorithm. This seem to fall in the single problem / existing proposed solution / concrete deliverable category. Indeed, we can also debate whether source tracing is useful... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 13:08:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ML8rIm024271 for ; Thu, 22 Mar 2001 13:08:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ML8rsb024270 for ipng-dist; Thu, 22 Mar 2001 13:08: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ML8fIm024263 for ; Thu, 22 Mar 2001 13:08:41 -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 NAA12762 for ; Thu, 22 Mar 2001 13:08:39 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11586 for ; Thu, 22 Mar 2001 13:08:37 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 9FD1F1E054; Thu, 22 Mar 2001 16:08:36 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id QAA24745; Thu, 22 Mar 2001 16:08:34 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 7864C35C42; Thu, 22 Mar 2001 15:08:33 -0600 (CST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Christian Huitema" Cc: jari.arkko@piuha.net, gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Mar 2001 15:08:32 -0600 Message-Id: <20010322210833.7864C35C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , "Christian Huitema" writes: > >I would think that a study of mechanisms to trace the actual source of >Internet packets would pass the charter test. After all, there have been >several proposals to do this by letting the routers mark bits in >packets, using a probabilistic algorithm. This seem to fall in the >single problem / existing proposed solution / concrete deliverable >category. Yup. But since I'm far from convinced of the feasibility of those solutions, I chose to propose ICMP Traceback as the preferred mechanism. The first such scheme, by Savage et al., seems to have too high a computational complexity, as shown by Song and Perrig. Song and Perrig have their own, much more efficient scheme, but it requires good knowledge of Internet topology, and I'm not convinced that that would be forthcoming. All such schemes suffer from a lack of a place to do the marking -- using the ID field breaks fragmentation and AH, there's no place in the v6 header except maybe the flow label, etc. > >Indeed, we can also debate whether source tracing is useful... > Indeed. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 13:44:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MLiBIm024338 for ; Thu, 22 Mar 2001 13:44:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MLiAmO024337 for ipng-dist; Thu, 22 Mar 2001 13:44: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MLhxIm024330 for ; Thu, 22 Mar 2001 13:43:59 -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 NAA11456 for ; Thu, 22 Mar 2001 13:43:58 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19144 for ; Thu, 22 Mar 2001 13:43:57 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA26126 for ; Thu, 22 Mar 2001 15:43:55 -0600 (CST) Message-Id: <200103222143.PAA26126@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: draft-francis-ipngwg-unique-site-local-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26122.985297434.1@gungnir.fnal.gov> Date: Thu, 22 Mar 2001 15:43:55 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I read this carefully and I think it's excellent. I don't care for the strong assumption that same-site determination will be done via DNS (although it might be), and the "This means" is perhaps an imprecise choice of words at the top of section 5.2, but other than that, I think it ought to go forward promptly. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 14:58:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MMwoIm024449 for ; Thu, 22 Mar 2001 14:58:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MMwnYW024448 for ipng-dist; Thu, 22 Mar 2001 14:58:49 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MMwdIm024441 for ; Thu, 22 Mar 2001 14:58:39 -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 OAA17035 for ; Thu, 22 Mar 2001 14:58:39 -0800 (PST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29175 for ; Thu, 22 Mar 2001 14:58:39 -0800 (PST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Thu, 22 Mar 2001 17:57:45 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G975H46A; Thu, 22 Mar 2001 17:57:44 -0500 Received: from nortelnetworks.com (DEATHVALLEY [47.16.4.194]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWR3YD; Thu, 22 Mar 2001 17:57:44 -0500 Message-ID: <3ABA833A.78DC7ACC@nortelnetworks.com> Date: Thu, 22 Mar 2001 17:56:59 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Christian Huitema , jari.arkko@piuha.net, "Glenn Morrow" , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, "Marcus Leech" Subject: Re: DDoS Work References: <20010322210833.7864C35C42@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, "Steven M. Bellovin" wrote: > > In message , "Christian > Huitema" writes: > > > > >I would think that a study of mechanisms to trace the actual source of > >Internet packets would pass the charter test. After all, there have been > >several proposals to do this by letting the routers mark bits in > >packets, using a probabilistic algorithm. This seem to fall in the > >single problem / existing proposed solution / concrete deliverable > >category. > > Yup. But since I'm far from convinced of the feasibility of those > solutions, I chose to propose ICMP Traceback as the preferred > mechanism. The first such scheme, by Savage et al., seems to have too > high a computational complexity, as shown by Song and Perrig. Song and > Perrig have their own, much more efficient scheme, but it requires good > knowledge of Internet topology, and I'm not convinced that that would > be forthcoming. All such schemes suffer from a lack of a place to do > the marking -- using the ID field breaks fragmentation and AH, there's > no place in the v6 header except maybe the flow label, etc. For IPv6, you could define a new extension header (hop-by-hop option). Brian > > > >Indeed, we can also debate whether source tracing is useful... > > > Indeed. > > --Steve Bellovin, http://www.research.att.com/~smb > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 22 15:13:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MNDsIm024472 for ; Thu, 22 Mar 2001 15:13:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MNDr40024471 for ipng-dist; Thu, 22 Mar 2001 15:13: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MNDgIm024464 for ; Thu, 22 Mar 2001 15:13:42 -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 PAA13662 for ; Thu, 22 Mar 2001 15:13:42 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05147 for ; Thu, 22 Mar 2001 15:13:41 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA14525; Fri, 23 Mar 2001 08:04:53 +0900 (JST) To: "Brian Haberman" cc: ipng@sunroof.eng.sun.com, ietf-itrace@research.att.com In-reply-to: haberman's message of Thu, 22 Mar 2001 17:56:59 EST. <3ABA833A.78DC7ACC@nortelnetworks.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DDoS Work From: itojun@iijlab.net Date: Fri, 23 Mar 2001 08:04:53 +0900 Message-ID: <14523.985302293@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk # not sure if it was okay to strip off cc: list >For IPv6, you could define a new extension header (hop-by-hop option). are you suggesting to insert hop-by-hop option to packets from someone (will break AH and/or ESP badly), or something else? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 15:26:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MNQiIm024512 for ; Thu, 22 Mar 2001 15:26:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MNQirp024511 for ipng-dist; Thu, 22 Mar 2001 15:26: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MNQYIm024504 for ; Thu, 22 Mar 2001 15:26: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 PAA28761 for ; Thu, 22 Mar 2001 15:26:34 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11523 for ; Thu, 22 Mar 2001 15:26:32 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2MNHed28464; Fri, 23 Mar 2001 00:17:40 +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 AAA14059; Fri, 23 Mar 2001 00:17:39 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2MNHcA44432; Fri, 23 Mar 2001 00:17:38 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103222317.f2MNHcA44432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Brian Haberman" cc: "Steven M. Bellovin" , Christian Huitema , jari.arkko@piuha.net, "Glenn Morrow" , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, "Marcus Leech" Subject: Re: DDoS Work In-reply-to: Your message of Thu, 22 Mar 2001 17:56:59 EST. <3ABA833A.78DC7ACC@nortelnetworks.com> Date: Fri, 23 Mar 2001 00:17:38 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: For IPv6, you could define a new extension header (hop-by-hop option). => and the hop-by-hop option will be (slowly) processed by each router (I don't believe this is you'd like to do)... But if we need some free space in headers IPv6 can provide this (ie. good idea, bad keyboard :-) Regards Francis.Dupont@enst-bretagne.fr PS: the current discussion can give what we want. Personally I vote for 3 (keep flow label unspecified) and to go to the bar! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 16:26:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2N0QRIm024671 for ; Thu, 22 Mar 2001 16:26:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2N0QR0H024670 for ipng-dist; Thu, 22 Mar 2001 16:26: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2N0QFIm024663 for ; Thu, 22 Mar 2001 16:26:15 -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 QAA21225 for ; Thu, 22 Mar 2001 16:26:14 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18961 for ; Thu, 22 Mar 2001 16:26:13 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id DFE5E4CE4F; Thu, 22 Mar 2001 19:26:12 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id TAA27912; Thu, 22 Mar 2001 19:26:10 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id E623F35C42; Thu, 22 Mar 2001 18:26:09 -0600 (CST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Brian Haberman" Cc: Christian Huitema , jari.arkko@piuha.net, "Glenn Morrow" , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, "Marcus Leech" Subject: Re: DDoS Work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Mar 2001 18:26:09 -0600 Message-Id: <20010323002610.E623F35C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3ABA833A.78DC7ACC@nortelnetworks.com>, "Brian Haberman" writes: >> >> Yup. But since I'm far from convinced of the feasibility of those >> solutions, I chose to propose ICMP Traceback as the preferred >> mechanism. The first such scheme, by Savage et al., seems to have too >> high a computational complexity, as shown by Song and Perrig. Song and >> Perrig have their own, much more efficient scheme, but it requires good >> knowledge of Internet topology, and I'm not convinced that that would >> be forthcoming. All such schemes suffer from a lack of a place to do >> the marking -- using the ID field breaks fragmentation and AH, there's >> no place in the v6 header except maybe the flow label, etc. > >For IPv6, you could define a new extension header (hop-by-hop option). > Yes, but unless the attacker(s)'s packets used it, how would you mark them? Even apart from considerations of the load on the routers, I'm reliably informed that anyone who builds a v6 router that inserts headers into transit packets will incur the Curse of Deering... --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 05:02:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ND2XIm025595 for ; Fri, 23 Mar 2001 05:02:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ND2WI8025594 for ipng-dist; Fri, 23 Mar 2001 05:02: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ND2DIm025580 for ; Fri, 23 Mar 2001 05:02:14 -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 FAA04121 for ; Fri, 23 Mar 2001 05:02:12 -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 FAA25862 for ; Fri, 23 Mar 2001 05:02:11 -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 IAA08780; Fri, 23 Mar 2001 08:02:09 -0500 (EST) Message-Id: <200103231302.IAA08780@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-dns-discovery-01.txt Date: Fri, 23 Mar 2001 08:02:09 -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 IPNG Working Group of the IETF. Title : Analysis of DNS Server Discovery Mechanisms for IPv6 Author(s) : D. Thaler Filename : draft-ietf-ipngwg-dns-discovery-01.txt Pages : 43 Date : 22-Mar-01 There are any number of ways that IPv6 hosts can discover information required to enable name resolution, in the absence of a DHCP server. This document discusses the issues and provides a taxonomy of possible solutions, and evaluates them against various design criteria. Finally, it provides recommendations as input to the standards process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-01.txt 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-dns-discovery-01.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-dns-discovery-01.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: <20010322122025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-discovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-discovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010322122025.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 Mar 23 05:02:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ND2bIm025598 for ; Fri, 23 Mar 2001 05:02:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ND2aoY025597 for ipng-dist; Fri, 23 Mar 2001 05:02:36 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ND2HIm025587 for ; Fri, 23 Mar 2001 05:02:17 -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 FAA23440 for ; Fri, 23 Mar 2001 05:02:16 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23687 for ; Fri, 23 Mar 2001 05:02:15 -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 IAA08804; Fri, 23 Mar 2001 08:02:14 -0500 (EST) Message-Id: <200103231302.IAA08804@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-ipv6-2260-00.txt Date: Fri, 23 Mar 2001 08:02:13 -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 IPNG Working Group of the IETF. Title : IPv6 multihoming support at site exit routers Author(s) : J. Hagino Filename : draft-ietf-ipngwg-ipv6-2260-00.txt Pages : 9 Date : 22-Mar-01 The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-2260-00.txt 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-ipv6-2260-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-ipngwg-ipv6-2260-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: <20010322122034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-2260-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-2260-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010322122034.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 Mar 23 08:11:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NGBpIm025940 for ; Fri, 23 Mar 2001 08:11:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NGBoAr025939 for ipng-dist; Fri, 23 Mar 2001 08:11: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NGBfIm025932 for ; Fri, 23 Mar 2001 08:11: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 IAA13885 for ; Fri, 23 Mar 2001 08:11:40 -0800 (PST) Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA17677 for ; Fri, 23 Mar 2001 08:11:39 -0800 (PST) Received: (cpmta 18934 invoked from network); 23 Mar 2001 08:11:28 -0800 Received: from pcp017502pcs.wireless.meeting.ietf.org (HELO dellchan) (135.222.64.4) by smtp.francis.com (209.228.32.66) with SMTP; 23 Mar 2001 08:11:28 -0800 X-Sent: 23 Mar 2001 16:11:28 GMT Message-ID: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> Reply-To: "Paul Francis" From: "Paul Francis" To: Subject: what is a site??? Date: Fri, 23 Mar 2001 08:11:05 -0800 Organization: TAHOE Networks 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 When I presented the near-unique stuff in IETF50 yesterday, Deering stated from the mike that a site is a location in space (geographical region, whatever...I don't remember Steve's exact wording). This had me totally baffled---and it isn't fun to be baffled in front of a couple hundred people. It had me baffled because it doesn't make a lot of sense (it begs certain nonsensical questions like, how big can it be (in square meters), if you have five routers, one each in New York, Maimi, Chicago, LA, and San Francisco, all connected by dedicated links, with only a single ISP connection point, is this a site, or is it too big or too sparse to be considered a site, etc. etc.)? Given that this statement came from somebody as authoritative as Steve, and that nobody disagreed with it, I naturally assumed that I must have hastily glossed over some important piece of text somewhere, and felt embarrased for apparently not having done my homework and for having such a fundamental mis-understanding of IPv6 (and it isn't fun to be embarrased in front of a couple hundred people). So I started doing some homework. There is nothing about sites in 2460. There is nothing that defines sites in draft-ietf-ipngwg-addr-arch-v3-03.txt (though it talks a lot about sites). draft-ietf-ipngwg-site-prefixes-05.txt has a section called "What is a Site?". This section starts by saying that it "does not attempt to define the concept of a site", but then goes on to say "A site is an administratively controlled piece of topology that is well connected". This is much closer to what I was thinking (though I probably would have defined it as a connected piece of topology whereby SLA assignment is coordinated or some such thing). Erik's definition in any event clearly has nothing to do with geography. I could continue to wade through IPv6 specs to find the definition of site. But at this point I don't think the onus is on me to do so. Rather Steve I think the burden is on you to point me to this illusive piece of text that defines what a site is. Thanks, PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 08:39:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NGdaIm026018 for ; Fri, 23 Mar 2001 08:39:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NGdZOG026017 for ipng-dist; Fri, 23 Mar 2001 08:39: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NGdPIm026003 for ; Fri, 23 Mar 2001 08:39: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 IAA12773 for ; Fri, 23 Mar 2001 08:39:24 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27811 for ; Fri, 23 Mar 2001 08:39:24 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA19803 for ; Fri, 23 Mar 2001 09:39:23 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA12668 for ; Fri, 23 Mar 2001 09:39:22 -0700 (MST)] Received: from email.mot.com (d50-39be.cig.mot.com [160.47.57.190]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id G3C8J2SG; Fri, 23 Mar 2001 10:39:21 -0600 Message-ID: <3ABB988C.F05DF4A0@email.mot.com> Date: Fri, 23 Mar 2001 10:40:12 -0800 From: Kevin Wang Reply-To: kwang1@email.mot.com Organization: Motorola X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Francis CC: ipng@sunroof.eng.sun.com Subject: Re: what is a site??? References: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> Content-Type: multipart/mixed; boundary="------------5A7CE705A5365F177E0919F1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------5A7CE705A5365F177E0919F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Paul, You had a very good question - a question I wanted to ask but was afraid I would be considered too careless in IPv6 specs. Seems 'site' in IPv6 is an elastic concept - it all depends on how big your heart is ;-) . But in reality when I tried to learn to configure the 6Bone connection, I was baffled too. Hope you can give us a concise and practical definition very soon. Best regards. Kevin Paul Francis wrote: > When I presented the near-unique stuff in IETF50 yesterday, Deering stated > from the mike that a site is a location in space (geographical region, > whatever...I don't remember Steve's exact wording). This had me totally > baffled---and it isn't fun to be baffled in front of a couple hundred > people. > > It had me baffled because it doesn't make a lot of sense (it begs certain > nonsensical questions like, how big can it be (in square meters), if you > have five routers, one each in New York, Maimi, Chicago, LA, and San > Francisco, all connected by dedicated links, with only a single ISP > connection point, is this a site, or is it too big or too sparse to be > considered a site, etc. etc.)? > > Given that this statement came from somebody as authoritative as Steve, and > that nobody disagreed with it, I naturally assumed that I must have hastily > glossed over some important piece of text somewhere, and felt embarrased for > apparently not having done my homework and for having such a fundamental > mis-understanding of IPv6 (and it isn't fun to be embarrased in front of a > couple hundred people). > > So I started doing some homework. There is nothing about sites in 2460. > There is nothing that defines sites in draft-ietf-ipngwg-addr-arch-v3-03.txt > (though it talks a lot about sites). draft-ietf-ipngwg-site-prefixes-05.txt > has a section called "What is a Site?". This section starts by saying that > it "does not attempt to define the concept of a site", but then goes on to > say "A site is an administratively controlled piece of topology that is well > connected". This is much closer to what I was thinking (though I probably > would have defined it as a connected piece of topology whereby SLA > assignment is coordinated or some such thing). Erik's definition in any > event clearly has nothing to do with geography. > > I could continue to wade through IPv6 specs to find the definition of site. > But at this point I don't think the onus is on me to do so. Rather Steve I > think the burden is on you to point me to this illusive piece of text that > defines what a site is. > > Thanks, > > PF > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------5A7CE705A5365F177E0919F1 Content-Type: text/x-vcard; charset=us-ascii; name="kwang1.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Kevin Wang Content-Disposition: attachment; filename="kwang1.vcf" begin:vcard n:Wang;Kuanjing x-mozilla-html:FALSE org:Motorola, Inc.;NAT, NSS adr:;;1501 W. Shure Dr.;Arlington Heights;IL;60004;USA version:2.1 email;internet:kwang1@email.mot.com title:S.E. fn:Kevin Wang end:vcard --------------5A7CE705A5365F177E0919F1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 09:53:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NHrcIm026289 for ; Fri, 23 Mar 2001 09:53:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NHrb0u026288 for ipng-dist; Fri, 23 Mar 2001 09:53: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NHrSIm026281 for ; Fri, 23 Mar 2001 09:53:28 -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 JAA01843 for ; Fri, 23 Mar 2001 09:53:27 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27995 for ; Fri, 23 Mar 2001 09:53:26 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 23 Mar 2001 10:27:22 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H3N6G8RG; Fri, 23 Mar 2001 10:27:23 -0500 Received: from nortelnetworks.com (abl6t0e9.us.nortel.com [47.16.4.40]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWR30W; Fri, 23 Mar 2001 10:27:20 -0500 Message-ID: <3ABB6B2D.EADB8E88@nortelnetworks.com> Date: Fri, 23 Mar 2001 10:26:37 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: ipng@sunroof.eng.sun.com, ietf-itrace@research.att.com Subject: Re: DDoS Work References: <14523.985302293@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > # not sure if it was okay to strip off cc: list > > >For IPv6, you could define a new extension header (hop-by-hop option). > > are you suggesting to insert hop-by-hop option to packets from someone > (will break AH and/or ESP badly), or something else? > I realized my mistake a few minutes after I sent the note. This week has been way too long! 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 Mar 23 11:51:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NJppIm026697 for ; Fri, 23 Mar 2001 11:51:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NJpohL026696 for ipng-dist; Fri, 23 Mar 2001 11:51: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NJpUIm026681; Fri, 23 Mar 2001 11:51:30 -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 LAA08267; Fri, 23 Mar 2001 11:51:28 -0800 (PST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10005; Fri, 23 Mar 2001 11:51:28 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 23 Mar 2001 11:52:14 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 23 Mar 2001 11:52:22 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 23 Mar 2001 11:52:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Sites with multiple border routers (not just 6to4) Date: Fri, 23 Mar 2001 11:52:22 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sites with multiple border routers (not just 6to4) Thread-Index: AcCzwG5qiL7JHKgCRmigIGctX4r12gAENicg From: "Christian Huitema" To: "Vladislav Yasevich" , "George Tsirtsis" Cc: X-OriginalArrivalTime: 23 Mar 2001 19:52:22.0647 (UTC) FILETIME=[C6D11870:01C0B3D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2NJpVIm026682 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This conversation originated in Sigtran, but this is really about the IPv6 routing architecture, so I bring it to IPNGWG. The initial context was the handling of a site with multiple "6to4" routers. > From: Vladislav Yasevich [mailto:vlad@zk3.dec.com] >... > However, I still don't see a need for a special address for > 6to4 routers. The DSTM mechanism can provide the TEP and > it might as well provide the 6to4 address of the router (not > any speciall address). If there is a need, this need is independent of 6to4. It relates to "egress control" and v6 multi-homing. Suppose that a site is multi-homed. Each station gets several IPv6 addresses. For a given TCP connection, it picks one of them as source addresses. As packets are sent, the egress router is chosen as a function of the destination address, independent of the source address. This means that we can see packets flowing through ISP-A, using a source address allocated by ISP-B. The only problem with that is, what happens if ISP-A, in the name of protection against source-address spoofing, rejects these packets? -- Christian Huitema > May be DSTM might be extended to privide multiple TEPs and > let the implementation choose one (or cycle through them)? > Just a thought. This way we don't have to reserve a speciall > address. > > -vlad > > George Tsirtsis wrote: > > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > Sent: Friday, March 23, 2001 10:50 AM > > To: itojun@iijlab.net > > Cc: Vladislav Yasevich; George Tsirtsis; NGTRANS List > > Subject: RE: (ngtrans) Sites with multiple 6to4 border routers > > > > > >> I believe that's what Brian Carpenter, Tony Hain, and Dave Thaler > > were > > > >> saying the meeting. You have to use a globaly IPv4 address to > > > >> create a 6to4 prefix. I don't beleave you can assign the same IPv4 > > > >> address to 2 independent devices... > > > >Uh? There is nothing impossible there. Suppose that we have a > > > >multi-homed site that connects to the Internet through multiple > > routers, > > > >both of which advertise the same IPv4 prefix, say 123.123.1/23. > > > > > > i guess you are talking about different thing from Vladislav > > said: > > > > > > > /-------\ /------ > > > > | | +-+ | > > > > | +-+A+---------------+ > > > > | | +-+ | > > > > | Site | | Internet > > > > | | +-+ | > > > > | +-+B+---------------+ > > > > | | +-+ | > > > > \-------/ \----- > > > > No. When I say that "It is quite natural to reserve a single IPv4 > > address for the 6to4 routing service", I mean that A and B both use > > 2002:xxxx:xxxx::/48; both A and B use x.x.x.x. They advertise different > > addresses in the IPv6 cloud; they advertise the same IPv4 prefix (say > > x.x.x/24) to the Internet; the routing of outward bound packets is > > determined by IPv6 routing inside the site, e.g. RIPng; the routing of > > packets from the Internet is determined by Internet routing protocols > > (e.g. BGP). > > > > GT> Indeed! The requirement for 2 or more 6to4 gates to be able to use > the > > same 6to4 prefix is that they advertise the same ipv4 prefix in the IPv4 > > Internet. Up to now it has been assumed that they only advertise a > single > > IPv4 address but this is clearly not necessary. > > > > GT> In this case, mechanisms that require outgoing and incoming paths to > be > > using the same 6to4 gate could make use of Alain's 6to4 designated > address. > > > > George -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 13:13:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NLDXIm026915 for ; Fri, 23 Mar 2001 13:13:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NLDXQQ026914 for ipng-dist; Fri, 23 Mar 2001 13:13:33 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NLDMIm026904 for ; Fri, 23 Mar 2001 13:13:22 -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 NAA25512 for ; Fri, 23 Mar 2001 13:13:12 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09787 for ; Fri, 23 Mar 2001 14:13:11 -0700 (MST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 23 Mar 2001 14:45:02 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Mar 2001 14:50:09 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301A021AA@crchy271.us.nortel.com> From: "Glenn Morrow" To: "Steven M. Bellovin" , tme@21rst-century.com Cc: jari.arkko@piuha.net, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, "Marcus Leech" Subject: RE: DDoS Work Date: Fri, 23 Mar 2001 14:49:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B3DA.D238BCB0" X-Orig: 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_01C0B3DA.D238BCB0 Content-Type: text/plain; charset="iso-8859-1" I will take a look. I am also very glad that Steve is involved in the discussions due to his previous work and expertise on the issue. -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Thursday, March 22, 2001 10:48 AM To: tme@21rst-century.com Cc: jari.arkko@piuha.net; Morrow, Glenn [RICH2:C330:EXCH]; ipng@sunroof.eng.sun.com; pekka.nikander@nomadiclab.com; ietf-itrace@research.att.com; jis@mit.edu; Leech, Marcus [FITZ2:8M70:EXCH] Subject: Re: DDoS Work In message <3ABA2BC6.9EFD750F@21rst-century.com>, Marshall Eubanks writes: > > >"Steven M. Bellovin" wrote: >> >> In message <3ABA1FB8.9040803@piuha.net>, Jari Arkko writes: >> > >> >* In the Internet Area, there is the itrace WG which is >> > specifically chartered for looking into DoS, but is >> > looking only at a particular solution. Is this >> > solution sufficient for all DoS issues? We're not sure >> > but at least some of the individual DoS concerns such >> > as attacking address autoconfiguration don't really >> > fall on the area that i-trace can deal with. >> >> Without addressing your general question, IESG policy is that working >> groups should be very carefully focused. A hypothetical "Fix DDoS Working >> Group" would probably not meet that test -- there are no concrete >> deliverables. >> >> That said, an RFC that discussed DoS avoidance strategies would be >> a good idea. I'm agnostic about whether that should be done in a >> WG or as an individual submission, but BCP status would be a good >> one to aim for. How this process should be organized is up to the >> AD's and the IESG. (Also note that the next rev of draft-rescorla-sec-cons >> has a good section on DoS attacks.) > >Is this available? The current draft has expired, and there is no new >version in the draft directory. > The DoS section was added in the -03 draft, which wasn't ready in time for the cut-off. I believe that Eric will submit it very soon. --Steve Bellovin, http://www.research.att.com/~smb ------_=_NextPart_001_01C0B3DA.D238BCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DDoS Work

I will take a look. I am also very glad that Steve is = involved in the discussions due to his previous work and expertise on = the issue.

-----Original Message-----
From: Steven M. Bellovin [mailto:smb@research.att.com]
Sent: Thursday, March 22, 2001 10:48 AM
To: tme@21rst-century.com
Cc: jari.arkko@piuha.net; Morrow, Glenn = [RICH2:C330:EXCH];
ipng@sunroof.eng.sun.com; = pekka.nikander@nomadiclab.com;
ietf-itrace@research.att.com; jis@mit.edu; Leech, = Marcus
[FITZ2:8M70:EXCH]
Subject: Re: DDoS Work


In message = <3ABA2BC6.9EFD750F@21rst-century.com>, Marshall Eubanks = writes:
>
>
>"Steven M. Bellovin" wrote:
>>
>> In message = <3ABA1FB8.9040803@piuha.net>, Jari Arkko writes:
>> >
>> >* In the Internet Area, there is the = itrace WG which is
>> >   specifically chartered for = looking into DoS, but is
>> >   looking only at a = particular solution. Is this
>> >   solution sufficient for = all DoS issues? We're not sure
>> >   but at least some of the = individual DoS concerns such
>> >   as attacking address = autoconfiguration don't really
>> >   fall on the area that = i-trace can deal with.
>>
>> Without addressing your general question, = IESG policy is that working
>> groups should be very carefully = focused.  A hypothetical "Fix DDoS Working
>> Group" would probably not meet that = test -- there are no concrete
>> deliverables.
>>
>> That said, an RFC that discussed DoS = avoidance strategies would be
>> a good idea.  I'm agnostic about = whether that should be done in a
>> WG or as an individual submission, but BCP = status would be a good
>> one to aim for.  How this process = should be organized is up to the
>> AD's and the IESG.  (Also note that = the next rev of draft-rescorla-sec-cons
>> has a good section on DoS attacks.)
>
>Is this available? The current draft has = expired, and there is no new
>version in the draft directory.
>
The DoS section was added in the -03 draft, which = wasn't ready in time for
the cut-off.  I believe that Eric will submit = it very soon.

        =         --Steve = Bellovin, http://www.research.att.com/~smb


------_=_NextPart_001_01C0B3DA.D238BCB0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 13:50:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NLoXIm027120 for ; Fri, 23 Mar 2001 13:50:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NLoXen027119 for ipng-dist; Fri, 23 Mar 2001 13:50:33 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NLoLIm027112 for ; Fri, 23 Mar 2001 13:50:21 -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 NAA26794 for ; Fri, 23 Mar 2001 13:50:15 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26745 for ; Fri, 23 Mar 2001 13:50:13 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 23 Mar 2001 14:45:09 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Mar 2001 14:44:59 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301A0219D@crchy271.us.nortel.com> From: "Glenn Morrow" To: jari.arkko@piuha.net, ipng@sunroof.eng.sun.com Cc: pekka.nikander@nomadiclab.com Subject: RE: DDoS Work Date: Fri, 23 Mar 2001 14:44:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B3DA.1E6DF920" 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_01C0B3DA.1E6DF920 Content-Type: text/plain; charset="iso-8859-1" Jari and Pekka, Thanks for stimulating discussion on this. I too agree that it should be a high priority and that if we can do something at the IP layer it should be done. I will also subscribe to the IPTRACE WG. Clearly there are other forms of attack such as stealing address, usurping addresses, using all addresses up on a subnet and application specific methods that should be addressed. I would definitely support activities that would help educate designers to the possible scenarios and even try to build specific layering mechanisms to guard against attacks. With this last meeting, I have seen many new proposals, especially related to mobility that significantly open up to door to more DoS attack. After reviewing the IPTRACE mail list, I have noticed that many of the stumbing blocks they are faced with are due to the fact that there is a significant deployment of routers currently out there and that there is nothing mandated to be built into them to help facilitate proposed solutions. I believe that the identification of problem areas i.e. possible DoS attack could be built into IPv6 in a scalable manner if we are careful. In beginning the discussion, I would like to bring up a discussion that occurred earlier this year on the list with Charlie Perkins, Frank and myself. This discussion is partly stimulated by some recent product announcements from some vendors on this type of functionality. I am thinking that perhaps now, since there are more products available which could be used to deploy the functionality, the standards discussion might be a bit more open to the proposals. I would like to again float the idea that perhaps some sort of filtering on source address should be mandated on the first hop. My reasoning on this is that the existing filtering mechanisms are sort of a pariah i.e. it might be there or it might be not and we really have no idea where that "there" might be throughout the network. Clearly, the most scalable and effective place to do this filtering is on the first hop. Doing it at other points within the network is not guaranteed to be completely affective as it may not stop all slaves. It seems that two mechanisms for these filters have been proposed. One mechanism is a simple ingress check on an interface. The other is an exception mechanism that I believe has been coined ACL access control lists. The ACL list appears to allow specific addresses or range of addresses to pass through. It seems to me that if the ACL lists are used then there might be a glimmer of hope that mobile nodes could use their home address as source on visited domains and a whole range of solutions designed with this assumption will be able to be used with less change. It seems that when a mobile enters a visited subnet, the ACL lists could be updated to allow them in as part of neighbor discovery and AAA operations. Furthurmore, it seems to me that handoff signaling between domains could provide the trust relationships necessary to transfer the necessary filter requirement. The mobility and ACL lists aside, the mandate of just requiring even the simplist form of ingress filtering on the first hop, would signifantly improve IPv6's DDoS protection. It might make the job of Itrace a bit easier, as well, if instead of dropping the packets, the packets could be tunnelled or flagged in some manner to the attacked site. There might even be some valid reasons for tunneling the packet to the spoofed subnet as well in order to alert them that another node is impersonating it. With these mechanisms in place you could turn on and off slave monitoring software in the visited sites to try to surmise the masters and take more action. Although these other ideas will certainly require some significant thinking and discussions on scalability etc.., I would really like people to seriously consider at a minimum just mandating the simple source address filtering on the first hop in IPv6. Another area that I do not see much activity on is that of DDoS on routers, themselves. Tunneling of router advertisements is a major new hole that could be exploited. I believe Michael Thomas has tried to bring this up in the mobile IP WG and I agree with him that we have to be very careful in doing this sort of thing. I honestly see no way to safely do this without requiring strong encryption on the tunnels and extremely tight access authorization. I would like to stimulate discussion and work on these topics as well. I think there might also be an issue with autoconfiguration address schemes. It seems that a rogue node could depleat all of the available addresses on a subnet if it wished. I'm hoping I am wrong about this and just have missed something. I beleive Pekka's 'PBK+ series of hashes' draft points out some other issues as well. As others should be able to see by the mail list activity it may be a significant amount of bandwidth discussing these issues. The intent of my first mail was to politely ask the question to the chairs, "Do you want this bandwidth on this list at this time or would you rather have it separated. Perhaps you may wish to simply have a separate mailing list for organizational purposes?". I don't think we need or want another WG unless we want to do these application centric frameworks. Thanks to all, Glenn -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Thursday, March 22, 2001 9:52 AM To: Morrow, Glenn [RICH2:C330:EXCH]; ipng@sunroof.eng.sun.com Cc: pekka.nikander@nomadiclab.com; ietf-itrace@research.att.com Subject: Re: DDoS Work Glenn Morrow wrote in the IPv6 mailing list: >Is this the appropriate group to discuss possible improvements >to detection, prevention, reporting and action against DoS >and DDoS attack for IPv6? > >It seems to me that perhaps a less constrained set of >mechanisms could be put in place to more effectively >deal with the issue than in IPv4. It may also be possible >to better harmonize these solutions with proposed node >mobility, renumbering and multihoming solutions. We believe addressing DoS and DDoS concerns should be a high priority. One idea we have played with is a general-purpose IP-layer DoS protection scheme, applicable to both existing and new protocols. For instance, servers could use a combination of additional packet roundtrips, client-stored state, and cryptographic puzzles to prevent resource starvation, requests from forged source addresses, and massive request generation from distributed clients. Today, people seem to be hoping that the application protocols do this by themselves. And, frankly, we're not doing a very good job at that. Most protocols, even security protocols, are known to have DoS problems that would have been possible to solve, had more attention be paid to them in the design work. The question is, is there something that could be done as a general support in IP (IPv6) for this? Such as ICMP mechanisms that demand puzzle solving from a client before proceeding etc. Needless to say, these mechanisms shouldn't create additional DoS possibilities. At this time we are not sure what the mechanisms in detail could be, whether they work on the IP layer or if they are reusable protocol components integrated to application protocols (a la SSL), or whether it is possible to avoid additional DoS dangers. Or if we just need a protocol designer's guide that explains how new protocols must deal with DoS attacks. >Would people recommend a new WG to deal with >these particulars or do people feel that this >or another existing WG is sufficient? Well, there are a number of potential discussion places: * The current DoS and security issues in mobile IP would call for some discussion in that group. * The current DoS issues for some of the IPv6 signaling and address autoconfiguration call for some discussion in that group. There's also some autoconfiguration issues in the zeroconf WG. * In the Internet Area, there is the itrace WG which is specifically chartered for looking into DoS, but is looking only at a particular solution. Is this solution sufficient for all DoS issues? We're not sure but at least some of the individual DoS concerns such as attacking address autoconfiguration don't really fall on the area that i-trace can deal with. * The HIP BOF on Tuesday seemed to decide that a new WG will be created to implement new identity mechanisms in IP, in order to deal better with mobility and DoS attacks. * Perhaps a completely new, separate working group might also be a possibility. In any case, we think DoS should get more attention than many of the other issues such as confidentiality and privacy that have been dealt with early. Jari Arkko Pekka Nikander Ericsson ------_=_NextPart_001_01C0B3DA.1E6DF920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DDoS Work

Jari and Pekka,

Thanks for stimulating discussion on this. I too = agree that it should be a high priority and that if we can do something = at the IP layer it should be done. I will also subscribe to the IPTRACE = WG. Clearly there are other forms of attack such as stealing address, = usurping addresses, using all addresses up on a subnet and application = specific methods that should be addressed. I would definitely support = activities that would help educate designers to the possible scenarios = and even try to build specific layering mechanisms to guard against = attacks. With this last meeting, I have seen many new proposals, = especially related to mobility that significantly open up to door to = more DoS attack.

After reviewing the IPTRACE mail list, I have noticed = that many of the stumbing blocks they are faced with are due to the = fact that there is a significant deployment of routers currently out = there and that there is nothing mandated to be built into them to help = facilitate proposed solutions. I believe that the identification of = problem areas i.e. possible DoS attack could be built into IPv6 in a = scalable manner if we are careful.

In beginning the discussion, I would like to bring up = a discussion that occurred earlier this year on the list with Charlie = Perkins, Frank and myself. This discussion is partly stimulated by some = recent product announcements from some vendors on this type of = functionality. I am thinking that perhaps now, since there are more = products available which could be used to deploy the functionality, the = standards discussion might be a bit more open to the = proposals.

I would like to again float the idea that perhaps = some sort of filtering on source address should be mandated on the = first hop. My reasoning on this is that the existing filtering = mechanisms are sort of a pariah i.e. it might be there or it might be = not and we really have no idea where that "there" might be = throughout the network. Clearly, the most scalable and effective place = to do this filtering is on the first hop. Doing it at other points = within the network is not guaranteed to be completely affective as it = may not stop all slaves.

It seems that two mechanisms for these filters have = been proposed. One mechanism is a simple ingress check on an interface. = The other is an exception mechanism that I believe has been coined ACL = access control lists.

The ACL list appears to allow specific addresses or = range of addresses to pass through. It seems to me that if the ACL = lists are used then there might be a glimmer of hope that mobile nodes = could use their home address as source on visited domains and a whole = range of solutions designed with this assumption will be able to be = used with less change.

It seems that when a mobile enters a visited subnet, = the ACL lists could be updated to allow them in as part of neighbor = discovery and AAA operations. Furthurmore, it seems to me that handoff = signaling between domains could provide the trust relationships = necessary to transfer the necessary filter requirement.

The mobility and ACL lists aside, the mandate of just = requiring even the simplist form of ingress filtering on the first hop, = would signifantly improve IPv6's DDoS protection. It might make the job = of Itrace a bit easier, as well, if instead of dropping the packets, = the packets could be tunnelled or flagged in some manner to the = attacked site. There might even be some valid reasons for tunneling the = packet to the spoofed subnet as well in order to alert them that = another node is impersonating it. With these mechanisms in place you = could turn on and off slave monitoring software in the visited sites to = try to surmise the masters and take more action.

Although these other ideas will certainly require = some significant thinking and discussions on scalability etc.., I would = really like people to seriously consider at a minimum just mandating = the simple source address filtering on the first hop in = IPv6.

Another area that I do not see much activity on is = that of DDoS on routers, themselves. Tunneling of router advertisements = is a major new hole that could be exploited. I believe Michael Thomas = has tried to bring this up in the mobile IP WG and I agree with him = that we have to be very careful in doing this sort of thing. I honestly = see no way to safely do this without requiring strong encryption on the = tunnels and extremely tight access authorization. I would like to = stimulate discussion and work on these topics as well.

I think there might also be an issue with = autoconfiguration address schemes. It seems that a rogue node could = depleat all of the available addresses on a subnet if it wished. I'm = hoping I am wrong about this and just have missed something. I beleive = Pekka's 'PBK+ series of hashes' draft points out some other issues as = well.

As others should be able to see by the mail list = activity it may be a significant amount of bandwidth discussing these = issues. The intent of my first mail was to politely ask the question to = the chairs, "Do you want this bandwidth on this list at this time = or would you rather have it separated. Perhaps you may wish to simply = have a separate mailing list for organizational purposes?". I = don't think we need or want another WG unless we want to do these = application centric frameworks.

Thanks to all,

Glenn




-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Thursday, March 22, 2001 9:52 AM
To: Morrow, Glenn [RICH2:C330:EXCH]; = ipng@sunroof.eng.sun.com
Cc: pekka.nikander@nomadiclab.com; = ietf-itrace@research.att.com
Subject: Re: DDoS Work



Glenn Morrow wrote in the IPv6 mailing list:

 >Is this the appropriate group to discuss = possible improvements
 >to detection, prevention, reporting and = action against DoS
 >and DDoS attack for IPv6?
 >
 >It seems to me that perhaps a less = constrained set of
 >mechanisms could be put in place to more = effectively
 >deal with the issue than in IPv4. It may = also be possible
 >to better harmonize these solutions with = proposed node
 >mobility, renumbering and multihoming = solutions.

We believe addressing DoS and DDoS concerns should be = a
high priority.

One idea we have played with is a = general-purpose
IP-layer DoS protection scheme, applicable to = both
existing and new protocols. For instance, servers = could
use a combination of additional packet = roundtrips,
client-stored state, and cryptographic puzzles = to
prevent resource starvation, requests from = forged
source addresses, and massive request generation = from
distributed clients. Today, people seem to be = hoping
that the application protocols do this by
themselves. And, frankly, we're not doing a very = good
job at that. Most protocols, even security = protocols,
are known to have DoS problems that would have = been
possible to solve, had more attention be paid to = them
in the design work.

The question is, is there something that could be = done
as a general support in IP (IPv6) for this? Such = as
ICMP mechanisms that demand puzzle solving from = a
client before proceeding etc. Needless to say, = these
mechanisms shouldn't create additional DoS
possibilities.

At this time we are not sure what the mechanisms = in
detail could be, whether they work on the IP layer = or
if they are reusable protocol components integrated = to
application protocols (a la SSL), or whether it = is
possible to avoid additional DoS dangers. Or if = we
just need a protocol designer's guide that = explains
how new protocols must deal with DoS attacks.

 >Would people recommend a new WG to deal = with
 >these particulars or do people feel that = this
 >or another existing WG is = sufficient?

Well, there are a number of potential discussion = places:

* The current DoS and security issues in mobile IP = would
   call for some discussion in that = group.
* The current DoS issues for some of the IPv6 = signaling
   and address autoconfiguration call for = some discussion
   in that group. There's also some = autoconfiguration
   issues in the zeroconf WG.
* In the Internet Area, there is the itrace WG which = is
   specifically chartered for looking into = DoS, but is
   looking only at a particular solution. = Is this
   solution sufficient for all DoS issues? = We're not sure
   but at least some of the individual DoS = concerns such
   as attacking address autoconfiguration = don't really
   fall on the area that i-trace can deal = with.
* The HIP BOF on Tuesday seemed to decide that = a
   new WG will be created to implement new = identity
   mechanisms in IP, in order to deal = better with
   mobility and DoS attacks.
* Perhaps a completely new, separate working group = might
   also be a possibility.

In any case, we think DoS should get more = attention
than many of the other issues such as = confidentiality
and privacy that have been dealt with early.

Jari Arkko
Pekka Nikander
Ericsson

------_=_NextPart_001_01C0B3DA.1E6DF920-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 18:20:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O2KSIm027597 for ; Fri, 23 Mar 2001 18:20:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O2KRdD027596 for ipng-dist; Fri, 23 Mar 2001 18:20: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O2JsIm027589 for ; Fri, 23 Mar 2001 18:19:55 -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 SAA29360 for ; Fri, 23 Mar 2001 18:19:54 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA15119 for ; Fri, 23 Mar 2001 18:19:53 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA01547; Fri, 23 Mar 2001 18:20:14 -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 ADB52961; Fri, 23 Mar 2001 18:19:49 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA01634; Fri, 23 Mar 2001 18:19:49 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15036.1093.630065.473040@thomasm-u1.cisco.com> Date: Fri, 23 Mar 2001 18:19:49 -0800 (PST) To: "Christian Huitema" Cc: "Vladislav Yasevich" , "George Tsirtsis" , Subject: Sites with multiple border routers (not just 6to4) In-Reply-To: References: 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 Christian -- I sent a note a while ago while the mip list was suffering melt down which brought up two other issues with RPF checks. The first one is that stationary hosts behind a mobile router would naively place their home address in the source and assumedly fail RPF checks as well. The second thing I brought up is that an RSVP reservation in the direction of MN->CN on a change of CoA would require that the filterspec for the reservation be propogated clear back to CN rather than the converging locally as you would hope for. For these reasons, I think that it is worth considering whether the Home Address destination option and most especially RPF checks as currently constituted are such a great idea. There is, perhaps, the larger issue of host identity to consider as well. Mike Christian Huitema writes: > This conversation originated in Sigtran, but this is really about the > IPv6 routing architecture, so I bring it to IPNGWG. The initial context > was the handling of a site with multiple "6to4" routers. > > > From: Vladislav Yasevich [mailto:vlad@zk3.dec.com] > >... > > However, I still don't see a need for a special address for > > 6to4 routers. The DSTM mechanism can provide the TEP and > > it might as well provide the 6to4 address of the router (not > > any speciall address). > > If there is a need, this need is independent of 6to4. It relates to > "egress control" and v6 multi-homing. Suppose that a site is > multi-homed. Each station gets several IPv6 addresses. For a given TCP > connection, it picks one of them as source addresses. As packets are > sent, the egress router is chosen as a function of the destination > address, independent of the source address. This means that we can see > packets flowing through ISP-A, using a source address allocated by > ISP-B. > > The only problem with that is, what happens if ISP-A, in the name of > protection against source-address spoofing, rejects these packets? > > -- Christian Huitema > > > May be DSTM might be extended to privide multiple TEPs and > > let the implementation choose one (or cycle through them)? > > Just a thought. This way we don't have to reserve a speciall > > address. > > > > -vlad > > > > George Tsirtsis wrote: > > > > > > -----Original Message----- > > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > > Sent: Friday, March 23, 2001 10:50 AM > > > To: itojun@iijlab.net > > > Cc: Vladislav Yasevich; George Tsirtsis; NGTRANS List > > > Subject: RE: (ngtrans) Sites with multiple 6to4 border routers > > > > > > > >> I believe that's what Brian Carpenter, Tony Hain, and Dave > Thaler > > > were > > > > >> saying the meeting. You have to use a globaly IPv4 address to > > > > >> create a 6to4 prefix. I don't beleave you can assign the same > IPv4 > > > > >> address to 2 independent devices... > > > > >Uh? There is nothing impossible there. Suppose that we have a > > > > >multi-homed site that connects to the Internet through multiple > > > routers, > > > > >both of which advertise the same IPv4 prefix, say 123.123.1/23. > > > > > > > > i guess you are talking about different thing from Vladislav > > > said: > > > > > > > > > /-------\ /------ > > > > > | | +-+ | > > > > > | +-+A+---------------+ > > > > > | | +-+ | > > > > > | Site | | Internet > > > > > | | +-+ | > > > > > | +-+B+---------------+ > > > > > | | +-+ | > > > > > \-------/ \----- > > > > > > No. When I say that "It is quite natural to reserve a single IPv4 > > > address for the 6to4 routing service", I mean that A and B both use > > > 2002:xxxx:xxxx::/48; both A and B use x.x.x.x. They advertise > different > > > addresses in the IPv6 cloud; they advertise the same IPv4 prefix > (say > > > x.x.x/24) to the Internet; the routing of outward bound packets is > > > determined by IPv6 routing inside the site, e.g. RIPng; the routing > of > > > packets from the Internet is determined by Internet routing > protocols > > > (e.g. BGP). > > > > > > GT> Indeed! The requirement for 2 or more 6to4 gates to be able to > use > > the > > > same 6to4 prefix is that they advertise the same ipv4 prefix in the > IPv4 > > > Internet. Up to now it has been assumed that they only advertise a > > single > > > IPv4 address but this is clearly not necessary. > > > > > > GT> In this case, mechanisms that require outgoing and incoming > paths to > > be > > > using the same 6to4 gate could make use of Alain's 6to4 designated > > address. > > > > > > George > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 23 19:17:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O3HiIm027676 for ; Fri, 23 Mar 2001 19:17:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O3Hda2027674 for ipng-dist; Fri, 23 Mar 2001 19:17: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O3HFIm027658 for ; Fri, 23 Mar 2001 19:17:15 -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 TAA05853 for ; Fri, 23 Mar 2001 19:17:11 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14744 for ; Fri, 23 Mar 2001 19:17:10 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id A28FC1E0C7; Fri, 23 Mar 2001 22:17:05 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id WAA18931; Fri, 23 Mar 2001 22:17:03 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 87CA035DC2; Fri, 23 Mar 2001 18:33:11 -0600 (CST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Robert Stone Cc: jari.arkko@piuha.net, gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Mar 2001 18:31:26 -0600 Message-Id: <20010324003311.87CA035DC2@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20010323164140.H23081@huron.arbor.net>, Robert Stone writes: >On Thu, Mar 22, 2001 at 10:17:21AM -0600, Steven M. Bellovin wrote: >> That said, an RFC that discussed DoS avoidance strategies would be >> a good idea. I'm agnostic about whether that should be done in a >> WG or as an individual submission, but BCP status would be a good >> one to aim for. How this process should be organized is up to the >> AD's and the IESG. (Also note that the next rev of draft-rescorla-sec-cons >> has a good section on DoS attacks.) > >For what it's worth, the following document could provide a starting point: > >http://www.cert.org/reports/dsit_workshop-final.html > >It provides some specific recommendations, but is too vague in some areas >and is, perhaps, a little out-of-date. > That report is specific to bandwidth-consumption attacks. I was suggesting a broader document for protocol designers that discussed CPU attacks, memory attacks, spoofing, black hole creation, etc., as well as design principles for minimizing or preventing such problems. For example, by not creating state until the third message of a four-way handshake, you minimize the chance of memory consumption attacks via spoofed IP addresses. (SCTP does that.) On the other hand, although cryptography is a powerful tool against intrusions, it can be expensive; an enemy might try to force you do do more cryptographic calculations. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 20:09:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O49EIm027708 for ; Fri, 23 Mar 2001 20:09:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O49EDP027707 for ipng-dist; Fri, 23 Mar 2001 20:09: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O495Im027700 for ; Fri, 23 Mar 2001 20:09:05 -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 UAA13043 for ; Fri, 23 Mar 2001 20:09:04 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25346 for ; Fri, 23 Mar 2001 20:09:03 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id UAA16000; Fri, 23 Mar 2001 20:07:48 -0800 (PST) Received: from [10.83.97.214] (rtp-dial-1-214.cisco.com [10.83.97.214]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAH23539; Fri, 23 Mar 2001 20:08:52 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> References: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> Date: Fri, 23 Mar 2001 20:08:43 -0800 To: "Paul Francis" From: Steve Deering Subject: Re: what is a site??? Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:11 AM -0800 3/23/01, Paul Francis wrote: >When I presented the near-unique stuff in IETF50 yesterday, Deering stated >from the mike that a site is a location in space (geographical region, >whatever...I don't remember Steve's exact wording). This had me totally >baffled---and it isn't fun to be baffled in front of a couple hundred >people. Sorry, Paul. It is not at all your fault that you didn't know what this amorphous "site" thing is, and I apologize for blindsiding you in the meeting. (Though I *was* hoping to blindside you with the flaw I found in your proposal, but you deprived my of that pleasure by discovering it yourself. :-) The lack of a proper description and common understanding of what "sites" are is indeed a serious oversight (no pun intended). I sort of assumed that people would understand what was intended from the normal English meaning of the word "site", as in building site or job site. But that was clearly a flawed assumption on my part. Perhaps the more recent jargon term "web site" has muddied the connotation? >I could continue to wade through IPv6 specs to find the definition of site. >But at this point I don't think the onus is on me to do so. Rather Steve I >think the burden is on you to point me to this illusive piece of text that >defines what a site is. The "IP Version 6 Scoped Address Architecture" draft, the most recent version of which is draft-ietf-ipngwg-scoping-arch-02.txt, contains the best definition so far, buried in an itemized list of the three unicast scopes (in Section 4): o Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site). I have a hunch that you, and probably many others, will still find this description less than satisfying, preferring a simple, concrete rule for defining a site, but perhaps you can at least get a glimmer of the general notion that has been mostly buried in my mind and inadequately documented so far. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 20:29:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O4TZIm027730 for ; Fri, 23 Mar 2001 20:29:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O4TZAo027729 for ipng-dist; Fri, 23 Mar 2001 20:29: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O4TQIm027722 for ; Fri, 23 Mar 2001 20:29:26 -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 UAA25170 for ; Fri, 23 Mar 2001 20:29:25 -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 UAA25389 for ; Fri, 23 Mar 2001 20:29:24 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id UAA18256; Fri, 23 Mar 2001 20:28:09 -0800 (PST) Received: from [10.83.97.214] (rtp-dial-1-214.cisco.com [10.83.97.214]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAH23600; Fri, 23 Mar 2001 20:29:21 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4301A0219D@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E4301A0219D@crchy271.us.nortel.com> Date: Fri, 23 Mar 2001 20:29:12 -0800 To: "Glenn Morrow" From: Steve Deering Subject: RE: DDoS Work Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:44 PM -0600 3/23/01, Glenn Morrow wrote: >The intent of my first mail was to politely ask the question to >the chairs, "Do you want this bandwidth on this list at this time >or would you rather have it separated. Perhaps you may wish to >simply have a separate mailing list for organizational purposes?". Glenn, This chair has no objection to discussing, on this list, IPv6-specific techniques or mechanisms for foiling denial-of-service attacks. If the discussion becomes too voluminous or wanders far from IPv6 relevance, we can then think about where best to move it. On the other hand, if there is already another list perfectly suited to such a discussion, it would make sense to take it there now. If you do that, please send to this list a pointer, so those who are interested in the topic can subscribe to that other list. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 22:07:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O67TIm027808 for ; Fri, 23 Mar 2001 22:07:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O67TES027807 for ipng-dist; Fri, 23 Mar 2001 22:07:29 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O67IIm027800 for ; Fri, 23 Mar 2001 22:07:18 -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 WAA21514 for ; Fri, 23 Mar 2001 22:07:17 -0800 (PST) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA19912 for ; Fri, 23 Mar 2001 22:07:05 -0800 (PST) Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm43abc5a9a; Sat, 24 Mar 2001 05:59:13 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm33abbabf4; Fri, 23 Mar 2001 14:55:06 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA17032 for ietf-123-outbound.02@ietf.org; Fri, 23 Mar 2001 08:15:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA16791 for ; Fri, 23 Mar 2001 08:02:11 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08780; Fri, 23 Mar 2001 08:02:09 -0500 (EST) Message-Id: <200103231302.IAA08780@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-dns-discovery-01.txt Date: Fri, 23 Mar 2001 08:02:09 -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 IPNG Working Group of the IETF. Title : Analysis of DNS Server Discovery Mechanisms for IPv6 Author(s) : D. Thaler Filename : draft-ietf-ipngwg-dns-discovery-01.txt Pages : 43 Date : 22-Mar-01 There are any number of ways that IPv6 hosts can discover information required to enable name resolution, in the absence of a DHCP server. This document discusses the issues and provides a taxonomy of possible solutions, and evaluates them against various design criteria. Finally, it provides recommendations as input to the standards process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-01.txt 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-dns-discovery-01.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-dns-discovery-01.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: <20010322122025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-discovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-discovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010322122025.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 Mar 23 23:29:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O7TZIm027936 for ; Fri, 23 Mar 2001 23:29:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O7TZ2W027935 for ipng-dist; Fri, 23 Mar 2001 23:29: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O7TOIm027928 for ; Fri, 23 Mar 2001 23:29:24 -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 XAA08956 for ; Fri, 23 Mar 2001 23:29:19 -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 XAA01952 for ; Fri, 23 Mar 2001 23:29:18 -0800 (PST) Received: from localhost (shuttle.wide.toshiba.co.jp [202.249.10.124]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA10303; Sat, 24 Mar 2001 16:29:59 +0900 (JST) Date: Sat, 24 Mar 2001 01:54:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: horape@tinuviel.compendium.net.ar Cc: ipng@sunroof.eng.sun.com Subject: Re: code for IPv6 or for AF independence In-Reply-To: <20010322021532.A16607@tinuviel.compendium.net.ar> References: <20010322021532.A16607@tinuviel.compendium.net.ar> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 22 Mar 2001 02:15:32 -0300, >>>>> horape@tinuviel.compendium.net.ar said: > After some discussions in the Debian IPv6 project I'm coming here > to hear this wg's opinion about what should "normal application" > programmers do? > By "normal application" I mean those that don't need to know what > network protocol is being used in the communication (telnet, smtp, > pop, etc, could run over tcp/ipv4, tcp/ipv6, tcp/ipx or any other > stream protocol with no changes) > Should we program for AF independence (using getaddrinfo/getnameinfo) > or for IPv6 (and relying in IPv4 mapped addresses for compatibility) I'd personally like the AF-independent style, and I believe it is the working group consensus as well, at least for clients (i.e. active open) side. However, for the server side (i.e. passive open), there are several opinions. Some people argue that the AF-independent style is still better, because of its flexbility and simplicity of access actrol. Some other people argue that using mapped addresses is better for porting existing IPv4-only applications with as less effort as possible. 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 Sat Mar 24 01:20:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O9KbIm028018 for ; Sat, 24 Mar 2001 01:20:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O9KaFV028017 for ipng-dist; Sat, 24 Mar 2001 01:20: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O9KPIm028010 for ; Sat, 24 Mar 2001 01:20: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 BAA01314 for ; Sat, 24 Mar 2001 01:20:15 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17102 for ; Sat, 24 Mar 2001 02:20:10 -0700 (MST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HN9JP5LP; Sat, 24 Mar 2001 10:20:08 +0100 Reply-To: From: "Thomas Eklund" To: "'Glenn Morrow'" , , Cc: Subject: RE: DDoS Work Date: Sat, 24 Mar 2001 10:20:02 +0100 Message-ID: <31A473DBB655D21180850008C71E251A0344D973@mail.kebne.se> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <31A473DBB655D21180850008C71E251A042BC6D6@mail.kebne.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn, the concerns you raise I think we have addressed in our draft (draft-perkins-aaav6-03.txt) > I would like to again float the idea that perhaps some sort > of filtering > on source address should be mandated on the first hop. If you look at ou AAA for IPv6 we have a mechanism to intercept ND and to have an access control towards your AAA server. What we then discuss in the draft are possible ways to update your packet filters (ACL) for that authenticated IPaddress and authorized services (TCP and UDP port numbers) autmatically in the access router. Personally I think that the draft lays out a very nice foundation for access control and automatically updating you ingress filters in the access. Please read it and comment it. Do you agree with the basic approach or do you mean something else? > My reasoning on > this is that the existing filtering mechanisms are sort of a > pariah i.e. > it might be there or it might be not and we really have no idea where > that "there" might be throughout the network. Clearly, the > most scalable > and effective place to do this filtering is on the first hop. Doing it > at other points within the network is not guaranteed to be completely > affective as it may not stop all slaves. Exactly. The draft shows that. > > It seems that two mechanisms for these filters have been proposed. One > mechanism is a simple ingress check on an interface. The other is an > exception mechanism that I believe has been coined ACL access control > lists. > > The ACL list appears to allow specific addresses or range of addresses > to pass through. It seems to me that if the ACL lists are used then > there might be a glimmer of hope that mobile nodes could use > their home > address as source on visited domains and a whole range of solutions > designed with this assumption will be able to be used with > less change. There is no need for that. You tie it to the AAA infrastructure the mobile node could use its new CoA after it has been trough the access control on the new network, which means that the autoconfigured CoA it gets is authenticated (which is done in the AAA server). > > It seems that when a mobile enters a visited subnet, the ACL > lists could > be updated to allow them in as part of neighbor discovery and AAA > operations. This is what the draft do. > Although these other ideas will certainly require some significant > thinking and discussions on scalability etc.., I would really like > people to seriously consider at a minimum just mandating the simple > source address filtering on the first hop in IPv6. As I said see at our draft where we have a discussion about it. -- thomas eklund -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 24 06:56:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2OEuYIm028280 for ; Sat, 24 Mar 2001 06:56:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2OEuYGX028279 for ipng-dist; Sat, 24 Mar 2001 06: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2OEuNIm028272 for ; Sat, 24 Mar 2001 06:56: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 GAA00109 for ; Sat, 24 Mar 2001 06:56:23 -0800 (PST) Received: from buddha.automagic.org ([207.61.141.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA21271 for ; Sat, 24 Mar 2001 06:56:23 -0800 (PST) Received: (qmail 32604 invoked by uid 100); 24 Mar 2001 14:56:21 -0000 Date: Sat, 24 Mar 2001 09:56:21 -0500 From: Joe Abley To: Paul Francis Cc: ipng@sunroof.eng.sun.com Subject: Re: what is a site??? Message-ID: <20010324095621.F12301@buddha.home.automagic.org> References: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org>; from paul@francis.com on Fri, Mar 23, 2001 at 08:11:05AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Mar 23, 2001 at 08:11:05AM -0800, Paul Francis wrote: > When I presented the near-unique stuff in IETF50 yesterday, Deering stated > from the mike that a site is a location in space (geographical region, > whatever...I don't remember Steve's exact wording). This had me totally > baffled---and it isn't fun to be baffled in front of a couple hundred > people. Steve's reference notwithstanding, I don't really understand why it helps to have a site defined in (admittedly vague) geographic terms, as opposed to referring only to network topology. Seems to me that the geographic reference just adds confusion, since there will always be cases where it is perfectly legitimate to consider a network which spans cities (or countries, or continents) a single site. The fact that the majority of sites might fit within a single building or residence only seems relevant if there is some technical reason for delineating a subnetwork based on geography (and if there is, I'm not seeing it :) Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 24 15:10:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ONA3Im028638 for ; Sat, 24 Mar 2001 15:10:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ONA24r028637 for ipng-dist; Sat, 24 Mar 2001 15:10: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ON9iIm028622; Sat, 24 Mar 2001 15:09:45 -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 PAA21552; Sat, 24 Mar 2001 15:09:46 -0800 (PST) Received: from starfruit.itojun.org (p205.usslc10.stsn.com [63.161.205.205]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27514; Sat, 24 Mar 2001 15:09:44 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 09ED67E77; Sun, 25 Mar 2001 08:09:37 +0900 (JST) Date: Sun, 25 Mar 2001 08:09:36 +0900 From: Jun-ichiro itojun Hagino Subject: IETF50 terminal cluster IPv6 usage Message-Id: <20010324230937.09ED67E77@starfruit.itojun.org> To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- Blind-Carbon-Copy To: ietf@ietf.org Subject: IETF50 terminal cluster IPv6 usage X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Sun, 25 Mar 2001 08:09:36 +0900 Sender: itojun@itojun.org http://www.kame.net/ietf50/ has all statistics gathered during IETF50 IPv6 terminal cluster operation. highlights include: - 7-8% of laptops are IPv6-aware (respond to IPv6 ping) - there seem to be 10+ machines who have configured their machine to be IPv6-only (using IPv6-to-IPv4 translator) Thanks go to Lucent term cluster team, and all people helped IPv6 network configurations/operations. I really hope IPv6 connectivity to be officially provided, at IETF51. itojun ------- End of Blind-Carbon-Copy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 24 22:50:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2P6oNIm028905 for ; Sat, 24 Mar 2001 22:50:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2P6oMuS028904 for ipng-dist; Sat, 24 Mar 2001 22:50:22 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2P6oBIm028897 for ; Sat, 24 Mar 2001 22:50:12 -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 WAA18758 for ; Sat, 24 Mar 2001 22:50:11 -0800 (PST) From: Anssi.Porttikivi@teleware.fi Received: from twnt0.teleware.fi (host013.teleware.fi [193.65.76.13] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25221 for ; Sat, 24 Mar 2001 22:50:10 -0800 (PST) Received: by weboffice.teleware.fi with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Mar 2001 09:50:17 +0300 Message-ID: <111D42604E7BD311897B00902755514A3398A8@weboffice.teleware.fi> To: ipng@sunroof.eng.sun.com Subject: site = organization = /48? Date: Sun, 25 Mar 2001 09:50:11 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Am I completely wrong, if I think, that in practice site-local and organization-local will often both mean the same thing: /48, i.e. one network of subnetworks identified with the 16-bit extensions? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 24 23:54:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2P7suIm029026 for ; Sat, 24 Mar 2001 23:54:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2P7suW2029025 for ipng-dist; Sat, 24 Mar 2001 23:54: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2P7slIm029018 for ; Sat, 24 Mar 2001 23:54:47 -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 XAA16829 for ; Sat, 24 Mar 2001 23:54:48 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA16524 for ; Sat, 24 Mar 2001 23:54:46 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id HA18460; Sun, 25 Mar 2001 17:54:34 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Steve Deering Cc: "Paul Francis" , ipng@sunroof.eng.sun.com Subject: Re: what is a site??? In-Reply-To: Your message of "Fri, 23 Mar 2001 20:08:43 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Mar 2001 17:54:33 +1000 Message-Id: <18446.985506873@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 23 Mar 2001 20:08:43 -0800 From: Steve Deering Message-ID: | I have a hunch that you, and probably many others, will still find this | description less than satisfying, preferring a simple, concrete rule for | defining a site, but perhaps you can at least get a glimmer of the | general notion that has been mostly buried in my mind and inadequately | documented so far. I find it less than satisfying, but not for that reason, in fact, for exactly the opposite reason, that definition is far too precise. A site should be whatever I want it to be. About the only requirement should be that it is internally connected (somehow, including using tunnels). No more than that is needed - it is just a collection of nodes that the administrator defines are a site, and then configures the routers at the borders of the collection of nodes to mark them as site boundary routers. I can't imagine why any relationship with buildings, geography, campuses, or anything else like that should be necessary - they add nothing. Just as the routing architecture, etc, don't impose any requirements on just what the thing is that gets a /48 routing prefix, beyond that it needs to be a connected network, we also don't need any specific definition of what is a site - all that can possibly do is to constrain thinking into the future. 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 Sun Mar 25 04:57:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PCvNIm029262 for ; Sun, 25 Mar 2001 04:57:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PCvNjx029261 for ipng-dist; Sun, 25 Mar 2001 04:57: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PCvDIm029254 for ; Sun, 25 Mar 2001 04:57:13 -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 EAA27861 for ; Sun, 25 Mar 2001 04:57:12 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA09320 for ; Sun, 25 Mar 2001 04:57:11 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 5B94E72543; Sun, 25 Mar 2001 15:57:09 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 250A2BA08; Sun, 25 Mar 2001 15:57:08 +0300 (EEST) Message-ID: <3ABDEC51.8D5AF4BC@nomadiclab.com> Date: Sun, 25 Mar 2001 07:02:09 -0600 From: Pekka Nikander X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, ietf-itrace@research.att.com Subject: Source addresses, DDoS prevention and ingress filtering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One point that has came up several times, in various forms, in the DDoS discussion is the idea of mandating some sort of source address filtering, ingress filter, PRF of whatever it is called. For example, Glenn Morrow expressed it as follows: > I would like to again float the idea that perhaps some sort > of filtering on source address should be mandated on the first hop. Let me try to explain why I _think_ that source address filtering is a bad idea, and what I _think_ that should be done instead. This is a lenghty message since I need to go quite deep into the basics before I get to the point; my apologies. To clarify, I am not trying to take sides, and I don't have any personal _opinion_ on this issue, at least not yet :-) I am sure that some of my points have been raised several times before, but here we go anyway. This message is divided in three parts: A. Discussion about source address filtering B. A comparison between source and destination addresses C. My thoughts what should be done instead A. Discussion about source address filtering Now, according to my analysis, currently there are basically three functional reasons for including the source address into IPv6 packets. 1. Source addresses are needed to be able to reply to packets, such as unconnected UDP queries or TCP SYN packets. 2. Source addresses are needed to be able to report back error conditions, e.g., ICMP Packet Too Big. 3. Source addresses are used for identifying upper layer endpoints, e.g., to differentiate between TCP sockets. It is instructive to note that in the two first cases the source address is really needed, but in the last case it is merely a convenient piece of information that could be easily replaced with something else identifying the remote endpoint (compare e.g. to HIP). Now, mandating source address filtering attempts to add another purpose for the source address; a purpose that I don't believe could ever be really reliable. 4. Source addresses identify the interface through which the packet was originated. (FALSE) Maybe this was the original intention of the source address, but to me it seems like the infrastructure has never really supported this allusion. Furthermore, it is instructive to note that even with honest nodes the source addess does not always identify the sender. For example, some neighbour solicitation packets carry the unspecified source address, etc. Furthermore, even strict and mandatory ingress filtering does not quite achieve the maxim -- if the filtering was perfect, it would at most lead to a situation where the source address identifies the source link of the packet, not the specific interface at the link. Even further, I think that there are several reasons why even trying to achieve this illusion is a bad idea. a) Since source address filtering would be a piece of functionality whose malfunction does not have any immediate local effects, I have hard time believing that we would ever get even 90% coverage. b) Taking the trend described at the open plenary on Wednesday evening, i.e. internet turning more and more into a densely connected mesh instead of being more-or-less hierarchical tree, employing source address filtering in any other place but the ingress router would be quite hard operationally, and hard even at the ingress routers. We have already seen this in the various multihoming discussions. c) Being mandated (but not working properly), it would encourage people to trust the source address even more that they do today. B. Comparison between source and destination addresses IMHO, on instructive point of view is to compare the functions of the source and destination addresses. Most people seem to believe, perhaps even unconsciously, that source and destination addresses are functionally equivalent. That is, it seems to be common thinking that the destination address identifies the destination interface(s) of the packet and the source address identifies the source interface of the packet. As we know, this is not true. Now, the question is whether we should aim to make it true again (if it ever was) or should we abandon that thinking altogether. Let us consider the semantics in detail. The destination address has semantical meaning to the routing system. We rely on the integrity of routing information in order to get the packets to their intended recipients. This is inherent in the nature of the routing system. That is, the destination address or at least the routing part of the destination address must be "correct" for the packet ever have any changes to get delivered. The source address does not (currently) have any such semantics. It is just set by the sender, and used by the receiver. The only case when an intermediate router cares about it is when it wants to send an error report back. However, this latter practice does not seem to be such a good idea, since the source address does not necessarily carry information about the real sender of the packet. In short, the practise greatly eases reflection DDoS attacks, since you can fairly easily employ many of the routers in the infrastructure to act as reflectors. (Just mix routing headers and hop-by-hop options.) Furthermore, as I already pointed out, asymmetric routing, multihoming, and mobility are all reasons why the source address should not carry such semantics. To say this in other words, I think that the source address should not be called "source" address but "reply-to" address. That would be more accurate from the semantic point of view, since it merely indicates the sender's request where to send replies instead of identifying the real source of the address. C. My thoughts what should be done instead I know this is a radical idea and that it is probably too late to propose this, but I think that we should deprecate the source address in the IPv6 header altogether. Instead, we should use a separate destination option, perhaps "Reply-To Address Destination Option", whenever we assume that the recipient may not know where to send the replies. Please note that if we use end-to-end IPsec, we never need to use this option, and that any other TCP packets but the first SYN packet would not need to carry it either. Depracating the source address field from it current use would free it for other purposes. My suggestion is that the main function would be to use it for _recording_ the path of the packet. That is, each router that touches the packet would (perhaps probabilistically) somehow record its identity into the source address field. Thus, the source address field would no longer be a source address field but a source path field. This would have several benefits. First, those that believe in ingress filtering would perhaps be happy with the recorded packet path information. Second, those not believing in ingress filtering would be happy, too, since packets would not have to be dropped. Third, one could easily make the reply-to address private by including the destination option within an ESP header. Fourth, ICMP error reports generated by intermediate routers would be sent along the source path instead of relying on the perhaps false source address. (This might require some modifications to the error reporting functionality, but I think that wouldn't be that hard.) I know that it would be virtually impossible to employ such a drastic change to the architecture at this point. However, maybe this suggestion could work as a source of ideas for some not-so-drastic approach. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 06:24:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PEOBIm029345 for ; Sun, 25 Mar 2001 06:24:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PEOBFQ029344 for ipng-dist; Sun, 25 Mar 2001 06:24: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PENxIm029337 for ; Sun, 25 Mar 2001 06:23:59 -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 GAA02884 for ; Sun, 25 Mar 2001 06:23:59 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28058 for ; Sun, 25 Mar 2001 06:23:58 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 0131B4CE01; Sun, 25 Mar 2001 09:23:57 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id JAA05741; Sun, 25 Mar 2001 09:23:56 -0500 (EST) Received: from berkshire.research.att.com (localhost.research.att.com [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id BE72735C42; Sun, 25 Mar 2001 09:23:55 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Robert Elz Cc: Steve Deering , "Paul Francis" , ipng@sunroof.eng.sun.com Subject: Re: what is a site??? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Mar 2001 09:23:55 -0500 Message-Id: <20010325142355.BE72735C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <18446.985506873@mundamutti.cs.mu.OZ.AU>, Robert Elz writes: > Date: Fri, 23 Mar 2001 20:08:43 -0800 > From: Steve Deering > Message-ID: > > | I have a hunch that you, and probably many others, will still find this > | description less than satisfying, preferring a simple, concrete rule for > | defining a site, but perhaps you can at least get a glimmer of the > | general notion that has been mostly buried in my mind and inadequately > | documented so far. > >I find it less than satisfying, but not for that reason, in fact, for >exactly the opposite reason, that definition is far too precise. > >A site should be whatever I want it to be. About the only requirement >should be that it is internally connected (somehow, including using tunnels). > >No more than that is needed - it is just a collection of nodes that the >administrator defines are a site, and then configures the routers at the >borders of the collection of nodes to mark them as site boundary routers. Yah. I tend to equate "site" with "AS". --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 10:03:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PI3KIm029553 for ; Sun, 25 Mar 2001 10:03:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PI3Kis029552 for ipng-dist; Sun, 25 Mar 2001 10:03: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PI3AIm029545 for ; Sun, 25 Mar 2001 10:03:11 -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 KAA10838 for ; Sun, 25 Mar 2001 10:03:10 -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 KAA08495 for ; Sun, 25 Mar 2001 10:03:10 -0800 (PST) Received: from vaio (as1-20.chi.il.dial.anet.com [198.92.156.20]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA28797; Sun, 25 Mar 2001 12:00:40 -0600 (CST) Message-ID: <007401c0b555$21c3c6a0$df00a8c0@vaio> From: "JIM FLEMING" To: "Steven M. Bellovin" , "Robert Elz" Cc: "Steve Deering" , "Paul Francis" , References: <20010325142355.BE72735C42@berkshire.research.att.com> Subject: Re: what is a site??? Date: Sun, 25 Mar 2001 11:57:58 -0600 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 With IPv8, "site" is defined by the left-most 64-bits of the 128-bit IPv6 address. Those bits are assumed to be a "SITE-ID". The easiest way to obtain a site-id for FREE (without paying ICANN/IETF taxes), is to use a 32-bit IPv4 address. Microsoft supports this with the 2002::0000 format, in time for the 2002 expansion of the IPv8 network, via Windows 2000 (or is it 2002 ?). The right-most 64-bits are the persistent address. They are used to number the hosts/nodes/processes within the site. The SITE-ID can change, depending on routing conditions on the IPv4 transport. The right-most 64-bits change less often because those are managed by the local administrator. In order to prevent collisions in the "management" of the right-most bits, all of the major TLD Communities have been allocated blocks (tax FREE) to manage**. IN-ADDR.[TLD] is used in place of IN-ADDR.ARPA. Using the right-most 64-bits for a managed persistent address, routes around the IPv6 "Privacy Problem". http://www.internetwk.com/columns/frezz100499.htm Jim Fleming http://www.unir.com http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif **http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: "Steven M. Bellovin" To: "Robert Elz" Cc: "Steve Deering" ; "Paul Francis" ; Sent: Sunday, March 25, 2001 8:23 AM Subject: Re: what is a site??? > In message <18446.985506873@mundamutti.cs.mu.OZ.AU>, Robert Elz writes: > > Date: Fri, 23 Mar 2001 20:08:43 -0800 > > From: Steve Deering > > Message-ID: > > > > | I have a hunch that you, and probably many others, will still find this > > | description less than satisfying, preferring a simple, concrete rule for > > | defining a site, but perhaps you can at least get a glimmer of the > > | general notion that has been mostly buried in my mind and inadequately > > | documented so far. > > > >I find it less than satisfying, but not for that reason, in fact, for > >exactly the opposite reason, that definition is far too precise. > > > >A site should be whatever I want it to be. About the only requirement > >should be that it is internally connected (somehow, including using tunnels). > > > >No more than that is needed - it is just a collection of nodes that the > >administrator defines are a site, and then configures the routers at the > >borders of the collection of nodes to mark them as site boundary routers. > > Yah. I tend to equate "site" with "AS". > > > --Steve Bellovin, http://www.research.att.com/~smb > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sun Mar 25 10:46:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PIkwIm029605 for ; Sun, 25 Mar 2001 10:46:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PIkvYd029604 for ipng-dist; Sun, 25 Mar 2001 10:46:57 -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.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PIkkIm029597 for ; Sun, 25 Mar 2001 10:46:46 -0800 (PST) Received: from rouget.sun.com (dsl197-48.Eng.Sun.COM [129.146.197.48]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with ESMTP id f2PIkjxf909704; Sun, 25 Mar 2001 10:46:45 -0800 (PST) Message-Id: <5.0.2.1.0.20010325104313.00ac34e0@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 25 Mar 2001 10:49:58 -0800 To: "Steven M. Bellovin" , Robert Elz From: Alain Durand Subject: Re: what is a site??? Cc: Steve Deering , "Paul Francis" , ipng@sunroof.eng.sun.com In-Reply-To: <20010325142355.BE72735C42@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:23 AM 3/25/2001 -0500, Steven M. Bellovin wrote: >Yah. I tend to equate "site" with "AS". I disagree... A simple view of a site is a corporate network in a building or a campus of buildings. Such sites will not have nor need an AS. However, we could take anything that fit in a /48 and call this a site. I'm not sure that it would be a good idea... - 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 Sun Mar 25 13:51:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PLpqIm029949 for ; Sun, 25 Mar 2001 13:51:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PLppig029948 for ipng-dist; Sun, 25 Mar 2001 13:51:51 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PLphIm029941 for ; Sun, 25 Mar 2001 13:51:43 -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 NAA22505 for ; Sun, 25 Mar 2001 13:51:42 -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 NAA16406 for ; Sun, 25 Mar 2001 13:51:41 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hIOx-0009WH-00; Sun, 25 Mar 2001 13:50:19 -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: what is a site??? References: <18446.985506873@mundamutti.cs.mu.OZ.AU> Message-Id: Date: Sun, 25 Mar 2001 13:50:19 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk so all 's global backbone, aggregation, and servers are one site? 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 Sun Mar 25 14:16:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PMGuIm029991 for ; Sun, 25 Mar 2001 14:16:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PMGtAt029990 for ipng-dist; Sun, 25 Mar 2001 14:16: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PMGbIm029975; Sun, 25 Mar 2001 14:16:37 -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 OAA12204; Sun, 25 Mar 2001 14:16:38 -0800 (PST) Received: from dc.ogud.com (208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com [208.59.114.172]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00848; Sun, 25 Mar 2001 14:16:28 -0800 (PST) Received: from localhost (ogud@localhost) by dc.ogud.com (8.11.2/8.11.2) with ESMTP id f2PMH0E59831; Sun, 25 Mar 2001 17:17:01 -0500 (EST) (envelope-from ogud@ogud.com) Date: Sun, 25 Mar 2001 17:16:55 -0500 (EST) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: namedroppers@ops.ietf.org cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: notes on A6 transition from AAAA (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Included is the "infamus" beer plan, on how to retire AAAA everywhere but stub resolvers. Please send all followup to namedroppers. Olafur (DNSEXT WG co-chair) ps: The peole haching this plan were Mark Andrews, Rob Austein, Alain Durand and Olafur Gudmundsson ---------- Forwarded message ---------- Date: Sun, 18 Mar 2001 20:05:32 -0800 From: Alain Durand To: sra@hactrn.net, ogud@ogud.com Subject: notes on A6 transition from AAAA Transition from AAAA to A6 Stub resolvers that ask for AAAA in queries with the RD bit turn ON will be returned AAAA answers. Resolvers that have send queries with RD bit OFF and ask for AAAA will be returned whatever is available, A6 or AAAA. Note that they SHOULD issues A6 queries in the first place. The entity that in its server role received a query with the RD bit turn ON and process that request in its resolver role issues A6 queries with the RD bit turned OFF is responsible for the systhesis of AAAA from A6 records. This entity MUST try first A6 then MAY try AAAA queries to process the request. A authoritative server that only has AAAA entries and is asked for an A6 record MUST NOT synthesize A6 records from the AAAA ones. There is no restriction on populating both types, but it is strongly recommended against, and in such a case, both RRsets MUST be identical. If a query does not contain EDNS indicator, then any IPv6 addresses contain in additional data section MUST be AAAA. Root and TLD zones MUST only contain A6 with prefix of 0. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 17:02:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2Q12pIm000257 for ; Sun, 25 Mar 2001 17:02:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2Q12pQh000254 for ipng-dist; Sun, 25 Mar 2001 17:02:51 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2Q12fIm000242 for ; Sun, 25 Mar 2001 17:02:41 -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 RAA16244 for ; Sun, 25 Mar 2001 17:02:41 -0800 (PST) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11362; Sun, 25 Mar 2001 17:02:38 -0800 (PST) Received: from duplo.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.3/8.11.3) with ESMTP id f2Q0v2I10713; Mon, 26 Mar 2001 09:57:02 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.2/8.10.2) id f2Q0UfZ01342; Mon, 26 Mar 2001 09:30:41 +0900 (JST) Date: Mon, 26 Mar 2001 09:30:41 +0900 (JST) From: Atsushi Onoe Message-Id: <200103260030.f2Q0UfZ01342@duplo.sm.sony.co.jp> To: Alain.Durand@Sun.COM Cc: smb@research.att.com, kre@munnari.oz.au, deering@cisco.com, francis@tahoenetworks.com, ipng@sunroof.eng.sun.com Subject: Re: what is a site??? In-Reply-To: Your message of "Sun, 25 Mar 2001 10:49:58 -0800" <5.0.2.1.0.20010325104313.00ac34e0@jurassic> References: <5.0.2.1.0.20010325104313.00ac34e0@jurassic> X-Mailer: Cue version 0.6 (010302-0947/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, we could take anything that fit in a /48 and call this a site. > I'm not sure that it would be a good idea... I think it is a good idea, though it cannot be the _definition_ of the "site". IMHO, site-local scope will be used to protect against renumbering, and for the networks not connected to the Internet. For this purpose, some connected networks serapated within a single geographic location _can_ be a . But a is not limited to be an single location. Unlike IPv4 usage of a private address, IPv6 site cannot be nested. So I don't think it is a good idea that you assign a for a too small piece of networks only for the reason that they are geographically isolted. Atsushi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 03:07:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QB7YIm000743 for ; Mon, 26 Mar 2001 03:07:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QB7X1M000742 for ipng-dist; Mon, 26 Mar 2001 03:07:33 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QB7OIm000735 for ; Mon, 26 Mar 2001 03:07:24 -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 DAA29072 for ; Mon, 26 Mar 2001 03:07:23 -0800 (PST) Received: from Yellow.japan-telecom.co.jp (Yellow.japan-telecom.co.jp [210.146.35.35]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11640 for ; Mon, 26 Mar 2001 03:07:22 -0800 (PST) Received: from japan-telecom.co.jp (localhost [127.0.0.1]) by Yellow.japan-telecom.co.jp (3.7W-Yellow) with ESMTP id TAA18967; Mon, 26 Mar 2001 19:53:28 +0900 (JST) Received: (from root@localhost) by japan-telecom.co.jp (3.7W-SP340201) id TAA17343; Mon, 26 Mar 2001 19:59:27 +0900 (JST) Received: from unknown [172.18.82.245] by SP340201.japan-telecom.co.jp with SMTP id VAA17333 ; Mon, 26 Mar 2001 19:59:26 +0900 To: kre@munnari.OZ.AU Cc: deering@cisco.com, francis@tahoenetworks.com, ipng@sunroof.eng.sun.com Subject: Re: what is a site? X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010326195731W.tomohide@japan-telecom.co.jp> Date: Mon, 26 Mar 2001 19:57:31 +0900 From: Tomohide Nagashima X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, >we also don't need any specific definition of >what is a site - all that can possibly do is to constrain thinking into >the future. As I also think we should not constrain concept of site. But I belive we still need some minimun defenition of site, or need some example that show such a set is site or not. For example, how about it? There is a company that has two sets of network in two place. As each network is too far, this company get connectibity from two ISPs( ISP1 has prefixes in TLA1, ISP2 has prefixes in TLA2). And this company want to communicate this two network without Grobal network, this company connect this two network with released line. like this; [TLA1] [TLA2] | | ----- ( NLA1-1 is from TLA1, and NLA2-1 is from TLA2 ) then can we call a set of NLA1-1 and NLA2-1 is a site ? I belive that this set is not a site but two sites. but if we define site is whatever I want it to be, then someone will regard this a set of two networks is a site. ---- Tomohide Nagashima tomohide@japan-telecom.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 Mon Mar 26 05:55:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QDtnIm000892 for ; Mon, 26 Mar 2001 05:55:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QDtnqJ000891 for ipng-dist; Mon, 26 Mar 2001 05:55: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QDtdIm000884 for ; Mon, 26 Mar 2001 05:55:39 -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 FAA24278 for ; Mon, 26 Mar 2001 05:55:40 -0800 (PST) Received: from fw1-b.osis.gov (fw1-b.osis.gov [204.178.104.234]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA22014 for ; Mon, 26 Mar 2001 05:55:39 -0800 (PST) Received: from neptune.jioc.osis.gov by fw1-b.osis.gov with SMTP id IAA16279 (InterLock SMTP Gateway 3.0 for ); Mon, 26 Mar 2001 08:55:37 -0500 Received: by neptune.jioc.osis.gov with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 07:54:47 -0600 Message-Id: From: "SESVOLD, DALE" To: ipng@sunroof.eng.sun.com Subject: RE: what is a site??? Date: Mon, 26 Mar 2001 07:54:46 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B5FC.51ADA500" 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_01C0B5FC.51ADA500 Content-Type: text/plain What ever a site is defined to be one would have the following issues: Distinct: not necessarily uniquely numbered but able to be differentiated from other sites with easily distinquishable routing boundry Routable within: sub-networks to support hierchial structure handle this in the following manner: Distinct: bits 17-48 designate a separate site, can be set using bits 17-48 from globally routeable address assigned to one of the site's networks or by creating a nearly random number as previously proposed on this list. Routeable: bits 49-64 are already designated for subnetting a site. As a Network Administrator I can see the requirement to be able to set up my our intranet routing domain, and would like to know that I will not inadvertantly route out to another site (same designation). An easy way to avert this is to use bits 17-48 for site designation. Beyond this, the loose definition of a site is adequate. DG Ses DALE G SESVOLD Senior Network Engineer MacAulay-Brown, Inc > > However, we could take anything that fit in a /48 and call this a site. > > I'm not sure that it would be a good idea... > > I think it is a good idea, though it cannot be the _definition_ of the > "site". > > IMHO, site-local scope will be used to protect against renumbering, > and for the networks not connected to the Internet. > For this purpose, some connected networks serapated within a single > geographic location _can_ be a . But a is not limited to > be an single location. > > Unlike IPv4 usage of a private address, IPv6 site cannot be nested. > So I don't think it is a good idea that you assign a for a too > small piece of networks only for the reason that they are geographically > isolted. > > Atsushi > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- ------_=_NextPart_001_01C0B5FC.51ADA500 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: what is a site???

What ever a site is = defined to be one would have the following issues:
Distinct:  not = necessarily uniquely numbered but able to be differentiated from other = sites with easily distinquishable routing boundry

Routable = within:  sub-networks to support hierchial structure

handle this in the = following manner:
Distinct:  = bits 17-48 designate a separate site, can be set using bits 17-48 from = globally routeable address assigned to one of the site's networks or by = creating a nearly random number as previously proposed on this = list.

Routeable:  = bits 49-64 are already designated for subnetting a site.

As a Network = Administrator I can see the requirement to be able to set up my our = intranet routing domain, and would like to know that I will not = inadvertantly route out to another site (same designation).  An = easy way to avert this is to use bits 17-48 for site = designation.

Beyond this, the = loose definition of a site is adequate.

DG Ses

DALE G = SESVOLD
Senior Network = Engineer
MacAulay-Brown, = Inc


    > However, we could take anything = that fit in a /48 and call this a site.
    > I'm not sure that it would be a = good idea...

    I think it is a good idea, though it = cannot be the _definition_ of the
    "site".

    IMHO, site-local scope will be used to = protect against renumbering,
    and for the networks not connected to = the Internet.
    For this purpose, some connected = networks serapated within a single
    geographic location _can_ be a = <site>.  But a <site> is not limited to
    be an single location.

    Unlike IPv4 usage of a private = address, IPv6 site cannot be nested.
    So I don't think it is a good idea = that you assign a <site> for a too
    small piece of networks only for the = reason that they are geographically
    isolted.

    Atsushi
    ---------------------------------------------------------= -----------
    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
    ---------------------------------------------------------= -----------

------_=_NextPart_001_01C0B5FC.51ADA500-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 07:00:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QF0OIm001024 for ; Mon, 26 Mar 2001 07:00:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QF0OXm001023 for ipng-dist; Mon, 26 Mar 2001 07:00:24 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QF0EIm001016 for ; Mon, 26 Mar 2001 07:00:14 -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 HAA20832 for ; Mon, 26 Mar 2001 07:00:03 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07898 for ; Mon, 26 Mar 2001 08:00:01 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA08136 for ; Mon, 26 Mar 2001 07:59:59 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA20283 for ; Mon, 26 Mar 2001 07:59:59 -0700 (MST)] Received: from email.mot.com (d50-39be.cig.mot.com [160.47.57.190]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id G3C8KLXN; Mon, 26 Mar 2001 08:59:58 -0600 Message-ID: <3ABF75BC.EF6B51AE@email.mot.com> Date: Mon, 26 Mar 2001 09:00:44 -0800 From: Kevin Wang Reply-To: kwang1@email.mot.com Organization: Motorola X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tomohide Nagashima CC: kre@munnari.OZ.AU, deering@cisco.com, francis@tahoenetworks.com, ipng@sunroof.eng.sun.com Subject: Re: what is a site? References: <20010326195731W.tomohide@japan-telecom.co.jp> Content-Type: multipart/mixed; boundary="------------CCED667EF14C417CA1B0DC03" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------CCED667EF14C417CA1B0DC03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We can consider that in your example there are two Autonomous Systems, and each is a site. Do you mean this? Kevin Tomohide Nagashima wrote: > Hello, > > >we also don't need any specific definition of > >what is a site - all that can possibly do is to constrain thinking into > >the future. > > As I also think we should not constrain concept of site. But I belive we > still need some minimun defenition of site, or need some example that show > such a set is site or not. > > For example, how about it? > > There is a company that has two sets of network in two place. > As each network is too far, this company get connectibity from > two ISPs( ISP1 has prefixes in TLA1, ISP2 has prefixes in TLA2). > And this company want to communicate this two network without > Grobal network, this company connect this two network with > released line. like this; > > [TLA1] [TLA2] > | | > ----- > > ( NLA1-1 is from TLA1, and NLA2-1 is from TLA2 ) > > then can we call a set of NLA1-1 and NLA2-1 is a site ? > > I belive that this set is not a site but two sites. > but if we define site is whatever I want it to be, > then someone will regard this a set of two networks is a site. > > ---- > Tomohide Nagashima > tomohide@japan-telecom.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 > -------------------------------------------------------------------- --------------CCED667EF14C417CA1B0DC03 Content-Type: text/x-vcard; charset=us-ascii; name="kwang1.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Kevin Wang Content-Disposition: attachment; filename="kwang1.vcf" begin:vcard n:Wang;Kuanjing x-mozilla-html:FALSE org:Motorola, Inc.;NAT, NSS adr:;;1501 W. Shure Dr.;Arlington Heights;IL;60004;USA version:2.1 email;internet:kwang1@email.mot.com title:S.E. fn:Kevin Wang end:vcard --------------CCED667EF14C417CA1B0DC03-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 07:02:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QF29Im001036 for ; Mon, 26 Mar 2001 07:02:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QF28A6001035 for ipng-dist; Mon, 26 Mar 2001 07: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QF1tIm001026 for ; Mon, 26 Mar 2001 07:01:55 -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 HAA01967 for ; Mon, 26 Mar 2001 07:01:54 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08926 for ; Mon, 26 Mar 2001 08:01:52 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA04693 for ; Mon, 26 Mar 2001 08:01:51 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA22896 for ; Mon, 26 Mar 2001 08:01:50 -0700 (MST)] Received: from email.mot.com (d50-39be.cig.mot.com [160.47.57.190]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id G3C8KLZR; Mon, 26 Mar 2001 09:01:50 -0600 Message-ID: <3ABF762C.8D0305ED@email.mot.com> Date: Mon, 26 Mar 2001 09:02:36 -0800 From: Kevin Wang Reply-To: kwang1@email.mot.com Organization: Motorola X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tomohide Nagashima CC: kre@munnari.OZ.AU, deering@cisco.com, francis@tahoenetworks.com, ipng@sunroof.eng.sun.com Subject: Re: what is a site? References: <20010326195731W.tomohide@japan-telecom.co.jp> Content-Type: multipart/mixed; boundary="------------1A28A50958DF455A351F6C8A" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------1A28A50958DF455A351F6C8A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We can consider that in your example there are two Autonomous Systems, and each is a site. Do you mean this? Kevin Tomohide Nagashima wrote: > Hello, > > >we also don't need any specific definition of > >what is a site - all that can possibly do is to constrain thinking into > >the future. > > As I also think we should not constrain concept of site. But I belive we > still need some minimun defenition of site, or need some example that show > such a set is site or not. > > For example, how about it? > > There is a company that has two sets of network in two place. > As each network is too far, this company get connectibity from > two ISPs( ISP1 has prefixes in TLA1, ISP2 has prefixes in TLA2). > And this company want to communicate this two network without > Grobal network, this company connect this two network with > released line. like this; > > [TLA1] [TLA2] > | | > ----- > > ( NLA1-1 is from TLA1, and NLA2-1 is from TLA2 ) > > then can we call a set of NLA1-1 and NLA2-1 is a site ? > > I belive that this set is not a site but two sites. > but if we define site is whatever I want it to be, > then someone will regard this a set of two networks is a site. > > ---- > Tomohide Nagashima > tomohide@japan-telecom.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 > -------------------------------------------------------------------- --------------1A28A50958DF455A351F6C8A Content-Type: text/x-vcard; charset=us-ascii; name="kwang1.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Kevin Wang Content-Disposition: attachment; filename="kwang1.vcf" begin:vcard n:Wang;Kuanjing x-mozilla-html:FALSE org:Motorola, Inc.;NAT, NSS adr:;;1501 W. Shure Dr.;Arlington Heights;IL;60004;USA version:2.1 email;internet:kwang1@email.mot.com title:S.E. fn:Kevin Wang end:vcard --------------1A28A50958DF455A351F6C8A-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 07:19:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFJOIm001097 for ; Mon, 26 Mar 2001 07:19:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QFJOT7001096 for ipng-dist; Mon, 26 Mar 2001 07:19: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFJEIm001089 for ; Mon, 26 Mar 2001 07:19:14 -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 HAA05092 for ; Mon, 26 Mar 2001 07:18:53 -0800 (PST) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11436 for ; Mon, 26 Mar 2001 07:18:02 -0800 (PST) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id KAA07928; Mon, 26 Mar 2001 10:17:18 -0500 (EST) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with SMTP id KAA21598; Mon, 26 Mar 2001 10:15:15 -0500 (EST) Date: Mon, 26 Mar 2001 10:15:15 -0500 (EST) From: Greg Maxwell X-Sender: gmaxwell@da1server To: Kevin Wang cc: Tomohide Nagashima , kre@munnari.OZ.AU, deering@cisco.com, francis@tahoenetworks.com, ipng@sunroof.eng.sun.com Subject: Re: what is a site? In-Reply-To: <3ABF75BC.EF6B51AE@email.mot.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, 26 Mar 2001, Kevin Wang wrote: > Hi, > > We can consider that in your example there are two Autonomous Systems, and > each is a site. Do you mean this? I think the best description of a site for these purposes is: "A site and an autotomous system would be the same, however, we are conserned with ASN proliferation and therefor only assign ASNs to ASes which actually require enumeration for the purposes of operating global routing protocols". So a site is a ASN potentially without BGP. This seems to fit togeather the idea of site-locals and the concept of having a unified routing policy within ASes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 07:37:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFbAIm001149 for ; Mon, 26 Mar 2001 07:37:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QFbABw001147 for ipng-dist; Mon, 26 Mar 2001 07:37: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFb0Im001140 for ; Mon, 26 Mar 2001 07:37:01 -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 HAA27104 for ; Mon, 26 Mar 2001 07:37:00 -0800 (PST) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA10593 for ; Mon, 26 Mar 2001 07:36:59 -0800 (PST) Received: (cpmta 12478 invoked from network); 26 Mar 2001 07:36:59 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.65) with SMTP; 26 Mar 2001 07:36:59 -0800 X-Sent: 26 Mar 2001 15:36:59 GMT Message-ID: <000201c0b60a$8c0d8b80$6501a8c0@smateo1.sfba.home.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Paul Francis" , "Steve Deering" Cc: References: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> Subject: Re: what is a site??? Date: Mon, 26 Mar 2001 01:17:14 -0800 Organization: TAHOE Networks 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 > > Sorry, Paul. It is not at all your fault that you didn't know what > this amorphous "site" thing is, and I apologize for blindsiding you > in the meeting. (Though I *was* hoping to blindside you with > the flaw I found in your proposal, but you deprived my of that > pleasure by discovering it yourself. :-) The latter would've been ok. One deserves to be blindsided with ones own flaws. I think it wasn't so much the blindsiding that bothered me, but the fact that, unknown to me at the time, you continued to use the word "site" in its common English sense rather than in the rigorous sense I was assuming. It should have been clear to you that I was attempting to speak in a rigorous sense (like when I suggested that two office networks in two cities connected by a dedicated link with only a single ISP connection surely would be considered a single "site" in the networking sense. Obviously at that point in time we couldn't have been discussing the dictionary meaning of the word "site".) Anyway forget about it...apology appreciated and accepted. Thinking back, I remember you started that thread with the statement that many people equated a site-local with an IPv4 net-10 address, and that this was incorrect. Other than the fact that an individual site-local address has a higher probability of being globally unique because of the EID field, what else is different? I can't re-create your argument in my head. By the way, I can certainly see that nailing down the definition of "site" would be difficult. I think the problem is that we use site in two different contexts: One for "site-local", and the other for SLA (Site Level Aggregator). It is not necessarily the case that the boundaries of a site-local "site" match those of a globally aggregatable SLA "site". In fact, I suspect that if you decoupled the assignment of SLAs for a site-local prefix from that of SLAs for a globally aggregatable prefix, you could in fact achieve smooth renumbering when merging two "sites" (if you had near-unique site-local addresses). But I'll save that for version two of the internet draft. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 07:39:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFdPIm001161 for ; Mon, 26 Mar 2001 07:39:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QFdOZX001160 for ipng-dist; Mon, 26 Mar 2001 07:39: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFdEIm001153 for ; Mon, 26 Mar 2001 07:39:14 -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 HAA02459 for ; Mon, 26 Mar 2001 07:39:14 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA11880 for ; Mon, 26 Mar 2001 07:39:12 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA08540; Tue, 27 Mar 2001 01:38:51 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Tomohide Nagashima Cc: deering@cisco.com, francis@tahoenetworks.com, ipng@sunroof.eng.sun.com Subject: Re: what is a site? In-Reply-To: Your message of "Mon, 26 Mar 2001 19:57:31 +0900." <20010326195731W.tomohide@japan-telecom.co.jp> Date: Tue, 27 Mar 2001 01:38:50 +1000 Message-Id: <29055.985621130@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 26 Mar 2001 19:57:31 +0900 From: Tomohide Nagashima Message-ID: <20010326195731W.tomohide@japan-telecom.co.jp> | As I also think we should not constrain concept of site. But I belive we | still need some minimun defenition of site, or need some example that show | such a set is site or not. Yes, a minimum definition is needed - that is, a site must be internally connected. That's all I would say about it. As presently defined sites cannot overlap, but it isn't at all beyond the realms of possibility that we might want to change that sometime in the future, so I wouldn't even include that in the definition. | I belive that this set is not a site but two sites. | but if we define site is whatever I want it to be, | then someone will regard this a set of two networks is a site. It can be one site, two sites, or N sites, for any value of N >= 0. Take your diagram, and stick the two nets with the two different NLAs in one building (in one room perhaps), rather than a long way apart. Logically the situation is exactly the same, but almost everyone would consider that to be one site. On the other hand, the admins of the company may split it into seperate sites - one for the research dept, one for sales, one for admin, ... Basically, it should be whatever makes sense for the administrators. 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 Mar 26 07:56:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFuBIm001268 for ; Mon, 26 Mar 2001 07:56:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QFuBq4001267 for ipng-dist; Mon, 26 Mar 2001 07:56: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QFtsIm001260 for ; Mon, 26 Mar 2001 07:55: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 HAA10850 for ; Mon, 26 Mar 2001 07:55:54 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06156 for ; Mon, 26 Mar 2001 07:55:52 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 26 Mar 2001 09:46:24 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Mar 2001 09:51:30 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301A63019@crchy271.us.nortel.com> From: "Glenn Morrow" To: "thomas.eklund" , "jari.arkko" , ipng Cc: "pekka.nikander" Subject: RE: DDoS Work Date: Mon, 26 Mar 2001 09:51:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B60C.9C4F7650" X-Orig: 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_01C0B60C.9C4F7650 Content-Type: text/plain; charset="iso-8859-1" Thomas, It will take some time to reply to this. I will certainly take a look. -----Original Message----- From: Thomas Eklund [mailto:thomas.eklund@xelerated.com] Sent: Saturday, March 24, 2001 3:20 AM To: Morrow, Glenn [RICH2:C330:EXCH]; jari.arkko; ipng Cc: pekka.nikander Subject: RE: DDoS Work Glenn, the concerns you raise I think we have addressed in our draft (draft-perkins-aaav6-03.txt) > I would like to again float the idea that perhaps some sort > of filtering > on source address should be mandated on the first hop. If you look at ou AAA for IPv6 we have a mechanism to intercept ND and to have an access control towards your AAA server. What we then discuss in the draft are possible ways to update your packet filters (ACL) for that authenticated IPaddress and authorized services (TCP and UDP port numbers) autmatically in the access router. Personally I think that the draft lays out a very nice foundation for access control and automatically updating you ingress filters in the access. Please read it and comment it. Do you agree with the basic approach or do you mean something else? > My reasoning on > this is that the existing filtering mechanisms are sort of a > pariah i.e. > it might be there or it might be not and we really have no idea where > that "there" might be throughout the network. Clearly, the > most scalable > and effective place to do this filtering is on the first hop. Doing it > at other points within the network is not guaranteed to be completely > affective as it may not stop all slaves. Exactly. The draft shows that. > > It seems that two mechanisms for these filters have been proposed. One > mechanism is a simple ingress check on an interface. The other is an > exception mechanism that I believe has been coined ACL access control > lists. > > The ACL list appears to allow specific addresses or range of addresses > to pass through. It seems to me that if the ACL lists are used then > there might be a glimmer of hope that mobile nodes could use > their home > address as source on visited domains and a whole range of solutions > designed with this assumption will be able to be used with > less change. There is no need for that. You tie it to the AAA infrastructure the mobile node could use its new CoA after it has been trough the access control on the new network, which means that the autoconfigured CoA it gets is authenticated (which is done in the AAA server). > > It seems that when a mobile enters a visited subnet, the ACL > lists could > be updated to allow them in as part of neighbor discovery and AAA > operations. This is what the draft do. > Although these other ideas will certainly require some significant > thinking and discussions on scalability etc.., I would really like > people to seriously consider at a minimum just mandating the simple > source address filtering on the first hop in IPv6. As I said see at our draft where we have a discussion about it. -- thomas eklund ------_=_NextPart_001_01C0B60C.9C4F7650 Content-Type: text/html; charset="iso-8859-1" RE: DDoS Work

Thomas,

It will take some time to reply to this. I will certainly take a look.

-----Original Message-----
From: Thomas Eklund [mailto:thomas.eklund@xelerated.com]
Sent: Saturday, March 24, 2001 3:20 AM
To: Morrow, Glenn [RICH2:C330:EXCH]; jari.arkko; ipng
Cc: pekka.nikander
Subject: RE: DDoS Work


Glenn,
the concerns you raise I think we have addressed in our draft
(draft-perkins-aaav6-03.txt)

> I would like to again float the idea that perhaps some sort
> of filtering
> on source address should be mandated on the first hop.
If you look at ou AAA for IPv6 we have a mechanism to intercept ND and to
have an access control towards your AAA server. What we then discuss in the
draft are possible ways to update your packet filters (ACL) for that
authenticated IPaddress and authorized services (TCP and UDP port numbers)
autmatically in the access router.

Personally I think that the draft lays out a very nice foundation for access
control and automatically updating you ingress filters in the access.

Please read it and comment it. Do you agree with the basic approach  or do
you mean something else?

> My reasoning on
> this is that the existing filtering mechanisms are sort of a
> pariah i.e.
> it might be there or it might be not and we really have no idea where
> that "there" might be throughout the network. Clearly, the
> most scalable
> and effective place to do this filtering is on the first hop. Doing it
> at other points within the network is not guaranteed to be completely
> affective as it may not stop all slaves.

Exactly. The draft shows that.

>
> It seems that two mechanisms for these filters have been proposed. One
> mechanism is a simple ingress check on an interface. The other is an
> exception mechanism that I believe has been coined ACL access control
> lists.
>
> The ACL list appears to allow specific addresses or range of addresses
> to pass through. It seems to me that if the ACL lists are used then
> there might be a glimmer of hope that mobile nodes could use
> their home
> address as source on visited domains and a whole range of solutions
> designed with this assumption will be able to be used with
> less change.

There is no need for that.
You tie it to the AAA infrastructure the mobile node could use its new CoA
after it has been trough the access control on the new network, which means
that the autoconfigured CoA it gets is authenticated (which is done in the
AAA server).


>
> It seems that when a mobile enters a visited subnet, the ACL
> lists could
> be updated to allow them in as part of neighbor discovery and AAA
> operations.
This is what the draft do.

> Although these other ideas will certainly require some significant
> thinking and discussions on scalability etc.., I would really like
> people to seriously consider at a minimum just mandating the simple
> source address filtering on the first hop in IPv6.

As I said see at our draft where we have a discussion about it.

-- thomas eklund

------_=_NextPart_001_01C0B60C.9C4F7650-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 08:19:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QGJtIm001365 for ; Mon, 26 Mar 2001 08:19:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QGJs19001364 for ipng-dist; Mon, 26 Mar 2001 08:19:54 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QGJjIm001357 for ; Mon, 26 Mar 2001 08:19:45 -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 IAA03349 for ; Mon, 26 Mar 2001 08:19:45 -0800 (PST) Received: from t-mta3.odn.ne.jp (mfep3.odn.ne.jp [143.90.131.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18250 for ; Mon, 26 Mar 2001 08:19:44 -0800 (PST) Received: from localhost ([210.188.42.82]) by t-mta3.odn.ne.jp with ESMTP id <20010326161942590.VXEW.25390.t-mta3.odn.ne.jp@mta3.odn.ne.jp>; Tue, 27 Mar 2001 01:19:42 +0900 To: gmaxwell@martin.fl.us Cc: kwang1@email.mot.com, tomohide@japan-telecom.co.jp, kre@munnari.OZ.AU, deering@cisco.com, francis@tahoenetworks.com, ipng@sunroof.eng.sun.com Subject: Re: what is a site? In-Reply-To: References: <3ABF75BC.EF6B51AE@email.mot.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010327011805Q.tomohide@japan-telecom.co.jp> Date: Tue, 27 Mar 2001 01:18:05 +0900 From: Tomohide Nagashima X-Dispatcher: imput version 20000228(IM140) Lines: 53 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I thought that these AS is for "the company" (which is originally defined by my previous e-mail), right? Then, sorry but I wonder if "a site" and "Autonomous System" is not same. > [TLA1] [TLA2] > | | >----- Both NLA1-1 and NLA2-1 is allocated to "the company". and I belive that NLA1-1 and NLA2-1 are different sites. i.e. "the company" has two sites. And I select definition of the term AS from rfc 1771; > The use of the term Autonomous System > here stresses the fact that, even when multiple IGPs and metrics are > used, the administration of an AS appears to other ASs to have a > single coherent interior routing plan and presents a consistent > picture of what destinations are reachable through it. I thought that "the company" operate this two NLA network with same routing plan, we can consider that a set of NLA1-1 and NLA2-1 is same AS, but the line between TLA1 and NLA1-1 will not present any reachability to anyone in IPv6 Grobal Network, so I also belive this set (of NLA1-1 and NLA2-1) is not one AS. Greg idea that this set has two AS is right in some part. But if NLA1-1(=site=AS) and NLA2-1(=site=AS) was operated with same IGP, Are these two AS is different AS ?? I belive a site is a site. That is not more or less. The concept of AS or NLA holder has no relationship with concept of site, What do you think about it ? ---- Tomohide Nagashima tomohide@japan-telecom.co.jp From: Greg Maxwell > I think the best description of a site for these purposes is: > > "A site and an autotomous system would be the same, however, we are > conserned with ASN proliferation and therefor only assign ASNs to ASes > which actually require enumeration for the purposes of operating global > routing protocols". > > So a site is a ASN potentially without BGP. > > This seems to fit togeather the idea of site-locals and the concept of > having a unified routing policy within ASes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 08:46:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QGkfIm001468 for ; Mon, 26 Mar 2001 08:46:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QGkecQ001467 for ipng-dist; Mon, 26 Mar 2001 08:46:40 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QGkVIm001460 for ; Mon, 26 Mar 2001 08:46: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 IAA20757 for ; Mon, 26 Mar 2001 08:46:31 -0800 (PST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09038 for ; Mon, 26 Mar 2001 08:46:30 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 26 Mar 2001 08:46:32 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Mar 2001 08:46:42 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 26 Mar 2001 08:46:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: what is a site??? Date: Mon, 26 Mar 2001 08:46:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: what is a site??? Thread-Index: AcC0GKM4tOFc0S7MSu2Pc7m5uuaPvgB+O6/A From: "Christian Huitema" To: "Steve Deering" , "Paul Francis" Cc: X-OriginalArrivalTime: 26 Mar 2001 16:46:42.0257 (UTC) FILETIME=[55DDBC10:01C0B614] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2QGkVIm001461 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, May I observe that the definition of a site in the "Scoped Address Architecture" draft contains a loophole? The draft says that "A personal residence may be treated as ... a part of a site (for example, when the residence obtains Internet access via an employer's or school's site)." This is in fact the classic definition of a "corporate" network, i.e. all the systems that are hidden behind the corporate firewall(s). From a networking point of view, there is not much difference between an employee's home, a remote office, or even the laptop of a traveling employee: once there are brought "behind the firewall" through some kind of VPN tunnel, they effectively become part of the "site." So far, I have found two important attributes of "IPv6 sites." The first one is the address stability: site addresses are stable, even if the site's external prefixes change; indeed, they are only subject to renumbering if two sites are merging. The second one is the "border police": site local packets are not supposed to leave the site, nor to originate outside the site; this provides a very rough form of access control, which may be adequate for some inexpensive devices or services. (Yes, I know perfectly well that this is weak -- at least as weak as firewalls.) I believe that most practical network manager will equate a site with a corporate network, with the practical exception of large corporations that will probably have to split their network into multiple sites, e.g. one site per campus. Or, to put it differently, the site will be a subset of the corporate network that enjoys its own independent connections to the Internet. By the way, it is a bad idea to swallow an employee's home network into a corporate site, as indicated in the addressing example. You definitely don't want the employee's teen-age children to roam your network... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 11:05:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ5JIm002243 for ; Mon, 26 Mar 2001 11:05:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJ5J23002242 for ipng-dist; Mon, 26 Mar 2001 11:05:19 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ5DIm002235 for ; Mon, 26 Mar 2001 11:05:14 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2QJ2JX01429 for ipng@sunroof.eng.sun.com; Mon, 26 Mar 2001 11:02:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NLfqIm027056 for ; Fri, 23 Mar 2001 13:41:52 -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 NAA28416 for ; Fri, 23 Mar 2001 13:41:50 -0800 (PST) Received: from huron.arbor.net (huron.arbor.net [204.181.64.19]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24531 for ; Fri, 23 Mar 2001 13:41:50 -0800 (PST) Received: by huron.arbor.net (Postfix, from userid 1010) id 9A96C724B4; Fri, 23 Mar 2001 16:41:40 -0500 (EST) Date: Fri, 23 Mar 2001 16:41:40 -0500 From: Robert Stone To: "Steven M. Bellovin" Cc: jari.arkko@piuha.net, gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work Message-ID: <20010323164140.H23081@huron.arbor.net> References: <20010322161721.ACFFC35C42@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010322161721.ACFFC35C42@berkshire.research.att.com>; from smb@research.att.com on Thu, Mar 22, 2001 at 10:17:21AM -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Mar 22, 2001 at 10:17:21AM -0600, Steven M. Bellovin wrote: > That said, an RFC that discussed DoS avoidance strategies would be > a good idea. I'm agnostic about whether that should be done in a > WG or as an individual submission, but BCP status would be a good > one to aim for. How this process should be organized is up to the > AD's and the IESG. (Also note that the next rev of draft-rescorla-sec-cons > has a good section on DoS attacks.) For what it's worth, the following document could provide a starting point: http://www.cert.org/reports/dsit_workshop-final.html It provides some specific recommendations, but is too vague in some areas and is, perhaps, a little out-of-date. --- Robert Stone , Security Engineer, Arbor Networks, Inc. www.arbor.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 Mon Mar 26 11:05:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ5uIm002253 for ; Mon, 26 Mar 2001 11:05:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJ5txi002252 for ipng-dist; Mon, 26 Mar 2001 11:05:55 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ5mIm002245 for ; Mon, 26 Mar 2001 11:05:48 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2QJ2rI01459 for ipng@sunroof.eng.sun.com; Mon, 26 Mar 2001 11:02:53 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2Q2sMIm000352 for ; Sun, 25 Mar 2001 18:54: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 SAA06494 for ; Sun, 25 Mar 2001 18:54:21 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24908 for ; Sun, 25 Mar 2001 18:54:21 -0800 (PST) Received: from kenawang ([192.168.1.77]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA04595; Sun, 25 Mar 2001 18:53:42 -0800 (PST) Message-Id: <4.2.2.20010325215038.01af5a50@localhost> X-Sender: mrfpop@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 25 Mar 2001 21:54:07 -0500 To: Steve Deering From: Margaret Wasserman Subject: Re: what is a site??? Cc: Paul Francis , ipng@sunroof.eng.sun.com In-Reply-To: References: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, >I have a hunch that you, and probably many others, will still find this >description less than satisfying, preferring a simple, concrete rule for >defining a site, but perhaps you can at least get a glimmer of the >general notion that has been mostly buried in my mind and inadequately >documented so far. If I understand correctly, you will also be adding another restriction to the definition of "site" -- specifically that the routing structure of site (and/or a link) must be "convex". That is to say that the shortest routing path between two nodes within the site must stay entirely within the site. This restriction is required in order for the packet sending rules defined in the scoping architecture to be correct. Right? 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 Mon Mar 26 11:04:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ4rIm002233 for ; Mon, 26 Mar 2001 11:04:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJ4qFT002232 for ipng-dist; Mon, 26 Mar 2001 11: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 stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ4kIm002218 for ; Mon, 26 Mar 2001 11:04:46 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2QJ1pZ01399 for ipng@sunroof.eng.sun.com; Mon, 26 Mar 2001 11:01:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MLd5Im024319 for ; Thu, 22 Mar 2001 13:39:05 -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 NAA29104 for ; Thu, 22 Mar 2001 13:39:03 -0800 (PST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00264 for ; Thu, 22 Mar 2001 13:39:02 -0800 (PST) Received: from cs.ucdavis.edu (pcp001302pcs.wireless.meeting.ietf.org [135.222.67.34]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2MLCht16252; Thu, 22 Mar 2001 15:12:43 -0600 (CST) Message-ID: <3ABA95ED.3567A90@cs.ucdavis.edu> Date: Thu, 22 Mar 2001 16:16:45 -0800 From: "S. Felix Wu" Reply-To: wu@cs.ucdavis.edu Organization: Computer Science, UC Davis X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "Steven M. Bellovin" , gmorrow@nortelnetworks.com, ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com, ietf-itrace@research.att.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: DDoS Work References: <20010322161721.ACFFC35C42@berkshire.research.att.com> <3ABA2FBE.5000603@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > > But before we go too far in this question, let's > discuss more about whether there is something > still to be done for DoS prevention, and what. > After finding out that, we could discuss how the > work is organized. Right now, at least I'm uncertain > if we have done everything and how sufficient is > the work on the various WGs. Do some of Pekka's > ideas to protect address autoconfiguration suffice > for all of IPv6 signaling? Does i-trace solve all > tracing issues? I will try here to characterize, from a technical point of view, which problems can be solved using the potential solutions developed by the iTrace working group: (if I do not explain clearly, please accept my appology and let me know which points are not clear.) In high level, iTrace tries to identify the approximate location of a source (or sources) that generates a stream of source-spoofed IP packets toward a particular destination host or network. With the iTrace-backward option, it can handle upto one layer of reflecting devices. There is an inherent assumption that, in order to make iTrace practically useful, the packet stream between the source and destination must be big enough to get a "reasonably" good probability. Examples are synflood and DDoS. Counter-examples are smurf and TCPLand, because in both cases, the attack stream is too small (one packet) to get a good probability. On the other hand, realizing iTrace forces attackers to give up many existing attack options -- they have to perform smaller flow attacks or launch from a much bigger number of slaves. Second, iTrace is only for "identifying the sources." It is not by itself a complete solution to resolve the whole DDoS problem, for example. It, in some sense, offers a "location information" service for other applications or human administrators (or FBI). "How exactly such iTrace information can be used in a real world environment" should NOT be standardized in iTrace (because different applications and situations might need different responses), but some practical scenarios for utilizing iTrace should be described in a document for applicability statements. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 11:59:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJxUIm002432 for ; Mon, 26 Mar 2001 11:59:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJxTeJ002431 for ipng-dist; Mon, 26 Mar 2001 11:59:29 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJxIIm002424 for ; Mon, 26 Mar 2001 11:59:18 -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 LAA06737 for ; Mon, 26 Mar 2001 11:59:17 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24402 for ; Mon, 26 Mar 2001 11:59:16 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA16084; Mon, 26 Mar 2001 13:59:09 -0600 (CST) Message-Id: <200103261959.NAA16084@gungnir.fnal.gov> To: Anssi.Porttikivi@teleware.fi Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: site = organization = /48? In-reply-to: Your message of Sun, 25 Mar 2001 09:50:11 +0300. <111D42604E7BD311897B00902755514A3398A8@weboffice.teleware.fi> Date: Mon, 26 Mar 2001 13:59:09 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Am I completely wrong, if I think, that in practice site-local and > organization-local will often both mean the same thing: /48, i.e. one > network of subnetworks identified with the 16-bit extensions? I imagine so ... but be careful not to mix up the nomenclature for unicast address scopes with the multicast scopes! Only multicast has an "organization-local scope". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 12:15:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QKFIIm002503 for ; Mon, 26 Mar 2001 12:15:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QKFIqd002502 for ipng-dist; Mon, 26 Mar 2001 12:15:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QKExIm002486; Mon, 26 Mar 2001 12:14:59 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21018; Mon, 26 Mar 2001 15:14:58 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2QKEq904247; Mon, 26 Mar 2001 15:14:52 -0500 (EST) Message-Id: <200103262014.f2QKEq904247@thunk.east.sun.com> From: Bill Sommerfeld To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: notes on A6 transition from AAAA (fwd) In-reply-to: Your message of "Sun, 25 Mar 2001 17:16:55 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 26 Mar 2001 15:14:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A authoritative server that only has AAAA entries and > is asked for an A6 record MUST NOT synthesize A6 records > from the AAAA ones. There is no restriction on populating both > types, but it is strongly recommended against, and in such a case, > both RRsets MUST be identical. This proposal does not formally define equivalence of AAAA and A6. is this limited to zero-prefix A6, or does it include A6's with non-zero prefixes which just happen to resolve to the same thing? Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume the former.. > If a query does not contain EDNS indicator, then any IPv6 addresses > contain in additional data section MUST be AAAA. > > Root and TLD zones MUST only contain A6 with prefix of 0. Following the "prohibit on primary load, grumble on secondary load, allow through on cached queries" interpretation of the "be conservative in what you send, and liberal in what you accept" principle, I also assume that the "MUST"s on zone contents should be be enforced only when loading a primary.. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 18:24:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R2OvIm003447 for ; Mon, 26 Mar 2001 18:24:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R2Ovs9003446 for ipng-dist; Mon, 26 Mar 2001 18:24: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R2OmIm003439 for ; Mon, 26 Mar 2001 18:24:48 -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 SAA29737 for ; Mon, 26 Mar 2001 18:24:48 -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 SAA06759 for ; Mon, 26 Mar 2001 18:24:47 -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 SAA27150; Mon, 26 Mar 2001 18:24:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2R2Ogj30499; Mon, 26 Mar 2001 18:24:42 -0800 X-mProtect: Mon, 26 Mar 2001 18:24:42 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdAjjlCb; Mon, 26 Mar 2001 18:24:33 PST Message-Id: <4.3.2.7.2.20010326181530.01f6cef8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Mar 2001 18:20:18 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Minutes from Minneapolis IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng w.g. minutes from Minneapolis IETF can be found at: http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt Presentations for most of the talks can be found at: http://playground.sun.com/pub/ipng/html/meetings.html Please send me corrections and updates. 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 Mon Mar 26 21:53:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R5rHIm003786 for ; Mon, 26 Mar 2001 21:53:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R5rH1u003785 for ipng-dist; Mon, 26 Mar 2001 21: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R5r8Im003778 for ; Mon, 26 Mar 2001 21:53:08 -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 VAA14783 for ; Mon, 26 Mar 2001 21:53:07 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA13170 for ; Mon, 26 Mar 2001 22:53:06 -0700 (MST) Received: from 157.54.7.67 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Mar 2001 21:46:19 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 26 Mar 2001 21:44:55 -0800 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="iso-8859-1" Subject: draft-draves-ipngwg-router-selection-01 Date: Mon, 26 Mar 2001 21:44:55 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8029E690A@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-draves-ipngwg-router-selection-01 Thread-Index: AcC2gQKdvZLzj6bBSyytZ4fwmE39OA== From: "Richard Draves" To: Cc: "IPng List (E-mail)" X-OriginalArrivalTime: 27 Mar 2001 05:44:55.0177 (UTC) FILETIME=[0D03E790:01C0B681] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2R5r8Im003779 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-draves-ipngwg-router-selection-01 specifies a protocol (optional extensions to Neighbor Discovery's Router Advertisement) for distributing routes from routers to hosts. The idea is to help multi-homed hosts (hosts with multiple physical or virtual network interfaces), because Redirects don't work for them. The protocol is defined narrowly, to avoid the traditional problems with having hosts learn routes from routers. The hosts are not exposed to routing protocol metrics, routers do not dump their entire routing tables to hosts, etc. The ipng working group decided to accept the draft as a work item, but one of the major comments was that it would be a good idea to solicit feedback from the operational community. Hence this message. I know the draft does not relate directly to the multi6 charter, but I'm hoping to find on the multi6 list operational people with some knowledge of IPv6 who might be interested in this draft. Please confine followup discussions to the ipng list. Section 4 is of particular operational interest, because it discusses router configuration issues. ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router -selection-01.txt Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 02:04:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RA4JIm004704 for ; Tue, 27 Mar 2001 02:04:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RA4Je8004703 for ipng-dist; Tue, 27 Mar 2001 02:04: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RA43Im004693 for ; Tue, 27 Mar 2001 02:04:03 -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 CAA08826 for ; Tue, 27 Mar 2001 02:04:02 -0800 (PST) Received: from mercury (mercury.ukc.ac.uk [129.12.21.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04340 for ; Tue, 27 Mar 2001 03:04:01 -0700 (MST) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury with esmtp (Exim 3.16 #1) id 14hqKM-0003dW-00; Tue, 27 Mar 2001 11:03:51 +0100 Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 1.92 #1) id 14hqKT-0001z3-00; Tue, 27 Mar 2001 11:03:57 +0100 Message-ID: <3AC0658C.AD417668@ukc.ac.uk> Date: Tue, 27 Mar 2001 11:03:56 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Mobile IP TestBed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Does anyone knows if there are any companies that sells ready made equipments that support mobile IP. This is because I am interested to implement a mobile IP testbed and looking at purchasing equipment that are useful for my research. Thank you INdran -- ################################################# Kumarendra Sivarajah (INdran) Electronics Engineering Laboratory University of Kent at Canterbury Canterbury, Kent CT2 7NT United Kingdom Telephone(Office): +44 (0)1227 823257 Telephone(Mobile): +44 (0)7765 007016 Fax: +44 (0)7902 181526 ################################################# -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 06:43:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2REhJIm005220 for ; Tue, 27 Mar 2001 06:43:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2REhJPZ005219 for ipng-dist; Tue, 27 Mar 2001 06:43: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2REhAIm005212 for ; Tue, 27 Mar 2001 06:43:10 -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 GAA20619 for ; Tue, 27 Mar 2001 06:43:11 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17128 for ; Tue, 27 Mar 2001 06:43:10 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2REhCg26637 for ; Tue, 27 Mar 2001 08:43:12 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 27 Mar 2001 08:43:09 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 27 Mar 2001 08:43:09 -0600 Message-ID: To: ipng@sunroof.eng.sun.com Subject: Status of Base API Date: Tue, 27 Mar 2001 08:42:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The IEEE Austin Group (XNET/POSIX type folks) will be working to merge the base api draft-ietf-ipngwg-rfc2553-bis-03.txt into the formal API standard and update XNET 5.2. This will take till mid-June. Once that is done their text will be merged into the above draft and go for update RFC number. What we don't want to do is be out of synch with IEEE (who really will standardize this API) or have to rev another RFC number. It also appears there will be a strawman proposed to identify temporary addresses and other such addresses in the base api which will be needed and presented to the base api design team in the near future. Possibly a socket option. But at this time the spec is frozen as we don't want to confuse the IEEE during their process. 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 Tue Mar 27 08:36:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGaRIm005801 for ; Tue, 27 Mar 2001 08:36:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RGaQb5005800 for ipng-dist; Tue, 27 Mar 2001 08:36: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGaGIm005792 for ; Tue, 27 Mar 2001 08:36: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 IAA26739 for ; Tue, 27 Mar 2001 08:36:17 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27868 for ; Tue, 27 Mar 2001 09:36:10 -0700 (MST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 27 Mar 2001 10:23:46 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 10:28:53 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301A63C02@crchy271.us.nortel.com> From: "Glenn Morrow" To: Pekka Nikander , ipng@sunroof.eng.sun.com, ietf-itrace@research.att.com Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Tue, 27 Mar 2001 10:28:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B6DB.01823F20" X-Orig: 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_01C0B6DB.01823F20 Content-Type: text/plain; charset="iso-8859-1" Pekka, Right now the topological assumption is the norm and this is enforced with the fact that ingress filtering may or may not be on at any given point in the network. I don't believe anyone likes having to do source filtering but we need to realize that node mobility has been forced to bow to this topological correctness (see MIPv6 draft). This is the status quo from the mobility perspective. IMO, the fact that the filtering may or may not be on at any part of an IPv4 network is understandable due to the existing deployed base of routing products. For IPv6, I am hoping we can agree on something that is more advantageous for DDoS prevention. The ACL list filters on the first hop was making sense to me with the hope that perhaps the topological correctness could be avoided. I.e. you would get what you want. I then began to think about how the root-kits can be installed and came to the conclusion that ensuring topological correctness is the only way to quickly identify the location of an infected slave node. Once a slave is compromised, the root kit has access to all of the authentication credentials of the node; therefore, these compromised nodes would likely be able to pass any ACL checks. If node mobility relied on the ACL lists to get around topological correctness i.e. use the home address as source, the same vulnerability would exist. Mandating source filtering for topological correctness on the first hop is a strawman proposal. This would certainly reduce the job of tracing and other tools. No one has mentioned it yet but there may be holes in this strawman as well. For instance, it is conceivable that a router itself could be compromised. A root kit on a router could easily make a packet look as if it was not a first hop packet. This, in itself, is not a reason to not mandate the source filtering on first hops, though. One could certainly argue that if this constraint were applied to IPv6, it would have more inherent protection against DDoS than IPv4. I suspect that many of these DDoS veterans may have been down this road before at some point thoughout the years and am interested to hear their views. Although, I realize that all of the details of your proposal have not been conveyed, I believe it would simply force us to use "return to address" filtering. I hope you can see from my statement above how authentation/cryptographic DDoS prevention mechanisms can be compromised. The root-cause problem is that of insecure operating systems. Unfortunately, I'm not sure if we can do anything about this in the IETF; although, I am certainly open to informational RFCs to explain the vulnerabilities and perhaps give example code to prevent stack overflow etc.. At the same time I do not want to dissuade you from coming up with alternate solutions to DDoS or promoting the concept you have detailed below. Your suggestion seems to have some other merits than just DDoS. We should continue to consider all possibilities from a wide range of backgrounds. Thanks, Glenn -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Sunday, March 25, 2001 7:02 AM To: ipng@sunroof.eng.sun.com; ietf-itrace@research.att.com Subject: Source addresses, DDoS prevention and ingress filtering One point that has came up several times, in various forms, in the DDoS discussion is the idea of mandating some sort of source address filtering, ingress filter, PRF of whatever it is called. For example, Glenn Morrow expressed it as follows: > I would like to again float the idea that perhaps some sort > of filtering on source address should be mandated on the first hop. Let me try to explain why I _think_ that source address filtering is a bad idea, and what I _think_ that should be done instead. This is a lenghty message since I need to go quite deep into the basics before I get to the point; my apologies. To clarify, I am not trying to take sides, and I don't have any personal _opinion_ on this issue, at least not yet :-) I am sure that some of my points have been raised several times before, but here we go anyway. This message is divided in three parts: A. Discussion about source address filtering B. A comparison between source and destination addresses C. My thoughts what should be done instead A. Discussion about source address filtering Now, according to my analysis, currently there are basically three functional reasons for including the source address into IPv6 packets. 1. Source addresses are needed to be able to reply to packets, such as unconnected UDP queries or TCP SYN packets. 2. Source addresses are needed to be able to report back error conditions, e.g., ICMP Packet Too Big. 3. Source addresses are used for identifying upper layer endpoints, e.g., to differentiate between TCP sockets. It is instructive to note that in the two first cases the source address is really needed, but in the last case it is merely a convenient piece of information that could be easily replaced with something else identifying the remote endpoint (compare e.g. to HIP). Now, mandating source address filtering attempts to add another purpose for the source address; a purpose that I don't believe could ever be really reliable. 4. Source addresses identify the interface through which the packet was originated. (FALSE) Maybe this was the original intention of the source address, but to me it seems like the infrastructure has never really supported this allusion. Furthermore, it is instructive to note that even with honest nodes the source addess does not always identify the sender. For example, some neighbour solicitation packets carry the unspecified source address, etc. Furthermore, even strict and mandatory ingress filtering does not quite achieve the maxim -- if the filtering was perfect, it would at most lead to a situation where the source address identifies the source link of the packet, not the specific interface at the link. Even further, I think that there are several reasons why even trying to achieve this illusion is a bad idea. a) Since source address filtering would be a piece of functionality whose malfunction does not have any immediate local effects, I have hard time believing that we would ever get even 90% coverage. b) Taking the trend described at the open plenary on Wednesday evening, i.e. internet turning more and more into a densely connected mesh instead of being more-or-less hierarchical tree, employing source address filtering in any other place but the ingress router would be quite hard operationally, and hard even at the ingress routers. We have already seen this in the various multihoming discussions. c) Being mandated (but not working properly), it would encourage people to trust the source address even more that they do today. B. Comparison between source and destination addresses IMHO, on instructive point of view is to compare the functions of the source and destination addresses. Most people seem to believe, perhaps even unconsciously, that source and destination addresses are functionally equivalent. That is, it seems to be common thinking that the destination address identifies the destination interface(s) of the packet and the source address identifies the source interface of the packet. As we know, this is not true. Now, the question is whether we should aim to make it true again (if it ever was) or should we abandon that thinking altogether. Let us consider the semantics in detail. The destination address has semantical meaning to the routing system. We rely on the integrity of routing information in order to get the packets to their intended recipients. This is inherent in the nature of the routing system. That is, the destination address or at least the routing part of the destination address must be "correct" for the packet ever have any changes to get delivered. The source address does not (currently) have any such semantics. It is just set by the sender, and used by the receiver. The only case when an intermediate router cares about it is when it wants to send an error report back. However, this latter practice does not seem to be such a good idea, since the source address does not necessarily carry information about the real sender of the packet. In short, the practise greatly eases reflection DDoS attacks, since you can fairly easily employ many of the routers in the infrastructure to act as reflectors. (Just mix routing headers and hop-by-hop options.) Furthermore, as I already pointed out, asymmetric routing, multihoming, and mobility are all reasons why the source address should not carry such semantics. To say this in other words, I think that the source address should not be called "source" address but "reply-to" address. That would be more accurate from the semantic point of view, since it merely indicates the sender's request where to send replies instead of identifying the real source of the address. C. My thoughts what should be done instead I know this is a radical idea and that it is probably too late to propose this, but I think that we should deprecate the source address in the IPv6 header altogether. Instead, we should use a separate destination option, perhaps "Reply-To Address Destination Option", whenever we assume that the recipient may not know where to send the replies. Please note that if we use end-to-end IPsec, we never need to use this option, and that any other TCP packets but the first SYN packet would not need to carry it either. Depracating the source address field from it current use would free it for other purposes. My suggestion is that the main function would be to use it for _recording_ the path of the packet. That is, each router that touches the packet would (perhaps probabilistically) somehow record its identity into the source address field. Thus, the source address field would no longer be a source address field but a source path field. This would have several benefits. First, those that believe in ingress filtering would perhaps be happy with the recorded packet path information. Second, those not believing in ingress filtering would be happy, too, since packets would not have to be dropped. Third, one could easily make the reply-to address private by including the destination option within an ESP header. Fourth, ICMP error reports generated by intermediate routers would be sent along the source path instead of relying on the perhaps false source address. (This might require some modifications to the error reporting functionality, but I think that wouldn't be that hard.) I know that it would be virtually impossible to employ such a drastic change to the architecture at this point. However, maybe this suggestion could work as a source of ideas for some not-so-drastic approach. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C0B6DB.01823F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

Pekka,

Right now the topological assumption is the norm and = this is enforced with the fact that ingress filtering may or may not be = on at any given point in the network.  I don't believe anyone = likes having to do source filtering but we need to realize that node = mobility has been forced to bow to this topological correctness (see = MIPv6 draft). This is the status quo from the mobility perspective. =

IMO, the fact that the filtering may or may not be on = at any part of an IPv4 network is understandable due to the existing = deployed base of routing products. For IPv6, I am hoping we can agree = on something that is more advantageous for DDoS prevention.

The ACL list filters on the first hop was making = sense to me with the hope that perhaps the topological correctness = could be avoided. I.e. you would get what you want. I then began to = think about how the root-kits can be installed and came to the = conclusion that ensuring topological correctness is the only way to = quickly identify the location of an infected slave node. Once a slave = is compromised, the root kit has access to all of the authentication = credentials of the node; therefore, these compromised nodes would = likely be able to pass any ACL checks. If node mobility relied on the = ACL lists to get around topological correctness i.e. use the home = address as source, the same vulnerability would exist.

Mandating source filtering for topological = correctness on the first hop is a strawman proposal. This would = certainly reduce the job of tracing and other tools. No one has = mentioned it yet but there may be holes in this strawman as well. For = instance, it is conceivable that a router itself could be compromised. = A root kit on a router could easily make a packet look as if it was not = a first hop packet. This, in itself, is not a reason to not mandate the = source filtering on first hops, though. One could certainly argue that = if this constraint were applied to IPv6, it would have more inherent = protection against DDoS than IPv4. I suspect that many of these DDoS = veterans may have been down this road before at some point thoughout = the years and am interested to hear their views.

Although, I realize that all of the details of your = proposal have not been conveyed, I believe it would simply force us to = use "return to address" filtering. I hope you can see from my = statement above how authentation/cryptographic DDoS prevention = mechanisms can be compromised. The root-cause problem is that of = insecure operating systems. Unfortunately, I'm not sure if we can do = anything about this in the IETF; although, I am certainly open to = informational RFCs to explain the vulnerabilities and perhaps give = example code to prevent stack overflow etc..

At the same time I do not want to dissuade you from = coming up with alternate solutions to DDoS or promoting the concept you = have detailed below. Your suggestion seems to have some other merits = than just DDoS.

We should continue to consider all possibilities from = a wide range of backgrounds.

Thanks,

Glenn

-----Original Message-----
From: Pekka Nikander [mailto:pekka.nikander@noma= diclab.com]
Sent: Sunday, March 25, 2001 7:02 AM
To: ipng@sunroof.eng.sun.com; = ietf-itrace@research.att.com
Subject: Source addresses, DDoS prevention and = ingress filtering



One point that has came up several times, in various = forms, in
the DDoS discussion is the idea of mandating some = sort of source
address filtering, ingress filter, PRF of whatever = it is called.
For example, Glenn Morrow expressed it as = follows:
> I would like to again float the idea that = perhaps some sort
> of filtering on source address should be = mandated on the first hop.

Let me try to explain why I _think_ that source = address filtering
is a bad idea, and what I _think_ that should be = done instead. 
This is a lenghty message since I need to go quite = deep into
the basics before I get to the point; my = apologies.  To clarify,
I am not trying to take sides, and I don't have any = personal
_opinion_ on this issue, at least not yet :-)  = I am sure that
some of my points have been raised several times = before, but
here we go anyway.  This message is divided in = three parts:
  A. Discussion about source address = filtering
  B. A comparison between source and = destination addresses
  C. My thoughts what should be done = instead

A. Discussion about source address filtering

Now, according to my analysis, currently there are = basically three
functional reasons for including the source address = into IPv6 packets.

  1. Source addresses are needed to be able to = reply to
     packets, such as = unconnected UDP queries or TCP SYN packets.
  2. Source addresses are needed to be able to = report
     back error conditions, = e.g., ICMP Packet Too Big.
  3. Source addresses are used for identifying = upper layer
     endpoints, e.g., to = differentiate between TCP sockets.

It is instructive to note that in the two first cases = the
source address is really needed, but in the last = case it
is merely a convenient piece of information that = could be
easily replaced with something else identifying the = remote
endpoint (compare e.g. to HIP).

Now, mandating source address filtering attempts to = add another
purpose for the source address; a purpose that I = don't believe
could ever be really reliable.

  4. Source addresses identify the interface = through
     which the packet was = originated.  (FALSE)

Maybe this was the original intention of the source = address,
but to me it seems like the infrastructure has never = really
supported this allusion.  Furthermore, it is = instructive to
note that even with honest nodes the source addess = does not
always identify the sender.  For example, some = neighbour
solicitation packets carry the unspecified source = address, etc.
Furthermore, even strict and mandatory ingress = filtering does
not quite achieve the maxim -- if the filtering was = perfect, it
would at most lead to a situation where the source = address
identifies the source link of the packet, not the = specific
interface at the link. 

Even further, I think that there are several reasons = why
even trying to achieve this illusion is a bad = idea.

  a) Since source address filtering would be a = piece of
     functionality whose = malfunction does not have any immediate
     local effects, I have hard = time believing that we would
     ever get even 90% = coverage.
  b) Taking the trend described at the open = plenary on
     Wednesday evening, i.e. = internet turning more and more
     into a densely connected = mesh instead of being more-or-less
     hierarchical tree, = employing source address filtering in
     any other place but the = ingress router would be quite hard
     operationally, and hard = even at the ingress routers.  We have
     already seen this in the = various multihoming discussions.
  c) Being mandated (but not working properly), = it would
     encourage people to trust = the source address even more
     that they do today.  =

B. Comparison between source and destination = addresses

IMHO, on instructive point of view is to compare the = functions
of the source and destination addresses.  Most = people seem to
believe, perhaps even unconsciously, that source and = destination
addresses are functionally equivalent.  That = is, it seems to be
common thinking that the destination address = identifies the
destination interface(s) of the packet and the = source address
identifies the source interface of the packet.  = As we know,
this is not true.  Now, the question is whether = we should aim
to make it true again (if it ever was) or should we = abandon
that thinking altogether.

Let us consider the semantics in detail.  The = destination address
has semantical meaning to the routing system.  = We rely on the
integrity of routing information in order to get the = packets to
their intended recipients.  This is inherent in = the nature of
the routing system.  That is, the destination = address or at least
the routing part of the destination address must be = "correct"
for the packet ever have any changes to get = delivered.

The source address does not (currently) have any such = semantics.
It is just set by the sender, and used by the = receiver.  The only
case when an intermediate router cares about it is = when it wants
to send an error report back.  However, this = latter practice does
not seem to be such a good idea, since the source = address does not
necessarily carry information about the real sender = of the packet.
In short, the practise greatly eases reflection DDoS = attacks, since
you can fairly easily employ many of the routers in = the infrastructure
to act as reflectors.  (Just mix routing = headers and hop-by-hop options.)

Furthermore, as I already pointed out, asymmetric = routing, multihoming,
and mobility are all reasons why the source address = should
not carry such semantics.  To say this in other = words, I think that
the source address should not be called = "source" address but
"reply-to" address.  That would be = more accurate from the semantic
point of view, since it merely indicates the = sender's request where
to send replies instead of identifying the real = source of the address.

C. My thoughts what should be done instead

I know this is a radical idea and that it is probably = too late to
propose this, but I think that we should deprecate = the source
address in the IPv6 header altogether.  = Instead, we should use
a separate destination option, perhaps = "Reply-To Address Destination
Option", whenever we assume that the recipient = may not know where
to send the replies.  Please note that if we = use end-to-end IPsec,
we never need to use this option, and that any other = TCP packets
but the first SYN packet would not need to carry it = either. 

Depracating the source address field from it current = use would
free it for other purposes.  My suggestion is = that the main function
would be to use it for _recording_ the path of the = packet.  That is,
each router that touches the packet would (perhaps = probabilistically)
somehow record its identity into the source address = field.  Thus,
the source address field would no longer be a source = address field
but a source path field. 

This would have several benefits.  First, those = that believe in ingress
filtering would perhaps be happy with the recorded = packet path information.
Second, those not believing in ingress filtering = would be happy, too,
since packets would not have to be dropped.  = Third, one could easily
make the reply-to address private by including the = destination option
within an ESP header.  Fourth, ICMP error = reports generated by intermediate
routers would be sent along the source path instead = of relying on the
perhaps false source address.  (This might = require some modifications
to the error reporting functionality, but I think = that wouldn't be
that hard.) 

I know that it would be virtually impossible to = employ such a drastic
change to the architecture at this point.  = However, maybe this
suggestion could work as a source of ideas for some = not-so-drastic
approach.

--Pekka
---------------------------------------------------------------= -----
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
---------------------------------------------------------------= -----

------_=_NextPart_001_01C0B6DB.01823F20-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 10:03:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RI3nIm006309 for ; Tue, 27 Mar 2001 10:03:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RI3nOR006308 for ipng-dist; Tue, 27 Mar 2001 10:03:49 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RI3iIm006301 for ; Tue, 27 Mar 2001 10:03:44 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2RI0nb05489 for ipng@sunroof.eng.sun.com; Tue, 27 Mar 2001 10:00:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R05rIm003099; Mon, 26 Mar 2001 16:05: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 QAA19925; Mon, 26 Mar 2001 16:05:54 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [216.254.68.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA01055; Mon, 26 Mar 2001 16:05:46 -0800 (PST) Received: from localhost ([127.0.0.1]:13071 "EHLO hactrn.net" ident: "IDENT-NOT-QUERIED [port 13071]") by thrintun.hactrn.net with ESMTP id <23296-220>; Mon, 26 Mar 2001 19:05:38 -0500 To: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: notes on A6 transition from AAAA (fwd) In-Reply-To: Message from Bill Sommerfeld dated "Mon, 26 Mar 2001 15:14:52 EST" <200103262014.f2QKEq904247@thunk.east.sun.com> References: <200103262014.f2QKEq904247@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 26 Mar 2001 19:05:37 -0500 From: Rob Austein Message-Id: <20010327000539Z23296-220+147@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 26 Mar 2001 15:14:52 -0500 From: Bill Sommerfeld This proposal does not formally define equivalence of AAAA and A6. Right. There's still a bit of an open issue about what to do with AAAA in the long run, perhaps declare it to be a form of meta query for stub resolvers to use that means "get me an address, however that's implemented this week, and just return me the bits please". > A authoritative server that only has AAAA entries and > is asked for an A6 record MUST NOT synthesize A6 records > from the AAAA ones. There is no restriction on populating both > types, but it is strongly recommended against, and in such a case, > both RRsets MUST be identical. is this limited to zero-prefix A6, or does it include A6's with non-zero prefixes which just happen to resolve to the same thing? Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume the former.. No, our theory was that we really didn't want synthesized A6 RRs at all, full stop. We're not trying for parallel mechanisms here, the idea is that A6 would become the "real" data and AAAA would become the way that certain clients chose to retrieve a simplified form of it. > If a query does not contain EDNS indicator, then any IPv6 addresses > contain in additional data section MUST be AAAA. > > Root and TLD zones MUST only contain A6 with prefix of 0. Following the "prohibit on primary load, grumble on secondary load, allow through on cached queries" interpretation of the "be conservative in what you send, and liberal in what you accept" principle, I also assume that the "MUST"s on zone contents should be be enforced only when loading a primary.. As far as the software would be concerned, you're right. We were, however, also recommending that these limits be enforced by administrative policy for the root, TLDs, and other big public zones. That's out of the IETF's scope, other than making the recommendation. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 10:04:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RI4QIm006326 for ; Tue, 27 Mar 2001 10:04:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RI4Pmo006325 for ipng-dist; Tue, 27 Mar 2001 10:04:25 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RI4GIm006311 for ; Tue, 27 Mar 2001 10:04:16 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f2RI1Lt05519 for ipng@sunroof.eng.sun.com; Tue, 27 Mar 2001 10:01:21 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2REdGIm005201 for ; Tue, 27 Mar 2001 06:39:17 -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 GAA20230 for ; Tue, 27 Mar 2001 06:39:17 -0800 (PST) Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24932 for ; Tue, 27 Mar 2001 06:39:13 -0800 (PST) Received: from xtreme (1Cust11.tnt15.rtm1.nl.uu.net [213.116.124.11]) by lepidachrosite.lion-access.net (I-Lab) with SMTP id 7D6FBCAFCD; Tue, 27 Mar 2001 14:38:38 +0000 (GMT) From: "Joris Dobbelsteen" To: "'Tomohide Nagashima'" Cc: "IPng WG (E-mail)" Subject: RE: what is a site? Date: Tue, 27 Mar 2001 16:41:51 +0200 Message-ID: <000001c0b6cc$131e9990$0d0ca8c0@Joris2K.local> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010326195731W.tomohide@japan-telecom.co.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >-----Original Message----- From: owner-ipng@sunroof.eng.sun.com >[mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Tomohide Nagashima >Sent: Monday, 26 March 2001 12:58 >To: kre@munnari.OZ.AU >Cc: deering@cisco.com; francis@tahoenetworks.com; >ipng@sunroof.eng.sun.com >Subject: Re: what is a site? > > >Hello, > >>we also don't need any specific definition of >>what is a site - all that can possibly do is to constrain >thinking into >>the future. > >As I also think we should not constrain concept of site. But I >belive we >still need some minimun defenition of site, or need some >example that show >such a set is site or not. > >For example, how about it? > >There is a company that has two sets of network in two place. >As each network is too far, this company get connectibity from >two ISPs( ISP1 has prefixes in TLA1, ISP2 has prefixes in TLA2). >And this company want to communicate this two network without >Grobal network, this company connect this two network with >released line. like this; > > [TLA1] [TLA2] > | | >----- > >( NLA1-1 is from TLA1, and NLA2-1 is from TLA2 ) > >then can we call a set of NLA1-1 and NLA2-1 is a site ? > >From my opinion this can be a single site or two sites, it's just an administrative term in network management. My definition of a site is a computer network, that can exist of one or more links that all have there own services and would be able to preform it's basic functions without the need of an additional site. Probably here it's get complicated and this is were others may disagree. For me, sites exist for reasons of security (e.g. high-security envorment connected to an other network), network load balancing (e.g. distributing servers or slow links) or any other reason. Most sites are on a specific geographic posisition, but this usually has todo with the slow links between the sites. Note here that I'm not saying that two (or more) links that are separated by a big space I rather use the term link instead of network to identify a line where one or more computers are connected to AND where they all have direct access to each other without the need to go through a router or proxy. Note that I don't treath hubs and switches as such routers, but just a part of the link. [TLA1] [TLA2] | | ----slow-line---- As a illustion with the same meaning as above, I would threat this as one site if all systems for authentication, DNS, DHCP (examples) and other direct requirements for the network are all located on [TLA1]. Instead if they have both the services then they COULD be two sites (it would seem sense, but it's not nescesary to me). Note that the services may be the same, the authentication server on [TLA1] may be relicated with [TLA2]... >I belive that this set is not a site but two sites. >but if we define site is whatever I want it to be, >then someone will regard this a set of two networks is a site. > >---- >Tomohide Nagashima >tomohide@japan-telecom.co.jp > - Joris joris.dobbelsteen@mail.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 Mar 27 11:37:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RJbaIm006784 for ; Tue, 27 Mar 2001 11:37:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RJbaT0006783 for ipng-dist; Tue, 27 Mar 2001 11:37:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RJajIm006766; Tue, 27 Mar 2001 11:36:50 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10448; Tue, 27 Mar 2001 14:36:45 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2RJae919544; Tue, 27 Mar 2001 14:36:40 -0500 (EST) Message-Id: <200103271936.f2RJae919544@thunk.east.sun.com> From: Bill Sommerfeld To: Rob Austein cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: notes on A6 transition from AAAA (fwd) In-reply-to: Your message of "Mon, 26 Mar 2001 19:05:37 EST." <20010327000539Z23296-220+147@thrintun.hactrn.net> Reply-to: sommerfeld@east.sun.com Date: Tue, 27 Mar 2001 14:36:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > A authoritative server that only has AAAA entries and > > is asked for an A6 record MUST NOT synthesize A6 records > > from the AAAA ones. There is no restriction on populating both > > types, but it is strongly recommended against, and in such a case, > > both RRsets MUST be identical. > > is this limited to zero-prefix A6, or does it include A6's with > non-zero prefixes which just happen to resolve to the same thing? > Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume > the former.. > > No, our theory was that we really didn't want synthesized A6 RRs at > all, full stop. I was asking about the "populating both types as long as both RRsets are identical" approach -- you need to define what you mean by "identical". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 12:00:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RK0KIm006825 for ; Tue, 27 Mar 2001 12:00:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RK0KJj006824 for ipng-dist; Tue, 27 Mar 2001 12:00: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RJxwIm006817 for ; Tue, 27 Mar 2001 11:59:59 -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 LAA15065 for ; Tue, 27 Mar 2001 11:59:57 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25142 for ; Tue, 27 Mar 2001 11:59:56 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA21691 for ; Tue, 27 Mar 2001 13:59:55 -0600 (CST) Message-Id: <200103271959.NAA21691@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: an unplanned benefit of IPv6 Date: Tue, 27 Mar 2001 13:59:54 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You know what I'm going to liker about the shining all-v6 future? It's going to be rather difficult for the script kiddies to scan my entire address space looking for their favorite port. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 13:33:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RLXUIm007209 for ; Tue, 27 Mar 2001 13:33:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RLXUEq007208 for ipng-dist; Tue, 27 Mar 2001 13:33:30 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RLXKIm007201 for ; Tue, 27 Mar 2001 13:33:20 -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 NAA17172 for ; Tue, 27 Mar 2001 13:33:10 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21457 for ; Tue, 27 Mar 2001 13:33:09 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 27 Mar 2001 15:17:07 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 15:22:15 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301AD0D4E@crchy271.us.nortel.com> From: "Glenn Morrow" To: "thomas.eklund" , "jari.arkko" , ipng Cc: "pekka.nikander" Subject: RE: DDoS Work Date: Tue, 27 Mar 2001 15:22:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B703.FE080FE0" X-Orig: 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_01C0B703.FE080FE0 Content-Type: text/plain; charset="iso-8859-1" Thomas, The draft you reference below is certainly one instantiation of an architecture framework that could be used as a reference in my previous message. I guess the major disagreements are on what that AAA protocol is or if this is an AAA or OA&M function or should some of these interfaces ever be openly standardized etc... I understand the differing points of view on this and I certainly do not want to bring that debate into the IPv6 mailing list. There is a great deal of work going on in the IRTF and other WGs to try to make the best decision on this sort of thing. I believe the providers are still trying to agree on whether they want this sort of interface openly standardized and if so what to base it on. One thing I would like to re-iterate and get people to think about at least for a minute or two is if a slave has been invaded due to an insecure OS or other means, it won't matter which address the slave is using (COA or Home Address). Any authentication creditials will have been compromised; although some (me too) would like to use the home address as the source, the COA should probably be used and enforced in order to ensure topoligical correctness. This would make the job of ITRACE much easier in IPv6, IMHO. I guess I agree with your "there is no need for that" statement below. Thanks, Glenn -----Original Message----- From: Thomas Eklund [mailto:thomas.eklund@xelerated.com] Sent: Saturday, March 24, 2001 3:20 AM To: Morrow, Glenn [RICH2:C330:EXCH]; jari.arkko; ipng Cc: pekka.nikander Subject: RE: DDoS Work Glenn, the concerns you raise I think we have addressed in our draft (draft-perkins-aaav6-03.txt) > I would like to again float the idea that perhaps some sort > of filtering > on source address should be mandated on the first hop. If you look at ou AAA for IPv6 we have a mechanism to intercept ND and to have an access control towards your AAA server. What we then discuss in the draft are possible ways to update your packet filters (ACL) for that authenticated IPaddress and authorized services (TCP and UDP port numbers) autmatically in the access router. Personally I think that the draft lays out a very nice foundation for access control and automatically updating you ingress filters in the access. Please read it and comment it. Do you agree with the basic approach or do you mean something else? > My reasoning on > this is that the existing filtering mechanisms are sort of a > pariah i.e. > it might be there or it might be not and we really have no idea where > that "there" might be throughout the network. Clearly, the > most scalable > and effective place to do this filtering is on the first hop. Doing it > at other points within the network is not guaranteed to be completely > affective as it may not stop all slaves. Exactly. The draft shows that. > > It seems that two mechanisms for these filters have been proposed. One > mechanism is a simple ingress check on an interface. The other is an > exception mechanism that I believe has been coined ACL access control > lists. > > The ACL list appears to allow specific addresses or range of addresses > to pass through. It seems to me that if the ACL lists are used then > there might be a glimmer of hope that mobile nodes could use > their home > address as source on visited domains and a whole range of solutions > designed with this assumption will be able to be used with > less change. There is no need for that. You tie it to the AAA infrastructure the mobile node could use its new CoA after it has been trough the access control on the new network, which means that the autoconfigured CoA it gets is authenticated (which is done in the AAA server). > > It seems that when a mobile enters a visited subnet, the ACL > lists could > be updated to allow them in as part of neighbor discovery and AAA > operations. This is what the draft do. > Although these other ideas will certainly require some significant > thinking and discussions on scalability etc.., I would really like > people to seriously consider at a minimum just mandating the simple > source address filtering on the first hop in IPv6. As I said see at our draft where we have a discussion about it. -- thomas eklund ------_=_NextPart_001_01C0B703.FE080FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DDoS Work

Thomas,

The draft you reference below is certainly one = instantiation of an architecture framework that could be used as a = reference in my previous message.

I guess the major disagreements are on what that AAA = protocol is or if this is an AAA or OA&M function or should some of = these interfaces ever be openly standardized etc... I understand the = differing points of view on this and I certainly do not want to bring = that debate into the IPv6 mailing list. There is a great deal of work = going on in the IRTF and other WGs to try to make the best decision on = this sort of thing. I believe the providers are still trying to agree = on whether they want this sort of interface openly standardized and if = so what to base it on. 

One thing I would like to re-iterate and get people = to think about at least for a minute or two is if a slave has been = invaded due to an insecure OS or other means, it won't matter which = address the slave is using (COA or Home Address). Any authentication = creditials will have been compromised; although some (me too) would = like to use the home address as the source, the COA should probably be = used and enforced in order to ensure topoligical correctness. This = would make the job of ITRACE much easier in IPv6, IMHO. I guess I agree = with your "there is no need for that" statement = below.

Thanks,

Glenn

-----Original Message-----
From: Thomas Eklund [mailto:thomas.eklund@xelerat= ed.com]
Sent: Saturday, March 24, 2001 3:20 AM
To: Morrow, Glenn [RICH2:C330:EXCH]; jari.arkko; = ipng
Cc: pekka.nikander
Subject: RE: DDoS Work


Glenn,
the concerns you raise I think we have addressed in = our draft
(draft-perkins-aaav6-03.txt)

> I would like to again float the idea that = perhaps some sort
> of filtering
> on source address should be mandated on the = first hop.
If you look at ou AAA for IPv6 we have a mechanism = to intercept ND and to
have an access control towards your AAA server. What = we then discuss in the
draft are possible ways to update your packet = filters (ACL) for that
authenticated IPaddress and authorized services (TCP = and UDP port numbers)
autmatically in the access router.

Personally I think that the draft lays out a very = nice foundation for access
control and automatically updating you ingress = filters in the access.

Please read it and comment it. Do you agree with the = basic approach  or do
you mean something else?

> My reasoning on
> this is that the existing filtering mechanisms = are sort of a
> pariah i.e.
> it might be there or it might be not and we = really have no idea where
> that "there" might be throughout the = network. Clearly, the
> most scalable
> and effective place to do this filtering is on = the first hop. Doing it
> at other points within the network is not = guaranteed to be completely
> affective as it may not stop all slaves.

Exactly. The draft shows that.

>
> It seems that two mechanisms for these filters = have been proposed. One
> mechanism is a simple ingress check on an = interface. The other is an
> exception mechanism that I believe has been = coined ACL access control
> lists.
>
> The ACL list appears to allow specific = addresses or range of addresses
> to pass through. It seems to me that if the ACL = lists are used then
> there might be a glimmer of hope that mobile = nodes could use
> their home
> address as source on visited domains and a = whole range of solutions
> designed with this assumption will be able to = be used with
> less change.

There is no need for that.
You tie it to the AAA infrastructure the mobile node = could use its new CoA
after it has been trough the access control on the = new network, which means
that the autoconfigured CoA it gets is authenticated = (which is done in the
AAA server).


>
> It seems that when a mobile enters a visited = subnet, the ACL
> lists could
> be updated to allow them in as part of neighbor = discovery and AAA
> operations.
This is what the draft do.

> Although these other ideas will certainly = require some significant
> thinking and discussions on scalability etc.., = I would really like
> people to seriously consider at a minimum just = mandating the simple
> source address filtering on the first hop in = IPv6.

As I said see at our draft where we have a discussion = about it.

-- thomas eklund

------_=_NextPart_001_01C0B703.FE080FE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 14:46:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMk2Im007558 for ; Tue, 27 Mar 2001 14:46:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RMk2AJ007557 for ipng-dist; Tue, 27 Mar 2001 14:46: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMjqIm007549 for ; Tue, 27 Mar 2001 14:45: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 OAA04578 for ; Tue, 27 Mar 2001 14:45:53 -0800 (PST) Received: from euripides.enigma.ie (euripides.enigma.ie [194.106.143.89]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21163 for ; Tue, 27 Mar 2001 15:45:52 -0700 (MST) Received: (qmail 48861 invoked by uid 1001); 27 Mar 2001 22:45:50 -0000 Date: Tue, 27 Mar 2001 23:45:50 +0100 From: Niall Richard Murphy To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: Re: an unplanned benefit of IPv6 Message-ID: <20010327234550.A43015@enigma.ie> Mail-Followup-To: Niall Richard Murphy , Matt Crawford , ipng@sunroof.eng.sun.com References: <200103271959.NAA21691@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103271959.NAA21691@gungnir.fnal.gov>; from crawdad@fnal.gov on Tue, Mar 27, 2001 at 01:59:54PM -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 27, 2001 at 01:59:54PM -0600, Matt Crawford wrote: > You know what I'm going to liker about the shining all-v6 future? > It's going to be rather difficult for the script kiddies to scan my > entire address space looking for their favorite port. An unplanned deficit of IPv6: operating without DNS will be much, much harder. (Particularly if you can't type ":" quickly) Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 14:56:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMuZIm007652 for ; Tue, 27 Mar 2001 14:56:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RMuYHv007651 for ipng-dist; Tue, 27 Mar 2001 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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMuPIm007642 for ; Tue, 27 Mar 2001 14:56:25 -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 OAA07686 for ; Tue, 27 Mar 2001 14:56:21 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12403 for ; Tue, 27 Mar 2001 14:56:20 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f2RMuEq19952; Tue, 27 Mar 2001 14:56:14 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f2RMuEa01187; Tue, 27 Mar 2001 14:56:14 -0800 Message-Id: <200103272256.f2RMuEa01187@zed.isi.edu> Subject: Re: an unplanned benefit of IPv6 To: niallm-ipng@enigma.ie (Niall Richard Murphy) Date: Tue, 27 Mar 2001 14:56:14 -0800 (PST) Cc: crawdad@fnal.gov (Matt Crawford), ipng@sunroof.eng.sun.com In-Reply-To: <20010327234550.A43015@enigma.ie> from "Niall Richard Murphy" at Mar 27, 2001 11:45:50 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % On Tue, Mar 27, 2001 at 01:59:54PM -0600, Matt Crawford wrote: % > You know what I'm going to liker about the shining all-v6 future? % > It's going to be rather difficult for the script kiddies to scan my % > entire address space looking for their favorite port. % % An unplanned deficit of IPv6: operating without DNS will be much, much % harder. (Particularly if you can't type ":" quickly) % % Niall % -- or try the functional equivalent of dig -x 198.32.4.13, which with nibble support looks like: dig 6.a.7.4.7.7.e.f.f.f.0.2.0.0.a.0.0.0.0.0.0.0.0.0.5.0.8.0.e.f.f.3.ip6.int. (I think I am missing a "0" in there somewhere) bitstrings are even more "interesting". -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 15:10:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RNA7Im007700 for ; Tue, 27 Mar 2001 15:10:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RNA6U8007699 for ipng-dist; Tue, 27 Mar 2001 15:10:06 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RN9vIm007692 for ; Tue, 27 Mar 2001 15:09:57 -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 PAA10412 for ; Tue, 27 Mar 2001 15:09:58 -0800 (PST) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25642 for ; Tue, 27 Mar 2001 15:09:57 -0800 (PST) Received: by alfa.itea.ntnu.no id BAA0000002727; Wed, 28 Mar 2001 01:09:50 +0200 (MET DST) From: Stig Venås Date: Wed, 28 Mar 2001 01:09:50 +0200 To: Bill Manning Cc: Niall Richard Murphy , Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: an unplanned benefit of IPv6 Message-ID: <20010328010950.A30797@itea.ntnu.no> References: <20010327234550.A43015@enigma.ie> <200103272256.f2RMuEa01187@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200103272256.f2RMuEa01187@zed.isi.edu>; from bmanning@ISI.EDU on Tue, Mar 27, 2001 at 02:56:14PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 27, 2001 at 02:56:14PM -0800, Bill Manning wrote: > % > % On Tue, Mar 27, 2001 at 01:59:54PM -0600, Matt Crawford wrote: > % > You know what I'm going to liker about the shining all-v6 future? > % > It's going to be rather difficult for the script kiddies to scan my > % > entire address space looking for their favorite port. > % > % An unplanned deficit of IPv6: operating without DNS will be much, much > % harder. (Particularly if you can't type ":" quickly) > % > % Niall > % -- > > or try the functional equivalent of dig -x 198.32.4.13, which > with nibble support looks like: > > dig 6.a.7.4.7.7.e.f.f.f.0.2.0.0.a.0.0.0.0.0.0.0.0.0.5.0.8.0.e.f.f.3.ip6.int. > > (I think I am missing a "0" in there somewhere) > bitstrings are even more "interesting". Hexadecimal numeric keypads would help, preferably with a : key as well. Using words like dead and beef might make addresses easier to remember. Sorry, I couldn't resist Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 15:42:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RNgaIm007805 for ; Tue, 27 Mar 2001 15:42:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RNgaE2007804 for ipng-dist; Tue, 27 Mar 2001 15:42: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RNgQIm007797 for ; Tue, 27 Mar 2001 15:42:27 -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 PAA11104 for ; Tue, 27 Mar 2001 15:42:27 -0800 (PST) Received: from dillema.net (server.pasta.cs.UiT.No [129.242.16.119]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19660 for ; Tue, 27 Mar 2001 15:42:25 -0800 (PST) Received: (from dillema@localhost) by dillema.net (8.11.2/8.8.8) id f2RNekK10211; Wed, 28 Mar 2001 01:40:46 +0200 (CEST) Date: Wed, 28 Mar 2001 01:40:46 +0200 From: Feico Dillema To: Bill Manning Cc: Niall Richard Murphy , Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: an unplanned benefit of IPv6 Message-ID: <20010328014046.F7967@pasta.cs.uit.no> Mail-Followup-To: Bill Manning , Niall Richard Murphy , Matt Crawford , ipng@sunroof.eng.sun.com References: <20010327234550.A43015@enigma.ie> <200103272256.f2RMuEa01187@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103272256.f2RMuEa01187@zed.isi.edu>; from bmanning@ISI.EDU on Tue, Mar 27, 2001 at 02:56:14PM -0800 X-Operating-System: NetBSD drifter.dillema.net 1.5S NetBSD 1.5S (DRIFTER) X-URL: http://www.dillema.net/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 27, 2001 at 02:56:14PM -0800, Bill Manning wrote: > % > % On Tue, Mar 27, 2001 at 01:59:54PM -0600, Matt Crawford wrote: > % > You know what I'm going to liker about the shining all-v6 future? > % > It's going to be rather difficult for the script kiddies to scan my > % > entire address space looking for their favorite port. > % > % An unplanned deficit of IPv6: operating without DNS will be much, much > % harder. (Particularly if you can't type ":" quickly) > % > % Niall > % -- > > or try the functional equivalent of dig -x 198.32.4.13, which > with nibble support looks like: > > dig 6.a.7.4.7.7.e.f.f.f.0.2.0.0.a.0.0.0.0.0.0.0.0.0.5.0.8.0.e.f.f.3.ip6.int. Well, mostly a matter of time till the tools have been updated with proper support for IPv6. I personally use a little perl-script to make the above easier (both for v4 and v6 addresses, like: `ptrconf.pl 3ffe:2a00:100:3fff::1` gives me the nibble representation. Rest is most of the time cut 'n paste right? Feico. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 16:24:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S0OUIm007906 for ; Tue, 27 Mar 2001 16:24:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S0OUpl007905 for ipng-dist; Tue, 27 Mar 2001 16: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S0OKIm007898 for ; Tue, 27 Mar 2001 16:24:20 -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 QAA22735 for ; Tue, 27 Mar 2001 16:24:21 -0800 (PST) Received: from smtp.tndh.net (1Cust103.tnt4.redmond2.wa.da.uu.net [63.15.52.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07016 for ; Tue, 27 Mar 2001 16:24:15 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 27 Mar 2001 16:24:35 -0800 Received: from eagleswings [192.168.123.12] by smtp.tndh.net [63.15.52.103] (SLmail 3.2.3113) with SMTP id 04FA4A66EB2849FE8564766B10FFF437 for plus 1 more; Tue, 27 Mar 2001 16:24:34 -0800 Reply-To: From: "Tony Hain" To: "Matt Crawford" , Subject: RE: an unplanned benefit of IPv6 Date: Tue, 27 Mar 2001 16:24:28 -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: <200103271959.NAA21691@gungnir.fnal.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: EFD59E9B-BEAA443E-9967C248-585F24EB Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Add to that the anonymous address feature, where all the workstations without need for inbound connections will appear to be hopping around in random order. Setting policies like the preferred lifetime on anonymous addresses to very low and deprecate the hardware-based address, would minimize the exposure to scans ever finding the bulk of the workstations. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Matt Crawford Sent: Tuesday, March 27, 2001 12:00 PM To: ipng@sunroof.eng.sun.com Subject: an unplanned benefit of IPv6 You know what I'm going to liker about the shining all-v6 future? It's going to be rather difficult for the script kiddies to scan my entire address space looking for their favorite port. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mar 27 16:32:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S0WBIm007955 for ; Tue, 27 Mar 2001 16:32:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S0WB8U007954 for ipng-dist; Tue, 27 Mar 2001 16:32:11 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S0W1Im007947 for ; Tue, 27 Mar 2001 16:32:02 -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 QAA00333 for ; Tue, 27 Mar 2001 16:31:53 -0800 (PST) Received: from smtp.tndh.net (1Cust103.tnt4.redmond2.wa.da.uu.net [63.15.52.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10980 for ; Tue, 27 Mar 2001 16:31:51 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 27 Mar 2001 16:32:17 -0800 Received: from eagleswings [192.168.123.12] by smtp.tndh.net [63.15.52.103] (SLmail 3.2.3113) with SMTP id 7BD58C49BF62417DA17B6A1DF4D94E23 for plus 1 more; Tue, 27 Mar 2001 16:32:17 -0800 Reply-To: From: "Tony Hain" To: "Matt Crawford" , Subject: RE: an unplanned benefit of IPv6 Date: Tue, 27 Mar 2001 16:32:11 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: 85242160-66444E5A-B32AB54D-5A59823D Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Add to that the anonymous address feature, where all the workstations without need for inbound connections will appear to be hopping around in random order. Setting policies like the preferred lifetime on anonymous addresses to very low and deprecate the hardware-based address, would minimize the exposure to scans ever finding the bulk of the workstations. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Matt Crawford Sent: Tuesday, March 27, 2001 12:00 PM To: ipng@sunroof.eng.sun.com Subject: an unplanned benefit of IPv6 You know what I'm going to liker about the shining all-v6 future? It's going to be rather difficult for the script kiddies to scan my entire address space looking for their favorite port. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mar 27 23:55:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S7taIm008833 for ; Tue, 27 Mar 2001 23:55:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S7tZjq008832 for ipng-dist; Tue, 27 Mar 2001 23:55: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S7tQIm008825 for ; Tue, 27 Mar 2001 23:55: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 XAA25233 for ; Tue, 27 Mar 2001 23:55:27 -0800 (PST) Received: from Yellow.japan-telecom.co.jp (Yellow.japan-telecom.co.jp [210.146.35.35]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02116 for ; Tue, 27 Mar 2001 23:55:26 -0800 (PST) Received: from japan-telecom.co.jp (localhost [127.0.0.1]) by Yellow.japan-telecom.co.jp (3.7W-Yellow) with ESMTP id QAA16320; Wed, 28 Mar 2001 16:47:57 +0900 (JST) Received: (from root@localhost) by japan-telecom.co.jp (3.7W-SP340201) id QAA18048; Wed, 28 Mar 2001 16:54:01 +0900 (JST) Received: from unknown [172.18.82.245] by SP340201.japan-telecom.co.jp with SMTP id SAA18041 ; Wed, 28 Mar 2001 16:54:01 +0900 To: deering@cisco.com, francis@tahoenetworks.com, kwang1@email.mot.com, joris.dobbelsteen@mail.com Cc: ipng@sunroof.eng.sun.com Subject: Re: what is a site? X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010328165204O.tomohide@japan-telecom.co.jp> Date: Wed, 28 Mar 2001 16:52:04 +0900 From: Tomohide Nagashima X-Dispatcher: imput version 20000228(IM140) Lines: 119 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, At least, it is clear that "Site" is a set of links. But is the subset of Site the Site ? I begin to belive this answer is YES.If else, what do we call that ? I belive this will be a key of definition of "Site". I propose definition of "Site" as follows; I also propose new word "Full-Site". (Definition of Site) A set of link "S" is a Site <==> "N" is a integer set N = { n | n is integer , 0=< n =< 2^16 }. For the "M" which is subset of N; There is a one-to-one projection from S to M. (Definition of Full-Site) Especially, We call that a Site with M=N is a Full-Site. I think Full-Site has no reality , but this word is very useful. Then we will have these theorem, (Theorem) 1. |M| = |S| i.e. the number of M members is equal to the number of S members. 2. Any subset of Site is Site. 3. Full-Site is Site These are obvious. Here is a example. (Example) There are three links in my network like this; Link 1 Link 2 -----+---- --+------- | | --+---------+--- Link 3 We select projection as follows, Projection = { return 0x000a for Link 1 return 0x000b for Link 2 return 0x000c for Link 3 } This is off-cause one-to-one projection from "S" to "M". M = { 0x000a, 0x000b, 0x000c } is subset of N So this "my network" is Site. If we select subnet ID as follows, subnet ID = 0x000a for Link 1 subnet ID = 0x000b for Link 2 subnet ID = 0x000c for Link 3 then we can select Site-Local Address and Global Address as follows, Site-Local Global Link 1 fec0:0:0:a::/64 BLOB:A:L:a::/64 Link 2 fec0:0:0:b::/64 BLOB:A:L:b::/64 Link 3 fec0:0:0:c::/64 BLOB:A:L:c::/64 (BLOB:A:L::/48 is a prefix from upstream for this site.) If we add Link 4 with subnet ID = 0x000d , this new "my network" is also Site. We can add link until Site will became Full-Site. (Discussion) Let's think about following topology. [TLA1] [TLA2] | | --- 1) If administrator of Network1 and 2 regards that both Network1 and 2 should be in same Full-Site, ~~~~~~~~~~~~~~ Projection for numbering of Site-Local Address and Aggregatable Global Address for Network1 and Network2 are same projection ID(link_name). Link "s1" in Network1 will be allocated fec0:0:0:ID(s1)::/64 T:L:A1:ID(s1)::/64 Link "s2" in Network2 will be allocated fec0:0:0:ID(s2)::/64 T:L:A2:ID(s2)::/64 Note that It is possible that "s2" will be allocated T:L:A1:ID(s2)::/64. It is possible that "s1" and "s2" connect with Site-Local address. 2) If administrator of Network1 and 2 regards that Network1 and 2 should be in different Full-Sites, ~~~~~~~~~~~~~~~~~~~~ Projection for numbering of Site-Local Address and Aggregatable Global Address for Network1 and Network2 are differnt. Let's call the projection which is used in Full-Site of Network1 is ID1(link_name) the projection which is used in Full-Site of Network2 is ID2(link_name) Link "s1" in Network1 will be allocated fec0:0:0:ID1(s1)::/64 T:L:A1:ID1(s1)::/64 Link "s2" in Network2 will be allocated fec0:0:0:ID2(s2)::/64 T:L:A2:ID2(s2)::/64 Note that It is impossible that "s2" will be allocated T:L:A1:ID1(s2)::/64. It is impossible that "s1" and "s2" connect with Site-Local address. Which way administrator will select is depends on policy. Another way of define "Site" is that we call that only "Full-Site" in previous definition is "Site", and "Site" in previous is like ,,, "Sub-Site". But "Full-Site" in prev is too ideal to use it as usual, I belive we would define that as "Full-Site". Give me your comment? ---- Tomohide Nagashima tomohide@japan-telecom.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 Mar 28 07:51:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SFp1Im009414 for ; Wed, 28 Mar 2001 07:51:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SFp18e009413 for ipng-dist; Wed, 28 Mar 2001 07: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SFoqIm009406 for ; Wed, 28 Mar 2001 07:50:52 -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 HAA25897 for ; Wed, 28 Mar 2001 07:50:53 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09676 for ; Wed, 28 Mar 2001 07:50:48 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SFpEw25512 for ; Wed, 28 Mar 2001 09:51:14 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Mar 2001 09:49:11 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Mar 2001 09:49:11 -0600 Message-ID: To: deering@cisco.com, Bob.Hinden@nokia.com Cc: Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com Subject: Input to You as Chairs of IPng Date: Wed, 28 Mar 2001 09:49:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve and Bob, First of all you have done an outstanding job as Chairs and the Leaders of the IETF IPv6 Band since I met you at the Amsterdam IETF in 1993. You have been a guiding light and not dictating force with the working group. You have permitted new ideas to be presented and given all parties at all times the opportunity to present their technical case to the working group. You have also lead by example through your own individual technical contributions to the IPv6 IETF process. As Chairs you also have taken positions for the working group that may not have been popular or politically correct with our dubious and lately overworked and irksome IESG management team. You demand technical excellence, from yourselves and us; but at the end of the day you ship the specs. You have also went the extra mile out of the IETF to support implementors and the IPv6 Forum, and have kept our IPv6 Web Pages upto date. But, most important for me is that you have "lead" and not just managed this working group, have done it with integrity, and have been consistent with your processes for the working group so we are not surprised or blindsided by decisions. You provide a par excellence example of how an IETF working group should be managed and how the open process for standardization of technical specifications should be executed. You also have done a superb job of differentiating what is the markets role and the IETF's role for standardization, for which I am very happy about as a capitalist and libertarian by nature and makes my life easier back at my day job. Thank You and Good Job Gentlemen, /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 Wed Mar 28 07:54:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SFsvIm009446 for ; Wed, 28 Mar 2001 07:54:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SFsv8O009445 for ipng-dist; Wed, 28 Mar 2001 07: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SFsjIm009438 for ; Wed, 28 Mar 2001 07:54:45 -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 HAA26590 for ; Wed, 28 Mar 2001 07:54:41 -0800 (PST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16032 for ; Wed, 28 Mar 2001 07:54:41 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Wed, 28 Mar 2001 10:54:11 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HS2DBY18; Wed, 28 Mar 2001 10:54:11 -0500 Received: from nortelnetworks.com (archt1hf.us.nortel.com [47.102.148.89]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWRS25; Wed, 28 Mar 2001 10:54:08 -0500 Message-ID: <3AC208EF.9BAE080C@nortelnetworks.com> Date: Wed, 28 Mar 2001 10:53:19 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: Steve Deering , Paul Francis , ipng@sunroof.eng.sun.com Subject: Re: what is a site??? References: <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> <001401c0b3b3$ddcd21a0$0440de87@wireless.meeting.ietf.org> <4.2.2.20010325215038.01af5a50@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Margaret Wasserman wrote: > > Hi Steve, > > >I have a hunch that you, and probably many others, will still find this > >description less than satisfying, preferring a simple, concrete rule for > >defining a site, but perhaps you can at least get a glimmer of the > >general notion that has been mostly buried in my mind and inadequately > >documented so far. > > If I understand correctly, you will also be adding another > restriction to the definition of "site" -- specifically that > the routing structure of site (and/or a link) must be > "convex". That is to say that the shortest routing path > between two nodes within the site must stay entirely within > the site. > > This restriction is required in order for the packet sending > rules defined in the scoping architecture to be correct. > > Right? Yes. I have made a note to add this to the document. Brian > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 10:22:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SIMhIm009740 for ; Wed, 28 Mar 2001 10:22:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SIMhjR009739 for ipng-dist; Wed, 28 Mar 2001 10:22: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SIMYIm009732; Wed, 28 Mar 2001 10:22:34 -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 KAA21598; Wed, 28 Mar 2001 10:22:34 -0800 (PST) From: Imran.Patel@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15341; Wed, 28 Mar 2001 11:22:32 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SIMiH14310; Wed, 28 Mar 2001 21:22:44 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Mar 2001 21:22:31 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Mar 2001 21:22:31 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CE9F@eseis15nok> To: ipng@sunroof.eng.sun.com Cc: iptrans@sunroof.eng.sun.com Subject: pmtu discovery across translators Date: Wed, 28 Mar 2001 21:22:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello all, I have come across some confusion regarding pmtu discovery from ipv6 to ipv4 hosts. According to rfc 2765, when an ipv6 host sends a packet to an ipv4 host thru a translator, it performs pmtu discovery ...however if there is a link on the ipv4 side which has a lesser mtu then a icmpv4 dest unreachable message is sent which is translated to icmpv6 pkt too big message by the translator and sent back to the ipv6 host...thus all goes well and pmtu discovery works end-to-end. However, if there is a link on the ipv4 side with pmtu < 1280 then the ipv6 host will be confused since it is guaranteed 1280 byte pmtu in any case. The IPV6 spec (rfc 2460) has a solution for this too and it states that in such a case, the pmtu should not be decreased beyond 1280 and be kept at 1280 but a frag header be added for every packet sent to the ipv4 destination. But then it also makes a statement like this: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. and for above mentioned scenario it says: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. My question is that how does one know when to add a frag header if pmtu fails?? I guess pmtu discovery can fail due to two reasons: 1. Either there is a router on the ipv6 side which has not implemented pmtu discovery (eg an embedded implementation) and it sends back a next hop mtu = 0. 2. There is a link on the v4 side that has pmtu < 1280 and it sends some next hop mtu value < 1280 Do i need to add the frag header in both of these scenarios or just in the case of scenario 2. And if it is only in the case of scenario 2, then how do i distinguish it from scenario 1?? Also, rfc 2460 comments very little on what happens in case 1. Just: It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC-1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery. So, if there is one such router with no pmtu implementation which makes pmtu discovery fail, then what does a ipv6 end host needs to do?? regards, imran -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 10:34:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SIYOIm009836 for ; Wed, 28 Mar 2001 10:34:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SIYOQc009835 for ipng-dist; Wed, 28 Mar 2001 10:34:24 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SIYFIm009828 for ; Wed, 28 Mar 2001 10:34:15 -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 KAA12274 for ; Wed, 28 Mar 2001 10:34:15 -0800 (PST) From: Imran.Patel@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02451 for ; Wed, 28 Mar 2001 10:34:14 -0800 (PST) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SIYQH16929 for ; Wed, 28 Mar 2001 21:34:26 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 28 Mar 2001 21:34:13 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Mar 2001 21:34:13 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CEA1@eseis15nok> To: ipng@sunroof.eng.sun.com Subject: pmtu across translators Date: Wed, 28 Mar 2001 21:34:13 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello, ok i made a mistake in my previous mail. Actually, pmtu discovery fails if: 1. there is a link in the ipv6 internet which has mtu < 1280 (which shouldn't be possible anyway). 2. if there is a link in the ipv4 side across the translator which has mtu < 1280. So, now my re-framed question is : Do I need to add the frag header to every packet when the pmtu fails?? PS: ignore all the other stuff in previous mail:) regards, imran -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 11:12:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJCaIm010035 for ; Wed, 28 Mar 2001 11:12:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SJCakC010034 for ipng-dist; Wed, 28 Mar 2001 11:12: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJCRIm010027; Wed, 28 Mar 2001 11:12:27 -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 LAA27833; Wed, 28 Mar 2001 11:12:22 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16066; Wed, 28 Mar 2001 12:12:21 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SJCMg28633; Wed, 28 Mar 2001 13:12:22 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Mar 2001 13:12:19 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Mar 2001 13:12:19 -0600 Message-ID: To: Imran.Patel@nokia.com, ipng@sunroof.eng.sun.com Cc: iptrans@sunroof.eng.sun.com Subject: RE: pmtu discovery across translators Date: Wed, 28 Mar 2001 13:09:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think you need to add the frag header if pmtu < 1280 in the case you mention. MPLS TE had to do this for IPv6. Alex Conta is coauthor of that spec and maybe he can comment on how they handled that and it may apply. /jim > -----Original Message----- > From: ext Imran.Patel@nokia.com [mailto:Imran.Patel@nokia.com] > Sent: Wednesday,March 28,2001 1:23 PM > To: ipng@sunroof.eng.sun.com > Cc: iptrans@sunroof.eng.sun.com > Subject: pmtu discovery across translators > > > hello all, > > I have come across some confusion regarding pmtu discovery > from ipv6 to ipv4 > hosts. According to rfc 2765, when an ipv6 host sends a > packet to an ipv4 > host thru a translator, it performs pmtu discovery ...however > if there is a > link on the ipv4 side which has a lesser mtu then a icmpv4 > dest unreachable > message is sent which is translated to icmpv6 pkt too big > message by the > translator and sent back to the ipv6 host...thus all goes > well and pmtu > discovery works end-to-end. However, if there is a link on > the ipv4 side > with pmtu < 1280 then the ipv6 host will be confused since it > is guaranteed > 1280 byte pmtu in any case. The IPV6 spec (rfc 2460) has a > solution for this > too and it states that in such a case, the pmtu should not be > decreased > beyond 1280 and be kept at 1280 but a frag header be added > for every packet > sent to the ipv4 destination. But then it also makes a > statement like this: > > IPv6 requires that every link in the internet have an MTU of 1280 > octets or greater. On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and > reassembly must > be provided at a layer below IPv6. > > and for above mentioned scenario it says: > > In response to an IPv6 packet that is sent to an IPv4 destination > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280. In that case, > the IPv6 node > is not required to reduce the size of subsequent packets > to less than > 1280, but must include a Fragment header in those packets > so that the > IPv6-to-IPv4 translating router can obtain a suitable > Identification > value to use in resulting IPv4 fragments. Note that this means the > payload may have to be reduced to 1232 octets (1280 minus > 40 for the > IPv6 header and 8 for the Fragment header), and smaller still if > additional extension headers are used. > > My question is that how does one know when to add a frag > header if pmtu > fails?? I guess pmtu discovery can fail due to two reasons: > 1. Either there is a router on the ipv6 side which has not > implemented pmtu > discovery (eg an embedded implementation) and it sends back a > next hop mtu = > 0. > 2. There is a link on the v4 side that has pmtu < 1280 and it > sends some > next hop mtu value < 1280 > > Do i need to add the frag header in both of these scenarios > or just in the > case of scenario 2. And if it is only in the case of scenario > 2, then how do > i distinguish it from scenario 1?? > > Also, rfc 2460 comments very little on what happens in case 1. Just: > > It is strongly recommended that IPv6 nodes implement Path MTU > Discovery [RFC-1981], in order to discover and take > advantage of path > MTUs greater than 1280 octets. However, a minimal IPv6 > implementation (e.g., in a boot ROM) may simply restrict itself to > sending packets no larger than 1280 octets, and omit implementation > of Path MTU Discovery. > > So, if there is one such router with no pmtu implementation > which makes pmtu > discovery fail, then what does a ipv6 end host needs to do?? > > > regards, > imran > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 29 00:57:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T8vaIm011319 for ; Thu, 29 Mar 2001 00:57:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2T8va9D011318 for ipng-dist; Thu, 29 Mar 2001 00:57:36 -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] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T8vNIm011311 for ; Thu, 29 Mar 2001 00:57:24 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA26562; Thu, 29 Mar 2001 10:57:19 +0200 (MET DST) Date: Thu, 29 Mar 2001 00:57:17 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: pmtu across translators To: Imran.Patel@nokia.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2D6CADE9B0C6D411A27500508BB3CBD063CEA1@eseis15nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > hello, > ok i made a mistake in my previous mail. Actually, pmtu discovery fails if: > > 1. there is a link in the ipv6 internet which has mtu < 1280 (which > shouldn't be possible anyway). > 2. if there is a link in the ipv4 side across the translator which has mtu < > 1280. > > So, now my re-framed question is : > > Do I need to add the frag header to every packet when the pmtu fails?? RFC 2460 section 5 last paragraph says: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. Does that answer your question? 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 Mar 29 02:56:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TAuRIm011496 for ; Thu, 29 Mar 2001 02:56:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TAuR5Z011495 for ipng-dist; Thu, 29 Mar 2001 02:56: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TAuIIm011488 for ; Thu, 29 Mar 2001 02:56:18 -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 CAA19269 for ; Thu, 29 Mar 2001 02:56:18 -0800 (PST) From: Imran.Patel@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08547 for ; Thu, 29 Mar 2001 02:56:17 -0800 (PST) Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2TAuJS11836 for ; Thu, 29 Mar 2001 13:56:19 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 29 Mar 2001 13:56:14 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 29 Mar 2001 13:55:26 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CEA4@eseis15nok> To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: RE: pmtu across translators Date: Thu, 29 Mar 2001 13:55:22 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > RFC 2460 section 5 last paragraph says: > In response to an IPv6 packet that is sent to an IPv4 destination > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280. In that case, > the IPv6 node > is not required to reduce the size of subsequent packets > to less than > 1280, but must include a Fragment header in those packets > so that the > IPv6-to-IPv4 translating router can obtain a suitable > Identification > value to use in resulting IPv4 fragments. Note that this means the > payload may have to be reduced to 1232 octets (1280 minus > 40 for the > IPv6 header and 8 for the Fragment header), and smaller still if > additional extension headers are used. > > Does that answer your question? I know about that, but my question is whether i need to add a frag header everytime path mtu discovery fails (i.e. i get some mtu value < 1280 from the pkt too big message). The only case when i think pmtu discovery can fail is in the "translator scenario" (do you know of any other cases??). But note that RFC 2460 says that we need to add a frag header "In response to an IPv6 packet that is sent to an IPv4 destination....". I think it should be something like "Add a frag header when pmtu discovery to a destination fails" since we cannot distinguish the case when path mtu discovery is done from ipv6 to ipv4. regards, imran -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 06:40:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TEeTIm011628 for ; Thu, 29 Mar 2001 06:40:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TEeSxx011627 for ipng-dist; Thu, 29 Mar 2001 06:40: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TEeIIm011620 for ; Thu, 29 Mar 2001 06:40:19 -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 GAA18389 for ; Thu, 29 Mar 2001 06:40:19 -0800 (PST) Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19527 for ; Thu, 29 Mar 2001 06:40:18 -0800 (PST) Received: from xtreme (1Cust234.tnt37.rtm1.nl.uu.net [213.116.168.234]) by rubellite.lion-access.net (I-Lab) with SMTP id 6E45C27EC; Thu, 29 Mar 2001 14:40:12 +0000 (GMT) From: "Joris Dobbelsteen" To: "'Tomohide Nagashima'" , , , Cc: Subject: RE: what is a site? Date: Thu, 29 Mar 2001 16:43:03 +0200 Message-ID: <000f01c0b85e$913af290$0d0ca8c0@Joris2K.local> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010328165204O.tomohide@japan-telecom.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >-----Original Message----- >From: owner-ipng@sunroof.eng.sun.com >[mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Tomohide Nagashima >Sent: Wednesday, 28 March 2001 9:52 >To: deering@cisco.com; francis@tahoenetworks.com; kwang1@email.mot.com; >joris.dobbelsteen@mail.com >Cc: ipng@sunroof.eng.sun.com >Subject: Re: what is a site? > > >Hi, > >At least, it is clear that "Site" is a set of links. But is >the subset of Site >the Site ? This means that a site can be a part of another site.... At least, if I get this right... Why would we make a site a part of a site? You get something like this: Company-wide Network |- Sites |- Sites | |- Links | |- Sites | |- ...... |- Links You might benefit from this up to certain extend, but I tends to get a mess of sites and 'sub'-sites. So what's what at the end? Or for site-local addressing, who's local to me? You might get strange siturations: A is in the same site as B and B is in the same site as C, but A isn't (form his/her point of view) not in the same site as C. (However, C things A is in the same site). >I begin to believe this answer is YES.If else, what >do we call that ? >I belive this will be a key of definition of "Site". So a site can be hierarchical and can a site also be a part of two (totally) different sites? Wouldn't this get quite messy... > >I propose definition of "Site" as follows; >I also propose new word "Full-Site". > > (Definition of Site) > A set of link "S" is a Site <==> > "N" is a integer set N = { n | n is integer , 0=< n =< 2^16 }. ~~~~ Why an upper limit? ... N = {n | n is integer, 0= For the "M" which is subset of N; > There is a one-to-one projection from S to M. I got lost here... > > (Definition of Full-Site) > Especially, We call that a Site with M=N is a Full-Site. > >I think Full-Site has no reality , but this word is very useful. >Then we will have these theorem, > > (Theorem) > 1. |M| = |S| i.e. the number of M members is equal to the >number of S members. > 2. Any subset of Site is Site. > 3. Full-Site is Site > > These are obvious. > >Here is a example. > > (Example) There are three links in my network like this; > Link 1 Link 2 > -----+---- --+------- > | | > --+---------+--- > Link 3 > > We select projection as follows, > Projection = { > return 0x000a for Link 1 > return 0x000b for Link 2 > return 0x000c for Link 3 > } > > This is off-cause one-to-one projection from "S" to "M". > M = { 0x000a, 0x000b, 0x000c } is subset of N > > So this "my network" is Site. > > If we select subnet ID as follows, > subnet ID = 0x000a for Link 1 > subnet ID = 0x000b for Link 2 > subnet ID = 0x000c for Link 3 > > then we can select Site-Local Address and Global >Address as follows, > Site-Local Global > Link 1 fec0:0:0:a::/64 BLOB:A:L:a::/64 > Link 2 fec0:0:0:b::/64 BLOB:A:L:b::/64 > Link 3 fec0:0:0:c::/64 BLOB:A:L:c::/64 > (BLOB:A:L::/48 is a prefix from upstream for >this site.) As long as Site-Local addresses are routable over Link 1, 2 and 3, this would be OK for me... > > If we add Link 4 with subnet ID = 0x000d , this new >"my network" > is also Site. We can add link until Site will became >Full-Site. > > (Discussion) > > Let's think about following topology. > [TLA1] [TLA2] > | | > --- > > 1) If administrator of Network1 and 2 regards that both >Network1 and 2 should > be in same Full-Site, > ~~~~~~~~~~~~~~ > Projection for numbering of Site-Local Address and >Aggregatable Global > Address for Network1 and Network2 are same projection >ID(link_name). > > Link "s1" in Network1 will be allocated > fec0:0:0:ID(s1)::/64 > T:L:A1:ID(s1)::/64 > Link "s2" in Network2 will be allocated > fec0:0:0:ID(s2)::/64 > T:L:A2:ID(s2)::/64 > > Note that > It is possible that "s2" will be allocated T:L:A1:ID(s2)::/64. > It is possible that "s1" and "s2" connect with Site-Local address. > > 2) If administrator of Network1 and 2 regards that Network1 >and 2 should be > in different Full-Sites, > ~~~~~~~~~~~~~~~~~~~~ > Projection for numbering of Site-Local Address and >Aggregatable Global > Address for Network1 and Network2 are differnt. Let's call > the projection which is used in Full-Site of Network1 is >ID1(link_name) > the projection which is used in Full-Site of Network2 is >ID2(link_name) > > Link "s1" in Network1 will be allocated > fec0:0:0:ID1(s1)::/64 > T:L:A1:ID1(s1)::/64 > Link "s2" in Network2 will be allocated > fec0:0:0:ID2(s2)::/64 > T:L:A2:ID2(s2)::/64 > > Note that > It is impossible that "s2" will be allocated T:L:A1:ID1(s2)::/64. > It is impossible that "s1" and "s2" connect with >Site-Local address. > I would fully agree.... > Which way administrator will select is depends on policy. > > Another way of define "Site" is that we call that only >"Full-Site" in > previous definition is "Site", and "Site" in previous is like ,,, > "Sub-Site". But "Full-Site" in prev is too ideal to use it as usual, > I believe we would define that as "Full-Site". > >Give me your comment? > I don't see why we should use 'sub-sites'. From my point, this would be quite a stupid move to use sub-sites, it can cause networks to get quite messy. So actually, for me, the definition site, would be enough... Link, in this case, would be a part that requires only a TTL value of 1. This link-local is possible by sending a message with a TTL of 1. >---- >Tomohide Nagashima >tomohide@japan-telecom.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 >-------------------------------------------------------------------- > - Joris -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 08:23:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TGNdIm011910 for ; Thu, 29 Mar 2001 08:23:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TGNdMn011909 for ipng-dist; Thu, 29 Mar 2001 08:23: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TGNUIm011902 for ; Thu, 29 Mar 2001 08:23:30 -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 IAA22358 for ; Thu, 29 Mar 2001 08:23:30 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05667 for ; Thu, 29 Mar 2001 08:23:17 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.10.1/8.10.1) id f2TGN2O04808; Thu, 29 Mar 2001 10:23:02 -0600 (CST) Date: Thu, 29 Mar 2001 10:23:02 -0600 (CST) From: David Borman Message-Id: <200103291623.f2TGN2O04808@frantic.bsdi.com> To: deering@cisco.com, francis@tahoenetworks.com, joris.dobbelsteen@mail.com, kwang1@email.mot.com, tomohide@japan-telecom.co.jp Subject: RE: what is a site? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Joris Dobbelsteen" > Subject: RE: what is a site? > Date: Thu, 29 Mar 2001 16:43:03 +0200 > > >-----Original Message----- > >[mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Tomohide Nagashima > >Sent: Wednesday, 28 March 2001 9:52 > >Subject: Re: what is a site? ... > >At least, it is clear that "Site" is a set of links. But is > >the subset of Site > >the Site ? ... > >I begin to believe this answer is YES.If else, what > >do we call that ? > >I belive this will be a key of definition of "Site". > > So a site can be hierarchical and can a site also be a part of two (totally) > different sites? > Wouldn't this get quite messy... >From the definition of a site-local address in RFC 2373, pg. 10: Site-Local addresses have the following format: | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+----------------------------+ |1111111011| 0 | subnet ID | interface ID | +----------+-------------+-----------+----------------------------+ Site-Local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Routers must not forward any packets with site-local source or destination addresses outside of the site. The address format does not currently allow for hierarchical "site-local" addressing. Just as a machine can be attached to more than one link, with a link-local address on each link, a machine can be attached to more than one site, and thus have a site-local address in each site. The machine has to keep track of what site-local addressess are associated with each site, just as it has to keep track of which link-local addresses are associated with each link. I would expect that the machine would have a (logical) interface for each site to which it is attached. So, one definition of a "site" might be a collection of machines and networks that are all interconnected and accessable via the same set of site-local addresses (ignoring administrative barriers...). You could have a "site within a site", but it wouldn't be a sub-site. The transition points into and out of the "sub-site" would block all site-local addresses from crossing the boundry. So, what you really have is two sites, and what it looks like just depends on how you draw the picture. If the desire was to allow Big Sites to encompass multiple Small Sites, then we'd have to change the addressing format, say: | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+----------------------------+ |1111111011| Site ID | subnet ID | interface ID | +----------+-------------+-----------+----------------------------+ But if a host was to be part of both the big and the small site, it would have to have a site-local address for each site. So, I guess this would be more to allow overlapping sites, as opposed to sub-sites. It just seems like a sub-site when the bigger site totally overlaps the smaller site. But the "Site ID" would still not be guaranteed unique, a machine could still be attached to two Sites that each have the same Site ID. And with the addition of a "Site ID", you'd give people a whole lot more rope to build an administrative nightmare of overlapping sites. Maybe we better first figure out how to use the currently defined site-local addresses before delving into adding a "Site ID"... -David Borman, dab@bsdi.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 Mar 29 09:17:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2THHRIm012106 for ; Thu, 29 Mar 2001 09:17:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2THHQx3012105 for ipng-dist; Thu, 29 Mar 2001 09:17:26 -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] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2THHEIm012096 for ; Thu, 29 Mar 2001 09:17:14 -0800 (PST) Received: from lillen (d-mpk17-85-194.Eng.Sun.COM [129.146.85.194]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA24494; Thu, 29 Mar 2001 19:17:00 +0200 (MET DST) Date: Thu, 29 Mar 2001 09:16:58 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: pmtu across translators To: Imran.Patel@nokia.com Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2D6CADE9B0C6D411A27500508BB3CBD063CEA4@eseis15nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I know about that, but my question is whether i need to add a frag header > everytime path mtu discovery fails (i.e. i get some mtu value < 1280 from > the pkt too big message). I assume the key part is inside the parenthesis above (I haven't heard anybody refer to this as "failure"). In general I think that is the best approach. Note that with SIIT translators the IPv6 node can tell that there is a translator in the path (the destination address is an IPv4-mapped address) but that isn't the case when there is a NAT-PR translator. So apart from calling this "pmtu discovery fails" I agree with you. Erik > The only case when i think pmtu discovery can fail > is in the "translator scenario" (do you know of any other cases??). But note > that RFC 2460 says that we need to add a frag header "In response to an IPv6 > packet that is sent to an IPv4 destination....". I think it should be > something like "Add a frag header when pmtu discovery to a destination > fails" since we cannot distinguish the case when path mtu discovery is done > from ipv6 to ipv4. > > regards, > imran > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 30 02:55:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UAtkIm014317 for ; Fri, 30 Mar 2001 02:55:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UAtkPK014316 for ipng-dist; Fri, 30 Mar 2001 02:55: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UAtaIm014309 for ; Fri, 30 Mar 2001 02:55:37 -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 CAA16475 for ; Fri, 30 Mar 2001 02:55:36 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA10509 for ; Fri, 30 Mar 2001 02:55:33 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA06944; Fri, 30 Mar 2001 20:55:16 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Niall Richard Murphy Cc: Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: an unplanned benefit of IPv6 In-Reply-To: Your message of "Tue, 27 Mar 2001 23:45:50 +0100." <20010327234550.A43015@enigma.ie> Date: Fri, 30 Mar 2001 20:55:15 +1000 Message-Id: <13596.985949715@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 27 Mar 2001 23:45:50 +0100 From: Niall Richard Murphy Message-ID: <20010327234550.A43015@enigma.ie> | An unplanned deficit of IPv6: operating without DNS will be much, much | harder. (Particularly if you can't type ":" quickly) That wasn't unplanned, and isn't a defecit - ridding the world of the use of literal IP addresses is one of the things needed to make renumbering conceivable (if not by itself make it easy). 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 Mar 30 03:03:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UB3KIm014358 for ; Fri, 30 Mar 2001 03:03:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UB3Kor014357 for ipng-dist; Fri, 30 Mar 2001 03:03: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UB3BIm014350 for ; Fri, 30 Mar 2001 03:03:11 -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 DAA27550 for ; Fri, 30 Mar 2001 03:03:10 -0800 (PST) Received: from euripides.enigma.ie (euripides.enigma.ie [194.106.143.89]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21383 for ; Fri, 30 Mar 2001 03:03:09 -0800 (PST) Received: (qmail 55446 invoked by uid 1001); 30 Mar 2001 11:03:07 -0000 Date: Fri, 30 Mar 2001 12:03:07 +0100 From: Niall Richard Murphy To: Robert Elz Cc: Niall Richard Murphy , Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: an unplanned benefit of IPv6 Message-ID: <20010330120307.A71610@enigma.ie> Mail-Followup-To: Niall Richard Murphy , Robert Elz , Matt Crawford , ipng@sunroof.eng.sun.com References: <20010327234550.A43015@enigma.ie> <13596.985949715@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <13596.985949715@mundamutti.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Fri, Mar 30, 2001 at 08:55:15PM +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Mar 30, 2001 at 08:55:15PM +1000, Robert Elz wrote: > | An unplanned deficit of IPv6: operating without DNS will be much, much > | harder. (Particularly if you can't type ":" quickly) > That wasn't unplanned, and isn't a defecit - ridding the world of the > use of literal IP addresses is one of the things needed to make > renumbering conceivable (if not by itself make it easy). Perhaps I was exaggerating for the sake of effect :-) I feel there will still be a need to type IPv6 addresses in some circumstances no matter what, unfortunately... Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 30 04:30:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UCUCIm014421 for ; Fri, 30 Mar 2001 04:30:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UCUBs6014420 for ipng-dist; Fri, 30 Mar 2001 04:30: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UCU1Im014413 for ; Fri, 30 Mar 2001 04:30:01 -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 EAA28031 for ; Fri, 30 Mar 2001 04:29:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA29135 for ; Fri, 30 Mar 2001 05:29:58 -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 HAA10698; Fri, 30 Mar 2001 07:29:59 -0500 (EST) Message-Id: <200103301229.HAA10698@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-default-addr-select-03.txt Date: Fri, 30 Mar 2001 07:29:58 -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 IPNG Working Group of the IETF. Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-03.txt Pages : 20 Date : 29-Mar-01 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-03.txt 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-default-addr-select-03.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-default-addr-select-03.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: <20010329144607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-default-addr-select-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010329144607.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 Mar 30 07:53:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UFrgIm014793 for ; Fri, 30 Mar 2001 07:53:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UFrfgx014792 for ipng-dist; Fri, 30 Mar 2001 07:53: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UFrVIm014785 for ; Fri, 30 Mar 2001 07:53:32 -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 HAA29998 for ; Fri, 30 Mar 2001 07:53:31 -0800 (PST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04333 for ; Fri, 30 Mar 2001 07:53:31 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 30 Mar 2001 07:54:17 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Mar 2001 07:54:30 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 30 Mar 2001 07:54:30 -0800 content-class: urn:content-classes:message Subject: RE: an unplanned benefit of IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Mar 2001 07:54:29 -0800 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4678.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: an unplanned benefit of IPv6 Thread-Index: AcC5CXCCo9DlEFH2RPaVDAi0vPALGQAJ7W6w From: "Christian Huitema" To: "Niall Richard Murphy" , "Robert Elz" Cc: "Matt Crawford" , X-OriginalArrivalTime: 30 Mar 2001 15:54:30.0452 (UTC) FILETIME=[B4D13740:01C0B931] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2UFrWIm014786 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Niall Richard Murphy [mailto:niallm-ipng@enigma.ie] > On Fri, Mar 30, 2001 at 08:55:15PM +1000, Robert Elz wrote: > > > | An unplanned deficit of IPv6: operating without DNS will be much, > much > > | harder. (Particularly if you can't type ":" quickly) > > > That wasn't unplanned, and isn't a defecit - ridding the world of the > > use of literal IP addresses is one of the things needed to make > > renumbering conceivable (if not by itself make it easy). > > Perhaps I was exaggerating for the sake of effect :-) > > I feel there will still be a need to type IPv6 addresses in some > circumstance no matter what, unfortunately... We should not equate "operating without the DNS" and "typing addresses by hand." NAPSTER or Gnutella operate without the DNS; SIP only requires DNS entries for the proxies. These systems just exchange addresses as part of their normal operation. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 30 08:38:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGc8Im014914 for ; Fri, 30 Mar 2001 08:38:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UGc8gn014913 for ipng-dist; Fri, 30 Mar 2001 08:38: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGbxIm014906 for ; Fri, 30 Mar 2001 08:37:59 -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 IAA17717 for ; Fri, 30 Mar 2001 08:37:58 -0800 (PST) Received: from fw1-a.osis.gov (fw1-a.osis.gov [204.178.104.233]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA23804 for ; Fri, 30 Mar 2001 08:37:57 -0800 (PST) Received: from neptune.jioc.osis.gov by fw1-a.osis.gov with SMTP id LAA01438 (InterLock SMTP Gateway 4.2 for ); Fri, 30 Mar 2001 11:37:53 -0500 Received: by neptune.jioc.osis.gov with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 10:37:02 -0600 Message-Id: From: "SESVOLD, DALE" To: "'ipng@sunroof.eng.sun.com'" Subject: Single service on IPv6 address Date: Fri, 30 Mar 2001 10:37:01 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B937.A5AA3E00" 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_01C0B937.A5AA3E00 Content-Type: text/plain For anyone who can answer my curiosity, I attended an IPv6 conference hosted at Charleston, SC last fall and heard Robert Kahn talk about using the available IPv6 address space to address services individually. I understand this to mean: example: Server A with ftp, telnet,smtp, http IPv4 Server A 192.168.1.1:21 ftp 192.168.1.1:23 telnet 192.168.1.1:25 smtp 192.168.1.1:80 http IPv6 Server A [3ffe::215:554:ad2:111a]:21 ftp [3ffe::215:554:ad2:211a]:23 telnet [3ffe::215:554:ad2:311a]:25 smtp [3ffe::215:554:ad2:411a]:80 http We see very good security implications. Specifically, identying host OS and vulnerabilities would be difficult if an attacker did not know what multiple services were running on a given host. I could not find any references that any OSes are implementing this today. Is Microsoft, BSD, Linux, Solaris, or any other OS allowing configuration of services in this manner? tia Dale DALE G SESVOLD Senior Network Engineer MacAulay-Brown, Inc JIOC/J61, Vulnerability Assessments ------_=_NextPart_001_01C0B937.A5AA3E00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Single service on IPv6 address

For anyone who can answer my = curiosity,

I attended an IPv6 conference hosted = at Charleston, SC last fall and heard Robert Kahn talk about using the = available IPv6 address space to address services individually.  I = understand this to mean:

example: Server A with ftp, = telnet,smtp, http

IPv4 Server A
        192.168.1.1:21  ftp
        192.168.1.1:23  telnet
        192.168.1.1:25  smtp
        192.168.1.1:80  http

IPv6 Server A
        [3ffe::215:554:ad2:111a]:21     = ftp
        [3ffe::215:554:ad2:211a]:23     = telnet
        [3ffe::215:554:ad2:311a]:25     = smtp
        [3ffe::215:554:ad2:411a]:80     = http

We see very good security = implications.  Specifically, identying host OS and vulnerabilities = would be difficult if an attacker did not know what multiple services = were running on a given host.

I could not find any references that = any OSes are implementing this today.  Is Microsoft, BSD, Linux, = Solaris, or any other OS allowing configuration of services in this = manner?

tia

Dale

DALE G SESVOLD
Senior Network Engineer
MacAulay-Brown, Inc
JIOC/J61, Vulnerability = Assessments

------_=_NextPart_001_01C0B937.A5AA3E00-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 30 08:52:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGqQIm015020 for ; Fri, 30 Mar 2001 08:52:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UGqPKT015019 for ipng-dist; Fri, 30 Mar 2001 08:52:25 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGqGIm015012 for ; Fri, 30 Mar 2001 08:52:16 -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 IAA21156 for ; Fri, 30 Mar 2001 08:52:16 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07262 for ; Fri, 30 Mar 2001 08:52:15 -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 RAA26158; Fri, 30 Mar 2001 17:52:13 +0100 (BST) 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 RAA01333; Fri, 30 Mar 2001 17:52:12 +0100 (BST) Date: Fri, 30 Mar 2001 17:52:13 +0100 (BST) From: Tim Chown To: "SESVOLD, DALE" cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Single service on IPv6 address 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 Fri, 30 Mar 2001, SESVOLD, DALE wrote: > We see very good security implications. Specifically, identying host OS and > vulnerabilities would be difficult if an attacker did not know what multiple > services were running on a given host. > > I could not find any references that any OSes are implementing this today. > Is Microsoft, BSD, Linux, Solaris, or any other OS allowing configuration of > services in this manner? You might want to read here http://www.research.att.com/~smb/papers/index.html Fifth paper down. 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 Mar 30 14:09:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UM9rIm015710 for ; Fri, 30 Mar 2001 14:09:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UM9qoU015709 for ipng-dist; Fri, 30 Mar 2001 14:09: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UM9hIm015702 for ; Fri, 30 Mar 2001 14:09:43 -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 OAA02214 for ; Fri, 30 Mar 2001 14:09:43 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA29234 for ; Fri, 30 Mar 2001 14:09:41 -0800 (PST) Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Mar 2001 14:09:34 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 30 Mar 2001 14:09:05 -0800 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="iso-8859-1" Subject: two drafts Date: Fri, 30 Mar 2001 14:08:44 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF43F@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: two drafts Thread-Index: AcC5ZfjNBG3W+yN2SVuabtjvntSCKQ== From: "Richard Draves" To: "IPng List (E-mail)" X-OriginalArrivalTime: 30 Mar 2001 22:09:06.0093 (UTC) FILETIME=[0957DDD0:01C0B966] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2UM9iIm015703 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Title : Default Router Preferences and More-Specific Routes Author(s) : R. Draves Filename : draft-draves-ipngwg-router-selection-01.txt Pages : 11 Date : 29-Mar-01 Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-03.txt Pages : 20 Date : 29-Mar-01 I submitted the drafts that I presented in Minneapolis. Next week I'll submit new versions that incorporate the comments. I have not yet received any feedback from operational people on the router selection draft. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 30 15:57:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNv0Im016163 for ; Fri, 30 Mar 2001 15:57:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UNv0Yc016162 for ipng-dist; Fri, 30 Mar 2001 15: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNuoIm016155 for ; Fri, 30 Mar 2001 15:56:51 -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 PAA06382 for ; Fri, 30 Mar 2001 15:56:51 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14479 for ; Fri, 30 Mar 2001 15:56:50 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA28696; Fri, 30 Mar 2001 15:56:49 -0800 (PST) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAI12474; Fri, 30 Mar 2001 15:56:45 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: Date: Fri, 30 Mar 2001 15:56:45 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: interim meeting Cc: Bob Hinden Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those who didn't hear this in Minneapolis and haven't read the minutes, note that we are planning to hold an interim meeting of the IPng Working Group on May 30, 31, and June 1, 2001, hosted by Microsoft at their "site" in Redmond, Washington, USA, near Seattle. Part of the time will be spent as a joint meeting with folks from the 3GPP standards bodies that have IPv6 requirements, and there may also be some NGtrans sessions, though the exact times and details for those are still to be worked out. Please send proposed agenda topics to Bob and me. Information about accommodation, driving directions, etc. will be posted here as it becomes available. Bob & Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 30 16:57:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2V0vcIm016288 for ; Fri, 30 Mar 2001 16:57:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2V0vbw1016287 for ipng-dist; Fri, 30 Mar 2001 16:57: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2V0vSIm016280 for ; Fri, 30 Mar 2001 16:57:28 -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 QAA21772 for ; Fri, 30 Mar 2001 16:57:28 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA04654 for ; Fri, 30 Mar 2001 16:57:24 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id AA10920; Sat, 31 Mar 2001 10:57:12 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Niall Richard Murphy Cc: Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: an unplanned benefit of IPv6 In-Reply-To: Your message of "Fri, 30 Mar 2001 12:03:07 +0100." <20010330120307.A71610@enigma.ie> Date: Sat, 31 Mar 2001 10:57:11 +1000 Message-Id: <19697.986000231@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 30 Mar 2001 12:03:07 +0100 From: Niall Richard Murphy Message-ID: <20010330120307.A71610@enigma.ie> | I feel there will still be a need to type IPv6 addresses in some | circumstances no matter what, unfortunately... Yes, of course, that cannot be avoided. The feature is to make it as hard as possible, so no-one wants to do that ahen there is any conceivable better method available. But just typing addresses (or even sending them around in protocols, if they're designed correctly - and I don't know if the ones Christian mentioned are or not) isn't the real problem, it is recording the addresses in places that don't get automatically updated. The real killer to IPv4 renumbering is all the other people that you don't know who have your IPv4 address recorded somewhere for one reason or another. That is what IPv6 really needs to avoid. And that includes making all things like router filter lists be able to use DNS names, and then use them correctly (update them as the TTL's expire automatically). 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 Mar 30 17:30:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2V1UaIm016343 for ; Fri, 30 Mar 2001 17:30:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2V1Uatt016342 for ipng-dist; Fri, 30 Mar 2001 17:30:36 -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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2V1URIm016335 for ; Fri, 30 Mar 2001 17:30:27 -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 RAA23855; Fri, 30 Mar 2001 17:30:26 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16180; Fri, 30 Mar 2001 17:30:25 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA07381; Fri, 30 Mar 2001 17:30:27 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAI14029; Fri, 30 Mar 2001 17:30:22 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: References: Date: Fri, 30 Mar 2001 17:30:26 -0800 To: , ipng@sunroof.eng.sun.com From: Steve Deering Subject: Re: Input to You as Chairs of IPng Cc: Bob.Hinden@nokia.com, narten@raleigh.ibm.com, Erik.Nordmark@eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:49 AM -0600 3/28/01, wrote: >First of all you have done an outstanding job as Chairs... Jim: Thank you for the kind and generous evaluation! Others: For those of you who were not at the meeting in Minneapolis on Thursday of last week and are wondering what might have provoked Jim's message, Bob and I announced that we were interested in receiving feedback about how we are doing as Chairs of the IPng Working Group. We have served in this role for a long time, and thought it would be good to remind you, the group members, that you shouldn't feel shy about letting us or our Area Directors know if you are unhappy with how we've been doing our job or can suggest areas of improvement. We're not soliciting public statements of support (as nice as Jim's was), but rather private feedback, either directly to us or to our ADs, Erik and Thomas (Erik.Nordmark@eng.sun.com and narten@raleigh.ibm.com). Bob and Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 31 00:10:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2V8ABIm016561 for ; Sat, 31 Mar 2001 00:10:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2V8ABge016560 for ipng-dist; Sat, 31 Mar 2001 00:10: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.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2V8A0Im016553 for ; Sat, 31 Mar 2001 00:10:01 -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 AAA26115 for ; Sat, 31 Mar 2001 00:10:00 -0800 (PST) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28120 for ; Sat, 31 Mar 2001 00:09:59 -0800 (PST) Received: by alfa.itea.ntnu.no id KAA0000009821; Sat, 31 Mar 2001 10:07:17 +0200 (MET DST) From: Stig Venås Date: Sat, 31 Mar 2001 10:07:17 +0200 To: Robert Elz Cc: Niall Richard Murphy , Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: an unplanned benefit of IPv6 Message-ID: <20010331100717.A2250@itea.ntnu.no> References: <20010330120307.A71610@enigma.ie> <19697.986000231@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19697.986000231@mundamutti.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Sat, Mar 31, 2001 at 10:57:11AM +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Mar 31, 2001 at 10:57:11AM +1000, Robert Elz wrote: > The real killer to IPv4 renumbering is all the other people that you don't > know who have your IPv4 address recorded somewhere for one reason or > another. That is what IPv6 really needs to avoid. And that includes > making all things like router filter lists be able to use DNS names, > and then use them correctly (update them as the TTL's expire automatically). I agree but.... One problem I see, is that a DNS name might have several addresses, and you might want to filter them differently. Only way out of that, as far as I can see, is to register additional names for each of the addresses. It might be that the filter parsers and builders are able to sort out which addresses cannot apply in some situations, but still. Or you need a filter language where you can say filter those addresses of foo.bar that are "some conditional expression". I think one somehow could make router renumbering actually change prefixes in filter addresses in the filters, something like that must be implemented with great care, if it is possible. Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------