From owner-ipng@sunroof.eng.sun.com Tue Feb 1 06:22:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11EJwZ25593 for ipng-dist; Tue, 1 Feb 2000 06:19:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11EJnj25586 for ; Tue, 1 Feb 2000 06:19:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA01127 for ; Tue, 1 Feb 2000 06:19:49 -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 GAA16809 for ; Tue, 1 Feb 2000 06:19:38 -0800 (PST) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA04811; Tue, 1 Feb 2000 23:07:54 +0900 (JST) Date: Tue, 01 Feb 2000 23:18:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: haberman@nortelnetworks.com, pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: updated PIM for IPv6 draft In-Reply-To: In your message of "Thu, 27 Jan 2000 23:21:15 +0100" <200001272221.XAA02816@givry.inria.fr> References: <200001272221.XAA02816@givry.inria.fr> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 27 Jan 2000 23:21:15 +0100, >>>>> Francis Dupont said: > In your previous mail you wrote: > Does this mean that everyone agrees on the change? > => I agree (ie. the rationate for ICMPv6 checksum applies to PIMv6 one). > Regards > Francis.Dupont@inria.fr > PS: we need a way (flag day?) to solve the interopability issue > introduced by this change. Something might be necessary, but I'm not sure how the interoperability issues are serious. I think there've not been so many implementations of IPv6 PIM yet (unfortunately). Maybe we'll be able to make the status clear in forthcoming interop tests (e.g. connectathon, IPv6 Forum Summit, etc). 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 Feb 1 06:44:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11Ef0425617 for ipng-dist; Tue, 1 Feb 2000 06:41:00 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11Eepj25610 for ; Tue, 1 Feb 2000 06:40:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA25800 for ; Tue, 1 Feb 2000 06:40:51 -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 HAA00414 for ; Tue, 1 Feb 2000 07:40:42 -0700 (MST) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA04938; Tue, 1 Feb 2000 23:27:26 +0900 (JST) Date: Tue, 01 Feb 2000 23:38:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: kre@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: In your message of "Thu, 27 Jan 2000 20:31:37 +1100" <450.948965497@munnari.OZ.AU> References: <450.948965497@munnari.OZ.AU> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 104 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the delayed response. >>>>> On Thu, 27 Jan 2000 20:31:37 +1100, >>>>> Robert Elz said: > Date: Thu, 27 Jan 2000 11:38:51 +0900 > From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > > Message-ID: > | Of course yes in theory, but I'd think that an IPv6 extension header > | rarely needs a length field in more than one byte. > That depends what they end up being used for - I wouldn't like to define > something now which would constrain choices in the future. The (not > accepted but for this purpose that doesn't matter) payload header intended > to allow a UCP or TCP (or anything else) packet to appear in its data > field - clearly a one byte length would never have worked. Okay, I understand your concern. I still believe the structure is useful, but I don't stick to include it in the draft. > | Sorry, the sample code was too simple. In our actual code we of course > | reject an unknown header. > That's good. Then, when you stop parsing the packet when you reach the > unknown header, there's no need to know its length - because there's no > need to skip over it (or do anthing else at all to it). Packet processing > simply stops (and an ICMPv6 can be returned - that also doesn't need to be > able to parse the insides of the unknown header, or anything beyond it). Right, so the proposed structure is for parsing known headers in a generic way. That is, I prefer code like while (len < off) { ip6e = (struct ip6_ext *)(packetbuf + len); switch(nxt) { case IPPROTO_FRAGMENT: len += sizeof(struct ip6_frag); break; case IPPROTO_AH: len += (ip6e->ip6e_len + 2) << 2; break; case IPPROTO_HOPOPTS: case IPPROTO_DSTOPTS: case IPPROTO_ROUTING: len += (ip6e->ip6e_len + 1) << 3; break; default: /* impossible case. discard and/or return an error */ break; } nxt = ip6e->ip6e_nxt; } instead of the following: struct ah *ah; struct ip6_hbh *hbh; struct ip6_dest *dest; struct ip6_rthdr *rthdr; struct ip6_frag *frag; while (len < off) { ip6e = (struct ip6_ext *)(packetbuf + len); switch(nxt) { case IPPROTO_FRAGMENT: frag = (struct ip6_frag *)(packetbuf + len); len += sizeof(struct ip6_frag); nxt = frag->ip6f_nxt; break; case IPPROTO_AH: ah = (struct ah *)(packetbuf + len); len += (ah->ah_len + 2) << 2; nxt = ah->ah_nxt; break; case IPPROTO_HOPOPTS: hbh = (struct ip6_hbh *)(packetbuf + len); len += (hbh->ip6h_len + 1) << 3; nxt = hbh->ip6e_nxt; break; case IPPROTO_DSTOPTS: ....(omitted) case IPPROTO_ROUTING: ....(omitted) default: /* impossible case. discard and/or return an error */ break; } } (BTW: the both examples assume that we have already parsed all the headers correctly and no validation is necessary.) But again, I don't argue it should be in the draft anymore. 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 Feb 1 11:06:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11J3E125842 for ipng-dist; Tue, 1 Feb 2000 11:03:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11J33j25835 for ; Tue, 1 Feb 2000 11:03:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA15401; Tue, 1 Feb 2000 11:03:02 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06022; Tue, 1 Feb 2000 12:02:59 -0700 (MST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA119360; Tue, 1 Feb 2000 19:02:57 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA18220; Tue, 1 Feb 2000 19:02:53 GMT Message-ID: <38972D4F.6280A8F1@hursley.ibm.com> Date: Tue, 01 Feb 2000 13:00:31 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: Erik Nordmark , bmanning@ISI.EDU, ipng@sunroof.eng.sun.com Subject: Re: RESEND: DNS IPv6.INT issue References: <200001280223.VAA0000015375@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A recommendation is all there was. Brian Jim Bound wrote: > > Hi Erik, > > I think the IAB is out of there place here. Not there business other > than writing a recommendation. > > If we can keep ipv6.INT for awhile for nibbles this will work. > I don't see A6 getting deployed and this should not affect it. > So I don't think there is an issue dowm the road. > > As I said ipv6.INT is hard coded on our implementation in the resolver > and I would think others. I just don't want to send out a patch fix for > IPv6 for this reason. > > But I am also responding to the political issue and why do this in the > first place. > > Not trying to shoot the messenger guy... I hope you know that... > > thanks > /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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 1 11:23:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11JKYu25880 for ipng-dist; Tue, 1 Feb 2000 11:20:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11JKNj25873 for ; Tue, 1 Feb 2000 11:20:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA19064 for ; Tue, 1 Feb 2000 11:20:23 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16805 for ; Tue, 1 Feb 2000 12:20:18 -0700 (MST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA136618; Tue, 1 Feb 2000 19:20:16 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA30742; Tue, 1 Feb 2000 19:20:03 GMT Message-ID: <3897314C.28164FED@hursley.ibm.com> Date: Tue, 01 Feb 2000 13:17:32 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Deering CC: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: <200001290148.UAA0000019317@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: ... > > >And I don't know if you noticed, but the IAB has put a lot of effort into > > >blocking apparent attempts by others to put phone numbers into IPv6 > > >addresses. For example, see . > > > >Only by fiat as someone told me about it. If it was sent out as a URL > >for information to the community I missed that? Was it? > > I don't remember exactly, but I think the full text was posted to the > general IETF list, as well as being installed on the IAB web pages. > I'm sure Brian will correct me if I'm wrong. I don't have a record of it being sent to ietf-announce, but I think I was actually on vacation at the time, so I may not have everything. It was very public since it went to an ICANN public comments forum. > > >But the letter says the "IETF community" this and "IETF community" that. > >I don't want to get into our old battle but when did the community agree to > >all this the IAB claims they do? I think that on occasion you have to allow the IAB to speak for the community without a plenary debate. We can always be fired. 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 Tue Feb 1 11:25:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11JO6725955 for ipng-dist; Tue, 1 Feb 2000 11:24:06 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11JNsj25948 for ; Tue, 1 Feb 2000 11:23:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA22836 for ; Tue, 1 Feb 2000 11:23:53 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19094 for ; Tue, 1 Feb 2000 12:23:48 -0700 (MST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA278888; Tue, 1 Feb 2000 19:23:46 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA16240; Tue, 1 Feb 2000 19:23:44 GMT Message-ID: <3897322A.8117A271@hursley.ibm.com> Date: Tue, 01 Feb 2000 13:21:14 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: <200001290128.UAA0000016304@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: ... > The ITU can be dealt with but you need to use a large political hammer > and right now the IETF don't have one, except the technical argument. I > say you cannot win these various skirmishes with technical arguments. > You have to apply extreme pressure to places that cause pain sometimes > to get entities to listen. A big hammer is really good because you just > have to swing it once and land it as it covers a lot of area and has a > large mass. The recipient will be stunned so that the next time they > do battle with you they will have respect, then your negotiating > position is much better. As a user of the Internet I don't want to > happen the kind of things you describe above. I think on the IAB and > IESG there are some very good politicians in the ranks and can apply the > tactics to win a battle with entities like the ITU or ETSI. But overall > I don't believe the IESG or IAB have that skill-set as a "group". > What we need maybe is a group of pitt-bull dogs under the ISOC or maybe > under some supportive Govt Agency that will let the pitt-bull dogs out > of their cage when an entity cannot see or won't listen to the > technical arguments which are in the best interest of the Internet (that > I do believe the IESG and IAB are good at if they work with the > implementors when it gets to the details). > An interesting idea, but my experience is that the people with that kind of political skill are almost all in the telephant camp already. That is our basic problem. 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 Tue Feb 1 11:36:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11JWnc25998 for ipng-dist; Tue, 1 Feb 2000 11:32:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11JWdj25991 for ; Tue, 1 Feb 2000 11:32:40 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA21995 for ; Tue, 1 Feb 2000 11:32:39 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02250 for ; Tue, 1 Feb 2000 11:32:38 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA116542; Tue, 1 Feb 2000 19:32:36 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA13470; Tue, 1 Feb 2000 19:32:35 GMT Message-ID: <38973433.3D227B55@hursley.ibm.com> Date: Tue, 01 Feb 2000 13:29:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Narten CC: Bill Manning , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: <200001311925.OAA05926@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > Bill Manning writes: ... > > Since we were told by the IANA that ip6.int is/was ok, > > Really Bill. The world has changed quite a lot since those decisions > where made. Not all for the better. > > > I wonder why the IAB has decided that its not OK and we > > as operators and developers should start second guessing > > IANA and believe them on a potential political debate? > > ICANN deals with TLDs these days, so the question is are we > comfortable with the assumption that ICANN will work things out in > favor of our best interests. In retrospect it was clearly a mistake to mix up two entirely different types of usage in .int; it was a kludge at the time, and it's even less OK now that the world has changed. The *practical* question is whether the cost of fixing that mistake exceeds the cost of not fixing it. That's what we have to decide as engineers. 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 Tue Feb 1 12:55:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11Kqj826060 for ipng-dist; Tue, 1 Feb 2000 12:52:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11KqZj26053 for ; Tue, 1 Feb 2000 12:52:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA07947 for ; Tue, 1 Feb 2000 12:52:35 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12064 for ; Tue, 1 Feb 2000 12:52:34 -0800 (PST) Received: from ix.netcom.com (user-33qsehj.dialup.mindspring.com [199.174.58.51]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id PAA29615; Tue, 1 Feb 2000 15:52:23 -0500 (EST) Message-ID: <38976114.AC2ABCD3@ix.netcom.com> Date: Tue, 01 Feb 2000 14:41:24 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian E Carpenter CC: Thomas Narten , Bill Manning , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: <200001311925.OAA05926@rotala.raleigh.ibm.com> <38973433.3D227B55@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, I am a bit surprised at your comment here Brian. Andy recognized problem/bug always should be fixed, Biran. As a good engineer you do know this. Cost is or should not be of issue. Brian E Carpenter wrote: > Thomas Narten wrote: > > > > Bill Manning writes: > ... > > > Since we were told by the IANA that ip6.int is/was ok, > > > > Really Bill. The world has changed quite a lot since those decisions > > where made. Not all for the better. > > > > > I wonder why the IAB has decided that its not OK and we > > > as operators and developers should start second guessing > > > IANA and believe them on a potential political debate? > > > > ICANN deals with TLDs these days, so the question is are we > > comfortable with the assumption that ICANN will work things out in > > favor of our best interests. > > In retrospect it was clearly a mistake to mix up two entirely > different types of usage in .int; it was a kludge at the time, and > it's even less OK now that the world has changed. The *practical* > question is whether the cost of fixing that mistake exceeds the > cost of not fixing it. That's what we have to decide as engineers. > > 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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 1 12:56:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e11KpoA26051 for ipng-dist; Tue, 1 Feb 2000 12:51:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e11KpYj26044 for ; Tue, 1 Feb 2000 12:51:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA20815 for ; Tue, 1 Feb 2000 12:51:33 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08481 for ; Tue, 1 Feb 2000 13:51:33 -0700 (MST) Received: from ix.netcom.com (user-33qsehj.dialup.mindspring.com [199.174.58.51]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id PAA24443; Tue, 1 Feb 2000 15:49:32 -0500 (EST) Message-ID: <38976069.8EFF65B1@ix.netcom.com> Date: Tue, 01 Feb 2000 14:38:33 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian E Carpenter CC: Steve Deering , Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: <200001290148.UAA0000019317@quarry.zk3.dec.com> <3897314C.28164FED@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, Ok Brian, Your fired! >;) Just joking... I respect your opinion even though I often disagree with it. But vetting this in a public way is a healthy thing. Brian E Carpenter wrote: > Steve Deering wrote: > ... > > > >And I don't know if you noticed, but the IAB has put a lot of effort into > > > >blocking apparent attempts by others to put phone numbers into IPv6 > > > >addresses. For example, see . > > > > > >Only by fiat as someone told me about it. If it was sent out as a URL > > >for information to the community I missed that? Was it? > > > > I don't remember exactly, but I think the full text was posted to the > > general IETF list, as well as being installed on the IAB web pages. > > I'm sure Brian will correct me if I'm wrong. > > I don't have a record of it being sent to ietf-announce, but I think I was > actually on vacation at the time, so I may not have everything. > It was very public since it went to an ICANN public comments forum. > > > > > >But the letter says the "IETF community" this and "IETF community" that. > > >I don't want to get into our old battle but when did the community agree to > > >all this the IAB claims they do? > > I think that on occasion you have to allow the IAB to speak for the > community without a plenary debate. We can always be fired. > > 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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 1 20:25:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e124NG526442 for ipng-dist; Tue, 1 Feb 2000 20:23:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e124N7j26435 for ; Tue, 1 Feb 2000 20:23:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA27070 for ; Tue, 1 Feb 2000 20:23:02 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13075 for ; Tue, 1 Feb 2000 21:23:01 -0700 (MST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id C6E79156; Tue, 1 Feb 2000 23:23:00 -0500 (EST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 63590339; Tue, 1 Feb 2000 23:23:00 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000012326; Tue, 1 Feb 2000 23:22:56 -0500 (EST) From: Jim Bound Message-Id: <200002020422.XAA0000012326@quarry.zk3.dec.com> To: Brian Zill Cc: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of "Fri, 28 Jan 2000 19:25:34 PST." <3D2036E25376D31197A100805FEAD892712FEE@RED-MSG-02> Date: Tue, 01 Feb 2000 23:22:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >When implementing the basic API functions for our 1.4 release, there were a >number of places where I had to guess as to what the proper behavior should >be. So I'm soliciting clarifications from anyone with an opinion, >especially the RFC authors, and would also like to hear what other existing >implementations do. I am responding serially so I will get to all the responses to your mail too eventually. I am sure when we are done all will still not be totally defined. As a note it would help if all would space their questions out individually and not with runon sentences so I can respond (or others) to each question or comment as they occur inline. thanks... >I'm primarily interested in answers to the getaddrinfo and getnameinfo >questions, but I'll do this in the order they're presented in the RFC. If >this whole thing is too long to wade through, please at least look at those. We need to address each detail so thats fine. >Section 3.10, sockaddr_storage: >I believe the consensus now is to use ss_family and not __ss_family. >Correct me if I'm wrong. That is correct and as it is specified in XNS 5.2 as specified in sys/sockets.h. >Section 6.1, getipnodebyname: >What is the namespace for error_num? Regular system error number space, or >a private one? Four errors are explicitly listed (HOST_NOT_FOUND, >NO_ADDRESS, NO_RECOVERY, and TRY_AGAIN). The spec doesn't say that we're >supposed to define these in an include file somewhere, so I assumed that >you're supposed to use the system error codes that are the closest in >meaning. Is this correct? It is not specified if it is to be regular or private system number space its an implementation choice. But it must be thread safe. Yes that is correct and all that is expected. >Also, the text says "error_num will be set to one of the following values" >and then lists only the above four errors. Is the intent really that no >other errors are acceptable? I could see returning errors for invalid >arguments, things that would fault, etc. We currently return an invalid >argument error if the combination of the "af" and "flags" arguments yield a >name resolution lookup type we don't support. Likewise we return a fault >error code if the name argument is NULL, and an out of memory error code if >the system can't allocate space to hold the returned hostent structure. Is >this o.k.? Yes that is fine. The error returns assume that the function was able to execute when passed in correctly and after editing errors. This is a good point. We could extend the meaning of TRY_AGAIN to mean specific implementation error codes can be passed in. I could argue that NULL is HOST_NOT_FOUND, and likewise for an unsupported af and flags argument. Another way to treat it is with EINVAL for the cases you mention. But as we are deprecating the use of this API I suggest we not spend a lot of time on its syntax or semantics at this point. >And is returning a fault error better than just letting the user's code >fault? For this API, I think it is. Yes it is. >The AI_ADDRCONFIG flag is supposed to indicate that a AAAA query "should >occur only if the node has at least one IPv6 source address configured". I >assume this definition excludes the loopback address. Does it also exclude >link-local? If our stack is present on a machine with interfaces, then >people will have link-local addresses even if they don't have any native >IPv6 connectivity to anywhere off of their local link. But maybe the >machine they issued the query for is a node on the local link... How about >automatic tunneling addresses? We automatically assign one of those for >every IPv4 address, so if you have an IPv4 address, you have an IPv6 address >that can reach any other IPv6 enabled machine on the IPv4 Internet. And if >you don't have an IPv4 address, then you're probably not issuing a >getaddrinfo call with this flag set. It specifies the address must be a valid IPv4 or IPv6 source address. The intention was that it was an address that has been configured for an IPv6 interface. I think loopback should be excluded. I do not think tunnels apply as they are psuedo-interfaces. I think link-local is valid. I think what is a valid IPv6 source address in RFC 2373 is the test. We need to move this field to getaddrinfo section too. We can add these parameters but I would like to hear what other implementors think and how they have implemented it. I would think the simple case is the loopback is excluded and the addresses are retrieved that have actually been configured for an interface not a psuedo-interface. >Section 6.2 getipnodebyaddr: >The same error code issue that I asked about for getipnodebyname applies >here as well. >Again, we return errors that aren't explicitly listed: a fault error instead >of faulting if "src" is a NULL pointer, an invalid arguments error if "len" >isn't the right size for the given "af", and an address family not supported >error if "af" isn't one of the address families we support. same answers as previously provided. >Section 6.3 freehostent: >I have the same question that Itojun just asked about freeaddrinfo - what to >do if "ptr" is NULL? You can't return an error, so the options are to take >a fault, or just ignore the call. I agree with itojun that you should take >the fault -- this is a good way to get the programmer's attention that there >is something wrong with their code. Changing the call to return an error >code doesn't strike me as any better than just silently ignoring a NULL ptr >since far too many programmers don't bother to check return values from >calls like this. I agree returing an error is not good what XNS did is specify the programmer must only pass pointers provided by getipnodebyname and getipnodebyaddr. But this is deprecated too. We should make sure freeaddrinfo is correct. >Section 6.4 freeaddrinfo: >Exact same issue as for freehostent. Take the fault but further specify as XNS 5.2 did where the pointer must come from. >Section 6.4 getaddrinfo: >The spec is explicit about getaddrinfo having its own error code namespace >and what the various EAI_* error codes are. It's not always clear about >which one to use in certain situations, however. For example, EAI_SERVICE >means "servname not supported for ai_socktype". But there's also EAI_NONAME >for "nodename nor servname provided, or not known". So what to return if >someone gives you a service name that isn't valid for the requested socket >type? Am I actually expected to look up the service name for all other >socket types just so I can return EAI_SERVICE if it exists and EAI_NONAME if >it doesn't? Yes. But XNS provides much more info on error code processing and we should bring that into the discussion. Can you look at XNS version? And then comment. >Also, the spec says that in the "hints" structure, "all members >other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or >a NULL pointer". Okay, but what error code do I return if they aren't? >None really seem to apply, so currently I'm returning EAI_FAIL. EAI_FAIL is what I would use. This is indicative of the sockets API I have no issue adding additional more defined error codes. But do others want to do this too. >The existence of the EAI_BADFLAGS error implies that there is a combination >of input parameters that would warrant such a return value. Am I really >supposed to return this if I see a flag I don't recognize? That would make >it hard to introduce new flags in the future as new programs requesting the >new flag would fail on old systems. So I don't do that. This is a problem and one we need to fix. Good catch. XNS did not fix this either. But we are faced with changing and altering a non-IETF API and spec???? We can't really own this API like we did getipnodebyname (not ownership in the sense of a standard but "control"). But I am not sure we can make all old systems work anyway in all cases. >The precise meaning of the AI_CANONNAME flag is unclear to me. It says >that if this flag is set, then upon return, the first addrinfo struct's >ai_canonname field will point to "a null terminated string containing the >canonical name of the specified nodename". Someone define canonical name >for me please. Is this supposed to be the fully qualified domain name for >the host that, in DNS parlance, you get if you follow all the alias >pointers? Its the CNAME for the nodename in DNSese. Does that help? >But what if someone passes in an IPv6 address literal into >getaddrinfo when this flag is set? Am I supposed to do a reverse address >lookup just to fill in the ai_canonname field? No. I think thats bad flags. But we should discuss. I suppose it could be done I would argue it should not be done. In fact I would assume AI_NUMBERICHOST operation and the two cannot be set together? >I'm thinking yes, although I >currently don't do that. But what if AI_NUMERICHOST is also set? The text >describing AI_NUMERICHOST states "this flag prevents any type of name >resolution service from being called", so I'd think I couldn't perform a >reverse address lookup in that case. Or maybe I can -- does "any type of >name resolution service" include looking in /etc/hosts or a local cache of >previous DNS lookups? If the only reason to avoid a "name resolution >service" is to prevent the delay of hitting the DNS or equivalent, then that >might be o.k. If it really means that one is forbidden from finding some >sort of "canonical name" (I assume an address literal doesn't qualify) by >any means, does this make it illegal to set both the AI_CANONNAME and >AI_NUMERICHOST flags? Currently I return EAI_BADFLAGS in this case -- hey, >a use for that error code after all! yes I think its illegal and we should say that. >What am I supposed to do if in the "hints" structure, someone passes in a >value for ai_socktype that is at odds with ai_protocol? (e.g. SOCK_STREAM >with UDP). Is getaddrinfo supposed to check if the particular triple of >address family, socket type, and protocol is supported on the system? The >existence of the EAI_ADDRFAMILY error implies that just checking that the >address family is supported is enough (which is all I currently do). EAI_ADDRFAMILY is correct I think too. XNS is more verbose but I think we need to define this in text further. >Likewise, the spec isn't clear about whether one should use the value in >ai_socktype or ai_protocol when performing protocol specific service >lookups. The actual port number to name mappings appear to be assigned via >protocol (specifically, UDP and TCP). But the EAI_SERVICE error code says >"servname not supported for ai_socktype", it doesn't say "for ai_protocol". >The spec appears to assume that SOCK_STREAM means TCP and vice-versa, and >SOCK_DGRAM means UDP and vice-versa. Consider this line "if the caller >handles only TCP and not UDP, then the ai_socktype member of the hints >structure should be set to SOCK_STREAM" -- instead of saying that >ai_protocol should be set to IP_PROTOCOL_TCP. Currently, I use ai_socktype >with hardwired mappings from SOCK_STREAM to TCP and SOCK_DGRAM to UDP to >perform the service lookup, and only use ai_protocol to know what to set the >ai_protocol field in the returned addrinfo structures to. I do it this way, >because in my experience, programmers typically leave the protocol value >unspecified in socket() calls, instead choosing to specify the socket type. I think we need to be flexible here as I always specify the protocol value as one person. >In the returned addrinfo structures, the spec is silent on what the ai_flags >field should be. I can think of two possibilities: zero, or whatever was >passed into getaddrinfo in the ai_flags field of the hints structure. >Currently, I always return zero in this field. This should be specified one way or the other. >Section 6.5 getnameinfo: >The spec says "the salen argument gives the length of the sockaddr_in or >sockaddr_in6 structure". An overly pedantic member of our team (ok, it was >Rich :-) thinks this means that salen must exactly equal the length of a >sockaddr_in if sa->sa_family == AF_INET or it must exactly equal the length >of a sockaddr_in6 if sa->sa_family == AF_INET6 (i.e. just insisting salen is >large enough to hold a sockaddr of the appropriate type isn't good enough, >it must be exactly the right size). The rest of us disagree, because that >would mean that you can't call getnameinfo with a pointer to a struct >sockaddr_storage and salen set to sizeof(struct sockaddr_storage). Losing >that capability loses a lot of the address independence feature that makes >getnameinfo so nice in the first place. We'd really like to be able to >perform a getpeername call, with the result going into a sockaddr_storage, >and then be able to just pass that to getnameinfo to find out who we're >talking to without having to add any address family specific code. I would think it should be allowed to support what getpeername returns. Thus Rich is right? But should be more flexible and can we without breaking existing binaries? >The spec doesn't say anything about the error code namespace, so I used the >regular system one. We winged this. Now that getipnodebyname is gone we should think if we can be more verbose here? >Section 6.6 inet_pton: >Should we check if "src" and/or "dst" is a NULL pointer and return an error >(0?) if so? Or just let it fault? For "dst", the spec says that the buffer >it points to must be large enough to hold the expected result, so if we >treat a NULL pointer like any other too-small buffer, faulting would seem >appropriate. For "src" though, it would seem returning 0 (for an invalid >input string) would be appropriate. THe return should be zero as its not valid per the spec. If src is wrong then don't look at dst? >Section 6.6 inet_ntop: >Here the spec says that "dst" must be non-NULL, but doesn't say what error >to set if it isn't. However, ENOSPC is what is supposed to be set if the >size of the buffer "dst" points to is inadequate. So would that apply, >should it be EFAULT, or should we just let it fault? I think ENOSPC is pretty clear? The error condition is intuitive isn't it? As you see it? >The spec doesn't say anything about what to do if "src" is NULL. Options >appear to be to set EFAULT and return NULL, or just let it fault. In this case return EAFNOSUPPORT. A null addr for AF is not supported? We could be more verbose I agree. >The spec doesn't say anything about the error code namespace, although the >names appear to be Unix system error codes (strangely different approach >than the generic names used in Section 6.1 and 6.2 -- presumably different >authors), so I used the regular system one. I would use the system ones and this problem goes away with getipnodebyname gone in the spec. >Well, that's about it, thanks /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 Feb 1 20:40:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e124bWR26465 for ipng-dist; Tue, 1 Feb 2000 20:37:32 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e124bNj26458 for ; Tue, 1 Feb 2000 20:37:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA23412 for ; Tue, 1 Feb 2000 20:37:23 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26700 for ; Tue, 1 Feb 2000 20:37:21 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 86E8D156; Tue, 1 Feb 2000 23:37:21 -0500 (EST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 59CD530E; Tue, 1 Feb 2000 23:37:21 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000014445; Tue, 1 Feb 2000 23:37:20 -0500 (EST) From: Jim Bound Message-Id: <200002020437.XAA0000014445@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Brian Zill , ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of "Sat, 29 Jan 2000 14:41:32 +0900." <5959.949124492@coconut.itojun.org> Date: Tue, 01 Feb 2000 23:37:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi itojun, >>Section 6.4 getaddrinfo: > > (addition) > When host == NULL, loopback addresses and/or wildcard addresses will > be returned. At this moment KAME getaddrinfo returns all the > loopback/wildcard address in address family supported by the kernel. > For example, if you are on top of IPv6-only kernel, getaddrinfo will > return :: or ::1. If you are on dual-stack, getaddrinfo will > return :: and 0.0.0.0, or ::1 and 127.0.0.1. Is the behavior okay? I would say I would like to see consensus on this and hear from other implementors. It does not break binary compatibility so if we have consenus this can be considered. > (addition) > interaction of NI_NUMERICxxx with AF_LOCAL (AF_UNIX), or other address > families where hostname/servname cannot become decimal/hexadecimal > digits. > (Hideaki YOSHIFUJI pointed this out around Jan 19, 2000) Can you please recap the point please. thanks. NI_NUMERICxxx applies specifically to a situation where a failure has occurred. Why would AF_UNIX socket type be a consideration? >>The precise meaning of the AI_CANONNAME flag is unclear to me. It says >>that if this flag is set, then upon return, the first addrinfo struct's >>ai_canonname field will point to "a null terminated string containing the >>canonical name of the specified nodename". Someone define canonical name >>for me please. > > (just additional datapoint) > KAME code copies hp->h_name returned from getipnodebyname(), or > gethostbyname(). Not sure if this is the right answer to "canonical > name". Things gets tricky as > - KAME getaddrinfo calls name resolution twice, once for IPv4 and > once for IPv6 > - and hp->h_name can be different each time. > so KAME code puts ai_canonname for every addrinfo entries, if > AI_CANONNAME is given. If there is a CNAME use it. like ftp CNAME ftphost.foo.oohga >>What am I supposed to do if in the "hints" structure, someone passes in a >>value for ai_socktype that is at odds with ai_protocol? (e.g. SOCK_STREAM >>with UDP). Is getaddrinfo supposed to check if the particular triple of >>address family, socket type, and protocol is supported on the system? The >>existence of the EAI_ADDRFAMILY error implies that just checking that the >>address family is supported is enough (which is all I currently do). > (similar to the above) > The spec does not say how far we need to "glob" the input. > When KAME getaddrinfo is called with the following parameter: > host = "foo.internet.host" > serv = "daytime" > hints.ai_family = PF_UNSPEC > hints.ai_socktype = hints.ai_protocol = 0 > the code would return the following four entries: > AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET, port 13, SOCK_DGRAM, IPPROTO_UDP > AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET6, port 13, SOCK_DGRAM, IPPROTO_UDP > Past KAME code returned SOCK_STREAM only (2 entries), like: > AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP > Which behavior the spec prefer? We need to add the behavior set to the API similar to the behavior we had to getipnodebyname. We pretty much till this point have left getaddrinfo in tact per Posix. We now are going to change it. I believe what you have above is correct IMO returning all AF's and prototypes. > (addition) > is SOCK_RAW allowed in hints.ai_socktype? this is very useful > when we write "ping" which is less-dependent to AF > (hints.ai_protocol is opaque in this case). We need to look at the ramifications. My gut says no use the Advanced API for such things. >>Section 6.5 getnameinfo: > > (addition) > It is not 100% clear how the code should behave when a short buffer > is passed. RFC2553 seems to me to raise error. X/Open says to > truncate the result and success. The most recent ipngwg discussion > preferred RFC2553 (error), if I remember correctly. I will support RFC 2553. So we need to discuss? >>Section 6.5 getnameinfo: >>it must be exactly the right size). The rest of us disagree, because that >>would mean that you can't call getnameinfo with a pointer to a struct >>sockaddr_storage and salen set to sizeof(struct sockaddr_storage). Losing >>that capability loses a lot of the address independence feature that makes >>getnameinfo so nice in the first place. We'd really like to be able to >>perform a getpeername call, with the result going into a sockaddr_storage, >>and then be able to just pass that to getnameinfo to find out who we're >>talking to without having to add any address family specific code. > (comment to brian's) > by the time you call getnameinfo(), you should have done something like > getpeername(sock, &ss, &sslen); > and you have the exact length (like sizeof(sockaddr_in)) in sslen. > you are not passing sizeof(sockaddr_storage) in 2nd arg in this case. > getnameinfo(&ss, sslen, ...) > or, if you have sa_len field, this should be okay: > getnameinfo(&ss, ss.ss_len, ...) This is a good point. If you use &ss and &sslen in getpeername you can use it later for your socket operation. thanks /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 Feb 1 20:49:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e124lb326487 for ipng-dist; Tue, 1 Feb 2000 20:47:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e124lQj26480 for ; Tue, 1 Feb 2000 20:47:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA28561 for ; Tue, 1 Feb 2000 20:47:24 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29293 for ; Tue, 1 Feb 2000 20:47:23 -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/smtpfeed 1.04) with ESMTP id NAA14260; Wed, 2 Feb 2000 13:47:21 +0900 (JST) To: Jim Bound cc: Brian Zill , ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , Dave Thaler In-reply-to: bound's message of Tue, 01 Feb 2000 23:37:20 EST. <200002020437.XAA0000014445@quarry.zk3.dec.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: Clarifications wanted on Basic API (RFC 2553) From: itojun@iijlab.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <14244.949466758.0@coconut.itojun.org> Date: Wed, 02 Feb 2000 13:47:20 +0900 Message-ID: <14258.949466840@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14244.949466758.1@coconut.itojun.org> Content-Transfer-Encoding: 7bit >> (addition) >> interaction of NI_NUMERICxxx with AF_LOCAL (AF_UNIX), or other address >> families where hostname/servname cannot become decimal/hexadecimal >> digits. >> (Hideaki YOSHIFUJI pointed this out around Jan 19, 2000) >Can you please recap the point please. thanks. NI_NUMERICxxx applies >specifically to a situation where a failure has occurred. Why would >AF_UNIX socket type be a consideration? attached. (sorry if you already have a copy) >> (addition) >> is SOCK_RAW allowed in hints.ai_socktype? this is very useful >> when we write "ping" which is less-dependent to AF >> (hints.ai_protocol is opaque in this case). >We need to look at the ramifications. My gut says no use the Advanced >API for such things. Though behavior of raw socket is defined in advanced API, we need to resolve name to use raw socket (for example, to send icmp probe to destination we need to get IPv6 address for the destination). Advanced API does not define name-to-address translation, it relies upon basic API document (getaddrinfo). This is the reason why I brought this up here. >>>Section 6.5 getnameinfo: >> (addition) >> It is not 100% clear how the code should behave when a short buffer >> is passed. RFC2553 seems to me to raise error. X/Open says to >> truncate the result and success. The most recent ipngwg discussion >> preferred RFC2553 (error), if I remember correctly. >I will support RFC 2553. So we need to discuss? I was just unsure about my memory and would like a confirmation from someone. I think my memory was correct. itojun ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Return-Path: Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA10068 for ; Wed, 19 Jan 2000 01:00:25 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08431; Tue, 18 Jan 2000 08:59:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA04466; Tue, 18 Jan 2000 07:58:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0IFtaD09367 for ipng-dist; Tue, 18 Jan 2000 07:55:36 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0IFtPw09360 for ; Tue, 18 Jan 2000 07:55:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA12946 for ; Tue, 18 Jan 2000 07:55:26 -0800 (PST) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07389 for ; Tue, 18 Jan 2000 07:55:24 -0800 (PST) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id AAA01821; Wed, 19 Jan 2000 00:55:23 +0900 To: ipng@sunroof.eng.sun.com CC: drepper@cygnus.com Subject: getnameinfo() with NI_NUMERIC**** X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000119005523T.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 19 Jan 2000 00:55:23 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 82 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org Hi. About getnameinfo(), RFC2553 says: | The POSIX 1003.1g specification includes no function to perform the | reverse conversion from getaddrinfo(): to look up a nodename and | service name, given the binary address and port. Therefore, we | define the following function: | int getnameinfo(const struct sockaddr *sa, socklen_t salen, | char *host, size_t hostlen, | char *serv, size_t servlen, | int flags); | The first argument, sa, points to either a sockaddr_in structure (for | IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP | address and port number. The salen argument gives the length of the | sockaddr_in or sockaddr_in6 structure. The GNU C Library, used as Linux C library, extends getnameindo() to accept a pointer to sockaddr_un structure for PF_LOCAL sockets. I think this extension is natural because getnamefinfo() is a reverse-function of protocol-independent getaddrinfo() function. But, at this time, there are some issues, and I'd like to discuss them on this list. [1] NI_NUMERICHOST If we call getnameinfo() with NI_NUMERICHOST, it should returns in the numeric form of the host's address if sockaddr_in{,6} structure is given. On the other hand, getnameinfo() of the current glibc always returns "localhost" string as a host with sockaddr_un even if getnameinfo() is called with NI_NUMERICHOST. Since "localhost" doen't seem numeric (36-based number??), applications should be cofused. Which is the most appropriate? 1) return in an error 2) return INADDR_LOOPBACK ("127.0.0.1") ? 3) return IN6ADDR_LOOPBACK ("::1") ? 4) "-1" 5) "" 6) "localhost" 7) ? [2] NI_NUMERICSERV If we call getnemeinfo() with NI_NUMERICSERV, it returns in the numeric form of the service address (port number). The getnameinfo() of the current glibc always returns pathname like "/tmp/22", "/tmp/fileasdfgh", or "/whatever/path/to/file". 1st one is from getaddrinfo("localhost", "22") with PF_LOCAL (or PF_UNSPEC) hints. Next one is from getaddrinfo("localhost", NULL) (path is automatically selected), and the last one can be obttained if you call getaddrinfo("localhost", "/whatever/path/to/file"). Which is the most appropriate? 1) return in an error 2) return number if pathname matches ^/tmp/([0-9][0-9]*)$. (I mean, if "/tmp/22", it returns "22") otherwise, return in an error. 3) current behavior (pathname) 4) ? [3] When I complained about above issues, Ulrich Drepper at gnu.org / cygnus.com said, |I've looked a bit closer at the specification and found that it only |mentions AF_INET and AF_INET6. So whoever calls getnameinfo for |AF_LOCAL must expect everything since the behaviour is unspecified. How do you think about this opinion? Thanks in advance. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------- =_aaaaaaaaaa0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 1 22:58:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e126ujT26577 for ipng-dist; Tue, 1 Feb 2000 22:56:45 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e126uaj26570 for ; Tue, 1 Feb 2000 22:56:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA23968 for ; Tue, 1 Feb 2000 22:56:33 -0800 (PST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA04150 for ; Tue, 1 Feb 2000 22:56:33 -0800 (PST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id WAA16997; Tue, 1 Feb 2000 22:53:37 -0800 (PST) From: Bill Manning Message-Id: <200002020653.WAA16997@zephyr.isi.edu> Subject: Re: Clarifications wanted on Basic API (RFC 2553) To: bound@zk3.dec.com (Jim Bound) Date: Tue, 1 Feb 2000 22:53:37 -0800 (PST) Cc: itojun@iijlab.net, bzill@microsoft.com (Brian Zill), ipng@sunroof.eng.sun.com, gilligan@freegate.com ('gilligan@freegate.com'), set@thumper.bellcore.com ('set@thumper.bellcore.com'), bound@zk3.dec.com ('Jim Bound'), DTHALER@exchange.microsoft.com (Dave Thaler) In-Reply-To: <200002020437.XAA0000014445@quarry.zk3.dec.com> from "Jim Bound" at Feb 01, 2000 11:37:20 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Hi itojun, % % >>Section 6.4 getaddrinfo: % > % > (addition) % > When host == NULL, loopback addresses and/or wildcard addresses will % > be returned. At this moment KAME getaddrinfo returns all the % > loopback/wildcard address in address family supported by the kernel. % > For example, if you are on top of IPv6-only kernel, getaddrinfo will % > return :: or ::1. If you are on dual-stack, getaddrinfo will % > return :: and 0.0.0.0, or ::1 and 127.0.0.1. Is the behavior okay? Once, in an early ngtrans mtg (Memphis?) the following form was also considered "legal" ::127.0.0.1 --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 Feb 1 23:06:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e1275ES26595 for ipng-dist; Tue, 1 Feb 2000 23:05:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e12752j26588 for ; Tue, 1 Feb 2000 23:05:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA05611 for ; Tue, 1 Feb 2000 23:05:03 -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 AAA25264 for ; Wed, 2 Feb 2000 00:05:01 -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.04) with ESMTP id QAA16152; Wed, 2 Feb 2000 16:04:53 +0900 (JST) To: Bill Manning cc: bound@zk3.dec.com (Jim Bound), bzill@microsoft.com (Brian Zill), ipng@sunroof.eng.sun.com, gilligan@freegate.com ('gilligan@freegate.com'), set@thumper.bellcore.com ('set@thumper.bellcore.com'), DTHALER@exchange.microsoft.com (Dave Thaler) In-reply-to: bmanning's message of Tue, 01 Feb 2000 22:53:37 PST. <200002020653.WAA16997@zephyr.isi.edu> 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: Clarifications wanted on Basic API (RFC 2553) From: itojun@iijlab.net Date: Wed, 02 Feb 2000 16:04:53 +0900 Message-ID: <16150.949475093@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >% > (addition) >% > When host == NULL, loopback addresses and/or wildcard addresses will >% > be returned. At this moment KAME getaddrinfo returns all the >% > loopback/wildcard address in address family supported by the kernel. >% > For example, if you are on top of IPv6-only kernel, getaddrinfo will >% > return :: or ::1. If you are on dual-stack, getaddrinfo will >% > return :: and 0.0.0.0, or ::1 and 127.0.0.1. Is the behavior okay? > Once, in an early ngtrans mtg (Memphis?) the following form was also > considered "legal" ::127.0.0.1 that is 127.0.0.1 as IPv4 compatible address (RFC1933) - correct? This is not listed in RFC2373 as being loopback address and I don't think we need to list that one. If you use ::127.0.0.1, the node would tunnel IPv6 packet (from/to ::127.0.0.1) into IPv4 packet (from/to 127.0.0.1) packet and send that to loopback interface. I don't see benefit in it except for debugging purposes. getaddrinfo tries to return ai_addr portion that exactly matches with ai_family. So I think returning ::1 (for AF_INET6) and 127.0.0.1 (for AF_INET) is more correct. (for post-2553 getadrinfo, if ai_family is PF_INET6 and ai_flags has AI_ALL|AI_V4MAPPED, story may go different - you will get ::1 and ::127.0.0.1) 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 Tue Feb 1 23:07:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e1276Kf26604 for ipng-dist; Tue, 1 Feb 2000 23:06:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e12764j26597 for ; Tue, 1 Feb 2000 23:06:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA24480 for ; Tue, 1 Feb 2000 23:06: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 AAA25479 for ; Wed, 2 Feb 2000 00:06: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.04) with ESMTP id QAA16197; Wed, 2 Feb 2000 16:06:02 +0900 (JST) To: Bill Manning , bound@zk3.dec.com (Jim Bound), bzill@microsoft.com (Brian Zill), ipng@sunroof.eng.sun.com, gilligan@freegate.com ('gilligan@freegate.com'), set@thumper.bellcore.com ('set@thumper.bellcore.com'), DTHALER@exchange.microsoft.com (Dave Thaler) In-reply-to: itojun's message of Wed, 02 Feb 2000 16:04:53 JST. <16150.949475093@coconut.itojun.org> 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: Clarifications wanted on Basic API (RFC 2553) From: itojun@iijlab.net Date: Wed, 02 Feb 2000 16:06:02 +0900 Message-ID: <16195.949475162@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (for post-2553 getadrinfo, if ai_family is PF_INET6 and ai_flags has > AI_ALL|AI_V4MAPPED, story may go different - you will get ::1 and > ::127.0.0.1) the last line should read ::ffff:127.0.0.1 (v4 mapped). 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 Wed Feb 2 09:30:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e12HRio26877 for ipng-dist; Wed, 2 Feb 2000 09:27:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e12HRYj26870 for ; Wed, 2 Feb 2000 09:27:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA15136 for ; Wed, 2 Feb 2000 09:27:34 -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 JAA23479 for ; Wed, 2 Feb 2000 09:27:31 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA10342; Thu, 3 Feb 2000 02:15:30 +0900 (JST) Date: Thu, 03 Feb 2000 02:26:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. In-Reply-To: In your message of "Thu, 27 Jan 2000 13:04:28 -0500" <200001271804.NAA0000001845@quarry.zk3.dec.com> References: <200001271804.NAA0000001845@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, >>>>> On Thu, 27 Jan 2000 13:04:28 -0500, >>>>> Jim Bound said: > It is time to update because of the scope_id issues RFC 2553, the work will > be rfc2553bis. Before I start changing text, editing etc. I would like to > be clear on the input and issues we need to resolve in the spec. First I > present some assumptions, then the changes in general that must be made per > all the input. Once we get that level of understanding I can then start > changing the spec. All of this needs some discussion. Lastly I present > the reviewers of this update that are needed to achieve consensus on > this spec. > IMPORTANT: The reason we are updating the spec is because of the > scope_id issue. This is not a free-for-all to put everything people > want in the API, we have shipping products now, existing users, and > binary compatibility is imperative for this API and I would also add > source portability. > Assumptions: > Not being done in rfc2553bis at this time I assume these will be info > rfcs?: > A: A paper will be written for scope_ids (carl williams) > B: A paper on concatenating scope_ids and addresses (JINMEI Tatuya) > C: A paper on literal IPv6 addresses with port numbers (TBD) > D: A paper on multihoming API issues (TBD) > E: Others ????????????????? Thanks for referring our draft. We're now locally discussing the draft (B) and will soon be revised the draft including - more text about a background of the scope issues - a (proposed) specific format of scoped addresses with agreement among early implementors Regards. 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 Feb 2 11:07:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e12J4fX27009 for ipng-dist; Wed, 2 Feb 2000 11:04:41 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e12J4aj27002 for ; Wed, 2 Feb 2000 11:04:36 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA18732 for ipng@sunroof.eng.sun.com; Wed, 2 Feb 2000 11:03:16 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e12Imej26957 for ; Wed, 2 Feb 2000 10:48:40 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA08340 for ; Wed, 2 Feb 2000 10:48:39 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA09951 for ; Wed, 2 Feb 2000 10:48:38 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 Feb 2000 10:38:51 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <1BSJFXAY>; Wed, 2 Feb 2000 10:38:51 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A569057F0D17@SIT.platinum.corp.microsoft.com> From: Dave Thaler To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" Subject: RE: Clarifications wanted on Basic API (RFC 2553) Date: Wed, 2 Feb 2000 10:38:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound writes: > >The AI_ADDRCONFIG flag is supposed to indicate that a AAAA > query "should > >occur only if the node has at least one IPv6 source address > configured". I > >assume this definition excludes the loopback address. Does > it also exclude > >link-local? If our stack is present on a machine with > interfaces, then > >people will have link-local addresses even if they don't > have any native > >IPv6 connectivity to anywhere off of their local link. But maybe the > >machine they issued the query for is a node on the local > link... How about > >automatic tunneling addresses? We automatically assign one > of those for > >every IPv4 address, so if you have an IPv4 address, you have > an IPv6 address > >that can reach any other IPv6 enabled machine on the IPv4 > Internet. And if > >you don't have an IPv4 address, then you're probably not issuing a > >getaddrinfo call with this flag set. > > It specifies the address must be a valid IPv4 or IPv6 source address. > The intention was that it was an address that has been > configured for an > IPv6 interface. I think loopback should be excluded. I do not think > tunnels apply as they are psuedo-interfaces. I think link-local is > valid. I think what is a valid IPv6 source address in RFC 2373 is the > test. We need to move this field to getaddrinfo section too. We can > add these parameters but I would like to hear what other implementors > think and how they have implemented it. I would think the simple case > is the loopback is excluded and the addresses are retrieved that have > actually been configured for an interface not a psuedo-interface. I think we need to be very clear here when discussing this point. For example, are we talking about "all addresses on the loopback interface" or are we talking about "the loopback address only"? And are we talking about "all addresses on all pseudo-interfaces" (L2TP tunnels, etc) or a specific pseudo-interface only? > >Section 6.4 getaddrinfo: > >The precise meaning of the AI_CANONNAME flag is unclear to > me. It says > >that if this flag is set, then upon return, the first > addrinfo struct's > >ai_canonname field will point to "a null terminated string > containing the > >canonical name of the specified nodename". [...] > >But what if someone passes in an IPv6 address literal into > >getaddrinfo when this flag is set? Am I supposed to do a > reverse address > >lookup just to fill in the ai_canonname field? > > No. I think thats bad flags. But we should discuss. > I suppose it could be done I would argue it should not be done. > In fact I would assume AI_NUMBERICHOST operation and the two cannot be > set together? > > >I'm thinking yes, although I > >currently don't do that. But what if AI_NUMERICHOST is also > set? The text > >describing AI_NUMERICHOST states "this flag prevents any type of name > >resolution service from being called", so I'd think I > couldn't perform a > >reverse address lookup in that case. Or maybe I can -- does > "any type of > >name resolution service" include looking in /etc/hosts or a > local cache of > >previous DNS lookups? If the only reason to avoid a "name resolution > >service" is to prevent the delay of hitting the DNS or > equivalent, then that > >might be o.k. If it really means that one is forbidden from > finding some > >sort of "canonical name" (I assume an address literal > doesn't qualify) by > >any means, does this make it illegal to set both the AI_CANONNAME and > >AI_NUMERICHOST flags? Currently I return EAI_BADFLAGS in > this case -- hey, > >a use for that error code after all! > > yes I think its illegal and we should say that. Here's a technical argument for the alternative (in short: it's marginally more convenient)... There may be ways that an implementation can obtain the CNAME without doing an off-machine DNS-query (e.g. look in the local cache, or /etc/hosts, or whatever), so setting AI_CANONNAME does not mean that an actual DNS/whatever query needs to be done. The AI_NUMERICHOST is in my opinion most useful for mapping to, for example, the "-n" command line of traceroute, etc. which to me as a user, most often means "I really don't care about the names, just go fast!" :) Finally, such utilities often want to have both the address (in a sockaddr...) and some name (CNAME or not) they can print in messages. The code is simplest if there is some field in addrinfo that it can expect to be filled in in all cases (rather than adding checks to do it one way in one case, and a different way in another case). Today, the only such field is the ai_canonname field, which AI_CANONNAME means to fill in. Hence, the most convenient way for a traceroute-like utility to work is to always set AI_CANONNAME (or another flag that says to fill in another field, if you prefer) so it can use that field to print messages. And to set AI_NUMERICHOST based on whether the -n or equivalent option was specified. If ai_canonname MUST hold a CNAME, then perhaps this is an argument for another field (which perhaps either points to the same thing as ai_canonname or nodename) simply to make the app writer's job easier. Anyhow, that's the technical argument. Now you can discuss whether it's a good or bad idea to add/change something just for the sake of minor convenience :) -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 Wed Feb 2 14:18:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e12MG8827181 for ipng-dist; Wed, 2 Feb 2000 14:16:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e12MFxj27174 for ; Wed, 2 Feb 2000 14:15:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA09875 for ; Wed, 2 Feb 2000 14:15:57 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28819 for ; Wed, 2 Feb 2000 14:15:56 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id C63557BD; Wed, 2 Feb 2000 17:15:55 -0500 (EST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 867C458D; Wed, 2 Feb 2000 17:15:55 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000007170; Wed, 2 Feb 2000 17:15:54 -0500 (EST) From: Jim Bound Message-Id: <200002022215.RAA0000007170@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Brian Zill , ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , Dave Thaler Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of "Wed, 02 Feb 2000 13:47:20 +0900." <14258.949466840@coconut.itojun.org> Date: Wed, 02 Feb 2000 17:15:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, >> (addition) >> is SOCK_RAW allowed in hints.ai_socktype? this is very useful >> when we write "ping" which is less-dependent to AF >> (hints.ai_protocol is opaque in this case). >We need to look at the ramifications. My gut says no use the Advanced >API for such things. Though behavior of raw socket is defined in advanced API, we need to resolve name to use raw socket (for example, to send icmp probe to destination we need to get IPv6 address for the destination). Advanced API does not define name-to-address translation, it relies upon basic API document (getaddrinfo). Ah Ha...yes that is a different model than using gethostbyname today before doing the raw socket. I think we need to consider this and what the ramifications are to the adv api. It seems Francis believes this is doable too. Has Kame code done this yet? > I was just unsure about my memory and would like a confirmation > from someone. I think my memory was correct. OK. I just found out that XNS folks agree with us we should not truncate the name. >About getnameinfo(), RFC2553 says: > >| The POSIX 1003.1g specification includes no function to perform the >| reverse conversion from getaddrinfo(): to look up a nodename and >| service name, given the binary address and port. Therefore, we >| define the following function: >| int getnameinfo(const struct sockaddr *sa, socklen_t salen, >| char *host, size_t hostlen, >| char *serv, size_t servlen, >| int flags); >| The first argument, sa, points to either a sockaddr_in structure (for >| IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP >| address and port number. The salen argument gives the length of the >| sockaddr_in or sockaddr_in6 structure. >The GNU C Library, used as Linux C library, extends getnameindo() >to accept a pointer to sockaddr_un structure for PF_LOCAL sockets. >I think this extension is natural because getnamefinfo() is a >reverse-function of protocol-independent getaddrinfo() function. >But, at this time, there are some issues, and I'd like to discuss >them on this list. So this wants to add PF_LOCAL as AF argument? I would argue this is out-of-scope for rfc2553bis because PF_LOCAL is not an Internet communications problem but local to the implementation? It also does not aid in the solution to Internet problems (or Intranet) as does if*index functions. >[1] NI_NUMERICHOST > >If we call getnameinfo() with NI_NUMERICHOST, it should returns >in the numeric form of the host's address if sockaddr_in{,6} >structure is given. On the other hand, getnameinfo() of the current >glibc always returns "localhost" string as a host with sockaddr_un >even if getnameinfo() is called with NI_NUMERICHOST. >Since "localhost" doen't seem numeric (36-based number??), >applications should be cofused. Which is the most appropriate? > 1) return in an error > 2) return INADDR_LOOPBACK ("127.0.0.1") ? > 3) return IN6ADDR_LOOPBACK ("::1") ? > 4) "-1" > 5) "" > 6) "localhost" > 7) ? I would say glibc is an extension we cannot standardize in the IETF or XNS. But also look at the XNS 5.2 spec as they defined an error space for getnameinfo we need to do for rfc2553bis. >[2] NI_NUMERICSERV > >If we call getnemeinfo() with NI_NUMERICSERV, it returns in the >numeric form of the service address (port number). >The getnameinfo() of the current glibc always returns pathname >like "/tmp/22", "/tmp/fileasdfgh", or "/whatever/path/to/file". >1st one is from getaddrinfo("localhost", "22") with PF_LOCAL >(or PF_UNSPEC) hints. Next one is from getaddrinfo("localhost", >NULL) (path is automatically selected), and the last one can >be obttained if you call getaddrinfo("localhost", >"/whatever/path/to/file"). Which is the most appropriate? > 1) return in an error > 2) return number if pathname matches ^/tmp/([0-9][0-9]*)$. > (I mean, if "/tmp/22", it returns "22") > otherwise, return in an error. > 3) current behavior (pathname) > 4) ? > Same answer as above. >[3] > >When I complained about above issues, Ulrich Drepper at gnu.org / >cygnus.com said, >|I've looked a bit closer at the specification and found that it only >|mentions AF_INET and AF_INET6. So whoever calls getnameinfo for >|AF_LOCAL must expect everything since the behaviour is unspecified. AF_LOCAL likewise is out-of-scope. Its an implementation matter on each platform. >How do you think about this opinion? I think I answered above. thanks /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 Feb 2 14:47:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e12MiRq27223 for ipng-dist; Wed, 2 Feb 2000 14:44:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e12MiJj27216 for ; Wed, 2 Feb 2000 14:44:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA16994 for ; Wed, 2 Feb 2000 14:44:19 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13117 for ; Wed, 2 Feb 2000 14:44:19 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 9DDFC57889; Wed, 2 Feb 2000 16:44:18 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 968CD54601; Wed, 2 Feb 2000 16:44:18 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 7FC83BC4D8; Wed, 2 Feb 2000 16:44:11 -0600 (CST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 23D02B2A42; Wed, 2 Feb 2000 16:44:11 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000031318; Wed, 2 Feb 2000 17:44:17 -0500 (EST) From: Jim Bound Message-Id: <200002022244.RAA0000031318@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. In-reply-to: Your message of "Thu, 03 Feb 2000 02:26:10 +0900." Date: Wed, 02 Feb 2000 17:44:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi JINMEI, >> B: A paper on concatenating scope_ids and addresses (JINMEI Tatuya) > >Thanks for referring our draft. We're now locally discussing the draft >(B) and will soon be revised the draft including >- more text about a background of the scope issues >- a (proposed) specific format of scoped addresses with agreement > among early implementors This is great. I think we need two things from you. 1 is a draft for sure and I think you should go for RFC status. I think informational this also gives you credit for the idea. But also we need something for 2553bis we can get done quickly. Anyway think about my input and let us know. thanks /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 Feb 2 16:32:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e130U8A27342 for ipng-dist; Wed, 2 Feb 2000 16:30:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e130Tvj27335 for ; Wed, 2 Feb 2000 16:29:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA12037 for ; Wed, 2 Feb 2000 16:29:56 -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 RAA19060 for ; Wed, 2 Feb 2000 17:29:56 -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.04) with ESMTP id JAA29955; Thu, 3 Feb 2000 09:29:49 +0900 (JST) To: Jim Bound cc: Brian Zill , ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , Dave Thaler In-reply-to: bound's message of Wed, 02 Feb 2000 17:15:54 EST. <200002022215.RAA0000007170@quarry.zk3.dec.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: Clarifications wanted on Basic API (RFC 2553) From: itojun@iijlab.net Date: Thu, 03 Feb 2000 09:29:49 +0900 Message-ID: <29953.949537789@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Though behavior of raw socket is defined in advanced API, we need to >> resolve name to use raw socket (for example, to send icmp probe >> to destination we need to get IPv6 address for the destination). >> Advanced API does not define name-to-address translation, it relies >> upon basic API document (getaddrinfo). >Ah Ha...yes that is a different model than using gethostbyname today >before doing the raw socket. I think we need to consider this and what >the ramifications are to the adv api. It seems Francis believes this is >doable too. > >Has Kame code done this yet? KAME code already does it, and it is very useful when I write various userland code. 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 Feb 3 09:18:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e13HG6M27819 for ipng-dist; Thu, 3 Feb 2000 09:16:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e13HFuj27812 for ; Thu, 3 Feb 2000 09:15:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA15769 for ; Thu, 3 Feb 2000 09:15: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 JAA02110 for ; Thu, 3 Feb 2000 09:15:56 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA14778; Fri, 4 Feb 2000 02:03:49 +0900 (JST) Date: Fri, 04 Feb 2000 02:14:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. In-Reply-To: In your message of "Wed, 02 Feb 2000 17:44:17 -0500" <200002022244.RAA0000031318@quarry.zk3.dec.com> References: <200002022244.RAA0000031318@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 02 Feb 2000 17:44:17 -0500, >> - more text about a background of the scope issues >> - a (proposed) specific format of scoped addresses with agreement >> among early implementors > This is great. > I think we need two things from you. 1 is a draft for sure and I think > you should go for RFC status. I think informational this also gives you > credit for the idea. Okay, thanks. > But also we need something for 2553bis we can get > done quickly. Anyway think about my input and let us know. Hmm, if you mean some definitions (e.g. macro names of new flags) that are related to 2553bis, I'll try to clarify them ASAP, and will send the result to this list before revising our draft. Regards. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 3 17:34:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e141Vcu28378 for ipng-dist; Thu, 3 Feb 2000 17:31:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e141VTj28371 for ; Thu, 3 Feb 2000 17:31:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA16657 for ; Thu, 3 Feb 2000 17:31:26 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03421 for ; Thu, 3 Feb 2000 17:31:25 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 8D911104C45; Thu, 3 Feb 2000 19:31:25 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 8583CFB101; Thu, 3 Feb 2000 19:31:25 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 50E28BC4CC; Thu, 3 Feb 2000 19:31:18 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id ECAE8B2A43; Thu, 3 Feb 2000 19:31:17 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000012259; Thu, 3 Feb 2000 20:31:24 -0500 (EST) From: Jim Bound Message-Id: <200002040131.UAA0000012259@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. In-reply-to: Your message of "Fri, 04 Feb 2000 02:14:29 +0900." Date: Thu, 03 Feb 2000 20:31:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> But also we need something for 2553bis we can get >> done quickly. Anyway think about my input and let us know. > >Hmm, if you mean some definitions (e.g. macro names of new flags) that >are related to 2553bis, I'll try to clarify them ASAP, and will send >the result to this list before revising our draft. Whoops. If you want to add macros and other needs for parsing thats cool. But I was thinking the text we need to put in rfc2553bis that may be needed so an api developer has a clue. thx /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 Thu Feb 3 17:48:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e141jX828408 for ipng-dist; Thu, 3 Feb 2000 17:45:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e141jNj28401 for ; Thu, 3 Feb 2000 17:45:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA22445 for ; Thu, 3 Feb 2000 17:45:24 -0800 (PST) Received: from hitachi.tdts.com ([209.109.142.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA08489 for ; Thu, 3 Feb 2000 17:45:23 -0800 (PST) Received: from aeon.darkhaven.com (tchipman.tdts.com [207.223.218.66]) by hitachi.tdts.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1FLR7VYB; Thu, 3 Feb 2000 20:44:15 -0500 X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by polaris.net (8.9.2/8.7.6) with ESMTP id UAA18866 for ; Thu, 3 Feb 2000 20:39:16 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA21800; Thu, 3 Feb 2000 17:39:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA00112; Thu, 3 Feb 2000 17:38:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e141Vcu28378 for ipng-dist; Thu, 3 Feb 2000 17:31:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e141VTj28371 for ; Thu, 3 Feb 2000 17:31:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA16657 for ; Thu, 3 Feb 2000 17:31:26 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03421 for ; Thu, 3 Feb 2000 17:31:25 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 8D911104C45; Thu, 3 Feb 2000 19:31:25 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 8583CFB101; Thu, 3 Feb 2000 19:31:25 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 50E28BC4CC; Thu, 3 Feb 2000 19:31:18 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id ECAE8B2A43; Thu, 3 Feb 2000 19:31:17 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000012259; Thu, 3 Feb 2000 20:31:24 -0500 (EST) Message-Id: <200002040131.UAA0000012259@quarry.zk3.dec.com> In-reply-to: Your message of "Fri, 04 Feb 2000 02:14:29 +0900." Date: Thu, 03 Feb 2000 20:43:28 -0500 (EST) X-Mts: smtp Content-Type: text X-UIDL: 9073056aa11cc5c836ec37a97908a59e From: Jim Bound To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> But also we need something for 2553bis we can get >> done quickly. Anyway think about my input and let us know. > >Hmm, if you mean some definitions (e.g. macro names of new flags) that >are related to 2553bis, I'll try to clarify them ASAP, and will send >the result to this list before revising our draft. Whoops. If you want to add macros and other needs for parsing thats cool. But I was thinking the text we need to put in rfc2553bis that may be needed so an api developer has a clue. thx /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 4 06:57:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e14EsKE29498 for ipng-dist; Fri, 4 Feb 2000 06:54:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e14EsA029491 for ; Fri, 4 Feb 2000 06:54:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA11729 for ; Fri, 4 Feb 2000 06:54:11 -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 HAA12840 for ; Fri, 4 Feb 2000 07:54:07 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA18179; Fri, 4 Feb 2000 23:41:59 +0900 (JST) Date: Fri, 04 Feb 2000 23:52:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. In-Reply-To: In your message of "Thu, 03 Feb 2000 20:43:28 -0500 (EST)" <200002040131.UAA0000012259@quarry.zk3.dec.com> References: <200002040131.UAA0000012259@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 03 Feb 2000 20:43:28 -0500 (EST), >>>>> Jim Bound said: >> Hmm, if you mean some definitions (e.g. macro names of new flags) that >> are related to 2553bis, I'll try to clarify them ASAP, and will send >> the result to this list before revising our draft. > Whoops. If you want to add macros and other needs for parsing thats > cool. But I was thinking the text we need to put in rfc2553bis that may > be needed so an api developer has a clue. I see, thanks for the clarification. I'll discuss it in the KAME team and send some text to this list. It would contain an overview of the new address format and relationship between textual addresses and values in the sin6_scope_id field. 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 Feb 4 08:39:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e14Gb0C29626 for ipng-dist; Fri, 4 Feb 2000 08:37:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e14Gap029619 for ; Fri, 4 Feb 2000 08:36:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA02501 for ; Fri, 4 Feb 2000 08:36:51 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17428 for ; Fri, 4 Feb 2000 08:36:51 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 662ED6E1; Fri, 4 Feb 2000 11:36:50 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 4728238E; Fri, 4 Feb 2000 11:36:50 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000023734; Fri, 4 Feb 2000 11:36:49 -0500 (EST) From: Jim Bound Message-Id: <200002041636.LAA0000023734@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. In-reply-to: Your message of "Fri, 04 Feb 2000 23:52:36 +0900." Date: Fri, 04 Feb 2000 11:36:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thank you........any help is going to be highly appreciated by the authors... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 6 20:32:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e174UaN01199 for ipng-dist; Sun, 6 Feb 2000 20:30:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e174UR001192 for ; Sun, 6 Feb 2000 20:30:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA26011 for ; Sun, 6 Feb 2000 20:30:26 -0800 (PST) Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA04578 for ; Sun, 6 Feb 2000 21:30:25 -0700 (MST) Received: from cc.usu.edu by cc.usu.edu (PMDF V5.2-32 #39375) id <01JLLOGAZ7Q89EE3AX@cc.usu.edu> for ipng@sunroof.eng.sun.com; Sun, 6 Feb 2000 21:30:23 MDT Date: Sun, 06 Feb 2000 21:30:22 -0600 (MDT) From: sl531@cc.usu.edu Subject: draft-ietf-mobileip-ipv6-09 In-reply-to: <17191.932383872@coconut.itojun.org> To: itojun@iijlab.net Cc: Aaron Griggs , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I know very little about IPv6 mobility and security issues so correct me if am wrong. Please UNICAST me your expert advice. 1> Draft mention that while transmitting packet if corresponding node's Binding cache has valid care_of_address entry for mobile node's home address then it replaces later by former and append routing header with later as last hop. Do the firewall entertain source routing ?? 2> Also encapsulated packets from home agent can invade foreign network's firewall. Is that acceptable ?? 3> While registering primary care_of_address with its home agent mobile node sends either an AH [9] or ESP [10] header providing sender authentication, data integrity protection, and replay protection, via Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? Thanks. Rajeeb Mishra -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 7 04:49:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e17Ckw701332 for ipng-dist; Mon, 7 Feb 2000 04:46:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e17Ckn001325 for ; Mon, 7 Feb 2000 04:46:49 -0800 (PST) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA02680 for ; Mon, 7 Feb 2000 04:46:47 -0800 (PST) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23373 for ; Mon, 7 Feb 2000 04:36:58 -0800 (PST) Received: from orpheus.amdahl.com (localhost [127.0.0.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id EAA29206 for ; Mon, 7 Feb 2000 04:46:46 -0800 (PST) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.253.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id EAA29202 for ; Mon, 7 Feb 2000 04:46:45 -0800 (PST) Received: from fujitsuI.fujitsu.com (localhost [127.0.0.1]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id EAA05605 for ; Mon, 7 Feb 2000 04:46:13 -0800 (PST) Received: from abroad2.proxy.fujitsu.co.jp (fcvsrv.fujitsu.co.jp [133.161.11.2]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id EAA05575 for ; Mon, 7 Feb 2000 04:45:54 -0800 (PST) Received: from abroad.proxy.fujitsu.co.jp by abroad2.proxy.fujitsu.co.jp (8.9.3/3.7W-9912-Abroad Gateway) id VAA12701; Mon, 7 Feb 2000 21:45:52 +0900 (JST) Received: from m4.gw.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-9912-Abroad Gateway) id VAA15999; Mon, 7 Feb 2000 21:45:52 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id VAA00440; Mon, 7 Feb 2000 21:45:51 +0900 (JST) Received: from localhost (dhcp25.pkt.ts.fujitsu.co.jp [10.36.204.25]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id VAA12474; Mon, 7 Feb 2000 21:45:50 +0900 (JST) To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: non-standard IPv4 form support in getaddrinfo() X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000207214636G.shin@nd.net.fujitsu.co.jp> Date: Mon, 07 Feb 2000 21:46:36 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have one concern in getaddrinfo() and would like to here opinion of other people. RFC2553 says inet_pton() don't support non-standard IPv4 addr forms. (such as. 10.1 for 10.0.0.1) But does it also require getaddrinfo() don't support non-standard IPv4 addr forms? Actually KAME getaddrinfo() uses inet_pton() so KAME doesn't support non-standard IPv4 forms. And recently KAME is being merged into freebsd-current, and several people become upset as they find non-standard IPv4 forms are no longer available. They also use it in their scripts. To think about backword compatibility with many existing scripts, I think abondoning it in getaddrinfo() is not good choice. On the other hand, I think sync'ing getaddrinfo() behaviour between platforms will also be important. Are other platforms actually abondoning or likely to abondon non-standard IPv4 forms in its getaddrinfo() support? Yoshinobu Inoue -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 7 16:31:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e180SWe02246 for ipng-dist; Mon, 7 Feb 2000 16:28:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e180SN002239 for ; Mon, 7 Feb 2000 16:28:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA12147 for ; Mon, 7 Feb 2000 16:28:23 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26860 for ; Mon, 7 Feb 2000 16:28:22 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id ECF3C542; Mon, 7 Feb 2000 19:28:21 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id D283D632; Mon, 7 Feb 2000 19:28:21 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id TAA0000017094; Mon, 7 Feb 2000 19:28:20 -0500 (EST) From: Jim Bound Message-Id: <200002080028.TAA0000017094@quarry.zk3.dec.com> To: Yoshinobu Inoue Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Mon, 07 Feb 2000 21:46:36 +0900." <20000207214636G.shin@nd.net.fujitsu.co.jp> Date: Mon, 07 Feb 2000 19:28:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hello, I have one concern in getaddrinfo() and would like to >here opinion of other people. >RFC2553 says inet_pton() don't support non-standard IPv4 addr >forms. (such as. 10.1 for 10.0.0.1) >But does it also require getaddrinfo() don't support >non-standard IPv4 addr forms? Its not stated. But I don't think we should. >Actually KAME getaddrinfo() uses inet_pton() so KAME doesn't >support non-standard IPv4 forms. I think all of us will do this till scope-ids show up. Then inet_pton don't work. So in that sense adding a scope-id to an address is non-standard. >And recently KAME is being merged into freebsd-current, and >several people become upset as they find non-standard IPv4 >forms are no longer available. They also use it in their >scripts. Why are they doing this? >To think about backword compatibility with many existing >scripts, I think abondoning it in getaddrinfo() is not >good choice. Why how much of a market or set of users are we talking about? >On the other hand, I think sync'ing getaddrinfo() behaviour >between platforms will also be important. Thats the purpose of rfc2553 and xns specs. But we cannot synch all possible combinations. >Are other platforms actually abondoning or likely to abondon >non-standard IPv4 forms in its getaddrinfo() support? right now yes we are. /jim Yoshinobu Inoue -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 7 16:34:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e180XNI02273 for ipng-dist; Mon, 7 Feb 2000 16:33:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e180XD002265 for ; Mon, 7 Feb 2000 16:33:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA08073 for ; Mon, 7 Feb 2000 16:33:13 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA29347 for ; Mon, 7 Feb 2000 16:33:12 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 7A908104BD9; Mon, 7 Feb 2000 18:33:12 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 773A0FB101 for ; Mon, 7 Feb 2000 18:33:12 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 396914FB07; Mon, 7 Feb 2000 18:33:05 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id DF6D24C906 for ; Mon, 7 Feb 2000 18:33:04 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id TAA0000018035; Mon, 7 Feb 2000 19:33:11 -0500 (EST) From: Jim Bound Message-Id: <200002080033.TAA0000018035@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: rfc2553bis getaddrinfo Date: Mon, 07 Feb 2000 19:33:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk folks, 1. I think getaddrinfo should support raw sockets. 2. I do not think getaddrinfo should discuss AF_UNIX/LOCAL as its implememntation defined how that will work, but we should make sure getaddrinfo does not prohibit the use of AF_UNIX/LOCAL. 3. I think its fine to specify AI_CANNONICAL with AI_NUMERICHOST but the behavior is implementation defined if the nodename is an Ipv6 nummeric address (likewise for getnameinfo). We cannot assume DNS implementatons keep non-global addresses in the DNS. Nor can we assume a DNS link-local or site-local lookup or even whats in /etc/hosts, etc... /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 Feb 7 17:24:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e181LOv02340 for ipng-dist; Mon, 7 Feb 2000 17:21:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e181LD002333 for ; Mon, 7 Feb 2000 17:21:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA17516 for ; Mon, 7 Feb 2000 17:21:08 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24689 for ; Mon, 7 Feb 2000 17:21:07 -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 KAA19259; Tue, 8 Feb 2000 10:18:26 +0900 (JST) To: Jim Bound cc: Yoshinobu Inoue , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Mon, 07 Feb 2000 19:28:20 EST. <200002080028.TAA0000017094@quarry.zk3.dec.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: non-standard IPv4 form support in getaddrinfo() From: itojun@iijlab.net Date: Tue, 08 Feb 2000 10:18:26 +0900 Message-ID: <19257.949972706@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm still not sure about it, and I personally prefer using inet_pton(). It is about classful IPv4 address notation, which should have been dead since introduction of CIDR. Examples: 10 = 10.0.0.0, 10.16777215 = 10.255.255.255 10.1 = 10.0.0.1 10.1.1 = 10.1.0.1, >>Hello, I have one concern in getaddrinfo() and would like to >>here opinion of other people. >>RFC2553 says inet_pton() don't support non-standard IPv4 addr >>forms. (such as. 10.1 for 10.0.0.1) >>But does it also require getaddrinfo() don't support >>non-standard IPv4 addr forms? >Its not stated. But I don't think we should. Just for comment: XNS5.2 says - use inet_aton() for numeric IPv4 address decoding, and inet_pton() for IPv6 case. inet_aton() supports classful notation so XNS 5.2 getaddrinfo supports classful notation for IPv4 address. Is it the right behavior to pick? >>Actually KAME getaddrinfo() uses inet_pton() so KAME doesn't >>support non-standard IPv4 forms. >I think all of us will do this till scope-ids show up. Then inet_pton >don't work. So in that sense adding a scope-id to an address is >non-standard. What do you mean by "do this"? Do you mean that, if your getaddrinfo sees "10" it is ambiguous to it? I tend to agree with you but it's not really ambiguous (we have scope boundary character, and scoped address is just for IPv6). >>And recently KAME is being merged into freebsd-current, and >>several people become upset as they find non-standard IPv4 >>forms are no longer available. They also use it in their >>scripts. >Why are they doing this? >>To think about backword compatibility with many existing >>scripts, I think abondoning it in getaddrinfo() is not >>good choice. >Why how much of a market or set of users are we talking about? There are some people still typing % ftp 127.1 % telnet 10.1 and so forth. I personally never use it. 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 Feb 7 17:31:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e181Txq02359 for ipng-dist; Mon, 7 Feb 2000 17:29:59 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e181To002352 for ; Mon, 7 Feb 2000 17:29:51 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA19326 for ; Mon, 7 Feb 2000 17:29:50 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28512 for ; Mon, 7 Feb 2000 17:29:50 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id BD4D9653; Mon, 7 Feb 2000 20:29:49 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 9CAC5790; Mon, 7 Feb 2000 20:29:49 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000026846; Mon, 7 Feb 2000 20:29:49 -0500 (EST) From: Jim Bound Message-Id: <200002080129.UAA0000026846@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Yoshinobu Inoue , ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Tue, 08 Feb 2000 10:18:26 +0900." <19257.949972706@coconut.itojun.org> Date: Mon, 07 Feb 2000 20:29:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm still not sure about it, and I personally prefer using inet_pton(). > It is about classful IPv4 address notation, which should have been > dead since introduction of CIDR. Examples: > 10 = 10.0.0.0, > 10.16777215 = 10.255.255.255 > 10.1 = 10.0.0.1 > 10.1.1 = 10.1.0.1, We have to have some rules that is the way rfc2553 is and I am not clear this should be up for discussion. If you want that then add it to the list. I am against it. >>Hello, I have one concern in getaddrinfo() and would like to >>here opinion of other people. >>RFC2553 says inet_pton() don't support non-standard IPv4 addr >>forms. (such as. 10.1 for 10.0.0.1) >>But does it also require getaddrinfo() don't support >>non-standard IPv4 addr forms? >Its not stated. But I don't think we should. > Just for comment: XNS5.2 says > - use inet_aton() for numeric IPv4 address decoding, and inet_pton() > for IPv6 case. > inet_aton() supports classful notation so XNS 5.2 getaddrinfo > supports classful notation for IPv4 address. > > Is it the right behavior to pick? Not IMO. We had consensus on this previously. >>Actually KAME getaddrinfo() uses inet_pton() so KAME doesn't >>support non-standard IPv4 forms. >I think all of us will do this till scope-ids show up. Then inet_pton >don't work. So in that sense adding a scope-id to an address is >non-standard. What do you mean by "do this"? We will parse for scopes. Do you mean that, if your getaddrinfo sees "10" it is ambiguous to it? Yes. I tend to agree with you but it's not really ambiguous (we have scope boundary character, and scoped address is just for IPv6). I await Jimeni's text. >>And recently KAME is being merged into freebsd-current, and >>several people become upset as they find non-standard IPv4 >>forms are no longer available. They also use it in their >>scripts. >Why are they doing this? >>To think about backword compatibility with many existing >>scripts, I think abondoning it in getaddrinfo() is not >>good choice. >Why how much of a market or set of users are we talking about? There are some people still typing % ftp 127.1 % telnet 10.1 and so forth. I personally never use it. Too bad they loose. /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 Feb 7 17:42:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e181eSp02378 for ipng-dist; Mon, 7 Feb 2000 17:40:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e181eH002371 for ; Mon, 7 Feb 2000 17:40:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA21413 for ; Mon, 7 Feb 2000 17:40:16 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03544 for ; Mon, 7 Feb 2000 17:40:16 -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 KAA19539; Tue, 8 Feb 2000 10:37:40 +0900 (JST) To: Jim Bound cc: shin@kame.net, ipng@sunroof.eng.sun.com In-reply-to: bound's message of Mon, 07 Feb 2000 20:29:49 EST. <200002080129.UAA0000026846@quarry.zk3.dec.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: non-standard IPv4 form support in getaddrinfo() From: itojun@iijlab.net Date: Tue, 08 Feb 2000 10:37:40 +0900 Message-ID: <19537.949973860@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We have to have some rules that is the way rfc2553 is and I am not clear >this should be up for discussion. If you want that then add it to the >list. I am against it. I am against as well so I personally don't ask you to list it:-) >> Just for comment: XNS5.2 says >> - use inet_aton() for numeric IPv4 address decoding, and inet_pton() >> for IPv6 case. >> inet_aton() supports classful notation so XNS 5.2 getaddrinfo >> supports classful notation for IPv4 address. >> Is it the right behavior to pick? >Not IMO. We had consensus on this previously. As long as RFC2553bis and XNS will say the same thing I'll be happy. (I'm NOT saying that XNS behavior should be picked, I'm saying that both have to pick the right behavior) Thanks. 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 Feb 7 18:55:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e182qES02450 for ipng-dist; Mon, 7 Feb 2000 18:52:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e182q5002443 for ; Mon, 7 Feb 2000 18:52:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA01738 for ; Mon, 7 Feb 2000 18:52:03 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03274 for ; Mon, 7 Feb 2000 18:52:03 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 46FC637E; Mon, 7 Feb 2000 21:52:03 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 25CFD1BB; Mon, 7 Feb 2000 21:52:03 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000013679; Mon, 7 Feb 2000 21:52:01 -0500 (EST) From: Jim Bound Message-Id: <200002080252.VAA0000013679@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , shin@kame.net, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Tue, 08 Feb 2000 10:37:40 +0900." <19537.949973860@coconut.itojun.org> Date: Mon, 07 Feb 2000 21:52:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk rfc2553bis and xns will be 100% in synch....as this time xns team is here from the beginning for rfc2553bis update working with the ipng team. at this point my job is really an "editor". part of that job is to make sure we get this done quickly but correctly. thx /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 Feb 7 19:17:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e183Dab02474 for ipng-dist; Mon, 7 Feb 2000 19:13:36 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e183DQ002467 for ; Mon, 7 Feb 2000 19:13:27 -0800 (PST) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA03467 for ; Mon, 7 Feb 2000 19:13:14 -0800 (PST) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15823 for ; Mon, 7 Feb 2000 19:03:25 -0800 (PST) Received: from orpheus.amdahl.com (localhost [127.0.0.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id TAA10278 for ; Mon, 7 Feb 2000 19:13:14 -0800 (PST) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.253.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id TAA10269 for ; Mon, 7 Feb 2000 19:13:13 -0800 (PST) Received: from fujitsuI.fujitsu.com (localhost [127.0.0.1]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id TAA04150 for ; Mon, 7 Feb 2000 19:12:39 -0800 (PST) Received: from abroad2.proxy.fujitsu.co.jp (fcvsrv.fujitsu.co.jp [133.161.11.2]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id TAA04141 for ; Mon, 7 Feb 2000 19:12:37 -0800 (PST) Received: from abroad.proxy.fujitsu.co.jp by abroad2.proxy.fujitsu.co.jp (8.9.3/3.7W-0002-Abroad Gateway) id MAA01591; Tue, 8 Feb 2000 12:12:36 +0900 (JST) Received: from m1.gw.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-0002-Abroad Gateway) id MAA26180; Tue, 8 Feb 2000 12:12:36 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master) id MAA16957; Tue, 8 Feb 2000 12:12:35 +0900 (JST) Received: from localhost ([192.168.245.220]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9912) id MAA06362; Tue, 8 Feb 2000 12:12:33 +0900 (JST) To: bound@zk3.dec.com Cc: itojun@iijlab.net, shin@kame.net, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-Reply-To: <200002080252.VAA0000013679@quarry.zk3.dec.com> References: <19537.949973860@coconut.itojun.org> <200002080252.VAA0000013679@quarry.zk3.dec.com> X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000208121317U.shin@nd.net.fujitsu.co.jp> Date: Tue, 08 Feb 2000 12:13:17 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > rfc2553bis and xns will be 100% in synch....as this time xns team is > here from the beginning for rfc2553bis update working with the ipng > team. at this point my job is really an "editor". part of that job is > to make sure we get this done quickly but correctly. Let me make sure the contents of the fix again, because I might change the code just before release. -RFC2553bis will require inet_pton() for getaddrinfo() resolving numeric IPv4 addr. -XNS spec will be updated to require inet_pton() for getaddrinfo() resolving numeric IPv4 addr. Are these assumptions correct? Yoshinobu Inoue > thx > /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 Feb 8 05:42:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18DeEU02838 for ipng-dist; Tue, 8 Feb 2000 05:40:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18De4002831 for ; Tue, 8 Feb 2000 05:40:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA10332 for ; Tue, 8 Feb 2000 05:40:04 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA21897 for ; Tue, 8 Feb 2000 05:40:03 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 3CB70104BA4; Tue, 8 Feb 2000 07:40:03 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 32629FB101; Tue, 8 Feb 2000 07:40:03 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id D21F8BC4D9; Tue, 8 Feb 2000 07:39:55 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 56B26B2A44; Tue, 8 Feb 2000 07:39:55 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id IAA0000000228; Tue, 8 Feb 2000 08:40:00 -0500 (EST) From: Jim Bound Message-Id: <200002081340.IAA0000000228@quarry.zk3.dec.com> To: Yoshinobu Inoue Cc: bound@zk3.dec.com, itojun@iijlab.net, shin@kame.net, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Tue, 08 Feb 2000 12:13:17 +0900." <20000208121317U.shin@nd.net.fujitsu.co.jp> Date: Tue, 08 Feb 2000 08:40:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yoshinobu, >> rfc2553bis and xns will be 100% in synch....as this time xns team is >> here from the beginning for rfc2553bis update working with the ipng >> team. at this point my job is really an "editor". part of that job is >> to make sure we get this done quickly but correctly. > >Let me make sure the contents of the fix again, because I >might change the code just before release. Be careful. All of us have been burned now 3 times. I personally have changed important network applications twice now. This list takes time to reach consensus. >> -RFC2553bis will require inet_pton() for getaddrinfo() >> resolving numeric IPv4 addr. > > -XNS spec will be updated to require inet_pton() for getaddrinfo() > resolving numeric IPv4 addr. No. We cannot require this and should not state this at all. getaddrinfo is a "middleware" API not a systems API like getipnodebyname. Hence, it does a lot more than just get one address or name. It returns to the programmer and entire set of values in various datastructures depending on what is presented and the flags set. Because we will be permitting users to key in a sin6_scope_id with an address to ftp or telnet as examples inet_pton may or may not be used depending on how an implementation of getaddrinfo parses the string containing scope_id + address. A first level string operation behind the getaddrinfo may parse out first the scope_id then use inet_pton to convert it to a presentable address. Or an implementation may invent a new parser for the string scoped-id + address. inet_pton is a useful tool in rfc2553 which has consensus and implementors can use it or not use it. We do not mandate its use and nor will XNS. >Are these assumptions correct? I think the answer is NO. /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 Feb 8 06:05:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18E23x02878 for ipng-dist; Tue, 8 Feb 2000 06:02:03 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18E1p002871 for ; Tue, 8 Feb 2000 06:01:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA13818 for ; Tue, 8 Feb 2000 06:01:52 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00231 for ; Tue, 8 Feb 2000 06:01:50 -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 WAA27060; Tue, 8 Feb 2000 22:59:09 +0900 (JST) To: Jim Bound cc: Yoshinobu Inoue , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Tue, 08 Feb 2000 08:40:00 EST. <200002081340.IAA0000000228@quarry.zk3.dec.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: non-standard IPv4 form support in getaddrinfo() From: itojun@iijlab.net Date: Tue, 08 Feb 2000 22:59:09 +0900 Message-ID: <27058.950018349@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >No. We cannot require this and should not state this at all. >getaddrinfo is a "middleware" API not a systems API like >getipnodebyname. Hence, it does a lot more than just get one address >or name. It returns to the programmer and entire set of values in >various datastructures depending on what is presented and the flags set. >Because we will be permitting users to key in a sin6_scope_id with an >address to ftp or telnet as examples inet_pton may or may not be used >depending on how an implementation of getaddrinfo parses the string >containing scope_id + address. A first level string operation behind >the getaddrinfo may parse out first the scope_id then use inet_pton to >convert it to a presentable address. Or an implementation may invent a >new parser for the string scoped-id + address. Let me rephrase what shin tried to ask. Will RFC2553bis declare what kind of input string getaddrinfo(3) should take? Independent from the use of scopeid portion, I think there should be clear definition on it. And then, the acceptable IPv4 numeric "input string" set will automatically decide whether classfull notation will be allowed or not. 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 Tue Feb 8 06:47:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18EhhK02914 for ipng-dist; Tue, 8 Feb 2000 06:43:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18EhY002907 for ; Tue, 8 Feb 2000 06:43:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA26675 for ; Tue, 8 Feb 2000 06:43:34 -0800 (PST) Received: from zmamail02.zma.compaq.com ([161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17595 for ; Tue, 8 Feb 2000 06:43:33 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id A4566762; Tue, 8 Feb 2000 09:43:32 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 4EE564C4; Tue, 8 Feb 2000 09:43:32 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000012774; Tue, 8 Feb 2000 09:43:30 -0500 (EST) From: Jim Bound Message-Id: <200002081443.JAA0000012774@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Yoshinobu Inoue , ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Tue, 08 Feb 2000 22:59:09 +0900." <27058.950018349@coconut.itojun.org> Date: Tue, 08 Feb 2000 09:43:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me rephrase what shin tried to ask. Will RFC2553bis declare what kind of input string getaddrinfo(3) should take? Independent from the use of scopeid portion, I think there should be clear definition on it. Its a pointer to a Null terminated string char *nodename. As rfc2553 states: ------------------------ The nodename and servname arguments are pointers to null-terminated strings or NULL. One or both of these two arguments must be a non- NULL pointer. In the normal client scenario, both the nodename and servname are specified. In the normal server scenario, only the servname is specified. A non-NULL nodename string can be either a node name or a numeric host address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). A non-NULL servname string can be either a service name or a decimal port number. --------------------------- What more would you like to see specified. What would you like to see the text say? Then we can discuss it in concrete terms instead of abstract terms. > And then, the acceptable IPv4 numeric "input string" set will > automatically decide whether classfull notation will be allowed or not. I think we need to discuss the above before we can answer this question. thanks /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 Feb 8 07:01:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18EvVS02955 for ipng-dist; Tue, 8 Feb 2000 06:57:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18EvK002948 for ; Tue, 8 Feb 2000 06:57:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA00405 for ; Tue, 8 Feb 2000 06:57:20 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23780 for ; Tue, 8 Feb 2000 06:57:19 -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 XAA28000; Tue, 8 Feb 2000 23:54:45 +0900 (JST) To: Jim Bound cc: Yoshinobu Inoue , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Tue, 08 Feb 2000 09:43:30 EST. <200002081443.JAA0000012774@quarry.zk3.dec.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: non-standard IPv4 form support in getaddrinfo() From: itojun@iijlab.net Date: Tue, 08 Feb 2000 23:54:45 +0900 Message-ID: <27998.950021685@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Its a pointer to a Null terminated string char *nodename. As rfc2553 >states: >------------------------ > The nodename and servname arguments are pointers to null-terminated > strings or NULL. One or both of these two arguments must be a non- > NULL pointer. In the normal client scenario, both the nodename and > servname are specified. In the normal server scenario, only the > servname is specified. A non-NULL nodename string can be either a > node name or a numeric host address string (i.e., a dotted-decimal ~~~~~~~~~~~~~~~~~~~~~~ > IPv4 address or an IPv6 hex address). A non-NULL servname string can ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > be either a service name or a decimal port number. >--------------------------- >What more would you like to see specified. What would you like to see >the text say? Then we can discuss it in concrete terms instead of >abstract terms. >> And then, the acceptable IPv4 numeric "input string" set will >> automatically decide whether classfull notation will be allowed or not. >I think we need to discuss the above before we can answer this question. I see, "dotted-decimal IPv4 address" in the above was not clear enough and this leaded to difference in understanding (between "allow classful notation" and "disallow it"). I personally prefer the following text to be added, or the following text to replace the line in the paren (underlined part). itojun For IPv4 numeric address, getaddrinfo accepts what inet_pton() takes. For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes, and the extended numeric IPv6 address format for scoped addresses defined in *jinmei draft*. (To recap for discussion purposes, inet_pton() takes the following: it will take dotted-quad decimals. If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where ddd is a one to three digit decimal number between 0 and 255. Note that many implementations of the existing inet_addr() and inet_aton() functions accept nonstandard input: octal numbers, hexadecimal numbers, and fewer than four numbers. inet_pton() does not accept these formats. ) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 8 07:47:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18FivI03008 for ipng-dist; Tue, 8 Feb 2000 07:44:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18Fim003001 for ; Tue, 8 Feb 2000 07:44:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA27508 for ; Tue, 8 Feb 2000 07:44:47 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06094 for ; Tue, 8 Feb 2000 08:44:46 -0700 (MST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 38ECD104B9D; Tue, 8 Feb 2000 09:44:46 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 33B86FB101; Tue, 8 Feb 2000 09:44:46 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id D93EB4FB0C; Tue, 8 Feb 2000 09:44:38 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 6B61B4C901; Tue, 8 Feb 2000 09:44:38 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000025221; Tue, 8 Feb 2000 10:44:43 -0500 (EST) From: Jim Bound Message-Id: <200002081544.KAA0000025221@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Yoshinobu Inoue , ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Tue, 08 Feb 2000 23:54:45 +0900." <27998.950021685@coconut.itojun.org> Date: Tue, 08 Feb 2000 10:44:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, >> The nodename and servname arguments are pointers to null-terminated >> strings or NULL. One or both of these two arguments must be a non- >> NULL pointer. In the normal client scenario, both the nodename and >> servname are specified. In the normal server scenario, only the >> servname is specified. A non-NULL nodename string can be either a >> node name or a numeric host address string (i.e., a dotted-decimal >~~~~~~~~~~~~~~~~~~~~~~ >> IPv4 address or an IPv6 hex address). A non-NULL servname string can >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> And then, the acceptable IPv4 numeric "input string" set will >>> automatically decide whether classfull notation will be allowed or not. >>I think we need to discuss the above before we can answer this question. > I see, "dotted-decimal IPv4 address" in the above was not clear enough > and this leaded to difference in understanding (between "allow classful > notation" and "disallow it"). I think its very clear and well defined. It seems to me you want it to do more and not that its not clear. I wrote the first implementation of it and it was perfectly clear to me as one implementors opinion. > I personally prefer the following text to be added, or the following > text to replace the line in the paren (underlined part). >For IPv4 numeric address, getaddrinfo accepts what inet_pton() takes. I don't think we should do this and limit how getaddrinfo processes IPv4 numeric addresses in the future. >For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes, >and the extended numeric IPv6 address format for scoped >addresses defined in *jinmei draft*. This is totally unacceptable to me as an implementor I do not want to change the syntax, semantics, or behavior of inet_pton or inet_ntop which it would have to change to support jinmei's draft. This will require a new API parser. We should not change inet_pton in rfc2553 at all. Is my feeling. The ramifications to installed base are to negative. >(To recap for discussion purposes, inet_pton() takes the following: > it will take dotted-quad decimals. > If the af argument is AF_INET, the function accepts a string in the > standard IPv4 dotted-decimal form: > ddd.ddd.ddd.ddd > > where ddd is a one to three digit decimal number between 0 and 255. > Note that many implementations of the existing inet_addr() and > inet_aton() functions accept nonstandard input: octal numbers, > hexadecimal numbers, and fewer than four numbers. inet_pton() does > not accept these formats. ) /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 Feb 8 07:58:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18FtU703060 for ipng-dist; Tue, 8 Feb 2000 07:55:30 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18FtK003053 for ; Tue, 8 Feb 2000 07:55:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24617 for ; Tue, 8 Feb 2000 07:55:19 -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 IAA11909 for ; Tue, 8 Feb 2000 08:55:17 -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 AAA29051; Wed, 9 Feb 2000 00:52:40 +0900 (JST) To: Jim Bound cc: Yoshinobu Inoue , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Tue, 08 Feb 2000 10:44:43 EST. <200002081544.KAA0000025221@quarry.zk3.dec.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: non-standard IPv4 form support in getaddrinfo() From: itojun@iijlab.net Date: Wed, 09 Feb 2000 00:52:40 +0900 Message-ID: <29049.950025160@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I see, "dotted-decimal IPv4 address" in the above was not clear enough >> and this leaded to difference in understanding (between "allow classful >> notation" and "disallow it"). >I think its very clear and well defined. It seems to me you want it to >do more and not that its not clear. I wrote the first implementation of >it and it was perfectly clear to me as one implementors opinion. >I don't think we should do this and limit how getaddrinfo processes IPv4 >numeric addresses in the future. I see, is there any chance to put reference to "(standard) dotted-decimal IPv4 address"? i think XNS and RFC2553 disagreed in some point in the past, due to the text around here. getaddrinfo() description is less clear than what inet_pton() description says. >>For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes, >>and the extended numeric IPv6 address format for scoped >>addresses defined in *jinmei draft*. >This is totally unacceptable to me as an implementor I do not want to >change the syntax, semantics, or behavior of inet_pton or inet_ntop >which it would have to change to support jinmei's draft. This will >require a new API parser. >We should not change inet_pton in rfc2553 at all. Is my feeling. >The ramifications to installed base are to negative. (maybe due to my poor english skill) I never tried to suggest change inet_pton() behavior in the above. I think you are misreading the above. we do not need to change inet_pton() behavior at all. For simple (standard) IPv6 numeric, getaddrinfo() needs to just call inet_pton() (or some other supporting function). To support jinmei draft, getaddrinfo() needs to do (1) scope-address splitting, (2) scope parsing and (3) call inet_pton(). 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 Tue Feb 8 08:22:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18GJYT03116 for ipng-dist; Tue, 8 Feb 2000 08:19:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18GJO003109 for ; Tue, 8 Feb 2000 08:19:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25545 for ; Tue, 8 Feb 2000 08:19:24 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05300 for ; Tue, 8 Feb 2000 08:19:23 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 6B49857905; Tue, 8 Feb 2000 10:19:23 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 68D8054601 for ; Tue, 8 Feb 2000 10:19:23 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 4720D4FB0C; Tue, 8 Feb 2000 10:19:16 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id EAB3E4C903 for ; Tue, 8 Feb 2000 10:19:15 -0600 (CST) Received: from whitestar.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000003012; Tue, 8 Feb 2000 11:19:21 -0500 (EST) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA26696; Tue, 8 Feb 2000 11:19:20 -0500 Message-Id: <38A04208.25856F84@zk3.dec.com> Date: Tue, 08 Feb 2000 11:19:20 -0500 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: Jim Bound Cc: IPNG Working Group Subject: Re: non-standard IPv4 form support in getaddrinfo() References: <200002081544.KAA0000025221@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim I agree with Itojun that some of the following text may help clarify what getaddrinfo() considers a valid 'nodename'. We should avoid all the references to inet_*() functions, but add either a definition or a reference to what is considered a "standard IPv4 dotted-decimal form." -vlad > > >(To recap for discussion purposes, inet_pton() takes the following: > > it will take dotted-quad decimals. > > If the af argument is AF_INET, the function accepts a string in the > > standard IPv4 dotted-decimal form: > > > ddd.ddd.ddd.ddd > > > > where ddd is a one to three digit decimal number between 0 and 255. > > Note that many implementations of the existing inet_addr() and > > inet_aton() functions accept nonstandard input: octal numbers, > > hexadecimal numbers, and fewer than four numbers. inet_pton() does > > not accept these formats. > ) > +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 8 08:29:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18GRxH03171 for ipng-dist; Tue, 8 Feb 2000 08:27:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18GRo003164 for ; Tue, 8 Feb 2000 08:27:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA03703 for ; Tue, 8 Feb 2000 08:27:48 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10316 for ; Tue, 8 Feb 2000 08:27:48 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 7A1611520BC; Tue, 8 Feb 2000 10:27:48 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 668A6148506; Tue, 8 Feb 2000 10:27:48 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 230E9BC4C4; Tue, 8 Feb 2000 10:27:41 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id A6365B2A43; Tue, 8 Feb 2000 10:27:40 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000005090; Tue, 8 Feb 2000 11:27:47 -0500 (EST) From: Jim Bound Message-Id: <200002081627.LAA0000005090@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Yoshinobu Inoue , ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Wed, 09 Feb 2000 00:52:40 +0900." <29049.950025160@coconut.itojun.org> Date: Tue, 08 Feb 2000 11:27:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, I see, is there any chance to put reference to "(standard) dotted-decimal IPv4 address"? i think XNS and RFC2553 disagreed in some point in the past, due to the text around here. getaddrinfo() description is less clear than what inet_pton() description says. We need to make sure XNS and rfc2553 are in synch here as I said before. We can further define what is mean't by "standard" yes. >>For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes, >>and the extended numeric IPv6 address format for scoped >>addresses defined in *jinmei draft*. >This is totally unacceptable to me as an implementor I do not want to >change the syntax, semantics, or behavior of inet_pton or inet_ntop >which it would have to change to support jinmei's draft. This will >require a new API parser. >We should not change inet_pton in rfc2553 at all. Is my feeling. >The ramifications to installed base are to negative. (maybe due to my poor english skill) I never tried to suggest change inet_pton() behavior in the above. I think you are misreading the above. we do not need to change inet_pton() behavior at all. OK we have had this problem before talking. Lets parse your sentence in public as I need to make sure folks know I am not "misreading" input from the team, as saying that implies I am not capable of comprehension of mail. Your english is fine. But lets see what I did OK: >For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes, OK the clause above states IPv6 numeric address, getaddrinfo accepts what inet_pton takes: To me that means when presented with a numeric addres inet_pton can parse it. Thats fine I agree and there is no change to inet_pton. I would add that address must be a standard address if I think we should say anything about inet_pton at all in the spec for getaddrinfo. >and the extended numeric IPv6 address format for scoped >addresses defined in *jinmei draft*. Above the word "and" is a conjunction tying it to the previous context in the sentence above. The "and" makes it a dependent clause on the first clause. I take it to mean that your saying in addition to the IPv6 numeric address inet_pton should also support parsing an "extended IPv6 numeric address" which "is defined in jinmei's draft" That to me means your saying inet_pton must be able to accept: A) 4ffe::12 (which it does today) and B) 4ffe::12|323 (where | is a delimeter to define the scope_id 323 or however we all agree to define this via jinmei's work) If we support "B" above its a change to inet_pton and why I said what I did. SO I DID NOT MISREAD YOUR TEXT. You were just not clear and defining at the detail level. > For simple (standard) IPv6 numeric, getaddrinfo() needs to just call > inet_pton() (or some other supporting function). This is clear. > To support jinmei draft, getaddrinfo() needs to do (1) scope-address > splitting, (2) scope parsing and (3) call inet_pton(). This is how I would like to see it done too but I am not sure we have consensus on this? I do not think rfc2553 should specify the actual routines to do this but state an implementation will support a user entering a conbined IPv6 address + sin6_scope_id for which getaddrinfo will return an Ipv6 address and the scope_id in sockaddr->sin6_scope_id. We cannot mandate getaddrinfo use inet_pton at all. /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 Feb 8 08:52:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18GngN03252 for ipng-dist; Tue, 8 Feb 2000 08:49:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18GnX003245 for ; Tue, 8 Feb 2000 08:49:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA01669 for ; Tue, 8 Feb 2000 08:49:33 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22532 for ; Tue, 8 Feb 2000 08:49:32 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 247C05790A; Tue, 8 Feb 2000 10:49:32 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 1D29054601; Tue, 8 Feb 2000 10:49:32 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id F0791BC4D9; Tue, 8 Feb 2000 10:49:24 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 7DE4AB2A43; Tue, 8 Feb 2000 10:49:24 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000010257; Tue, 8 Feb 2000 11:49:30 -0500 (EST) From: Jim Bound Message-Id: <200002081649.LAA0000010257@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Yoshinobu Inoue , ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Wed, 09 Feb 2000 01:39:24 +0900." <29879.950027964@coconut.itojun.org> Date: Tue, 08 Feb 2000 11:49:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I see. the only thing I would like to see is, more clarification in the input string when we call getaddrinfo(). I'm just fine even if it does not refer inet_pton(). I agree. /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 Feb 8 10:40:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18IbdS03432 for ipng-dist; Tue, 8 Feb 2000 10:37:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18IbS003425 for ; Tue, 8 Feb 2000 10:37:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA27632 for ; Tue, 8 Feb 2000 10:37:27 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16002 for ; Tue, 8 Feb 2000 11:37:27 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA21806; Tue, 8 Feb 2000 10:29:33 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA14052; Tue, 8 Feb 2000 10:29:33 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.1) id KAA15076; Tue, 8 Feb 2000 10:31:04 -0800 (PST) Date: Tue, 8 Feb 2000 10:31:04 -0800 (PST) From: Tim Hartrick Message-Id: <200002081831.KAA15076@feller.mentat.com> To: bound@zk3.dec.com Subject: Re: non-standard IPv4 form support in getaddrinfo() Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > IPv6 numeric address" which "is defined in jinmei's draft" > > That to me means your saying inet_pton must be able to accept: > > A) 4ffe::12 (which it does today) > and > B) 4ffe::12|323 (where | is a delimeter to define the scope_id 323 > or however we all agree to define this via jinmei's > work) > > If we support "B" above its a change to inet_pton and why I said what I > did. > So are you saying that if an implementation chooses to enhance the inet_pton so that is can parse over/around the scope_id in example B) that it will not be in compliance with XNS? I can understand not requiring inet_pton to be able to parse B). But for- bidding it from being able to parse B) doesn't seem right. 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 Tue Feb 8 10:40:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18IdNG03442 for ipng-dist; Tue, 8 Feb 2000 10:39:23 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18IdI003435 for ; Tue, 8 Feb 2000 10:39:18 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA00813 for ipng@sunroof.eng.sun.com; Tue, 8 Feb 2000 10:37:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18IG3003388 for ; Tue, 8 Feb 2000 10:16:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA13510 for ; Tue, 8 Feb 2000 10:16:02 -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 KAA13134 for ; Tue, 8 Feb 2000 10:16:00 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA03710; Wed, 9 Feb 2000 03:03:40 +0900 (JST) Date: Wed, 09 Feb 2000 03:14:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: itojun@iijlab.net, shin@nd.net.fujitsu.co.jp, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-Reply-To: In your message of "Tue, 08 Feb 2000 11:27:46 -0500" <200002081627.LAA0000005090@quarry.zk3.dec.com> References: <29049.950025160@coconut.itojun.org> <200002081627.LAA0000005090@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 61 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 08 Feb 2000 11:27:46 -0500, >>>>> Jim Bound said: >> For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes, > OK the clause above states IPv6 numeric address, getaddrinfo accepts > what inet_pton takes: To me that means when presented with a numeric > addres inet_pton can parse it. Thats fine I agree and there is no > change to inet_pton. I would add that address must be a standard > address if I think we should say anything about inet_pton at all in the > spec for getaddrinfo. >> and the extended numeric IPv6 address format for scoped >> addresses defined in *jinmei draft*. > Above the word "and" is a conjunction tying it to the previous context > in the sentence above. The "and" makes it a dependent clause on the > first clause. I take it to mean that your saying in addition to the > IPv6 numeric address inet_pton should also support parsing an "extended > IPv6 numeric address" which "is defined in jinmei's draft" > That to me means your saying inet_pton must be able to accept: > A) 4ffe::12 (which it does today) > and > B) 4ffe::12|323 (where | is a delimeter to define the scope_id 323 > or however we all agree to define this via jinmei's > work) > If we support "B" above its a change to inet_pton and why I said what I > did. > SO I DID NOT MISREAD YOUR TEXT. You were just not clear and defining at > the detail level. I think itojun's intention was the following: For 4ffe::12|323, getaddrinfo first separate the address into the "real" address portion (4ffe::12) and the scope_id portion(323), and pass the "real" address portion to inet_pton in order to translate the textual addres into a 128bit IPv6 binary address. He didn't argue that inet_pton should understand the compound form (above "B"). In any case, their (itojun and Yoshinobu) main concern is how getaddrinfo() treats *IPv4* addresses, more specifically, if the function should accept the "classful" format of *IPv4* addresses like 10 = 10.0.0.0, 10.16777215 = 10.255.255.255 10.1 = 10.0.0.1 10.1.1 = 10.1.0.1, I think this is not (directly) relevant to our draft of *IPv6* textual addresses. 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 Feb 8 12:23:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e18KLMC03674 for ipng-dist; Tue, 8 Feb 2000 12:21:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e18KLC003664 for ; Tue, 8 Feb 2000 12:21:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA26174 for ; Tue, 8 Feb 2000 12:21:11 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26188 for ; Tue, 8 Feb 2000 12:21:10 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id CA4BC212; Tue, 8 Feb 2000 15:21:09 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id AA50B28D; Tue, 8 Feb 2000 15:21:09 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000020670; Tue, 8 Feb 2000 15:21:09 -0500 (EST) From: Jim Bound Message-Id: <200002082021.PAA0000020670@quarry.zk3.dec.com> To: Tim Hartrick Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Tue, 08 Feb 2000 10:31:04 PST." <200002081831.KAA15076@feller.mentat.com> Date: Tue, 08 Feb 2000 15:21:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >So are you saying that if an implementation chooses to enhance the inet_pton >so that is can parse over/around the scope_id in example B) that it will >not be in compliance with XNS? > >I can understand not requiring inet_pton to be able to parse B). But for- >bidding it from being able to parse B) doesn't seem right. I agree. What I am saying is this. We should not change the definition in rfc2553 or xns of inet_pton except to define more clearly with examples what "standard" means. If implementors want to create and added value inet_pton thats their choice it is not the business of the standard pro or con and will remain silent on the topic. 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 Thu Feb 10 11:37:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1AJYLq06409 for ipng-dist; Thu, 10 Feb 2000 11:34:21 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1AJYH006402 for ; Thu, 10 Feb 2000 11:34:17 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA01800 for ipng@sunroof.eng.sun.com; Thu, 10 Feb 2000 11:32:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1AINL006219 for ; Thu, 10 Feb 2000 10:23:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA19246 for ; Thu, 10 Feb 2000 10:23:20 -0800 (PST) Received: from tounes.gw.tn (tounes.gw.tn [193.95.50.118]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28114 for ; Thu, 10 Feb 2000 10:23:17 -0800 (PST) Received: from tounes (tounes.tn [193.95.50.110]) by tounes.gw.tn (8.8.8/8.8.8) with ESMTP id TAA00850 for ; Thu, 10 Feb 2000 19:22:21 -0100 (GMT) Received: from tounes.ati.tn (tounes.ati.tn [193.95.66.21]) by tounes.tngw.tn (8.8.8/8.8.8) with ESMTP id TAA00875 for ; Thu, 10 Feb 2000 19:22:28 -0100 (GMT) Received: from email.rnu.tn ([193.95.67.131]) by tounes.ati.tn (8.8.7/8.8.8) with ESMTP id TAA06935 for ; Thu, 10 Feb 2000 19:08:36 -0100 Received: from ensi.rnu.tn ([193.95.37.60]) by email.rnu.tn (8.8.8/8.8.8) with ESMTP id HAA09579 for ; Thu, 10 Feb 2000 07:31:42 +0100 Message-Id: <38A30237.57541399@ensi.rnu.tn> Date: Thu, 10 Feb 2000 19:23:52 +0100 From: Mounir Eddabbabi Organization: ENSI X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Is IPv6 died ? Content-Type: multipart/mixed; boundary="------------C38828B3061340DB06280810" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------C38828B3061340DB06280810 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi every one I have just assisted in a conference of a technical leader in a company of telecommunication (field of investments: ATM) that IPv6 died !!! What must I answer it especially that it has just said to me that all the problems relating to addressing, the routing and the quality of service are solved once for all. I would like to know your contribution so that I can answer it in a collective way. Best regards --------------C38828B3061340DB06280810 Content-Type: text/x-vcard; charset=us-ascii; name="Mounir.Eddabbabi.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mounir Eddabbabi Content-Disposition: attachment; filename="Mounir.Eddabbabi.vcf" begin:vcard n:Eddabbabi;Mounir tel;home:216-4-896142 x-mozilla-html:FALSE url:http://members.xoom.com/dabbabi/ org:ENSI;RSR version:2.1 email;internet:Mounir.Eddabbabi@ensi.rnu.tn title:Master Student adr;quoted-printable:;;BP 290=0D=0AAv Taieb M'Hiri;Ariana;;2080;Tunisia x-mozilla-cpt:;0 fn:Mounir Eddabbabi end:vcard --------------C38828B3061340DB06280810-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 10 15:22:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1ANKBl06567 for ipng-dist; Thu, 10 Feb 2000 15:20:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1ANK2006560 for ; Thu, 10 Feb 2000 15:20:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA24286 for ; Thu, 10 Feb 2000 15:20:02 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23329 for ; Thu, 10 Feb 2000 16:19:52 -0700 (MST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA59416; Thu, 10 Feb 2000 23:19:49 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA23552; Thu, 10 Feb 2000 23:19:47 GMT Message-ID: <38A3472C.B389F8D4@hursley.ibm.com> Date: Thu, 10 Feb 2000 17:18:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mounir Eddabbabi CC: ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? References: <38A30237.57541399@ensi.rnu.tn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mounir, You have been seriously misled. Those problems have certainly not been solved and IPv6 is far from dead. There is a short-sighted mentality that prefers to deny the intrinsic problems of the 32-bit address space, and it has some vocal advocates. That doesn't mean that deployment of IPv6 is an easy thing - it will still take us most of the next ten years. You can find some of the issues explored in http://www.ietf.org/internet-drafts/draft-carpenter-transparency-05.txt which will be published as an RFC within a few days. Regards - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Mounir Eddabbabi wrote: > > Hi every one > > I have just assisted in a conference of a technical leader in a company > of telecommunication (field of > investments: ATM) that IPv6 died !!! What must I answer it especially > that it has just said to me that all > the problems relating to addressing, the routing and the quality of > service are solved once for all. I would like to > know your contribution so that I can answer it in a collective way. > > Best regards -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 10 20:08:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1B462g06739 for ipng-dist; Thu, 10 Feb 2000 20:06:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1B45s006732 for ; Thu, 10 Feb 2000 20:05:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA09579 for ; Thu, 10 Feb 2000 20:05:52 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25213 for ; Thu, 10 Feb 2000 20:05:52 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id XAA19530; Thu, 10 Feb 2000 23:09:55 -0500 (EST) To: mobile-ip@standards.nortelnetworks.com, ipng@sunroof.eng.sun.com Cc: raj.patil@nokia.com, qa3445@email.mot.com, oran@cisco.com From: Dave Johnson Reply-To: Dave Johnson Subject: New (and I think final) Mobile IPv6 draft submitted Date: Thu, 10 Feb 2000 23:09:55 -0500 Message-ID: <19528.950242195@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This afternoon, I submitted a new version of the Mobile IPv6 draft that I think includes fixes for all of the comments I've received on earlier versions of the draft, including several places where changes or clarifications were needed to get along properly with IPsec. Here is the list of major changes since the previous version of the draft: - Added additional material in Section 10.2, discussing use any automated key management protocol [13] (such as IKE [8]) to create any new SA (or SA bundle) while away from home. - Also added additional material in Section 10.2 to define the order in which the Home Address option and Binding Update option appear in the packet relative to the AH or ESP header that is required when a Binding Update is inserted. In addition, this change corrects the placement of the Home Address option in the packet to be before (not after) the AH or ESP header, so that the Home Address option is processed by the destination node before the AH or ESP header is processed. - Changed the dynamic home agent address discovery mechanism to use dedicated ICMP message types (defined in Sections 5.6 and 5.7) rather than (re)using the Binding Update and Binding Acknowledgement options. This change was primarily motivated by the fact that IP packets sent to an anycast address cannot (currently) use AH or ESP authentication since the packet is not directed to any single node with which a Security Association could be established. In addition, this change simplifies the processing of Binding Updates and Binding Acknowledgements, since it removes the special cases there for dynamic home agent address discovery. - Removed the Binding Acknowledgement option Status value of 135 (dynamic home agent address discovery response) since it is no longer needed with the revised dynamic home agent address discovery mechanism. - Removed the Home Agents List Sub-Option since it is no longer needed with the revised dynamic home agent address discovery mechanism. - Added a Duplicate Address Detection (D) bit in the Binding Update option format, to request the mobile node's home agent to perform Duplicate Address Detection on the mobile node's home link for the home address in this binding. Also defined a new Status value of 138 (Duplicate Address Detection failed) for the Binding Acknowledgement, to indicate any failure of this Duplicate Address Detection on the home link. The addition of the Duplicate Address Detection (D) bit in the Binding Update option also reduced the Reserved field from a 5-bit field to a 4-bit field (and caused it to be renamed Reservd so that the label fits in the packet format drawing). - Added text in Section 9.3 and 10.16 to describe the use of the new Duplicate Address Detection (D) bit in the Binding Update option format. - Changed the description of the Home Agents List conceptual data structure to require maintenance of a Home Agents List by each mobile node, as well as by each home agent. A mobile node uses this list to enable notifying a home agent on its previous link, when the mobile node moves to a new link. - In Section 10.10, changed the procedure for retransmitting Binding Updates to require that the Sequence Number field in each successive retransmission MUST be greater than that used in the previous transmission. The draft previously incorrectly specified here that the same sequence number must be used for each retransmission. The change is needed since such reuse of sequence numbers will fail if the original transmission of the Binding Update was in fact received, but the Binding Acknowledgement (instead of the Binding Update) was lost in transmission on the network. Changing the Sequence Number on each retransmission also avoids the any acknowledgement ambiguity problem, making the start time for the binding lifetime more clear. - Corrected yet a few more minor typographical errors in places. I think (and hope :-) that this version of the draft will be the final version before going to Proposed Standard. We plan to start a Last Call on the draft once the official announcement of this new version comes out on the IETF-Announce mailing list. For those who would like to get a copy of the new version now while we wait for the official announcement, it is available on the CMU Monarch Project web pages at http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-10.txt If you have any comments on this new version, please let me know. Comments are best sent to the Mobile IP mailing list at MOBILE-IP@standards.nortelnetworks.com. Dave -- David B. Johnson dbj@cs.cmu.edu Associate Professor http://www.cs.cmu.edu/~dbj/ Computer Science Department http://www.monarch.cs.cmu.edu/ Carnegie Mellon University Phone: (412) 268-7399 5000 Forbes Avenue Fax: (412) 268-5576 Pittsburgh, PA 15213-3891 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 10 20:49:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1B4ks406784 for ipng-dist; Thu, 10 Feb 2000 20:46:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1B4kj006777 for ; Thu, 10 Feb 2000 20:46:46 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA00523 for ; Thu, 10 Feb 2000 20:46:45 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07634 for ; Thu, 10 Feb 2000 20:46:44 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id XAA19702; Thu, 10 Feb 2000 23:50:25 -0500 (EST) To: sl531@cc.usu.edu Cc: itojun@iijlab.net, Aaron Griggs , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Sun, 06 Feb 2000 21:30:22 CST" From: Dave Johnson Reply-To: Dave Johnson Subject: Re: draft-ietf-mobileip-ipv6-09 Date: Thu, 10 Feb 2000 23:50:24 -0500 Message-ID: <19700.950244624@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hi, >I know very little about IPv6 mobility and security issues so correct me >if am wrong. Please UNICAST me your expert advice. > >1> Draft mention that while transmitting packet if corresponding node's >Binding cache has valid care_of_address entry for mobile node's home >address then it replaces later by former and append routing header with >later as last hop. Do the firewall entertain source routing ?? Firewalls *can* do anything they want to (unfortunately) but there is no reason that it should block packets containing such a routing header. >2> Also encapsulated packets from home agent can invade foreign network's >firewall. Is that acceptable ?? Again, there is no reason that a firewall should block such packets. >3> While registering primary care_of_address with its home agent mobile >node sends either an AH [9] or ESP [10] header providing sender >authentication, data integrity protection, and replay protection, via >Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? There are no foreign agents in Mobile IPv6 (they were optional in Mobile IPv4, but in Mobile IPv6, this is a simple IPv6 router). Also, the Binding Update is sent from the mobile node to the home agent using standard IPsec. I'm not sure what you mean by "surrendering your secured data" here, but the authentication (and optional encryption) is done directly between the mobile node and the home agent. Nothing is shared with the router or anyone else in the foreign network. >Thanks. > >Rajeeb Mishra 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 Thu Feb 10 20:51:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1B4oRd06802 for ipng-dist; Thu, 10 Feb 2000 20:50:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1B4oG006795 for ; Thu, 10 Feb 2000 20:50:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA12448 for ; Thu, 10 Feb 2000 20:50:15 -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 VAA17884 for ; Thu, 10 Feb 2000 21:50:14 -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.04) with ESMTP id NAA24632; Fri, 11 Feb 2000 13:50:04 +0900 (JST) To: Dave Johnson cc: mobile-ip@standards.nortelnetworks.com, ipng@sunroof.eng.sun.com, raj.patil@nokia.com, qa3445@email.mot.com, oran@cisco.com In-reply-to: dbj's message of Thu, 10 Feb 2000 23:09:55 EST. <19528.950242195@maredsous.monarch.cs.cmu.edu> 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: New (and I think final) Mobile IPv6 draft submitted From: itojun@iijlab.net Date: Fri, 11 Feb 2000 13:50:04 +0900 Message-ID: <24630.950244604@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - Also added additional material in Section 10.2 to define the > order in which the Home Address option and Binding Update option > appear in the packet relative to the AH or ESP header that is > required when a Binding Update is inserted. In addition, this > change corrects the placement of the Home Address option in the > packet to be before (not after) the AH or ESP header, so that the > Home Address option is processed by the destination node before > the AH or ESP header is processed. If home address option (or any of option that need authenticity) appear prior to ESP header, we need to mandate use of AH for these packets. ESP does not protect packet portion before ESP header. There are many "AH or ESP" in document, I'm not sure which one (or all of them) need clarification. 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 Feb 11 06:41:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BEbhE07021 for ipng-dist; Fri, 11 Feb 2000 06:37:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BEbX007014 for ; Fri, 11 Feb 2000 06:37:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA03629 for ; Fri, 11 Feb 2000 06:37:34 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24013 for ; Fri, 11 Feb 2000 06:37:33 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 2869851D; Fri, 11 Feb 2000 09:37:33 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 0CC8A5F7; Fri, 11 Feb 2000 09:37:33 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000031835; Fri, 11 Feb 2000 09:37:32 -0500 (EST) From: Jim Bound Message-Id: <200002111437.JAA0000031835@quarry.zk3.dec.com> To: Mounir Eddabbabi Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Thu, 10 Feb 2000 17:18:04 CST." <38A3472C.B389F8D4@hursley.ibm.com> Date: Fri, 11 Feb 2000 09:37:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mournir, You have gotten a lot of good responses and so I will not repeat. In 2000 we will see IPv6 products deployed that offer an alternative to NAT with IPv4. In a book I will be getting into the market very soon I will depict the horrors very clearly of the existing debaucle breaking the end-to-end model much further than the IAB transparency draft and in much greater technical detail. Thats whats happening now the end-to-end model is being assaulted and IPv6 will be the counter-attack. Go take a look at the NAT WGs list of things NAT breaks its unbelieveable and RSIP is not going to fix all that either it is just another bandaid. The patient is turning green and until the elixir of IPv6 is provided the patient will continue to have ill-health. If you can find the time come to the IPv6 U.S. Summit in Telluride Colorado March 13-17 sponsored by the IPv6 Forum. This is where you can learn why IPv6 is not dead, meet customers that will deploy IPv6, and meet the vendors who can speak freely without being IETF politically correct (as on this list) who are investing millions of dollars in the development of IPv6 for desk tops, servers, routers, and other products. And come see my talk "How To Get to IPv6" and NOW, and other talks from product engineers and product marketing people who will clearly articulate the technical, business, and future product reasons IPv6 will happen and will not die. 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 Feb 11 09:08:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BH5kX07175 for ipng-dist; Fri, 11 Feb 2000 09:05:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BH5b007168 for ; Fri, 11 Feb 2000 09:05:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19762 for ; Fri, 11 Feb 2000 09:05:36 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10490 for ; Fri, 11 Feb 2000 09:05:35 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 1D5746AD; Fri, 11 Feb 2000 12:05:35 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 8F33478F; Fri, 11 Feb 2000 12:05:34 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000001184; Fri, 11 Feb 2000 12:05:33 -0500 (EST) From: Jim Bound Message-Id: <200002111705.MAA0000001184@quarry.zk3.dec.com> To: Brian E Carpenter Cc: Mounir Eddabbabi , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Thu, 10 Feb 2000 17:18:04 CST." <38A3472C.B389F8D4@hursley.ibm.com> Date: Fri, 11 Feb 2000 12:05:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Your wondering why this kind of press happens well lets look at some of the words in your conclusions of the http://www.ietf.org/internet-drafts/draft-carpenter-transparency-05.txt ------------------------------------------ The notion that servers can use precious globally unique addresses from a small pool, because there will always be fewer servers than clients, may become anachronistic when most electrical devices become network-manageable and thus become servers for a management protocol. Similarly, if every PC becomes a telephone (or the converse), capable of receiving unsolicited incoming calls, the lack of stable IP addresses for PCs will be an issue. Another impending paradigm shift is when domestic and small-office subscribers move from dial-up to always-on Internet connectivity, at which point transient address assignment from a pool becomes much less appropriate. ------------------------------------------- But it will work for early IPv6 adoption as interoperation tool for IPv4 and IPv6. Please define how your using "anachronistic" here.. I am not clear how your using it in the network context. ------------------------------------------------- 5.2 Complete failure of IPv6 In this scenario, IPv6 fails to reach any significant level of operational deployment, IPv4 addressing is the only available mechanism, and address transparency cannot be restored. IPSEC cannot be deployed globally in its current form. In the very long term, the pool of globally unique IPv4 addresses will be nearly totally allocated, and new addresses will generally not be available for any purpose. It is unclear exactly what is likely to happen if the Internet continues to rely exclusively on IPv4, because in that eventuality a variety of schemes are likely to promulgated, with a view toward providing an acceptable evolutionary path for the network. However, we can examine two of the more simplistic sub-scenarios which are possible, while realising that the future would be unlikely to match either one exactly: ------------------------------------------- To even suggest this from the IAB is counter-productive and I think the IAB should give justification why this is even possible given the present momentum of IPv6 and the current rate of deployment by vendors and discussion in the Wireless and Mobile areneas. If IPv6 did not happen the IETF has failed to pick the right IPng when we chose SIP and then developed IPv6. The IETF will be fired by the world networking comunnity, the market, and vendors. We will go fix it out of the IETF in a new standars body is my prediction. The IETF exists because the market lets it exist it is not an entity unto itself with no higher authority. The higher authority is the market and the market is not happey with the band-aids on IPv4. ------------------ Suppose that a mechanism is created to continuously recover and re- allocate IPv4 addresses. A single global address space is maintained, with all sites progressively moving to an Intranet private address model, with global addresses being assigned temporarily from a pool of several billion. -------------------- This is not going to ever happen anymore than it is now. This is where the ITU, ETSI, and ICANN will join together with help from people like me to suggest an alternative most likely IPv6 and an end to the IETF. ----------------------------- 5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT (NAT with port number translation). This has the disadvantage that the host is unaware of the unique address being used for its traffic, being aware only of its ambiguous private address, with all the problems that this generates. See [NAT-ARCH]. ---------------------------- Add see the applications that will not work with this in NAT-ARCH. But many users are stuck with this for now and not happy. ------------------- 5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP addressing implemented at the host rather than by a NAT box. See [RSIP]. In this case the host is aware of its unique address, allowing for substantial restoration of the end-to-end usefulness of addresses, e.g. for TCP or cryptographic checksums. --------------------- Good band-aid if we must have them but requires running code on all clients for it to work. An alternative and like this will be used via DSTM for IPv6 early adoption. -------------------------------- 5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model in which address translation is replaced by systematic encapsulation of all packets for wide-area transport. This model has never been fully developed, although it is completely compatible with end-to-end addressing. -------------------------------- How about a technical reference to this or delete it from the draft. It does nothing more than detirorate to NAT in the a tunnel. -------------------------------------- 6. Conclusion None of the above scenarios is clean, simple and straightforward. Although the pure IPv6 scenario is the cleanest and simplest, it is not straightforward to reach it. The various scenarios without use of IPv6 are all messy and ultimately seem to lead to dead ends of one kind or another. Partial deployment of IPv6, which is a required step on the road to full deployment, is also messy but avoids the dead ends. -------------------------------------------- Excuse me IPv6 is clean and straight forward and the only part that is not simple is transition. Why is partial IPv6 deployment messy? The only thing that is messy is sitting around in the IETF for 5 years trying how to do transition. It is time the vendors just go do it and I am not clear the IETF should have ever been involved with the transition aspects of IPv6 other than as a forum to discuss and work out technical scenarios. /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 Feb 11 09:51:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BHmZF07231 for ipng-dist; Fri, 11 Feb 2000 09:48:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BHmR007224 for ; Fri, 11 Feb 2000 09:48:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA11694 for ; Fri, 11 Feb 2000 09:48:26 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03167 for ; Fri, 11 Feb 2000 09:48:26 -0800 (PST) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA25347; Fri, 11 Feb 2000 09:48:07 -0800 (PST) Message-Id: <200002111748.JAA25347@omega.cisco.com> To: Brian E Carpenter cc: Mounir Eddabbabi , ipng@sunroof.eng.sun.com, yakov@cisco.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Thu, 10 Feb 2000 17:18:04 CST." <38A3472C.B389F8D4@hursley.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25337.950291284.1@cisco.com> Date: Fri, 11 Feb 2000 09:48:05 -0800 From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > You have been seriously misled. Those problems have certainly not been > solved and IPv6 is far from dead. However, it would be equally misleading to believe that IPv6 solves the routing and QoS any better than IPv4 - it does not. > There is a short-sighted mentality that prefers to deny the intrinsic > problems of the 32-bit address space, and it has some vocal advocates. There is a short-sighted mentality that prefers to deny the intrinsic relationship between addressing and routing, and claims that in order to scale the Internet, all one needs to do is to make IP addresses larger. With this in mind it would be somewhat naive (to say the least) to claim that IPv6 significantly improves the ability of the Internet to scale. Moreover, the falling sky of IPv4 depletion is further off than many proponents of IPv6 would have one believe. Let's not confuse facts with opinions. Wrt some facts the following is from http://moat.nlanr.net/IPaddrocc/18monthSequel/: The address occupancy for the two dates were: 27 November 1997: 3,538,970 Class-C equivalent host clusters maximally supporting 905,976,320 hosts utilizing 21.1 percent of the totally available addressing space 27 May 1999: 3,752,222 Class-C equivalent host clusters maximally supporting 960,568,832 hosts utilizing 22.4 percent of the totally available addressing space In other words, the actively used address space increased by roughly 6 percent over the 18 month period, while still staying below a quarter of the available 32 bit address space. Finally, one needs to remember that IPv6 is just one possible solution to the IPv4 address depletion problem, but not the only one possible. While the alternatives (e.g., NAT) are not without problems, neither is IPv6. Important to remember that each has its own set of tradeoffs, these tradeoffs require careful cost/benefit analysis, and this analysis may yield different conclusions depending on a specific situation. Yakov. P.S. While the ipng mailing may not be the place to discuss alternatives to IPv6, perhaps there should be a mailing list where such alternatives could be discussed... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 11 10:07:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BI3Ol07273 for ipng-dist; Fri, 11 Feb 2000 10:03:24 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BI2t007266 for ; Fri, 11 Feb 2000 10:03:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA01342 for ; Fri, 11 Feb 2000 10:02:15 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10573 for ; Fri, 11 Feb 2000 10:02:13 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 68CD5703; Fri, 11 Feb 2000 13:02:13 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 3E2505EA; Fri, 11 Feb 2000 13:02:13 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000007208; Fri, 11 Feb 2000 13:02:12 -0500 (EST) From: Jim Bound Message-Id: <200002111802.NAA0000007208@quarry.zk3.dec.com> To: Yakov Rekhter Cc: Brian E Carpenter , Mounir Eddabbabi , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Fri, 11 Feb 2000 09:48:05 PST." <200002111748.JAA25347@omega.cisco.com> Date: Fri, 11 Feb 2000 13:02:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is no alternative to IPv6 and it is the IETF choice to solve these problems long term with that mechanism and why it was chosen as the IPng in the IETF not NAT, TUBA, and the alternatives. We have already had that discussion and all others have lost and IPv6 is the answer. And every vendor I know is implementing IPv6 right now for production release. Also at the IPv6 Forum our Key Note speaker is Judy Estrin CTO from Cisco. 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 Feb 11 10:11:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BI9rZ07309 for ipng-dist; Fri, 11 Feb 2000 10:09:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BI9i007302 for ; Fri, 11 Feb 2000 10:09:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA02968 for ; Fri, 11 Feb 2000 10:09:39 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14943 for ; Fri, 11 Feb 2000 10:09:39 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 82D6F1520A2; Fri, 11 Feb 2000 12:09:38 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 7C91B148506; Fri, 11 Feb 2000 12:09:38 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 472F84FB06; Fri, 11 Feb 2000 12:09:31 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id CD7684C901; Fri, 11 Feb 2000 12:09:30 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000018828; Fri, 11 Feb 2000 13:09:37 -0500 (EST) From: Jim Bound Message-Id: <200002111809.NAA0000018828@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: "Yakov Rekhter Brian E Carpenter" , Mounir Eddabbabi , bound@zk3.dec.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Fri, 11 Feb 2000 09:48:05 PST." <200002111748.JAA25347@omega.cisco.com> Date: Fri, 11 Feb 2000 13:09:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk WEB Attacker states "deploy IPv6 as soon as possible" see attached mail we just got on the IPv6 Forum. /jim Return-Path: owner-members@ipv6forum.com Received: from quarry.zk3.dec.com by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM) id MAA0000019692; Fri, 11 Feb 2000 12:48:33 -0500 (EST) Received: from mail2.digital.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000022806; Fri, 11 Feb 2000 12:48:32 -0500 (EST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by mail2.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id JAA01323 for ; Fri, 11 Feb 2000 09:48:01 -0800 (PST) Received: (from majordom@localhost) by jazz.viagenie.qc.ca (Viagenie/8.9.3) id MAA08684 for ipv6forum.com.members-outgoing; Fri, 11 Feb 2000 12:44:39 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by jazz.viagenie.qc.ca (Viagenie/8.9.3) with ESMTP id MAA08673 for ; Fri, 11 Feb 2000 12:44:37 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA18832 for ; Fri, 11 Feb 2000 18:41:40 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA16468 for ; Fri, 11 Feb 2000 18:42:28 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id <1XR6THN2>; Fri, 11 Feb 2000 18:42:52 +0100 Message-ID: From: Petri Bernhard To: "'IPv6 Forum Members'" Subject: ZDNET Article on the recent Web Denial-of-Service Attacks Date: Fri, 11 Feb 2000 18:42:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-members@ipv6forum.com Precedence: bulk There is a article in ZDNET quoting a hacker called "Mixter", who created the tool allegedly been used in the recent Web Denial-of-Service Attacks, at: http://www.zdnet.com/zdnn/stories/news/0,4586,2436358,00.html For IPv6, the interesting thing is that "Mixter" says that IPv4 can't really prevent such attacks since "the real problem is the lack of authentification in current protocols", so that the only possible way to prevent such attacks is "migrating to IPv6 (the next-generation Internet protocol), which provides necessary authentication facilities and a bunch of other security extensions." "Mixter" also says: "IPv6 should get implemented as soon as possible, not only because of security aspects, but because the growth of the Internet will make it inevitably necessary by 2004, or sooner. The old IP protocol is a relic, comparable to the Y2K bug. It is soon going to cause problems if people don't care about it." --------------------------- Kind regards Bernhard Bernhard Petri, Siemens Tel: +49 89 722-34578 Fax: +49 89 722-29098 bernhard.petri@icn.siemens.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 Feb 11 11:26:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BJNvI07423 for ipng-dist; Fri, 11 Feb 2000 11:23:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BJNm007416 for ; Fri, 11 Feb 2000 11:23:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA03615 for ; Fri, 11 Feb 2000 11:23:47 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23977 for ; Fri, 11 Feb 2000 11:23:46 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA122728; Fri, 11 Feb 2000 19:23:44 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA25410; Fri, 11 Feb 2000 19:23:42 GMT Message-ID: <38A46199.2DB149B2@hursley.ibm.com> Date: Fri, 11 Feb 2000 13:23:05 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: Mounir Eddabbabi , ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? References: <200002111705.MAA0000001184@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Jim Bound wrote: > > Brian, > > Your wondering why this kind of press happens well lets look at some of > the words in your conclusions of the > http://www.ietf.org/internet-drafts/draft-carpenter-transparency-05.txt > > ------------------------------------------ > The notion that servers can use precious globally unique addresses > from a small pool, because there will always be fewer servers than > clients, may become anachronistic when most electrical devices become > network-manageable and thus become servers for a management protocol. > Similarly, if every PC becomes a telephone (or the converse), capable > of receiving unsolicited incoming calls, the lack of stable IP > addresses for PCs will be an issue. Another impending paradigm shift > is when domestic and small-office subscribers move from dial-up to > always-on Internet connectivity, at which point transient address > assignment from a pool becomes much less appropriate. > ------------------------------------------- > > But it will work for early IPv6 adoption as interoperation tool for IPv4 and > IPv6. Please define how your using "anachronistic" here.. I am not > clear how your using it in the network context. I thought it was pretty clear: when most electrical devices (that means a few hundred in every house and every car) need always-on IP addresses, re-using addresses from a small pool will be an obsolete method. I wouldn't care to put a date on it. > > ------------------------------------------------- > 5.2 Complete failure of IPv6 > > In this scenario, IPv6 fails to reach any significant level of > operational deployment, IPv4 addressing is the only available > mechanism, and address transparency cannot be restored. IPSEC cannot > be deployed globally in its current form. In the very long term, the > pool of globally unique IPv4 addresses will be nearly totally > allocated, and new addresses will generally not be available for any > purpose. > > It is unclear exactly what is likely to happen if the Internet > continues to rely exclusively on IPv4, because in that eventuality a > variety of schemes are likely to promulgated, with a view toward > providing an acceptable evolutionary path for the network. However, > we can examine two of the more simplistic sub-scenarios which are > possible, while realising that the future would be unlikely to match > either one exactly: > ------------------------------------------- > > To even suggest this from the IAB is counter-productive and I think the It's not an IAB document. It was a submission by me to an IAB workshop. > IAB should give justification why this is even possible given the > present momentum of IPv6 and the current rate of deployment by vendors > and discussion in the Wireless and Mobile areneas. Personally I hope it isn't possible, but in scenario analysis you have to consider multiple scenarios. There are plenty of people, including at least one person who just wrote to this list, who think the opposite to you. ... > ------------------ > Suppose that a mechanism is created to continuously recover and re- > allocate IPv4 addresses. A single global address space is maintained, > with all sites progressively moving to an Intranet private address > model, with global addresses being assigned temporarily from a pool > of several billion. > -------------------- > > This is not going to ever happen anymore than it is now. This is where > the ITU, ETSI, and ICANN will join together with help from people like > me to suggest an alternative most likely IPv6 and an end to the IETF. Again, this is scenario analysis. > > ----------------------------- > 5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT > (NAT with port number translation). This has the disadvantage that > the host is unaware of the unique address being used for its traffic, > being aware only of its ambiguous private address, with all the > problems that this generates. See [NAT-ARCH]. > ---------------------------- > > Add see the applications that will not work with this in NAT-ARCH. > But many users are stuck with this for now and not happy. I agree. > > ------------------- > 5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP > addressing implemented at the host rather than by a NAT box. See > [RSIP]. In this case the host is aware of its unique address, > allowing for substantial restoration of the end-to-end usefulness of > addresses, e.g. for TCP or cryptographic checksums. > --------------------- > > Good band-aid if we must have them but requires running code on all > clients for it to work. An alternative and like this will be used via > DSTM for IPv6 early adoption. > > -------------------------------- > 5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model > in which address translation is replaced by systematic encapsulation > of all packets for wide-area transport. This model has never been > fully developed, although it is completely compatible with end-to-end > addressing. > -------------------------------- > > How about a technical reference to this or delete it from the draft. > It does nothing more than detirorate to NAT in the a tunnel. There is no technical reference, as the second sentence indicates. I don't think the comparison with NAT is correct, it is more like inverted RSIP in fact. > > -------------------------------------- > 6. Conclusion > > None of the above scenarios is clean, simple and straightforward. > Although the pure IPv6 scenario is the cleanest and simplest, it is > not straightforward to reach it. The various scenarios without use of > IPv6 are all messy and ultimately seem to lead to dead ends of one > kind or another. Partial deployment of IPv6, which is a required step > on the road to full deployment, is also messy but avoids the dead > ends. > -------------------------------------------- > > Excuse me IPv6 is clean and straight forward and the only part that is > not simple is transition. I think that's what my words say. > ...Why is partial IPv6 deployment messy? Because it leads us to v4/v6 translators. I would like to add that each time I have given a talk based on this document, people (plural) have come up to me afterwards and said "Now I understand why we need IPv6." BTW you are too late with these comments; the document was approved for Info RFC publication a while back and the RFC will be out any day. 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 Feb 11 11:41:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BJaSL07466 for ipng-dist; Fri, 11 Feb 2000 11:36:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BJaH007459 for ; Fri, 11 Feb 2000 11:36:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA12204 for ; Fri, 11 Feb 2000 11:36:14 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19417 for ; Fri, 11 Feb 2000 12:36:14 -0700 (MST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 8702A4CE; Fri, 11 Feb 2000 14:36:13 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 41CC552B; Fri, 11 Feb 2000 14:36:13 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000020585; Fri, 11 Feb 2000 14:36:12 -0500 (EST) From: Jim Bound Message-Id: <200002111936.OAA0000020585@quarry.zk3.dec.com> To: Brian E Carpenter Cc: Jim Bound , Mounir Eddabbabi , ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Fri, 11 Feb 2000 13:23:05 CST." <38A46199.2DB149B2@hursley.ibm.com> Date: Fri, 11 Feb 2000 14:36:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Intention was not to change the doc. My comments are not needed for the spec. I accept your responses. Glad to hear that people are telling you they now understand. That is good news and what I concluded too. Do you disagree with me that IPv6 is the IPng selected by the IETF processes to proceed standards track work on and that other ideas were rejected after an open and extended process. /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 Feb 11 11:41:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BJZ2Y07457 for ipng-dist; Fri, 11 Feb 2000 11:35:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BJYq007446 for ; Fri, 11 Feb 2000 11:34:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA06344 for ; Fri, 11 Feb 2000 11:34:51 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29577 for ; Fri, 11 Feb 2000 11:34:49 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA125550; Fri, 11 Feb 2000 19:34:47 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA24182; Fri, 11 Feb 2000 19:34:44 GMT Message-ID: <38A46432.A0618C84@hursley.ibm.com> Date: Fri, 11 Feb 2000 13:34:10 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Yakov Rekhter CC: Mounir Eddabbabi , ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? References: <200002111748.JAA25347@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yakov Rekhter wrote: > > Brian, > > > You have been seriously misled. Those problems have certainly not been > > solved and IPv6 is far from dead. > > However, it would be equally misleading to believe that IPv6 solves > the routing and QoS any better than IPv4 - it does not. I agree, to a close approximation. > > > There is a short-sighted mentality that prefers to deny the intrinsic > > problems of the 32-bit address space, and it has some vocal advocates. > > There is a short-sighted mentality that prefers to deny the intrinsic > relationship between addressing and routing, and claims that in order to > scale the Internet, all one needs to do is to make IP addresses > larger. With this in mind it would be somewhat naive (to say the least) > to claim that IPv6 significantly improves the ability of the Internet > to scale. IPv6 addresses will aggregate better than IPv4 addresses, because we have the luxury of enough bits to do aggregator-based address assignment. This will limit the size of the default free routing table compared to today. This is the only effect on scaling of the routing system. However, the fact that IPv6 does not necessitate artificial separate addressing realms does also indirectly help scaling, by reducing complexity and administration. > > Moreover, the falling sky of IPv4 depletion is further off than many > proponents of IPv6 would have one believe. Let's not confuse facts with > opinions. Wrt some facts the following is from > http://moat.nlanr.net/IPaddrocc/18monthSequel/: > > The address occupancy for the two dates were: > > 27 November 1997: > 3,538,970 Class-C equivalent host clusters > maximally supporting 905,976,320 hosts > utilizing 21.1 percent of the totally available addressing space > 27 May 1999: > 3,752,222 Class-C equivalent host clusters > maximally supporting 960,568,832 hosts > utilizing 22.4 percent of the totally available addressing space > > In other words, the actively used address space increased by roughly > 6 percent over the 18 month period, while still staying below a quarter > of the available 32 bit address space. However, we know that if addresses were more freely available from the registries, all the recent growth in private address space would have been added to this. I agree that of course we don't know the end date when 4 billion addresses will have been allocated; but it will come. > Finally, one needs to remember that IPv6 is just one possible solution > to the IPv4 address depletion problem, but not the only one possible. > While the alternatives (e.g., NAT) are not without problems, neither is > IPv6. Important to remember that each has its own set of tradeoffs, > these tradeoffs require careful cost/benefit analysis, and this > analysis may yield different conclusions depending on a specific > situation. Let's say that NAT and RSIP delay the evil day, but not for ever, and they don't work in all market segments. 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 Feb 11 12:24:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BKJlt07589 for ipng-dist; Fri, 11 Feb 2000 12:19:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BKJc007582 for ; Fri, 11 Feb 2000 12:19:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA03335 for ; Fri, 11 Feb 2000 12:19:36 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13033 for ; Fri, 11 Feb 2000 13:19:35 -0700 (MST) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id MAA09527; Fri, 11 Feb 2000 12:19:19 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200002111748.JAA25347@omega.cisco.com> References: <200002111748.JAA25347@omega.cisco.com> Date: Fri, 11 Feb 2000 12:19:18 -0800 To: Yakov Rekhter From: Steve Deering Subject: Re: Is IPv6 died ? Cc: Brian E Carpenter , Mounir Eddabbabi , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:48 AM -0800 2/11/00, Yakov Rekhter wrote: >Brian, > > > You have been seriously misled. Those problems have certainly not been > > solved and IPv6 is far from dead. > >However, it would be equally misleading to believe that IPv6 solves >the routing and QoS any better than IPv4 - it does not. Neither Brian nor anyone else here said that. >There is a short-sighted mentality that prefers to deny the intrinsic >relationship between addressing and routing, and claims that in order to >scale the Internet, all one needs to do is to make IP addresses >larger. No one here claimed that. > With this in mind it would be somewhat naive (to say the least) >to claim that IPv6 significantly improves the ability of the Internet >to scale. There are many dimensions in which the Internet has serious scaling problems, some of which are solved by changing the IP header and others of which have solutions that are largely orthogonal to the IP header format. The existence of the latter type of problem does not diminish or eliminate the need to address the former type of problem. >Moreover, the falling sky of IPv4 depletion is further off than many >proponents of IPv6 would have one believe. Let's not confuse facts with >opinions. Wrt some facts the following is from >http://moat.nlanr.net/IPaddrocc/18monthSequel/: Under a regime of rationing, consumption statistics tell you nothing about the demand for the resource nor the degree of hardship suffered by those denied the resource. >P.S. While the ipng mailing may not be the place to discuss >alternatives to IPv6,... It is definitely not the place. >...perhaps there should be a mailing list where such alternatives could >be discussed... The big-internet list probably still exists, for those who wish to continue such interminable discussions. 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 Feb 11 12:26:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BKNiT07616 for ipng-dist; Fri, 11 Feb 2000 12:23:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BKNX007609 for ; Fri, 11 Feb 2000 12:23:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA04071 for ; Fri, 11 Feb 2000 12:23:32 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23674 for ; Fri, 11 Feb 2000 12:23:30 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA252190; Fri, 11 Feb 2000 20:23:28 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA28010; Fri, 11 Feb 2000 20:23:26 GMT Message-ID: <38A46F3C.990D8406@hursley.ibm.com> Date: Fri, 11 Feb 2000 14:21:16 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: Mounir Eddabbabi , ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? References: <200002111936.OAA0000020585@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > Do you disagree with me that IPv6 is the IPng selected by the IETF > processes to proceed standards track work on and that other ideas were > rejected after an open and extended process. Of course you are correct. 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 Feb 11 13:12:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1BL5hO07701 for ipng-dist; Fri, 11 Feb 2000 13:05:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1BL5T007694 for ; Fri, 11 Feb 2000 13:05:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12131 for ; Fri, 11 Feb 2000 13:05:26 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11218 for ; Fri, 11 Feb 2000 14:05:23 -0700 (MST) Received: from ix.netcom.com (user-33qsecv.dialup.mindspring.com [199.174.57.159]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id QAA31959; Fri, 11 Feb 2000 16:04:09 -0500 (EST) Message-ID: <38A492C2.4A15002E@ix.netcom.com> Date: Fri, 11 Feb 2000 14:52:51 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian E Carpenter CC: Jim Bound , Mounir Eddabbabi , "ipng@sunroof.eng.sun.com" Subject: Re: Is IPv6 died ? References: <200002111705.MAA0000001184@quarry.zk3.dec.com> <38A46199.2DB149B2@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, Brian E Carpenter wrote: > Jim, > > Jim Bound wrote: > > > > Brian, > > > > Your wondering why this kind of press happens well lets look at some of > > the words in your conclusions of the > > http://www.ietf.org/internet-drafts/draft-carpenter-transparency-05.txt > > > > ------------------------------------------ > > The notion that servers can use precious globally unique addresses > > from a small pool, because there will always be fewer servers than > > clients, may become anachronistic when most electrical devices become > > network-manageable and thus become servers for a management protocol. > > Similarly, if every PC becomes a telephone (or the converse), capable > > of receiving unsolicited incoming calls, the lack of stable IP > > addresses for PCs will be an issue. Another impending paradigm shift > > is when domestic and small-office subscribers move from dial-up to > > always-on Internet connectivity, at which point transient address > > assignment from a pool becomes much less appropriate. > > ------------------------------------------- > > > > But it will work for early IPv6 adoption as interoperation tool for IPv4 and > > IPv6. Please define how your using "anachronistic" here.. I am not > > clear how your using it in the network context. > > I thought it was pretty clear: when most electrical devices (that means a > few hundred in every house and every car) need always-on IP addresses, > re-using addresses from a small pool will be an obsolete method. > I wouldn't care to put a date on it. Remember that "Always On" IP addresses pose a serious security risk, which is well known and also well documented. Although IPv6 addresses some of those "Security Holes" is is not yet ready for "Prime Time", even though it has been in development for 7 or so years. Unless or until those "Security Holes" are adequately addressed in an adequate manner as well as not infringing upon "Privacy Issues", "Always-on" IP addressing is and will remain a potential serious hazard. > > > > > > ------------------------------------------------- > > 5.2 Complete failure of IPv6 > > > > In this scenario, IPv6 fails to reach any significant level of > > operational deployment, IPv4 addressing is the only available > > mechanism, and address transparency cannot be restored. IPSEC cannot > > be deployed globally in its current form. In the very long term, the > > pool of globally unique IPv4 addresses will be nearly totally > > allocated, and new addresses will generally not be available for any > > purpose. > > > > It is unclear exactly what is likely to happen if the Internet > > continues to rely exclusively on IPv4, because in that eventuality a > > variety of schemes are likely to promulgated, with a view toward > > providing an acceptable evolutionary path for the network. However, > > we can examine two of the more simplistic sub-scenarios which are > > possible, while realising that the future would be unlikely to match > > either one exactly: > > ------------------------------------------- > > > > To even suggest this from the IAB is counter-productive and I think the > > It's not an IAB document. It was a submission by me to an IAB workshop. Nice piece of spin here Brian. One is practically the same as the other... >;) > > > > IAB should give justification why this is even possible given the > > present momentum of IPv6 and the current rate of deployment by vendors > > and discussion in the Wireless and Mobile areneas. > > Personally I hope it isn't possible, but in scenario analysis you > have to consider multiple scenarios. There are plenty of people, > including at least one person who just wrote to this list, > who think the opposite to you. > > ... > > ------------------ > > Suppose that a mechanism is created to continuously recover and re- > > allocate IPv4 addresses. A single global address space is maintained, > > with all sites progressively moving to an Intranet private address > > model, with global addresses being assigned temporarily from a pool > > of several billion. > > -------------------- > > > > This is not going to ever happen anymore than it is now. This is where > > the ITU, ETSI, and ICANN will join together with help from people like > > me to suggest an alternative most likely IPv6 and an end to the IETF. > > Again, this is scenario analysis. Indeed it is a scenario analysis, all be it one that is unfolding before our very eyes. >;) > > > > > > ----------------------------- > > 5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT > > (NAT with port number translation). This has the disadvantage that > > the host is unaware of the unique address being used for its traffic, > > being aware only of its ambiguous private address, with all the > > problems that this generates. See [NAT-ARCH]. > > ---------------------------- > > > > Add see the applications that will not work with this in NAT-ARCH. > > But many users are stuck with this for now and not happy. > > I agree. > > > > > ------------------- > > 5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP > > addressing implemented at the host rather than by a NAT box. See > > [RSIP]. In this case the host is aware of its unique address, > > allowing for substantial restoration of the end-to-end usefulness of > > addresses, e.g. for TCP or cryptographic checksums. > > --------------------- > > > > Good band-aid if we must have them but requires running code on all > > clients for it to work. An alternative and like this will be used via > > DSTM for IPv6 early adoption. > > > > -------------------------------- > > 5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model > > in which address translation is replaced by systematic encapsulation > > of all packets for wide-area transport. This model has never been > > fully developed, although it is completely compatible with end-to-end > > addressing. > > -------------------------------- > > > > How about a technical reference to this or delete it from the draft. > > It does nothing more than detirorate to NAT in the a tunnel. > > There is no technical reference, as the second sentence indicates. > I don't think the comparison with NAT is correct, it is more > like inverted RSIP in fact. > > > > -------------------------------------- > > 6. Conclusion > > > > None of the above scenarios is clean, simple and straightforward. > > Although the pure IPv6 scenario is the cleanest and simplest, it is > > not straightforward to reach it. The various scenarios without use of > > IPv6 are all messy and ultimately seem to lead to dead ends of one > > kind or another. Partial deployment of IPv6, which is a required step > > on the road to full deployment, is also messy but avoids the dead > > ends. > > -------------------------------------------- > > > > Excuse me IPv6 is clean and straight forward and the only part that is > > not simple is transition. > > I think that's what my words say. > > > ...Why is partial IPv6 deployment messy? > > Because it leads us to v4/v6 translators. With IPv8 this problem is avoided. > > > I would like to add that each time I have given a talk based on this > document, people (plural) have come up to me afterwards and said "Now > I understand why we need IPv6." I have given talks about IPv8 with the same results. >;) In fact many see IPv8 as viable but preferable to IPv6. I find this strange as it is really more of a partnership arrangement. > > > BTW you are too late with these comments; the document was approved for > Info RFC publication a while back and the RFC will be out any day. Well maybe it is time to start on revising this potential RFC? > > > 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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 13 05:54:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1DDqPU08783 for ipng-dist; Sun, 13 Feb 2000 05:52:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1DDqF008776 for ; Sun, 13 Feb 2000 05:52:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA01375 for ; Sun, 13 Feb 2000 05:52:16 -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 FAA10322 for ; Sun, 13 Feb 2000 05:52:10 -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 NA32525; Mon, 14 Feb 2000 00:52:06 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? In-Reply-To: Your message of "Fri, 11 Feb 2000 12:19:18 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Feb 2000 00:52:06 +1100 Message-Id: <27248.950449926@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Feb 2000 12:19:18 -0800 From: Steve Deering Message-ID: | The big-internet list probably still exists, for those who wish to continue | such interminable discussions. It does, though it is currently disabled (for the past 3 or so years, the only incoming traffic has been spam). Should any traffic even wildly plausibly suitable for that list appear on it, I will enable the list again. 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 Feb 13 09:17:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1DHFaM08839 for ipng-dist; Sun, 13 Feb 2000 09:15:36 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1DHFR008832 for ; Sun, 13 Feb 2000 09:15:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA07499 for ; Sun, 13 Feb 2000 09:15:24 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04580 for ; Sun, 13 Feb 2000 09:15:24 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id C13A257821; Sun, 13 Feb 2000 11:15:23 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id B294254601; Sun, 13 Feb 2000 11:15:23 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 7F3BC4FB02; Sun, 13 Feb 2000 11:15:16 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 1640C4C901; Sun, 13 Feb 2000 11:15:16 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000028749; Sun, 13 Feb 2000 12:15:21 -0500 (EST) From: Jim Bound Message-Id: <200002131715.MAA0000028749@quarry.zk3.dec.com> To: Brian E Carpenter Cc: Jim Bound , Mounir Eddabbabi , ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Fri, 11 Feb 2000 14:21:16 CST." <38A46F3C.990D8406@hursley.ibm.com> Date: Sun, 13 Feb 2000 12:15:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >> Do you disagree with me that IPv6 is the IPng selected by the IETF >> processes to proceed standards track work on and that other ideas were >> rejected after an open and extended process. > >Of course you are correct. Let me try to explain my anxiety here I am not picking on you or anyone else. OK. I think if we in the IETF agree to the above (besides you and me) then I have no issues with the IETF. And I intend to work in various mobile/celluar forums to influence that the IP work get done in the IETF. But if I thought in my darkest moments that those who do not agree with the above and believe the IETF is still searching for an anwser to IPng as I feel Yakov in his mail IMO alluded to, and such a supposition was supported by the IETF mgmt team, then I am bummed out about all the work, years, and time I have put into the IETF. I work on many things I technically don't agree with and even change specs I am working on as a co-author to support consensus even when I feel the technical change a working group wants is technically wrong. So I will always compromise (in 95% of the cases) to move towards consensus, and then if there is a business opportunity go build it as an engineer. But if after 6 years of work if I thought this process in the IETF had any consensus that IPv6 is not the IPng I would feel betrayed as an engineer working in this standards forum and I think many others would too. I am not talking about fixing IPv6 parts that need to change that are not widely deployed, but a complete movement towards other than IPv6. Then I would have no choice but go work elsewhere on this stuff, etc... and all that would go with that decision. I do not think that is the case and Yakov's view that we may need an alternative to IPv6 is a minority view and a non-standard view in this IETF. In fact I think anyother mail we get on this list that there is an alternative is also bogus. I think part of the lingering problem, in hindsight, from all this was the way we announced the IPng choice as an IPng Directorate on that sacred day at that sacred IETF meeting years ago (either Toronto or Seattle). I recall members of the press core I was sitting next to at the plenary saying to me "Jim - well it sounds like all proposals won but SIP was selected". The consenus of our directorate I think was to announce this in the nicest way possible, which Scott and Allison did. But I did warn that if we did it as nice as we did we would be dealing with the fact we did not shoot the other proposals in the head publicly and directly in the future. History demonstrates in various scenes over the centuries that at times it is very wise to beat your opponent to their knees and then start recontruction, this may prevent future whining from ones opponents in the future, and permits them to move forward in a liberated manner. Lastly I don't understand why very bright folks who know routing very well like Yakov don't put their engineer hats on and help make routing work with IPv6. I have put some time into NAT as far as reviewing drafts for DNS and IPv4/IPv6 continuity and the affect to the APIs on a NAT implementation. I even work on it at my real job. I started AATN which spawned RSIP and support what Mike Borella and others are trying to do here. We have even adopted some of the wisdom as far as lessons learned from NAT and address conservation (though the RIRs have an extreme interpretations of that) for IPv6 Transition and early adopter deployment scenarios. It really comes down to being an IETF team player I guess. p.s. I intend to use your transparency draft as a reference in the book I am working on so I am glad it will get RFC status. Turns out it saves me re-writing things. The only thing I will do different is actually show diagrams, figures, etc where many apps break or must be altered if transparency is lost and then have a pain scale to users that continually goes up exponentially, as things like translation is used for IPv4 or for IPv6. It really should be avoided whenever possible. /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 Feb 14 08:45:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1EGhDD09287 for ipng-dist; Mon, 14 Feb 2000 08:43:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1EGh1009280 for ; Mon, 14 Feb 2000 08:43:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04485 for ; Mon, 14 Feb 2000 08:43:02 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01068 for ; Mon, 14 Feb 2000 09:43:00 -0700 (MST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA30864; Mon, 14 Feb 2000 11:39:07 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA33974; Mon, 14 Feb 2000 11:39:08 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA09406; Mon, 14 Feb 2000 11:35:58 -0500 Message-Id: <200002141635.LAA09406@rotala.raleigh.ibm.com> To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? In-Reply-To: Message from Jim Bound of "Sun, 13 Feb 2000 12:15:21 EST." <200002131715.MAA0000028749@quarry.zk3.dec.com> Date: Mon, 14 Feb 2000 11:35:58 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Couple of observations. The IETF has rough consensus on the selection of IPv6. Rough does not mean unanimous, nor does it mean that the detractors will necessarily be silent. We all know that in the end, the market will determine what happens here. The official IETF stance certainly has some influence here, but it is limited and by no means definitive. Vendors tend to act based on business cases. Most, if not all of the detractors, seem to have fault with specifics of IPv6 itself, but that doesn't mean they have an alternative that is any more widely accepted. > Lastly I don't understand why very bright folks who know routing very > well like Yakov don't put their engineer hats on and help make routing > work with IPv6. Folks that say routing doesn't work with IPv6 are of course being dishonest. What some folks are saying is that routing in IPv6 (longest match with provider-based aggregation) is fundamentally the same as in IPv4/CIDR (and this is correct). Thus, the argument goes, why bother with IPv6. Of course, that is a strawman argument. We should keep in mind: - IPv6 wasn't designed to "fix the routing problem", despite what many folks wish. It actually fixes the "lack of globally unique addresses" problem. Plus, it has other benefits. - Although IPv6 may not "fix" the routing problem, there is good reason to believe it will result in smaller tables than will result with continued use of IPv4 because of: - increased ease of end-site renumbering (if more renumbering takes place, fewer instances of broken aggregation) - more aggressive aggregation from the start (no legacy assignments to deal with) - a multihoming model based on multiple per-host prefixes (prefixes for multihomed sites are not advertised as exceptions to achieve multihoming) Finally, the IETF is always willing to look at new approaches to existing problems. Whether a new approach merits serious work in the IETF depends on the cost/benefit when weighed against the existing solutions. So certainly, if a credible alternative to IPv6 was brought up for consideration, the IETF would look at it. We would be foolish not to. However, this is no different than with any other protocol in the IETF. 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 Feb 14 09:42:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1EHdft09445 for ipng-dist; Mon, 14 Feb 2000 09:39:41 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1EHdW009438 for ; Mon, 14 Feb 2000 09:39:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA15002 for ; Mon, 14 Feb 2000 09:39:32 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29007 for ; Mon, 14 Feb 2000 09:39:27 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 868C46E5; Mon, 14 Feb 2000 12:39:26 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 64BA2304; Mon, 14 Feb 2000 12:39:26 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000014443; Mon, 14 Feb 2000 12:39:26 -0500 (EST) From: Jim Bound Message-Id: <200002141739.MAA0000014443@quarry.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Mon, 14 Feb 2000 11:35:58 EST." <200002141635.LAA09406@rotala.raleigh.ibm.com> Date: Mon, 14 Feb 2000 12:39:25 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nice response Thomas...I don't disagree with anything you said. I personally believe also IPv6 can be routed faster than IPv4 and the lookups in the stack can use a better "fast-path". Also because routers are not to do fragmentation is a routing benefit too. thanks /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 Feb 14 09:46:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1EHjen09484 for ipng-dist; Mon, 14 Feb 2000 09:45:40 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1EHja009477 for ; Mon, 14 Feb 2000 09:45:36 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA01196 for ipng@sunroof.eng.sun.com; Mon, 14 Feb 2000 09:44:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1E8b7009155 for ; Mon, 14 Feb 2000 00:37:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA03781 for ; Mon, 14 Feb 2000 00:37:07 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18791 for ; Mon, 14 Feb 2000 00:37:06 -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/smtpfeed 1.04) with ESMTP id RAA14499; Mon, 14 Feb 2000 17:36:59 +0900 (JST) To: v6-bsd-related: ; Subject: KAME IPv6/IPsec stack, STABLE kit 20000214 From: core@kame.net Date: Mon, 14 Feb 2000 17:36:59 +0900 Message-ID: <14496.950517419@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (sorry if you have received this more than once) As usual, KAME Project has released by-monthly "STABLE" kit of IPv6/IPsec network code for the following platforms (yes, we have 6 supported platforms): BSD/OS 3.1 and 4.1 FreeBSD 2.2.8 and 3.4 NetBSD 1.4.1 OpenBSD 2.6 Our code has been tested by the TAHI IPv6 conformance test suite (http://www.tahi.org/). They are redistributable under BSD-like license, i.e. free of charge but absolutely no warranty. They are avaiable from the following web site: http://www.kame.net/ To know the changes and improvements from the previous STABLE kit, please refer to the CHANGELOG file in the distribution. There are bunch of good changes happened since the previous STABLE kit, like the complete integration of ALTQ, more stabilization of IPsec portion, advanced API clarifications and others. Bunch of documents are included in tar.gz file so please be sure to check those. NOTE: KAME code is being merged into {Free,Net,Open}BSD-current tree. The difference between KAME kit and merged tree are like below: (1) KAME kit comes with more experimental protocols/APIs support and userland programs (which may attract researchers more), (2) KAME kit is based on public release version of *BSD, and (3) the merged tree will give tightly integrated IPv6-ready operating system when it gets released as public release version of *BSD than KAME kit. --KAME 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 Mon Feb 14 21:54:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1F5qNs10110 for ipng-dist; Mon, 14 Feb 2000 21:52:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1F5qE010103 for ; Mon, 14 Feb 2000 21:52:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA22821 for ; Mon, 14 Feb 2000 21:52:14 -0800 (PST) Received: from mail0.yrp.nttdocomo.co.jp (mail0.yrp.nttdocomo.co.jp [202.245.184.18]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA21220 for ; Mon, 14 Feb 2000 21:52:13 -0800 (PST) Received: from mml.yrp.nttdocomo.co.jp (mml.yrp.nttdocomo.co.jp [172.21.48.50]) by mail0.yrp.nttdocomo.co.jp (8.9.0/YRPHUB0-8819980304) with ESMTP id OAA21436; Tue, 15 Feb 2000 14:52:11 +0900 (JST) Received: from [172.21.51.64] (dhcp51-64.yrp.nttdocomo.co.jp [172.21.51.64]) by mml.yrp.nttdocomo.co.jp (8.9.2/3.7W-mml-990617) with ESMTP id OAA10260; Tue, 15 Feb 2000 14:52:08 +0900 (JST) Mime-Version: 1.0 X-Mailer: Macintosh Eudora Pro Version 4.2.1-J Message-Id: In-Reply-To: <200002141635.LAA09406@rotala.raleigh.ibm.com> References: <200002141635.LAA09406@rotala.raleigh.ibm.com> Date: Tue, 15 Feb 2000 14:51:43 +0900 To: Thomas Narten From: Norihiro Ishikawa Subject: Re: Is IPv6 died ? Cc: Jim Bound , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since I am not involved in any IP work, my position is fairly neutral. But, considering the ongoing discussion, the more realistic approach is to extend IPv4 for fixing "lack of globally unique addresses" problem. Considering the ultimate deployment of IPv4, the solution should be compatible with IPv4 as much as possible. Since I am not an IP expert, I am not sure whether this approach is feasible or not. I understand the technical merit of IPv6. But, to deploy IPv6, the business and operational merit is more important. To discuss this issue, it seems to me that a neutral forum in IETF is needed, with the excellent guidance of IAB. Any comments ? Norihiro Ishikawa At 11:35 AM -0500 00.2.14, Thomas Narten wrote: > Jim, > > Couple of observations. > > The IETF has rough consensus on the selection of IPv6. Rough does not > mean unanimous, nor does it mean that the detractors will necessarily > be silent. We all know that in the end, the market will determine what > happens here. The official IETF stance certainly has some influence > here, but it is limited and by no means definitive. Vendors tend to > act based on business cases. > > Most, if not all of the detractors, seem to have fault with specifics > of IPv6 itself, but that doesn't mean they have an alternative that is > any more widely accepted. > >> Lastly I don't understand why very bright folks who know routing very >> well like Yakov don't put their engineer hats on and help make routing >> work with IPv6. > > Folks that say routing doesn't work with IPv6 are of course being > dishonest. What some folks are saying is that routing in IPv6 (longest > match with provider-based aggregation) is fundamentally the same as in > IPv4/CIDR (and this is correct). Thus, the argument goes, why bother > with IPv6. Of course, that is a strawman argument. We should keep in > mind: > > - IPv6 wasn't designed to "fix the routing problem", despite what many > folks wish. It actually fixes the "lack of globally unique > addresses" problem. Plus, it has other benefits. > > - Although IPv6 may not "fix" the routing problem, there is good > reason to believe it will result in smaller tables than will result > with continued use of IPv4 because of: > - increased ease of end-site renumbering (if more renumbering > takes place, fewer instances of broken aggregation) > - more aggressive aggregation from the start (no legacy assignments > to deal with) > - a multihoming model based on multiple per-host prefixes > (prefixes for multihomed sites are not advertised as exceptions > to achieve multihoming) > > Finally, the IETF is always willing to look at new approaches to > existing problems. Whether a new approach merits serious work in the > IETF depends on the cost/benefit when weighed against the existing > solutions. So certainly, if a credible alternative to IPv6 was brought > up for consideration, the IETF would look at it. We would be foolish > not to. However, this is no different than with any other protocol in > the IETF. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 15 03:35:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FBXQL10304 for ipng-dist; Tue, 15 Feb 2000 03:33:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FBXE010297 for ; Tue, 15 Feb 2000 03:33:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA05963 for ; Tue, 15 Feb 2000 03:33:13 -0800 (PST) Received: from spmler1.mail.eds.com (ns3.eds.com [194.128.225.190]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02632 for ; Tue, 15 Feb 2000 03:33:11 -0800 (PST) Received: from nnse.eds.com (nnse.eds.com [205.191.69.78]) by spmler1.mail.eds.com (8.9.3/8.9.3) with ESMTP id LAA23886; Tue, 15 Feb 2000 11:38:29 GMT Received: from nnse.eds.com (localhost [127.0.0.1]) by nnse.eds.com (8.9.3/8.9.3) with ESMTP id LAA18003; Tue, 15 Feb 2000 11:32:43 GMT Received: from itbmm001.exit01.exch.eds.com ([206.122.210.126]) by nnse.eds.com (8.9.3/8.9.3) with ESMTP id LAA17995; Tue, 15 Feb 2000 11:32:39 GMT Received: by ITBMM001 with Internet Mail Service (5.5.2650.21) id <1FLHYFK5>; Tue, 15 Feb 2000 12:32:33 +0100 Message-ID: From: "Leone, Guido" To: "'Norihiro Ishikawa'" Cc: ipng@sunroof.eng.sun.com Subject: R:Is IPv6 died ? Date: Tue, 15 Feb 2000 12:32:36 +0100 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e1FBXE010298 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Technical v/s business merit discussion is something that normally changes a lot it's conclusions as the time goes on: the Y2K issue is an example (btw: IPvX and Y2K similarities are on the press). The fact that the new economy is based on an obsolete network layer protocol is still not relevant because it is perceived as just a technical problem that, as such, must be handled by engineers without business and financial impacts. Internet must be left alone. So the question is: is IPv4 to IPv6 transition something that can be understud outside the computer networking community as 1) a needed evolution that 2) will happen without any sort of impact ? I agree that a dedicated forum could be a better place to discuss this. > ---------- > Da: Norihiro Ishikawa[SMTP:ishikawa@mml.yrp.nttdocomo.co.jp] > Inviato: martedì 15 febbraio 2000 6.51 > A: Thomas Narten > Cc: Jim Bound; ipng@sunroof.eng.sun.com > Oggetto: Re: Is IPv6 died ? > > Since I am not involved in any IP work, my position is fairly > neutral. > > But, considering the ongoing discussion, the more realistic > approach is to extend IPv4 for fixing "lack of globally unique > addresses" problem. Considering the ultimate deployment of IPv4, > the solution should be compatible with IPv4 as much as possible. > > Since I am not an IP expert, I am not sure whether this approach > is feasible or not. > > I understand the technical merit of IPv6. But, to deploy IPv6, > the business and operational merit is more important. > > To discuss this issue, it seems to me that a neutral forum in > IETF is needed, with the excellent guidance of IAB. > > Any comments ? > > Norihiro Ishikawa > > At 11:35 AM -0500 00.2.14, Thomas Narten wrote: > > Jim, > > > > Couple of observations. > > > > The IETF has rough consensus on the selection of IPv6. Rough does not > > mean unanimous, nor does it mean that the detractors will necessarily > > be silent. We all know that in the end, the market will determine what > > happens here. The official IETF stance certainly has some influence > > here, but it is limited and by no means definitive. Vendors tend to > > act based on business cases. > > > > Most, if not all of the detractors, seem to have fault with specifics > > of IPv6 itself, but that doesn't mean they have an alternative that is > > any more widely accepted. > > > >> Lastly I don't understand why very bright folks who know routing very > >> well like Yakov don't put their engineer hats on and help make routing > >> work with IPv6. > > > > Folks that say routing doesn't work with IPv6 are of course being > > dishonest. What some folks are saying is that routing in IPv6 (longest > > match with provider-based aggregation) is fundamentally the same as in > > IPv4/CIDR (and this is correct). Thus, the argument goes, why bother > > with IPv6. Of course, that is a strawman argument. We should keep in > > mind: > > > > - IPv6 wasn't designed to "fix the routing problem", despite what many > > folks wish. It actually fixes the "lack of globally unique > > addresses" problem. Plus, it has other benefits. > > > > - Although IPv6 may not "fix" the routing problem, there is good > > reason to believe it will result in smaller tables than will result > > with continued use of IPv4 because of: > > - increased ease of end-site renumbering (if more renumbering > > takes place, fewer instances of broken aggregation) > > - more aggressive aggregation from the start (no legacy assignments > > to deal with) > > - a multihoming model based on multiple per-host prefixes > > (prefixes for multihomed sites are not advertised as exceptions > > to achieve multihoming) > > > > Finally, the IETF is always willing to look at new approaches to > > existing problems. Whether a new approach merits serious work in the > > IETF depends on the cost/benefit when weighed against the existing > > solutions. So certainly, if a credible alternative to IPv6 was brought > > up for consideration, the IETF would look at it. We would be foolish > > not to. However, this is no different than with any other protocol in > > the IETF. > > > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Feb 15 04:49:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FClLI10380 for ipng-dist; Tue, 15 Feb 2000 04:47:21 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FClD010373 for ; Tue, 15 Feb 2000 04:47:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA08933 for ; Tue, 15 Feb 2000 04:47:11 -0800 (PST) Received: from mailer.berkom.de (mailer.berkom.de [141.39.13.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24906 for ; Tue, 15 Feb 2000 05:47:10 -0700 (MST) Received: from berkom.de (seeney.berkom.de [141.39.76.20]) by mailer.berkom.de (8.9.3/) with ESMTP id NAA07531 for ; Tue, 15 Feb 2000 13:47:09 +0100 (MET) Message-ID: <38A94CA8.EF97678D@berkom.de> Date: Tue, 15 Feb 2000 13:55:04 +0100 From: RMi X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Question to IPv6 over Ethernet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all Why there is not a RFC to transmission of IPv6 Packets over IEEE 802.3-Ethernet Networks (with LLC-sublayer) as well as RFC2019, 2464, 2467, etc. ? Thanks in advance, Ralf -- ******************************* Ralf Michaelis r.michaelis@berkom.de Phone +49 30 3497-3164 T-Nova Berkom Goslarer Ufer 35 D-10315 Berlin Germany ******************************* -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 15 05:50:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FDmKL10427 for ipng-dist; Tue, 15 Feb 2000 05:48:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FDmC010420 for ; Tue, 15 Feb 2000 05:48:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA14437 for ; Tue, 15 Feb 2000 05:48:12 -0800 (PST) Received: from salamander.eu.fore.com (salamander.eu.fore.com [193.132.138.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15367 for ; Tue, 15 Feb 2000 06:48:11 -0700 (MST) Received: from dubsrv1.eu.fore.com (dubsrv1 [169.144.161.100]) by salamander.eu.fore.com (8.9.1/8.9.1) with ESMTP id NAA25632 for ; Tue, 15 Feb 2000 13:40:34 GMT Received: from PAT-LAPTOP (dhcp-161-236.eu.fore.com [169.144.161.236]) by dubsrv1.eu.fore.com (8.9.1/8.9.1) with SMTP id NAA02967 for ; Tue, 15 Feb 2000 13:34:49 GMT Message-Id: <3.0.5.32.20000215132949.0085ee00@dubsrv1.eu.fore.com> X-Sender: rkelly@dubsrv1.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Feb 2000 13:29:49 +0000 To: ipng@sunroof.eng.sun.com From: Ronan Kelly Subject: IPNG Newbie Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am new to this list and IPNG. Can anyone recommend some good sources if info on IPNG Thanks Ronan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 15 06:17:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FEEcF10455 for ipng-dist; Tue, 15 Feb 2000 06:14:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FEET010448 for ; Tue, 15 Feb 2000 06:14:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA13860 for ; Tue, 15 Feb 2000 06:14:30 -0800 (PST) Received: from hclhprnd.hclt.com ([202.54.64.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25104 for ; Tue, 15 Feb 2000 06:14:25 -0800 (PST) Received: from indus.hclt.com (indus.hclt.com [204.160.251.52]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id TAA06550 for ; Tue, 15 Feb 2000 19:46:19 +0530 Received: (netpt8@localhost) by indus.hclt.com (8.8.5/SCO5) id OAA11705 for ipng@sunroof.eng.sun.com; Tue, 15 Feb 2000 14:22:58 GMT Message-Id: <200002151422.OAA11705@indus.hclt.com> From: netpt8@indus.hclt.com (Egear trainee) X-Mailer: SCO OpenServer Mail Release 5.0 To: ipng@sunroof.eng.sun.com Subject: source for Newbies Date: Tue, 15 Feb 100 19:52:58 IST Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi guys, If you are new for ipng, here is a good intro for you. Book : IPng and the TCP/IP Protocols Auth : Stephen A Thomas Publ : Wiley Computer Publishing You can also browse the RFCs (Please refer the index at www.ietf.org). Have a Nice Time. regards Vinayagam HCL Technologies Ltd. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 15 06:39:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FEbOp10482 for ipng-dist; Tue, 15 Feb 2000 06:37:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FEbF010475 for ; Tue, 15 Feb 2000 06:37:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA28708 for ; Tue, 15 Feb 2000 06:37:15 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04758 for ; Tue, 15 Feb 2000 06:37:15 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id AAD909A94A; Tue, 15 Feb 2000 08:37:14 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id A2CD190D83; Tue, 15 Feb 2000 08:37:14 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 6C6C9BC4D3; Tue, 15 Feb 2000 08:37:07 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 0DC40B2A44; Tue, 15 Feb 2000 08:37:07 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000024218; Tue, 15 Feb 2000 09:37:13 -0500 (EST) From: Jim Bound Message-Id: <200002151437.JAA0000024218@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: members@ipv6forum.com Subject: INFO: A Cryptographic Evaluation of IPsec Date: Tue, 15 Feb 2000 09:37:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Have you seen this white paper by Bruce Schneier and Niels Ferguson. If not all implementors should read it, and architects building IPsec into their entities infrastructure. http://www.counterpane.com/ipsec.html Kind of intense. I will note the papers comments on designing technology by committee does have its draw backs and I agree with them completely. /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 Feb 15 06:45:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FEihC10513 for ipng-dist; Tue, 15 Feb 2000 06:44:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FEiY010506 for ; Tue, 15 Feb 2000 06:44:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA18726 for ; Tue, 15 Feb 2000 06:44:34 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08309 for ; Tue, 15 Feb 2000 06:44:33 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 930E2578C4; Tue, 15 Feb 2000 08:44:33 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 909C254601; Tue, 15 Feb 2000 08:44:33 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 6172C4FB03; Tue, 15 Feb 2000 08:44:26 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id EC9BD4C901; Tue, 15 Feb 2000 08:44:25 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000023655; Tue, 15 Feb 2000 09:44:32 -0500 (EST) From: Jim Bound Message-Id: <200002151444.JAA0000023655@quarry.zk3.dec.com> To: Norihiro Ishikawa Cc: Thomas Narten , Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? In-reply-to: Your message of "Tue, 15 Feb 2000 14:51:43 +0900." Date: Tue, 15 Feb 2000 09:44:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Any comments ? IPv6 deployment guidance will come from the IPv6 Forum where the motivation is wide deployment of IPv6, development of partnerships with those who can help the deployment of IPv6, and to stimulate the market so vendors will build and ship IPv6 products. This is not the function of the IAB or the IETF. Some of us in the IETF deploy networking as a job in Intranets and the Internet, but this is fiat and not a premise to base the function of the IETF or IAB on for IPv6. The IETF and IABs job is to build standards and prouide opinions on the use of those standards. /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 Feb 15 06:46:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FEj9G10522 for ipng-dist; Tue, 15 Feb 2000 06:45:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FEit010515 for ; Tue, 15 Feb 2000 06:44:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA29148 for ; Tue, 15 Feb 2000 06:44:55 -0800 (PST) Received: from infobro.com (ns.infobro.com [204.255.254.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA11184 for ; Tue, 15 Feb 2000 07:44:55 -0700 (MST) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 15 Feb 2000 09:44:45 -0500 Received: by localhost with Microsoft MAPI; Tue, 15 Feb 2000 09:44:42 -0500 Message-ID: <01BF7799.4906B060.eric@infobro.com> From: "Eric D. Williams" To: "'ipng@sunroof.eng.sun.com'" Cc: "'Leone, Guido'" Subject: RE: Is IPv6 died ? Date: Tue, 15 Feb 2000 09:44:35 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e1FEiu010516 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, Is not ngtrans Working group the proper forum for this discussion? Description of Working Group: 1. Specify the tools and mechanisms that might be used for transition to IPv6. 2. Write documents outlining how the various transition tools and mechanisms might apply to various scenarios for a transition to IPv6. 3. Coordinate with the IPv6 6bone testbed, operating under the IPv6 Testing Address Allocation allocated in Experimental RFC 2471, to foster the development, testing, and deployment of IPv6. 4. Coordinate appropriately with other IPv6 related IETF activities and activities in other organizations. Although this is not my only comment, I will limit my current commentary as follows: As I remember the discussion of the candidates (way back in the day) the transition issue was seen as an important one, important enough in fact to establish a working group to develop methods to address transitioning to IPv6. As that is the case I would submit that is the proper forum for this type of discussion. IMHO, IPv6 (in its current incarnation) is certainly as close to a consensus profile for standardization as it is going to get (today) and represents a (sufficiently) extensible to accommodate transition issue as they arise. That's all for now. Eric Eric Williams, Pres. Information Brokers, Inc. Phone: +1 202.889.4395 http://www.infobro.com/ Fax: +1 202.889.4396 mailto:eric@infobro.com For More Info: info@infobro.com On Tuesday, February 15, 2000 6:33 AM, Leone, Guido [SMTP:guido.leone@eds.com] wrote: > Technical v/s business merit discussion is something that normally changes > a lot it's conclusions as the time goes on: the Y2K issue is an example > (btw: IPvX and Y2K similarities are on the press). > The fact that the new economy is based on an obsolete network layer protocol > is still not relevant because it is perceived as just a technical problem > that, as such, must be handled by engineers without business and financial > impacts. Internet must be left alone. > So the question is: is IPv4 to IPv6 transition something that can be > understud outside the computer networking community as 1) a needed evolution > that 2) will happen without any sort of impact ? > I agree that a dedicated forum could be a better place to discuss this. > > > > > ---------- > > Da: Norihiro Ishikawa[SMTP:ishikawa@mml.yrp.nttdocomo.co.jp] > > Inviato: martedì 15 febbraio 2000 6.51 > > A: Thomas Narten > > Cc: Jim Bound; ipng@sunroof.eng.sun.com > > Oggetto: Re: Is IPv6 died ? > > > > Since I am not involved in any IP work, my position is fairly > > neutral. > > > > But, considering the ongoing discussion, the more realistic > > approach is to extend IPv4 for fixing "lack of globally unique > > addresses" problem. Considering the ultimate deployment of IPv4, > > the solution should be compatible with IPv4 as much as possible. > > > > Since I am not an IP expert, I am not sure whether this approach > > is feasible or not. > > > > I understand the technical merit of IPv6. But, to deploy IPv6, > > the business and operational merit is more important. > > > > To discuss this issue, it seems to me that a neutral forum in > > IETF is needed, with the excellent guidance of IAB. > > > > Any comments ? > > > > Norihiro Ishikawa > > > > At 11:35 AM -0500 00.2.14, Thomas Narten wrote: > > > Jim, > > > > > > Couple of observations. > > > > > > The IETF has rough consensus on the selection of IPv6. Rough does not > > > mean unanimous, nor does it mean that the detractors will necessarily > > > be silent. We all know that in the end, the market will determine what > > > happens here. The official IETF stance certainly has some influence > > > here, but it is limited and by no means definitive. Vendors tend to > > > act based on business cases. > > > > > > Most, if not all of the detractors, seem to have fault with specifics > > > of IPv6 itself, but that doesn't mean they have an alternative that is > > > any more widely accepted. > > > > > >> Lastly I don't understand why very bright folks who know routing very > > >> well like Yakov don't put their engineer hats on and help make routing > > >> work with IPv6. > > > > > > Folks that say routing doesn't work with IPv6 are of course being > > > dishonest. What some folks are saying is that routing in IPv6 (longest > > > match with provider-based aggregation) is fundamentally the same as in > > > IPv4/CIDR (and this is correct). Thus, the argument goes, why bother > > > with IPv6. Of course, that is a strawman argument. We should keep in > > > mind: > > > > > > - IPv6 wasn't designed to "fix the routing problem", despite what many > > > folks wish. It actually fixes the "lack of globally unique > > > addresses" problem. Plus, it has other benefits. > > > > > > - Although IPv6 may not "fix" the routing problem, there is good > > > reason to believe it will result in smaller tables than will result > > > with continued use of IPv4 because of: > > > - increased ease of end-site renumbering (if more renumbering > > > takes place, fewer instances of broken aggregation) > > > - more aggressive aggregation from the start (no legacy assignments > > > to deal with) > > > - a multihoming model based on multiple per-host prefixes > > > (prefixes for multihomed sites are not advertised as exceptions > > > to achieve multihoming) > > > > > > Finally, the IETF is always willing to look at new approaches to > > > existing problems. Whether a new approach merits serious work in the > > > IETF depends on the cost/benefit when weighed against the existing > > > solutions. So certainly, if a credible alternative to IPv6 was brought > > > up for consideration, the IETF would look at it. We would be foolish > > > not to. However, this is no different than with any other protocol in > > > the IETF. > > > > > > 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 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Tue Feb 15 06:56:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FEsDX10587 for ipng-dist; Tue, 15 Feb 2000 06:54:13 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FEs4010580 for ; Tue, 15 Feb 2000 06:54:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA19635 for ; Tue, 15 Feb 2000 06:54:04 -0800 (PST) Received: from ausmail2.austin.ibm.com (ausmail2.austin.ibm.com [192.35.232.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15627 for ; Tue, 15 Feb 2000 07:54:03 -0700 (MST) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id IAA82142 for ; Tue, 15 Feb 2000 08:51:18 -0600 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [9.53.150.76]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id IAA42056; Tue, 15 Feb 2000 08:54:01 -0600 Received: (from marquard@localhost) by mojave.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id IAA29826; Tue, 15 Feb 2000 08:54:01 -0600 To: RMi Cc: ipng@sunroof.eng.sun.com Subject: Re: Question to IPv6 over Ethernet References: <38A94CA8.EF97678D@berkom.de> From: Dave Marquardt Date: 15 Feb 2000 08:54:01 -0600 In-Reply-To: RMi's message of "Tue, 15 Feb 2000 13:55:04 +0100" Message-ID: Lines: 8 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RMi writes: > Why there is not a RFC to transmission of IPv6 Packets over > IEEE 802.3-Ethernet Networks (with LLC-sublayer) as well as > RFC2019, 2464, 2467, etc. ? Because no one has been interested enough to write it yet. -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 Tue Feb 15 08:05:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FG1Jb10641 for ipng-dist; Tue, 15 Feb 2000 08:01:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FG18010634 for ; Tue, 15 Feb 2000 08:01:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA02132 for ; Tue, 15 Feb 2000 08:01:08 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21733 for ; Tue, 15 Feb 2000 09:01:07 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id KAA23843; Tue, 15 Feb 2000 10:01:04 -0600 (CST) Message-Id: <200002151601.KAA23843@gungnir.fnal.gov> To: RMi Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Question to IPv6 over Ethernet In-reply-to: Your message of Tue, 15 Feb 2000 13:55:04 +0100. <38A94CA8.EF97678D@berkom.de> Date: Tue, 15 Feb 2000 10:01:04 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why there is not a RFC to transmission of IPv6 Packets over > IEEE 802.3-Ethernet Networks (with LLC-sublayer) as well as > RFC2019, 2464, 2467, etc. ? Nobody wanted it. Speaking from my own experience, having two ways of doing IPv4 over ethernet did more harm than good. ______________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 15 13:14:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FLBps10889 for ipng-dist; Tue, 15 Feb 2000 13:11:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FLBe010882 for ; Tue, 15 Feb 2000 13:11:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12099 for ; Tue, 15 Feb 2000 13:11:37 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12083 for ; Tue, 15 Feb 2000 14:11:35 -0700 (MST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA368902; Tue, 15 Feb 2000 21:11:31 GMT Received: from hursley.ibm.com ([9.242.210.10]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA18980; Tue, 15 Feb 2000 21:11:27 GMT Message-ID: <38A9C09F.4D6788FC@hursley.ibm.com> Date: Tue, 15 Feb 2000 15:09:51 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Norihiro Ishikawa CC: Thomas Narten , Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? References: <200002141635.LAA09406@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Norihiro, That was the discussion we had in 1992 to 1994, which resulted in the rough consensus to create and deploy IPv6. That was expected to take about 15 years, starting 1995 and we are on track. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Norihiro Ishikawa wrote: > > Since I am not involved in any IP work, my position is fairly > neutral. > > But, considering the ongoing discussion, the more realistic > approach is to extend IPv4 for fixing "lack of globally unique > addresses" problem. Considering the ultimate deployment of IPv4, > the solution should be compatible with IPv4 as much as possible. > > Since I am not an IP expert, I am not sure whether this approach > is feasible or not. > > I understand the technical merit of IPv6. But, to deploy IPv6, > the business and operational merit is more important. > > To discuss this issue, it seems to me that a neutral forum in > IETF is needed, with the excellent guidance of IAB. > > Any comments ? > > Norihiro Ishikawa > > At 11:35 AM -0500 00.2.14, Thomas Narten wrote: > > Jim, > > > > Couple of observations. > > > > The IETF has rough consensus on the selection of IPv6. Rough does not > > mean unanimous, nor does it mean that the detractors will necessarily > > be silent. We all know that in the end, the market will determine what > > happens here. The official IETF stance certainly has some influence > > here, but it is limited and by no means definitive. Vendors tend to > > act based on business cases. > > > > Most, if not all of the detractors, seem to have fault with specifics > > of IPv6 itself, but that doesn't mean they have an alternative that is > > any more widely accepted. > > > >> Lastly I don't understand why very bright folks who know routing very > >> well like Yakov don't put their engineer hats on and help make routing > >> work with IPv6. > > > > Folks that say routing doesn't work with IPv6 are of course being > > dishonest. What some folks are saying is that routing in IPv6 (longest > > match with provider-based aggregation) is fundamentally the same as in > > IPv4/CIDR (and this is correct). Thus, the argument goes, why bother > > with IPv6. Of course, that is a strawman argument. We should keep in > > mind: > > > > - IPv6 wasn't designed to "fix the routing problem", despite what many > > folks wish. It actually fixes the "lack of globally unique > > addresses" problem. Plus, it has other benefits. > > > > - Although IPv6 may not "fix" the routing problem, there is good > > reason to believe it will result in smaller tables than will result > > with continued use of IPv4 because of: > > - increased ease of end-site renumbering (if more renumbering > > takes place, fewer instances of broken aggregation) > > - more aggressive aggregation from the start (no legacy assignments > > to deal with) > > - a multihoming model based on multiple per-host prefixes > > (prefixes for multihomed sites are not advertised as exceptions > > to achieve multihoming) > > > > Finally, the IETF is always willing to look at new approaches to > > existing problems. Whether a new approach merits serious work in the > > IETF depends on the cost/benefit when weighed against the existing > > solutions. So certainly, if a credible alternative to IPv6 was brought > > up for consideration, the IETF would look at it. We would be foolish > > not to. However, this is no different than with any other protocol in > > the IETF. > > > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Feb 15 13:43:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1FLc3f10914 for ipng-dist; Tue, 15 Feb 2000 13:38:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1FLbg010907 for ; Tue, 15 Feb 2000 13:37:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA14829 for ; Tue, 15 Feb 2000 13:37:17 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03646 for ; Tue, 15 Feb 2000 14:37:16 -0700 (MST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA365022 for ; Tue, 15 Feb 2000 21:37:13 GMT Received: from hursley.ibm.com ([9.242.210.10]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA30034 for ; Tue, 15 Feb 2000 21:37:11 GMT Message-ID: <38A9C6CD.C1CDF8A6@hursley.ibm.com> Date: Tue, 15 Feb 2000 15:36:13 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng Subject: [Fwd: Re: Is IPv6 died - reply from Brian Carpenter] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This bounced from th list for no good reason -------- Original Message -------- Subject: Re: Is IPv6 died - reply from Brian Carpenter Date: Tue, 15 Feb 2000 15:05:05 -0600 From: Brian E Carpenter Organization: IBM To: Fred Baker CC: Yakov Rekhter ,Mounir Eddabbabi ,ipng@sunroof.eng.sun References: <4.1.20000211125911.0460dbb0@flipper.cisco.com> Fred, Fred Baker wrote: > > At 12:08 PM 2/11/00 -0800, Yakov Rekhter wrote: > >IPv6 addresses will aggregate better than IPv4 addresses, because we > >have the luxury of enough bits to do aggregator-based address assignment. > > One thing we want to think about, Brian. I am concluding that to deploy > this, what we want to do is take the 490 transit AS's in the world, and > given them each a TLA, and use one TLA for all the multi-homed systems > (ballpark 5400 of them in today's Internet if I understand the numbers). > What that means is that the IP6 route table typically has in it: > > - a TLA route for each transit provider other than myself (490 minus one) > - said multihomed routes (5400) > - various routes within myself or to my customers (how big are you?) > - various routes advertised across bilateral connections from other > providers (what bilateral agreements do you choose to write?) > > It seems to me that this is pretty contained and well within the > capabilities of current routing protocols. I couldn't agree more. > > My point is that 6to4 isn't going to scale one bit better than ip4 > addressing, which it mimics, and trying to start from the tier one > providers (the current plan) isn't working and I don't see any real > difference between 6 or 8 TLA routes vs 500. 6to4 is certainly not intended to be anything but a transition tool. I agree that if we could persuade the major transit providers to get on board, life would be wonderful. > > Somebody's going to say "you mean sub-TLA, right?" No, I mean TLA. The > premise of the addressing plan is that you get an address from a central > provider who can delegate a sub-TLA to you, and you in turn delegate > customer prefixes to your customers, who in turn delegate subnets. I'm > suggesting that all you should need to demonstrate in order to be the first > guy in that food chain is that you are a transit as - that you have people > you could delegate sub-TLAs to. According to > http://www.telstra.net/ops/bgptable.html there are 490 such, which seems to > me a very reasonable number. Indeed > > >Let's say that NAT and RSIP delay the evil day, but not for ever, > >and they don't work in all market segments. > > Specifically, VoIP over NAT is interesting, as a telephone is essentially a > server - it activates when you call it - and therefore like any server has > to have a consistently available address any time someone wants to call it. Right 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 Tue Feb 15 20:53:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1G4pYX11131 for ipng-dist; Tue, 15 Feb 2000 20:51:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1G4pP011124 for ; Tue, 15 Feb 2000 20:51:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA02184 for ; Tue, 15 Feb 2000 20:51:24 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA00429 for ; Tue, 15 Feb 2000 20:51:24 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id B32C256D; Tue, 15 Feb 2000 23:51:23 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 97116581; Tue, 15 Feb 2000 23:51:23 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000006455; Tue, 15 Feb 2000 23:51:17 -0500 (EST) From: Jim Bound Message-Id: <200002160451.XAA0000006455@quarry.zk3.dec.com> To: haberman@nortelnetworks.com Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: draft-ietf-ipngwg-scoped-routing-02.txt Date: Tue, 15 Feb 2000 23:51:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, I think your draft is very concise and complete and we should move forward to PS if we are serious about keeping and processing scoped addresses. 6. Protocol Impact The performance impact on routing protocols is obvious. Routers implementing scoped address support will be forced to perform an additional check in the main forwarding path to determine if the source address is a site-local address. This will add overhead to the processing of every packet flowing through the router. In addition, there will be some storage overhead for the scope identifiers. If scoped addresses are going to be realized, this performance impact may be acceptable. I note you say "If ...."to be realized"... ??? Do you not think this is 100% a good idea as a router implementor? Also in the above should you not reiterate at this point in the draft that a multisited router will have to keep forwarding tables for each site-interface it supports? /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 Feb 15 20:56:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1G4tCA11150 for ipng-dist; Tue, 15 Feb 2000 20:55:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1G4t3011143 for ; Tue, 15 Feb 2000 20:55:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA29937 for ; Tue, 15 Feb 2000 20:55:02 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA01262 for ; Tue, 15 Feb 2000 20:55:02 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id AABC5104C90; Tue, 15 Feb 2000 22:55:01 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id A76E0FB101 for ; Tue, 15 Feb 2000 22:55:01 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 432254FB06; Tue, 15 Feb 2000 22:54:54 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id F2EA54C903 for ; Tue, 15 Feb 2000 22:54:53 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000007182; Tue, 15 Feb 2000 23:54:59 -0500 (EST) From: Jim Bound Message-Id: <200002160454.XAA0000007182@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: sin6_scope_id = 0 Date: Tue, 15 Feb 2000 23:54:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If sin6_scope_id = ZERO then that MUST mean that the site-identifier is not specified and the implementation should use a default. I believe this will work for both Hosts and Routers if Routers adhere to draft-ietf-ipngwg-scoped-routing-02.txt, because on the router it will not advertise site-prefixes on the default interface. Can I hear some consensus for this? thanks /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 Feb 15 21:20:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1G5I3F11184 for ipng-dist; Tue, 15 Feb 2000 21:18:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1G5Hs011177 for ; Tue, 15 Feb 2000 21:17:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA23729 for ; Tue, 15 Feb 2000 21:17:53 -0800 (PST) Received: from infobro.com (ns.infobro.com [204.255.254.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA25736 for ; Tue, 15 Feb 2000 22:17:52 -0700 (MST) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 16 Feb 2000 00:17:06 -0500 Received: by localhost with Microsoft MAPI; Wed, 16 Feb 2000 00:17:04 -0500 Message-ID: <01BF7813.26D24750.eric@infobro.com> From: "Eric D. Williams" To: "'Jim Bound'" , "ipng@sunroof.eng.sun.com" Subject: RE: sin6_scope_id = 0 Date: Wed, 16 Feb 2000 00:16:38 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You are right. Eric On Tuesday, February 15, 2000 11:55 PM, Jim Bound [SMTP:bound@zk3.dec.com] wrote: > If sin6_scope_id = ZERO then that MUST mean that the site-identifier is > not specified and the implementation should use a default. > > I believe this will work for both Hosts and Routers if Routers adhere to > draft-ietf-ipngwg-scoped-routing-02.txt, because on the router it will > not advertise site-prefixes on the default interface. > > Can I hear some consensus for this? > > thanks > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 16 03:18:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GBFtH11438 for ipng-dist; Wed, 16 Feb 2000 03:15:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GBFi011431 for ; Wed, 16 Feb 2000 03:15:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA26582 for ; Wed, 16 Feb 2000 03:15:43 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11827 for ; Wed, 16 Feb 2000 04:15:37 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id MAA25355; Wed, 16 Feb 2000 12:15:24 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id MAA16679; Wed, 16 Feb 2000 12:15:21 +0100 (MET) Message-Id: <200002161115.MAA16679@givry.inria.fr> From: Francis Dupont To: Yoshinobu Inoue cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of Mon, 07 Feb 2000 21:46:36 +0900. <20000207214636G.shin@nd.net.fujitsu.co.jp> Date: Wed, 16 Feb 2000 12:15:09 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: RFC2553 says inet_pton() don't support non-standard IPv4 addr forms. (such as. 10.1 for 10.0.0.1) => I believe these non-standard IPv4 address forms should be garbage collected... I am in favor of a little statement or a reference about what is the textual form of an IPv4 address (in fact we need this too for IPv4 compatible IPv6 addresses which are usually represented as ::. RFC 2373 uses but does not define the "standard IPv4 representation" then perhaps it is not enough to add a reference to it? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 16 04:05:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GC1cm11472 for ipng-dist; Wed, 16 Feb 2000 04:01:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GC1T011465 for ; Wed, 16 Feb 2000 04:01:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA20257 for ; Wed, 16 Feb 2000 04:01:28 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11219 for ; Wed, 16 Feb 2000 04:01:27 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Wed, 16 Feb 2000 07:00:23 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1NWN0R5J; Wed, 16 Feb 2000 07:00:23 -0500 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DJLA2SGJ; Wed, 16 Feb 2000 07:00:22 -0500 Message-ID: <38AA90F2.8D1993AC@nortelnetworks.com> Date: Wed, 16 Feb 2000 06:58:42 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: ipng@sunroof.eng.sun.com Subject: Re: sin6_scope_id = 0 References: <200002160454.XAA0000007182@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I agree. Brian Jim Bound wrote: > If sin6_scope_id = ZERO then that MUST mean that the site-identifier is > not specified and the implementation should use a default. > > I believe this will work for both Hosts and Routers if Routers adhere to > draft-ietf-ipngwg-scoped-routing-02.txt, because on the router it will > not advertise site-prefixes on the default interface. > > Can I hear some consensus for this? > > thanks > /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 > -------------------------------------------------------------------- -- Brian Haberman Nortel Networks haberman@nortelnetworks.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 Feb 16 04:07:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GC5wk11490 for ipng-dist; Wed, 16 Feb 2000 04:05:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GC5l011483 for ; Wed, 16 Feb 2000 04:05:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA18551 for ; Wed, 16 Feb 2000 04:05:46 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA26640 for ; Wed, 16 Feb 2000 05:05:46 -0700 (MST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Wed, 16 Feb 2000 07:05:05 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1NWN0R6L; Wed, 16 Feb 2000 07:05:05 -0500 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DJLA2SGR; Wed, 16 Feb 2000 07:05:04 -0500 Message-ID: <38AA920D.D74E023D@nortelnetworks.com> Date: Wed, 16 Feb 2000 07:03:25 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scoped-routing-02.txt References: <200002160451.XAA0000006455@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Jim Bound wrote: > I think your draft is very concise and complete and we should move > forward to PS if we are serious about keeping and processing scoped > addresses. Thanks. I was sort of waiting on the multi-homed/scoped-addressing architecture document, but I believe this draft can stand on its own. > > > 6. Protocol Impact > > The performance impact on routing protocols is obvious. Routers > implementing scoped address support will be forced to perform an > additional check in the main forwarding path to determine if the > source address is a site-local address. This will add overhead to > the processing of every packet flowing through the router. In > addition, there will be some storage overhead for the scope > identifiers. If scoped addresses are going to be realized, this > performance impact may be acceptable. > > I note you say "If ...."to be realized"... ??? > Do you not think this is 100% a good idea as a router implementor? I put the "If... to be realized" comment in there to emphasize that there is a performance impact, but if we as a WG are serious about scoped addresses then this impact should be acceptable. > > > Also in the above should you not reiterate at this point in the draft > that a multisited router will have to keep forwarding tables for each > site-interface it supports? Good point. I can add such a statement. > > > /jim Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 16 04:35:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GCX9011534 for ipng-dist; Wed, 16 Feb 2000 04:33:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GCX0011527 for ; Wed, 16 Feb 2000 04:33:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA27077 for ; Wed, 16 Feb 2000 04:32:59 -0800 (PST) Received: from mailgestao.intra.cet.pt (mailgestao.ptinovacao.pt [193.136.88.190]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04806 for ; Wed, 16 Feb 2000 05:32:56 -0700 (MST) Received: by EXCHANGE_GESTAO with Internet Mail Service (5.5.2448.0) id <129LZVJP>; Wed, 16 Feb 2000 12:33:19 -0000 Message-ID: From: Jacinto Vieira To: ipng@sunroof.eng.sun.com Subject: Ipv6 Internet Browser Date: Wed, 16 Feb 2000 12:36:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Someone could tell me what are the Internet browser that support IPv6. Thanks in the advance Luis J. Vieira -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 05:38:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GDaRq11604 for ipng-dist; Wed, 16 Feb 2000 05:36:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GDaI011597 for ; Wed, 16 Feb 2000 05:36:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA23759 for ; Wed, 16 Feb 2000 05:36:18 -0800 (PST) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA12899 for ; Wed, 16 Feb 2000 05:36:12 -0800 (PST) Received: from p-grive.issy.cnet.fr ([139.100.0.85]) by p-voyageur.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 10778WHN; Wed, 16 Feb 2000 14:37:42 +0100 Received: from cnet.francetelecom.fr (outofmem.issy.cnet.fr [139.100.10.56]) by p-grive.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 11N4YQBN; Wed, 16 Feb 2000 14:37:42 +0100 Message-ID: <38AAA7EE.C448C820@cnet.francetelecom.fr> Date: Wed, 16 Feb 2000 14:36:46 +0100 From: Jean-Michel COMBES X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: Jacinto Vieira CC: ipng@sunroof.eng.sun.com Subject: Re: Ipv6 Internet Browser References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, here's a list of browsers supporting IPv6 : Microsoft Internet Explorer (www.research.microsoft.com/msripv6) Mozilla (ftp://ftp.kame.net/pub/kame/misc/) Lynx (ftp://ftp.kame.net/pub/kame/misc/) w3m (www.freebsd.org) Jacinto Vieira a écrit : > Someone could tell me what are the Internet browser that support IPv6. > > Thanks in the advance > > Luis J. Vieira > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- France Telecom - CNET/DTL/SSR COMBES Jean-Michel, Internet/Intranet Security E-Mail : jeanmichel.combes@cnet.francetelecom.fr Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 05:58:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GDtx411624 for ipng-dist; Wed, 16 Feb 2000 05:55:59 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GDtm011617 for ; Wed, 16 Feb 2000 05:55:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA06029 for ; Wed, 16 Feb 2000 05:55:47 -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 GAA06247 for ; Wed, 16 Feb 2000 06:55:46 -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 WAA09958; Wed, 16 Feb 2000 22:55:17 +0900 (JST) To: Jean-Michel COMBES cc: Jacinto Vieira , ipng@sunroof.eng.sun.com In-reply-to: jeanmichel.combes's message of Wed, 16 Feb 2000 14:36:46 +0100. <38AAA7EE.C448C820@cnet.francetelecom.fr> 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: Ipv6 Internet Browser From: itojun@iijlab.net Date: Wed, 16 Feb 2000 22:55:17 +0900 Message-ID: <9956.950709317@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >here's a list of browsers supporting IPv6 : > Microsoft Internet Explorer (www.research.microsoft.com/msripv6) > Mozilla (ftp://ftp.kame.net/pub/kame/misc/) > Lynx (ftp://ftp.kame.net/pub/kame/misc/) > w3m (www.freebsd.org) It is also very useful to install IPv6/v4 dual stack proxy web server on your computer. By doing so you can use your favorite (IPv4-only) web browser to access IPv6 web servers. IPv4 client --IPv4--> IPv4/v6 proxy --IPv6--> IPv6 web server wwwoffle does it very nicely. 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 Wed Feb 16 06:11:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GE9GU11646 for ipng-dist; Wed, 16 Feb 2000 06:09:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GE97011639 for ; Wed, 16 Feb 2000 06:09:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA07249 for ; Wed, 16 Feb 2000 06:09:08 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12385 for ; Wed, 16 Feb 2000 07:09:06 -0700 (MST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 7BCD057A05; Wed, 16 Feb 2000 08:09:06 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 795C454602; Wed, 16 Feb 2000 08:09:06 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 4D8384FB08; Wed, 16 Feb 2000 08:08:59 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id DFFF74C901; Wed, 16 Feb 2000 08:08:58 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000016352; Wed, 16 Feb 2000 09:09:05 -0500 (EST) From: Jim Bound Message-Id: <200002161409.JAA0000016352@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com, members@ipv6forum.com Cc: bound@zk3.dec.com Subject: INFO: RESPONSE: A Cryptographic Evaluation of IPsec Date: Wed, 16 Feb 2000 09:09:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, >From mail yesterday below. Stephen Kent's response to the Counterpane IPsec Evaluation at: ftp://206.152.163.3/pub/ipsec_kent_reply.doc regards, /jim ------------------------------- From: Jim Bound Message-Id: <200002151437.JAA0000024218@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: members@ipv6forum.com Subject: INFO: A Cryptographic Evaluation of IPsec Date: Tue, 15 Feb 2000 09:37:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Have you seen this white paper by Bruce Schneier and Niels Ferguson. If not all implementors should read it, and architects building IPsec into their entities infrastructure. http://www.counterpane.com/ipsec.html Kind of intense. I will note the papers comments on designing technology by committee does have its draw backs and I agree with them completely. /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 Feb 16 06:27:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GEOvp11670 for ipng-dist; Wed, 16 Feb 2000 06:24:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GEOm011662 for ; Wed, 16 Feb 2000 06:24:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA08405 for ; Wed, 16 Feb 2000 06:24:49 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02660 for ; Wed, 16 Feb 2000 06:24:43 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id PAA29572; Wed, 16 Feb 2000 15:17:56 +0100 (MET) Date: Wed, 16 Feb 2000 15:17:56 +0100 From: Ignatios Souvatzis To: Jim Bound Cc: ipng@sunroof.eng.sun.com, members@ipv6forum.com Subject: Re: INFO: RESPONSE: A Cryptographic Evaluation of IPsec Message-ID: <20000216151755.E27517@theory.cs.uni-bonn.de> References: <200002161409.JAA0000016352@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200002161409.JAA0000016352@quarry.zk3.dec.com>; from bound@zk3.dec.com on Wed, Feb 16, 2000 at 09:09:04AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Feb 16, 2000 at 09:09:04AM -0500, Jim Bound wrote: > Folks, > > >From mail yesterday below. > Stephen Kent's response to the Counterpane IPsec Evaluation at: > ftp://206.152.163.3/pub/ipsec_kent_reply.doc This looks like TeX from a Mac (or other CR-only line break) machine, embedded in a MS Word document... can somebody please decode it? (TeX would be fine, but it seems to have been reorderd by the Word block processing...) Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 06:43:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GEaQd11688 for ipng-dist; Wed, 16 Feb 2000 06:36:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GEaH011681 for ; Wed, 16 Feb 2000 06:36:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA10023 for ; Wed, 16 Feb 2000 06:36:17 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24006 for ; Wed, 16 Feb 2000 07:36:16 -0700 (MST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id B665057A0B; Wed, 16 Feb 2000 08:36:16 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id B182F5460B; Wed, 16 Feb 2000 08:36:16 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 78F8EBC4C7; Wed, 16 Feb 2000 08:36:09 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 0915CB2A43; Wed, 16 Feb 2000 08:36:08 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000000805; Wed, 16 Feb 2000 09:35:59 -0500 (EST) From: Jim Bound Message-Id: <200002161435.JAA0000000805@quarry.zk3.dec.com> To: Francis Dupont Cc: Yoshinobu Inoue , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Wed, 16 Feb 2000 12:15:09 +0100." <200002161115.MAA16679@givry.inria.fr> Date: Wed, 16 Feb 2000 09:35:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > RFC2553 says inet_pton() don't support non-standard IPv4 addr > forms. (such as. 10.1 for 10.0.0.1) > >=> I believe these non-standard IPv4 address forms should be >garbage collected... I am in favor of a little statement or >a reference about what is the textual form of an IPv4 address >(in fact we need this too for IPv4 compatible IPv6 addresses >which are usually represented as ::. RFC 2373 >uses but does not define the "standard IPv4 representation" >then perhaps it is not enough to add a reference to it? I agreed to better word smithing to the textual form. But if 2373 ain't right go fix rfc2373 that is good standards practice, lets not make every reference to rfc2373 have to explain it. But I think 2373 is fine: By definition: :: is very clear. 1. :: is a separator 2. if all zeros proceed it one has an IPv4 compatible address 3. is what we all know IPv4 addresses to be which is a 4 byte dotted decimal notation where each '.' represents one byte. Ergo using # to represent a digit for this discussion #.#.#.# means 10.1.1.3 is valid but: 10.1 is incomplete and invalid 10/14 is invalid etc... I do not see the need to specify this in rfc2553bis nor should we. /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 Feb 16 07:07:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GF2bQ11718 for ipng-dist; Wed, 16 Feb 2000 07:02:37 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GF2R011711 for ; Wed, 16 Feb 2000 07:02:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA12426 for ; Wed, 16 Feb 2000 07:02:28 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19641 for ; Wed, 16 Feb 2000 07:02:27 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id C23F5151FBF; Wed, 16 Feb 2000 09:02:27 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id BB468148506; Wed, 16 Feb 2000 09:02:27 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 2AF8BBC4C9; Wed, 16 Feb 2000 09:02:20 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id B4EECB2A42; Wed, 16 Feb 2000 09:02:19 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000028624; Wed, 16 Feb 2000 10:02:25 -0500 (EST) From: Jim Bound Message-Id: <200002161502.KAA0000028624@quarry.zk3.dec.com> To: "Brian Haberman" Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scoped-routing-02.txt In-reply-to: Your message of "Wed, 16 Feb 2000 07:03:25 EST." <38AA920D.D74E023D@nortelnetworks.com> Date: Wed, 16 Feb 2000 10:02:25 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Processing site-identifiers is a performance hit across the board and forces datastructures for IP addresses to now maintain a tuple of address+site-identifier. so what we have done is increase the time+space computation where ever it is an issue (much like the old ES-IS vs ARP debates). This impacts performance and configuration. In addition this aspect of IPv6 will affect the IETF routing protocol work, SNMP MIB work (already is at present and Erik Nordmark has made several assumptions on that list I don't agree with regarding the API but will wait till he brings it to this list), Mobile, and others. I for one will at this time recommend publicly in all talks, papers, with the press, that users NOT USE ANYTHING BUT GLOBAL ADDRESSES and LINK-LOCAL ADDRESSES for unicast with IPv6 until this aspect of IPv6 is better defined for Routing, APIs, DNS, Address Selection, Autoconfiguration Affect, etc. I will also recommend that ONLY GLOBAL ADDRESSes be kept in the DNS at this time for IPv6 deployment. This will not be painful to users first adopting IPv6 as most of the early adopters I have spoken to will use Global Addresses cause it removes the need for NAT in their IPv6 infrastructure day one, and want the end-2-end model kept in tact with IPv6 out-of-the-box. Most early adopters I have spoken with want all the benefits for their networks the huge IPv6 address space gives them and consider it an advantage and benefit for IPv6. As far as link-local addresses those remain on the LAN and if users want multisited LANs on a host they will have to specify the sin6_scope_id either on the app command line or out-of-band to the app. We are fixing the API to support this now. I have a plan for using site-local by treating them as global but I won't go into this in the IETF and will explain it at the IPv6 Forum for the members first, as its a deployment strategy for IPv6 not a standards issue. Hint: vendors build a config switch in their v6 implementation that never permits a source address of lesser scope to be used with a dst address of greater scope. This means scope exceeded cannot happen at the router. Also apply the same rules to tunneled packets for transition operations. The IETF does not want to do this so we will add it as a vendor feature we will discuss out of the IETF. Until these scope issues are better defined, implemented in an interoperable manner between multiple independent implementations, and some of the work to define it reaches Proposed Standard Status. And the performance penalty you describe is in fact "really" acceptable cause we have seen it with running code. 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 Wed Feb 16 07:47:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GFj0811765 for ipng-dist; Wed, 16 Feb 2000 07:45:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GFio011758 for ; Wed, 16 Feb 2000 07:44:51 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA22729 for ; Wed, 16 Feb 2000 07:44:50 -0800 (PST) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11343 for ; Wed, 16 Feb 2000 07:44:24 -0800 (PST) Received: by odin.digi-data.com id <15377>; Wed, 16 Feb 2000 11:39:21 -0400 Message-Id: <00Feb16.113921ast.15377@odin.digi-data.com> From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ignatios Souvatzis , IPng Mailing List Subject: Re: INFO: RESPONSE: A Cryptographic Evaluation of IPsec References: <200002161409.JAA0000016352@quarry.zk3.dec.com> <20000216151755.E27517@theory.cs.uni-bonn.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 16 Feb 2000 11:39:18 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Ignatios, This is a decode of the message as you requested Yours sincerely, Robert Honore. " \chapter*{Executive summary} IPsec is a set of protocols that provides communication security for computers using IP-based communication networks. It provides authentication and confidentiality services on a packet level. To support the IPsec security, a key management protocol called ISAKMP is used. ISAKMP uses public-key cryptographic techniques to set up keys between the different parties to be used with IPsec. Both IPsec and ISAKMP are too complex. [a protocol is too complex only relative to a specified set of requirements that are satisfied by a simpler protocol. To substantiate this observation, one ought to define the requirements that one believes the protocol is trying top satisfy, and then offer a simpler protocol.] This high complexity leads to errors. We have found security flaws in both IPsec and ISAKMP, and expect that there are many more. We expect any actual implementation to contain many more errors, some of which will cause security weaknesses. These protocols give the impression of having been designed by a committee: they try to be everything for everybody at the cost of complexity. For normal standards, that is bad enough; for security systems, it is catastrophic. In our opinion, the complexity of both IPsec and ISAKMP can be reduced by a large factor without a significant loss of functionality. IPsec is in better shape than ISAKMP. The description and definitions are reasonably clear. A careful implementation of IPsec can achieve a good level of security. Unfortunately, IPsec by itself is not a very useful protocol. Use on a large scale requires the key management functions of ISAKMP. [while I would tend to agree with this observation, I should note that a non-trivial number of IPsec implementations, used in constrained contexts, are manually keyed.] ISAKMP is currently not in a suitable state for implementation. Major work will be required to get it to that point. There are many security-critical errors, as well as many unnecessary cross-dependencies within the protocol. These should all be eliminated before a new evaluation is done. Based on our analysis, we recommend that IPsec and ISAKMP not be used for confidential information. At the moment we cannot recommend a direct alternative. Some applications might be able to use SSL \cite{SSLv3Nov96}, which in our opinion is a much better protocol that provides a much higher level of security when used appropriately. \tableofcontents \chapter{Introduction} At the request of NSA, Counterpane has conducted a security review of the IPsec and ISAKMP security protocols. This evaluation is based on RFCs 2401--2411 and RFC 2451 \cite{RFC2401,RFC2402,RFC2403,RFC2404,RFC2405,RFC2406,RFC2407,RFC2408,RFC2409,RFC2410,RFC2411,RFC2451}. The Oakley protocol \cite{RFC2412} is only an informational RFC; it is not part of the standard and is not used in ISAKMP. RFC documents are available from {\tt ftp:ftp.isi.edu\slash in-notes\slash rfc.txt}. As \cite{RFC2401} states: ``The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is only one part of an overall system security architecture.'' This evaluation only deals with the IPsec and ISAKMP specifications and is not directly concerned with any of the other factors. However, we do comment on aspects of the specifications that affect other security factors. IPsec and ISAKMP are highly complex systems. Unfortunately, we cannot give a sufficiently detailed description of these systems in this document to allow the reader to understand our comments without being familiar with IPsec and ISAKMP. Our comments frequently refer to specific places in the RFC documents for ease of reference. The rest of this report is structured as follows. Chapter~\ref{chap:general} gives some general comments. Chapter~\ref{chap:bulk} discusses the IPsec protocols that handle bulk data. Chapter~\ref{chap:ISAKMP} discusses the ISAKMP generic definitions. Chapter~\ref{chap:IPsecDOI} talks about the IPsec Domain of Interpretation which gives more details on how the generic ISAKMP structure applies to the IPsec protocols. Finally, chapter~\ref{chap:IKE} discusses the IKE protocol that is the default key management protocol used with ISAKMP. \chapter{General comments}\label{chap:general} \section{Complexity} Complexity is the biggest enemy of security. This might seem an odd statement in the light of the many fielded systems that exhibit critical security failures for very simple reasons. It is true nonetheless. The simple failures are simple to avoid, and often simple to fix. The problem is not that we do not know how to solve them; it is that this knowledge is often not applied. Complexity, however, is a different beast because we do not really know how to handle it. Designing any software system is always a matter of weighing various requirements. These include functionality, efficiency, political acceptability, security, backward compatibility, deadlines, flexibility, ease of use, and many more. The unspoken requirement is often the complexity. If the system gets too complex, it becomes too difficult, and therefore too expensive, to make. As fulfilling more of the requirements usually involves a more complex design, many systems end up with a design that is as complex as the designers and implementors can reasonably handle. Virtually all software is developed using a try-and-fix methodology. Small pieces are implemented, tested, fixed, and tested again.\footnote{Usually several iterations are required.} Several of these small pieces are combined into a larger module, and this module is tested, fixed, and tested again. The end result is software that more or less functions as expected, although we are all familiar with the high frequency of functional failures of software systems. This process of making fairly complex systems and implementing them with a try-and-fix methodology has a devastating effect on the security. The central reason is that you cannot test for security. Therefore, security bugs are not detected during the development process in the same way that functional bugs are. Suppose a reasonably sized program is developed without any testing at all during development and quality control. We feel confident in stating that the result will be a completely useless program; most likely it will not perform any of the desired functions correctly. Yet this is exactly what we get from the try-and-fix methodology when we look at security. The only reasonable way to ``test'' the security of a security product is to perform security reviews on it.\footnote{A cracking contest can be seen as a cheap way of getting other people to do a security analysis. The big problem is interpreting the results. If the prize is not claimed, it does not imply that any competent analysis was done and came up empty.} A security review is a manual process; it is relatively expensive in terms of time and effort and it will never be able to show that the product is in fact secure. [this seems to ignore the approaches usually employed for high assurance system design and implementation , i.e., careful design and review coupled with rigid development procedures, all prior to testing.] The more complex the system is, the harder a security evaluation becomes. A more complex system will have more security-related errors in the specification, design, and implementation. We claim that the number of errors and difficulty of the evaluation are not linear functions of the complexity, but in fact grow much faster. For the sake of simplicity, let us assume the system has $n$ different options, each with two possible choices.\footnote{We use $n$ as the measure of the complexity. This seems reasonable, as the length of the system specification and the implementation is proportional to $n$.} Then there are $n(n-1)/2 = O(n^2)$ different pairs of options that could interact in unexpected ways, and $2^n$ different configurations altogether. Each possible interaction can lead to a security weakness, and the number of possible complex interactions that involve several options is huge. As each interaction can produce a security weakness, we expect that the number of actual security weaknesses grows very rapidly with increasing complexity. The same holds for the security evaluation. For a system with a moderate number of options, checking all the interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thus the difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknesses and a more difficult security analysis unavoidably results in insecure systems. In actual systems, the situation is not quite so bad; there are often options that are ``orthogonal'' in that they have no relation or interaction with each other. This occurs, for example, if the options are on different layers in the communication system, and the layers are separated by a well-defined interface that does not ``show'' the options on either side. For this very reason, such a separation of a system into relatively independent modules with clearly defined interfaces is a hallmark of good design. Good modularization can dramatically reduce the ``effective'' complexity of a system without the need to eliminate important features. Options within a single module can of course still have interactions that need to be analyzed, so the number of options per module should be minimized. Modularization works well when used properly, but most actual systems still include cross-dependencies where options in different modules do affect each other. A more complex system loses on all fronts. It contains more weaknesses to start with, it is much harder to analyze, and it is much harder to implement without introducing security-critical errors in the implementation. Complexity not only makes it virtually impossible to create a secure implementation, it also makes the system extremely hard to manage. The people running the actual system typically do not have a thorough understanding of the security issues involved. Configuration options should therefore be kept to a minimum, and the options should provide a very simple model to the user. Complex combinations of options are very likely to be configured erroneously, which results in a loss of security. The stories in \cite{TheCodebreakers} and \cite{A:WhyFail} illustrate how management of complex systems is often the weakest link. Both IPsec and ISAKMP are too complex to be secure. The design obviously tries to support many different situations with different options. We feel very strongly that the resulting system is well beyond the level of complexity that can be implemented securely with current methodologies. \section{Stating what is achieved} A security analysis evaluates the security aspects of a system. To be able to give any sensible answer, it should be clear what properties the system claims to have. That is, the system documentation should clearly state what security properties are achieved. This can be seen as the functional specification of the security properties. This applies not only to the entire system, but also to the individual modules. At each module or function, the security properties should be specified. A good comparison is the testing of a product. The testing verifies that the product performs according to the functional specifications. Without specifications, the testers might have some interesting comments, but they can never give a real answer. Without security specifications, the first task of the security analysis is to create descriptions of the security properties achieved, based on the perceived intentions of the system designer. The subsequent evaluation might then turn up problems of the form ``this function does not achieve the properties that we think it should have.'' The obvious answer will be: ``but that is not the properties that I designed it to have.'' Very quickly the discussion moves away from the actual security into what was meant. The overall result is a security evaluation that might point out some potential weaknesses, but that will hardly help in improving the security. The IPsec and ISAKMP protocols do not specify clearly which security properties they claim to achieve. [RFCs 2401, 2402, and 2406 clearly state the security services offered by the AH and ESP protocols.] The same holds for the modules and functions. [modules are not specified by these standards; they are implementation artifacts.] We recommend that each function, module, and protocol be extended to include clear specifications regarding the security-related functionality they achieve. We feel that unless this is done, it will not be possible to perform an adequate security evaluation on a system of this complexity. \chapter{Bulk data handling}\label{chap:bulk} In this chapter we discuss the methods used to handle the encryption and authentication of the bulk data, as specified in \cite{RFC2401,RFC2402,RFC2403,RFC2404,RFC2405,RFC2406,RFC2451,RFC2410,RFC2411}. Together these documents specify the IPsec protocol. They specify the actual encryption and authentication of packets, assuming that symmetric keys have already been exchanged. We refer the reader to \cite{RFC2401} sections 1--4.2 for an overview of this part of IPsec and the relevant terminology. \section{Functionality} IPsec is capable of providing authentication and confidentiality services on a packet level. The security configuration of an IPsec implementation is done centrally, presumably by the system administrator. [In some environments, a single administrator might control the configuration of each IPsec implementation, or each user might have some control over it. The latter would tend to be characterized as a distributed management paradigm, not a central one. Also, two IPsec peers communicate ONLY if both agree on the security parameters for the SA, i.e., there is suitable overlap in the SPDs. In that sense too, security configuration is distributed.] IPsec is very suitable for creating a VPN over the Internet, improved security for dial-in connections to portables, restricting access to parts of a network, etc. These are very much network-level functions. IPsec by itself does not supply application-level security. Authentication links the packet to the security gateway of the originating network, the originating host, or possibly the originating user, but not to the application in question or the data the application was handling when it sent the packet. [true, but for many applications, application layer security is not needed, and its implementation might well be accorded less assurance than the network layer security provided by IPsec. This paragraph seems to suggest that there is some important benefit to linking data to an application, through an application-specific security mechanism. There are good examples of where this is true, e.g., e-mail and directories. However, unless there are application-specific security semantics that cannot be captured by use of an application security protocol, your own arguments about simplicity, as well as a number of arguments re assurance, argue against proliferation of application security protocols.] The IPsec functionality can significantly increase the security of the network. It is not a panacea for all security problems, and applications that require security services will typically have to use other security systems in addition to IPsec. [I might disagree with the term "typically" here. A lot depends on the application, where IPsec is implemented, etc.] \section{Complexity}\label{sec:complexity} Our biggest criticism is that IPsec is too complex. There are too many options that achieve the same or similar properties. [if they were completely equivalent this would be a good basis for simplifying IPsec. However, there are subtle differences that have resulted in the proliferation of options you address below.] \subsection{Options} IPsec suffers from an abundance of options. For example, two hosts that want to authenticate IP packets can use four different modes: transport/AH, tunnel/AH, transport/ESP with NULL encryption, and tunnel/ESP with NULL encryption. The differences between these options, both in functionality and performance, are minor. In particular, the following options seem to create a great deal of needless complexity: \begin{enumerate} \item There are two modes that can be used: transport mode and tunnel mode. In transport mode, the IP header of the packet is left untouched. AH authenticates both the IP header and the packet payload. ESP encrypts and authenticates the payload, but not the header. The lack of header authentication in transport/ESP is a real weakness, as it allows various manipulations to be performed. In tunnel mode, the full original IP packet (including headers) is used as the payload in a new IP packet with new headers. The same AH or ESP functions are used. As the original header is now included in the ESP authentication, the transport/ESP authentication weakness no longer exists. Transport mode provides a subset of the functionality of tunnel mode. The only advantage that we can see to transport mode is that it uses a somewhat smaller bandwidth. However, the tunnel mode could be extended in a straightforward way with a specialized header-compression scheme that we will explain shortly. This would achieve virtually the same performance as transport mode without introducing an entirely new mode. We therefore recommend that the transport mode be eliminated. [transport mode and tunnel mode address fundamentally different requirements, from a networking point of view. When security gateways are involved, the use of tunnel mode is an absolute requirement, whereas it is a minor (and rarely used) feature for communications between end systems. A proposal to make all traffic tunnel mode, and to try to offset the added overhead through compression, seems to ignore the IPCOMP facility that is already available to IPsec implementations. Today, transport mode is used primarily to carry L2TP traffic, although this is primarily an efficiency issue.] \item There are two protocols: AH and ESP. AH provides authentication, and ESP provides encryption, authentication, or both. In transport mode, AH provides a stronger authentication than ESP can provide, as it also authenticates the IP header. One of the standard modes of operation would seem to be to use both AH and ESP in transport mode. [although this mode is required to be supported, it seems to be rarely used today. A plausible, near-term use for AH is to provide integrity and authenticity for IPsec traffic between an end system and a first-hop intermediary. For example, AH can be used between a host inside an enclave and a security gateway at the perimeter, to allow the SG to control what traffic leaves the enclave, without granting the SG access to plaintext traffic. This, and similar concatenated SA examples, motivate retention of AH. One could achieve a similar effect with (authentication-only) ESP tunnels, but with increased bandwidth and processing overhead.] In tunnel mode, the authentication that ESP provides is good enough (it includes the IP header), and AH is typically not combined with ESP \cite[section 4.5]{RFC2401}. [the example above shows why one might wish to use AH for the outer header, but most likely with ESP in transport mode.] (Implementations are not required to support nested tunnels that would allow ESP and AH to both be used.) The AH protocol \cite{RFC2402} authenticates the IP headers of the lower layers. [AH authenticates the IP header at the SAME layer, in many respects. AH was originally described as an IP (v4) option. In IPv6, AH is viewed as part of the AH header, and may appear before other header extensions (see section 4.1 of RFC 2401). I agree that AH represents ugly layering, but it's not as bad as you suggest here.] This creates all kind of problems, as some header fields change in transit. As a result, the AH protocol needs to be aware of all data formats used at lower layers so that these mutable fields can be avoided. [this is an inaccurate characterization, especially given the status of AH re IPv6. Don't think of AH as a transport protocol. It isn't.] This is a very ugly construction, and one that will create more problems when future extensions to the IP protocol are made that create new fields that the AH protocol is not aware of. [RFC 2402 explains how to deal with new IP header fields in v6 (see section 3.3.3.1.2.2). The existence of a mutability flag in such extensions makes processing relatively straightforward.] Also, as some header fields are not authenticated, the receiving application still cannot rely on the entire packet. To fully understand the authentication provided by AH, an application needs to take into account the same complex IP header parsing rules that AH uses. The complex definition of the functionality that AH provides can easily lead to security-relevant errors. The tunnel/ESP authentication avoids this problem, but uses more bandwidth. [but it does not provide exactly the same features, as noted above, so the alternative is not quite equivalent.] The extra bandwidth requirement can be reduced by a simple specialized compression scheme: for some suitably chosen set of IP header fields $X$, a single bit in the ESP header indicates whether the $X$ fields in the inner IP header are identical to the corresponding fields in the outer header.\footnote{A trivial generalization is to have several flag bits, each controlling a set of IP header fields.} The fields in question are then removed to reduce the payload size. This compression should be applied after computing the authentication but before any encryption. The authentication is thus still computed on the entire original packet. The receiver reconstitutes the original packet using the outer header fields, and verifies the authentication. A suitable choice of the set of header fields $X$ allows tunnel/ESP to achieve virtually the same low message expansion as transport/AH. We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality. [counter examples provided above suggest that this claim is a bit overstated.] \item The standard defines two categories of machines: hosts and security gateways. Hosts can use transport mode, but security gateways must always use tunnel mode. Eliminating transport mode would also allow this distinction to be eliminated. Various computers could of course still function as hosts or security gateways, but these different uses would no longer affect the protocol. \item The ESP protocol allows the payload to be encrypted without being authenticated. In virtually all cases, encryption without authentication is not useful. The only situation in which it makes sense not to use authentication in the ESP protocol is when the authentication is provided by a subsequent application of the AH protocol (as is done in transport mode because ESP authentication in transport mode is not strong enough). [this is one example of when one might not need authentication with ESP, but it is not the only one. In general, if there is a higher layer integrity and/or authentication function in place, providing integrity/authentication in IPsec is redundant, both in terms of space and processing. The authentication field for ESP or AH is 12 bytes. For applications where packet sizes are quite small, and for some environments where packet size is of critical importance, e.g., packet voice in a wireless environment, ESP w/o authentication may be appropriate. This is especially true if the application protocol embodies an authentication mechanism. This might happen if the application protocol wants to offer uniform protection irrespective of the lower layers. Admittedly, this might also cause the application to offer confidentiality as well, but depending on the application, the choices of what security services are being offered may vary.] Without the transport mode to worry about, ESP should always provide its own authentication. We recommend that ESP authentication always be used, and only encryption be made optional. [the question of authentication as an intrinsic part of ESP is independent of mode, i.e., whether one choose to provide authentication as a part of ESP is not determined by the choice of transport vs. tunnel mode.] \end{enumerate} We can thus remove three of the four operational modes without any significant loss of functionality. [sorry, can't agree, given the counter examples above.] \subsection{Undesirable options} There are existing combinations of options that are undesirable. These pose a problem when non-experts have to configure an IPsec installation. Given the fact that experts are rare and usually have better things to do, most IPsec installations will be configured by non-experts. [yes, we were aware of this concern. However, there is always a tradeoff between adopting the "we know what's best for you" approach, vs. the "you can screw it up if you want to approach." We opted for a point somewhere along this spectrum, but not at either end.] \begin{enumerate} \item In transport mode, use of ESP provides authentication of the payload only. The authentication excludes the IP headers of the packet. The result is a data stream that is advertised as ``authenticated'' for which critical pieces of information (such as the source and destination IP number) are not authenticated. Unless the system administrator is intimately familiar with the different forms of authentication used by IPsec, it is quite likely that the administrator will assume that the authentication protects the entire packet. The combination of transport mode and the ESP protocol (without the AH protocol) should therefore not be allowed. [The IP source and destination address are covered by the TCP checksum, which is covered by the ESP integrity check, so this does limit (a tiny bit) the ability to change these values without detection. A more significant observation is that transport mode IPsec SAs will probably always use source and/or destination IP addresses as part of the selector set. In such cases, tampering with the either address will result in a failed authentication check.] \item The standard allows ESP to be used with the NULL encryption, such that it provides only authentication. The authentication provided by ESP in transport mode is less functional than the authentication provided by AH, at a similar cost. If transport mode is retained, either the EPS ESP authentication should be extended or the use of ESP with only authentication should be forbidden and replaced by the use of AH. [ESP authentication is more efficient to compute than AH, because of the selective IP header coverage provided by AH. Thus there is good reason to allow authentication-only ESP as an alternative to AH. This point was debated by the group and, with implementation experience, vendors came to agree that this is true.] \item The ESP protocol can provide encryption without authentication. This does not make much sense in an application. It protects the application against passive eavesdroppers, but provides no protection against active attacks that are often far more devastating. Again, this mode can lure non-expert users into using an unsafe configuration that they think is secure. Encryption without authentication should be forbidden. [as noted above, there are examples where this feature set for ESP is attractive.] \end{enumerate} \subsection{Orthogonality} IPsec also suffers from a lack of orthogonality. The AH and ESP protocols can be used together, but should only be used in one particular order. In transport mode, ESP by itself provides only partial authentication of the IP packet, and using AH too is advisable. [not in most cases, as noted above.] In tunnel mode the ESP protocol authenticates the inner headers, so use of AH is no longer required. These interdependencies between the choices demonstrate that these options are not independent of each other. [true, but who says that this is a critical criteria? TCP and IP are not orthogonal either, e.g., note the TCP checksum covering parts of the IP header.] \subsection{Compatibility} The IPsec protocols are also hampered by the compatibility requirements. A simple problem is the TOS field in the IP header \cite[p.\ 10]{RFC2402}. Although this is supposed to be unchanged during the transmission of a packet (according to the IP specifications), some routers are known to change this field. IPsec chose to exclude the TOS field from the authentication provided by the AH protocol to avoid errors introduced by such rogue routers. The result is that, in transport/AH packets that have an authenticated header, the TOS field is not authenticated. This is clearly unexpected from the application point of view, which might want to rely on the correct value of the TOS field. This problem does not occur in tunnel mode. [it is unfortunate that cisco chose to not follow the specs here, and in several other places. I agree that an unenlightened system administrator might be surprised in this case. But, in practice, the effect is minimal. Your example cites transport mode, which means that the TOS bits are being acted upon by the end system. If end systems really paid attention to these bits in the first place, cisco would not have been able to corrupt them with impunity! The reason that these bits are being re-used by the ECN folks is because hosts have never made use of them. Still, going forward, one should pay attention to this vulnerability.] A more complex compatibility problem is the interaction between fragmentation and IPsec \cite[appendix B]{RFC2401}. This is a complex area, but a typical IPsec implementation has to perform specialized processing to facilitate the proper behavior of higher-level protocols in relation to fragmentation. Strictly speaking, fragmentation is part of the communication layer below the IPsec layer, and in an ideal world it would be transparent to IPsec. Compatibility requirements with existing protocols (such as TCP) force IPsec to explicitly handle fragmentation issues, which adds significantly to the overall complexity. Unfortunately, there does not seem to be an elegant solution to this problem. [The requirement here is the same that arises whenever an intermediate system adds info to a packet, or when a smaller MTU intermediate system is traversed. IPsec in an SG is doing what a router along a path would do if the "other side" network were smaller. IPsec in a host is doing what the NIC would do if the LAN MTU changed. The real complexity arises when we wish to do this optimally, at a security gateway or a BITS or BITW implementation, in cases where different SAs use different combinations of AH and ESP, or different algorithms, etc.] \subsection{Conclusion} The overall result is that IPsec bulk data handing is overly complex. In our opinion it is possible to define an equivalent system that is far less complex. \section{Order of operations} \subsection{Introduction} When both encryption and authentication are provided, IPsec performs the encryption first, and authenticates the ciphertext. In our opinion, this is the wrong order. Going by the ``Horton principle'' \cite{WS:SSL30}, the protocol should authenticate what was meant, not what was said. The ``meaning'' of the ciphertext still depends on the decryption key used. Authentication should thus be applied to the plaintext (as it is in SSL \cite{SSLv3Nov96}), and not to the ciphertext.[The order of processing is intentional. It is explicitly designed to allow a receiver to discard a packet as quickly as possible, in the event of DoS attacks, as you acknowledge below. The suggestion that this concern be addressed by the addition of a secondary MAC seems to violate the spirit of simplicity that this document espouses so strongly, and the specific proposed fix is not strong enough to warrant its incorporation. Moreover, this ordering allows parallel processing at a receiver, as a means of increasing throughput and reducing delay.] This does not always lead to a direct security problem. In the case of the ESP protocol, the encryption key and authentication key are part of a single ESP key in the SA. A successful authentication shows that the packet was sent by someone who knew the authentication key. The recipient trusts the sender to encrypt that packet with the other half of the ESP key, so that the decrypted data is in fact the same as the original data that was sent. The exact argument why this is secure gets to be very complicated, and requires special assumptions about the key agreement protocol. For example, suppose an attacker can manipulate the key agreement protocol used to set up the SA in such a way that the two parties get an agreement on the authentication key but a disagreement on the encryption key. When this is done, the data transmitted will be authenticated successfully, but decryption takes place with a different key than encryption, and all the plaintext data is still garbled. [The fundamental assumption is that an ESP SA that employs both encryption and an HMAC will have the keys bound together, irrespective of the means by which they are generated. This assumption probably could be better stated in the RFCs.] In other situations, the wrong order does lead to direct security weaknesses. \subsection{An attack on IPsec} Suppose two hosts have a manually keyed transport-mode AH-protocol SA, which we will call SAah. Due to the manual keying, the AH protocol does not provide any replay protection. These two hosts now negotiate a transport-mode encryption-only ESP SA (which we will call SAesp1) and use this to send information using both SAesp1 and SAah. The application can expect to get confidentiality and authentication on this channel, but no replay protection. When the immediate interaction is finished, SAesp1 is deleted. A few hours later, the two hosts again negotiate a transport-mode encryption-only ESP SA (SAesp2), and the receiver chooses the same SPI value for SAesp2 as was used for SAesp1. Again, data is transmitted using both SAesp2 and SAah. The attacker now introduces one of the packets from the first exchange. This packet was encrypted using SAesp1 and authenticated using SAah. The receiver checks the authentication and finds it valid. (As replay protection is not enabled, the sequence number field is ignored.) The receiver then proceeds to decrypt the packet using SAesp2, which presumably has a different decryption key then SAesp1. The end result is that the receiver accepts the packet as valid, decrypts it with the wrong key, and presents the garbled data to the application. Clearly, the authentication property has been violated. [this attack is not a criticism of the choice of ESP operation ordering, but rather the notion of applying AH and ESP (encryption only) in a particular order, as allowed by RFC 2401. The specific combination of keying operations described here, though not prohibited by 2401, does not seem likely to occur in practice. Specifically, if an IPsec implementation supports automated key management, as described above for the ESP SAs, then it is highly unlikely that the AH SA would be manually keyed. The push to retain manual keying as a base facility for IPsec is waning, and most implementations have IKE available. Under these circumstances, this vulnerability is unlikely to be realized.] \subsection{Other considerations} Doing the encryption first and authentication later allows the recipient to discard packets with erroneous authentication faster, without the overhead of the decryption. This helps the computer cope with denial-of-service attacks in which a large number of fake packets eat up a lot of CPU time. We question whether this would be the preferred mode of attack against a TCP/IP-enabled computer. If this property is really important, a 1- or 2-byte MAC (Message Authentication Code) on the ciphertext could be added. The MAC code allows the recipient to rapidly discard virtually all bogus packets at the cost of an additional MAC computation per packet. [a one or two byte MAC provides so little protection that this does not seem to be an attractive counter-proposal. Also, as noted above, it adds complexity …] \subsection{Conclusion} The ordering of encryption and authentication in IPsec is wrong. Authentication should be applied to the plaintext of the payload, and encryption should be applied after that. \section{Security Associations} A Security Association (SA) is a simplex ``connection' that affords security services to the traffic carried by it \cite[section 4]{RFC2401}. The two computers on either side of the SA store the mode, protocol, algorithms, and keys used in the SA. Each SA is used only in one direction; for bidirectional communications two SAs are required. Each SA implements a single mode and protocol; if two protocols (such as AH and ESP) are to be applied to a single packet, two SAs are required. Most of our aforementioned comments also affect the SA system; the use of two modes and two protocols make the SA system more complex than necessary. There are very few (if any) situations in which a computer sends an IP packet to a host, but no reply is ever sent. [we have a growing number of apps where this functionality may be appropriate. For example, broadcast packet video feeds and secure time feeds are unidirectional.] There are also very few situations in which the traffic in one direction needs to be secured, but the traffic in the other direction does not need to be secured. It therefore seems that in virtually all practical situations, SAs occur in pairs to allow bidirectional secured communications. In fact, the IKE protocol negotiates SAs in pairs. [IKE has not always been well coordinated with IPsec, unfortunately. This is why we have to have null encryption and null authentication algorithms. So, I don't think one should cite IKE behavior as a basis for making SAs bi-directional. I agree that the vast majority of examples that we see now are full duplex, but we have example where this may not apply, as noted above.] This would suggest that it is more logical to make an SA a bidirectional ``connection'' between two machines. This would halve the number of SAs in the overall system. It would also avoid asymmetric security configurations, which we think are undesirable (see section~\ref{sec:SPD}). [The SPI that is used as a primary de-multiplexing value, must be chosen locally, by the receiver, so having bi-directional SAs probably won't change the size of the SAD substantially. Specifically, how do you envision that a switch to bi-directionality would simplify implementations?] \section{Security policies}\label{sec:SPD} The security policies are stored in the SPD (Security Policy Database). For every packet that is to be sent out, the SPD is checked to find how the packet is to be processed. The SPD can specify three actions: discard the packet, let the packet bypass IPsec processing, or apply IPsec processing. In the last case, the SPD also specifies which SAs should be used (if suitable SAs have already been set up) or specifies with what parameters new SAs should be set up to be used. The SPD seems to be a very flexible control mechanism that allows a very fine-grained control over the security processing of each packet. Packets are classified according to a large number of selectors, and the SPD can match some or all selectors to determine the appropriate action. Depending on the SPD, this can result in either all traffic between two computers being carried on a single SA, or a separate SA being used for each application, or even each TCP connection. Such a very fine granularity has disadvantages. There is a significantly increased overhead in setting up the required SAs, and more traffic analysis information is made available to the attacker. At the same time we do not see any need for such a fine-grained control. [a lot of customers for IPsec products disagree!] The SPD should specify whether a packet should be discarded, should bypass any IPsec processing, requires authentication, or requires authentication and encryption. Whether several packets are combined on the same SA is not important. [yes it is. By allowing an administrator the ability to select the granularity of protection, one can control the level of partial traffic flow confidentiality offered between security gateways. Also, fine-grained access control allows an admin to allow some forms of connections through the gateway, while rejecting others. Access control is often the primary, underlying motivation for using IPsec. A number of attacks become possible if one cannot tightly bind the authentication provided by IPsec to the access control decision. Also, given the computational costs of SA establishment via IKE, it is important to allow an administrator to select the granularity of SAs.] The same holds for the exact choice of cryptographic algorithm: any good algorithm will do. There are two reasons for this. First of all, nobody ever attacks a system by cryptanalysis. Instead, attacks are made on the users, implementation, management, etc. Any reasonable cryptographic algorithm will provide adequate protection. The second reason is that there are very efficient and secure algorithms available. Two machines should negotiate the strongest algorithm that they are allowed. There is no reason to select individual algorithms on an application-by-application basis. [if one were to employ ESP without authentication, because a specific higher layer protocol provided its own authentication, and maybe because the application employed FEC, then one might well imagine using different encryption algorithms, or different modes (e.g., block vs. stream) for different SAs. while I agree that the focus on algorithm agility may be overstated, it does allow communicating parties to select a higher quality algorithm, relative to the mandated default, if they both support that algorithm.] In our opinion, management of the IPsec protocols can be simplified by letting the SPD contain policies formulated at such a higher level. As we argued in section~\ref{sec:complexity}, simplification will strengthen the actual system. [examples provided above illustrate why fine-grained access control is important.] It would be nice if the same high-level approach could be done in relation to the choice of SA end-points. As there currently does not seem to be a reliable automatic method of detecting IPsec-enabled security gateways, we do not see a practical alternative to manual configuration of these parameters. It is questionable whether automatic detection of IPsec-enabled gateways is possible at all. Without some initial knowledge of the other side, any detection and negotiation algorithm can be subverted by an active attacker. [the authors identify a good problem, but it is hardly an unsolvable one. A proposal was put forth (by Bob Moscowtiz, over a year ago) to include records in the DNS analogous to MX records. When one tried to establish an SA to a host "behind" an SG, fetching this record would direct the initiator to an appropriate SG. This solves the SG discovery problem. Other approaches have been put forth in the more recent BBN work on security policy management, which forms the basis for a new IETF WG, chaired by Luis Sanchez. The fact that none of the approaches has been deployed says more about the priorities of IPsec vendors and early adopters than about the intractability of the problem. The other part of the problem is verifying that an SG is authorized to represent the SA target. Here too, various approaches have been described on the IPsec mailing list.] \section{General comments} This section contains general comments that came up during our evaluation of IPsec. \begin{enumerate} \item In \cite[p.\ 22]{RFC2401}, several fields in the SAD are required for all implementations, but only used in some of them. It does not make sense to require the presence of fields within an implementation. Only the external behavior of the system should be standardized. [the SAD defined in 2401 is nominal, as the text explains. An implementation is not required to implement these fields, but must exhibit behavior consistent with the presence of these fields. We were unable to specify external behavior without reference to a construct of this sort. The SPD has the same property.] \item According to \cite[p.\ 23]{RFC2401}, an SA can be either for transport mode, tunnel mode, or ``wildcard,'' in which case the sending application can choose the mode on a packet-by-packet basis. Much of the rest of the text does not seem to take this possibility into account. It also appears to us to be needless complexity that will hardly every be used, and is never a necessity. We have already argued that transport mode should be eliminated, which implies that this option is removed too. If transport mode is to be retained, we would certainly get rid of this option. [I agree, but at least one knowledgeable WG member was quite adamant about this. So, chalk it up to the committee process!] \item IPsec does not allow replay protection on an SA that was established using manual key management techniques. This is a strange requirement. We realize that the replay protection limits the number of packets that can be transmitted with the SA to $2^{32}-1$. Still, there are applications that have a low data rate where replay protection is important and manual keying is the easiest solution. [elsewhere this critique argues for not presenting options in a standard that can be misconfigured. Yet here, the authors make an argument for just such an option! The WG decided that there was too great a chance that a manually keyed SA would fail to maintain counter state across key lifetime and thus made a value judgement to ban anti-replay in this context.] \item \cite[section 5.2.1, point 3]{RFC2401} suggests that an implementation can find the matching SPD entry for a packet using back-pointers from the SAD entries. In general this will not work correctly. Suppose the SPD contains two rules: the first one outlaws all packets to port $X$, and the second one allows all incoming packets that have been authenticated. An SA is set up for this second rule. The sender now sends a packet on this SA addressed to port $X$. This packet should be refused as it matches the first SPD rule. However, the backpointer from the SA points to the second rule in the SPD, which allows the packet. This shows that back-pointers from the SA do not always point to the appropriate rule, and that this is not a proper method of finding the relevant SPD entry. [this is point #3 and is applied only after points #1 and #2. Since point #1 calls for a liner search of the SPD, the packet would be rejected, as required. Thus point #3 is not in error.] \item The handling of ICMP messages as described in \cite[section 6]{RFC2401} is unclear to us. It states that an ICMP message generated by a router must not be forwarded over a transport-mode SA, but transport mode SAs can only occur in hosts. By definition, hosts do not forward packets, and a router never has access to a transport-mode SA. [the text in the beginning of section 6 is emphasizing that an SA from a router to a host or security gateway, must be a tunnel mode SA, vs. a transport mode SA. If we didn't make this clear, someone might choose to establish a transport mode SA from an intermediate system, and this would cause the source address checks to fail under certain circumstances, as noted by the text.] The text further suggests that unauthenticated ICMP messages should be disregarded. This creates problems. Let us envision two machines that are geographically far apart and have a tunnel-mode SA set up. There are probably a dozen routers between these two machines that forward the packets. None of these routers knows about the existence of the SA. Any ICMP messages relating to the packets that are sent will be unauthenticated and unencrypted. Simply discarding these ICMP messages results in a loss of IP functionality. This problem is mentioned, but the text claims this is due to the routers not implementing IPsec. Even if the routers implement IPsec, they still cannot send authenticated ICMP messages about the tunnel unless they themselves set up an SA with the tunnel end-point for the purpose of sending the ICMP packet. The tunnel end-point in turn wants to be sure the source is a real router. This requires a generic public-key infrastructure, which does not exist. [RFC 2401 clearly states the dangers associated with blindly accepting unauthenticated ICMP messages, and the functionality problems associated with discarding such messages. System administrators are provided with the ability to make this tradeoff locally. The first step to addressing this problem is the addition of IPsec into routers, as stated in the RFC. Only then does one face the need to have a PKI that identifies routers. Yes, this second PKI does not exist, but a subset of it (at BGP routers) might be established if the S-BGP technology is deployed. These are the routers most likely to issue ICMP PMTU messages. So, the answer here is that the specifications allow site administrators to make security/functionality tradeoffs, locally. The longer term solution described would require routers to implement IPsec, so that they can send authenticated ICMP messages. Yes, this would require a PKI, but such a PKI may arise for other reasons.] As far as we understand this problem, this is a fundamental compatibility problem with the existing IP protocol that does not have a good solution. \item \cite[section 6.1.2.1]{RFC2401} lists a number of possible ways of handling ICMP PMTU messages. An option that is not mentioned is to keep a limited history of packets that were sent, and to match the header inside the PMTU packet to the history list. This can identify the host where the packet that was too large originated. [the approach suggested by the authors was rejected as imposing too much of a burden on an SG. section 6.1.2.1 offers options (not suggestions) for an SG to respond to ICMP PMTU messages, including heuristics to employ when not enough information is present in the returned header. These options may not as responsive as a strategy that caches traffic on each SA, but they are modest in the overhead imposed. Also, an SA that carries a wide range of traffic (not fine-grained) might not benefit from a limited traffic history, as the traffic that caused the ICMP might well be from a host whose traffic has been flushed from the "limited history."] \item \cite[section 7]{RFC2401} mentions that each auditable event in the AH and ESP specifications lists a minimum set of information that should be included in the audit-log entry. Not all auditable events defined in \cite{RFC2406} include that information.[you're right. Exactly one auditable event in 2406 does not specify the list of data that SHOULD be audited. We'll fix that in the next pass. Furthermore, auditable events in \cite{RFC2401} do not specify such a minimum list of information. [there are exactly 3 events defined as auditable in 2401, one of which overlaps with 2406. So, to be more precise, the other 2 auditable events defined in 2401 ought to have the minimum data requirements defined. Another good point that we will fix in the next pass.] The documentation should be reviewed to ensure that a minimum list of audit-log information is specified with each auditable event. \item Various algorithm specifications require the implementation to reject known weak keys. For example, the DES-CBC encryption algorithm specifications \cite{RFC2405} requires that DES weak keys are rejected. It is questionable whether this actually increases security. It might very well be that the extra code that this requires creates more security problems due to bugs than are solved by rejecting weak keys. Weak keys are not really a problem in most situations. For DES, it is far less work for an attacker to do an exhaustive search over all possible keys than to wait for an SA that happens to use a weak key. After all, the easiest way for the attacker to detect the weak keys is to try them all. Weak-key rejection is only required for algorithms where detecting the weak key class by the weak cipher properties is significantly less work than trying all the weak keys in question. We recommend that the weak-key elimination requirement be removed. Encryption algorithms that have large classes of weak keys that introduce security weaknesses should simply not be used. [I tend to agree with this analysis. The argument for weak key checking was made by folks who don't understand the cryptographic issues involved, but who are persistent and loud, e.g., Bill Simpson. Ted T'so (co-chair of the WG) and I discussed this problem, and tried to explain it to the list, but were unsuccessful. Another flaw in the committee process.] \item The only mandatory encryption algorithm in ESP is DES-CBC. Due to the very limited key length of DES, this cannot be considered to be very secure. We strongly urge that this algorithm not be standardized but be replaced by a stronger alternative. The most obvious candidate is triple-DES. Blowfish could be used as an interim high-speed solution.\footnote{On a Pentium CPU, Blowfish is about six to seven times faster than triple-DES.} The upcoming AES standard will presumably gain quick acceptance and probably become the default encryption method for most systems. [DES as a default was mandated because of pressure from vendors who, at the time, could not get export permission for 3DES. Triple DES or AES will certainly augment DES as additional, mandatory defaults, and may replace it in the future. ] \item The insistence on randomly selected IV values in \cite{RFC2405} seems to be overkill. It is true that a counter would provide known low Hamming-weight input differentials to the block cipher. All reasonable block ciphers are secure enough against this type of attack. Use of a random generator results in an increased risk of an implementation error that will lead to low-entropy or constant IV values; such an error would typically not be found during testing. [In practice the IV is usually acquired from previous ciphertext output, as suggested in the text for CBC mode ciphers, which is easy to acquire and not likely to result in significant complexity. In hardware assisted environment an RNG is usually available anyway. In a high assurance hardware implementation, the crypto chip would generate the IV.] \item Use of a block cipher with a 64-bit block size should in general be limited to at most $2^{32}$ block encryptions per key. This is due to the birthday paradox. After $2^{32}$ blocks we can expect one collision.\footnote{To get a $10^{-6}$ probability of a collision it should be limited to about $2^{22}$ blocks.} In CBC mode, two equal ciphertexts give the attacker the XOR of two blocks of the plaintext. The specifications for the DES-CBC encryption algorithm \cite{RFC2405} should mention this, and require that any SA using such an algorithm limit the total amount of data encrypted by a single key to a suitable value. \item The preferred mode for using a block cipher in ESP seems to be CBC mode \cite{RFC2451}. This is probably the most widely used cipher mode, but it has some disadvantages. As mentioned earlier, a collision gives direct information about the relation of two plaintext blocks. Furthermore, in hardware implementations each of the encryptions has to be done in turn. This gives a limited parallelism, which hinders high-speed hardware implementations. [first, this is not an intrinsic part of the architecture; one can define different modes for use with existing or different algorithms if the WG is so motivated. Second, current hardware is available at speeds higher than the associated packet processing capability of current IPsec devices, so this does not appear to be a problem for the near term. Transition to AES will decrease the processing burden (relative to 3DES), which may render this concern less serious.] Although not used very often, the counter mode seems to be preferable. The ciphertext of block $i$ is formed as $C_i = P_i \oplus E_K( i )$, where $i$ is the block number that needs to be sent at the start of the packet.\footnote{If replay protection is always in use, then the starting $i$-value could be formed as $2^{32}$ times the sequence number. This saves eight bytes per packet.} After more than $2^{32}$ blocks counter mode also reveals some information about the plaintext, but this is less than what occurs in CBC. The big advantage of counter mode is that hardware implementations can parallelize the encryption and decryption process, thus achieving a much higher throughput. [earlier the authors criticize IPsec for a lack of orthogonality, but introducing interdependence between the anti-replay counter and encryption would certainly violate the spirit of the earlier criticism! Counter mode versions of algorithms can be added to the list easily if there is sufficient vendor support.] \item \cite[section 2.3]{RFC2451} states that Blowfish has weak keys, but that the likelihood of generating one is very small. We disagree with these statements. The likelihood of getting two equal 32-bit values in any one 256-entry S-box is about ${256 \choose 2} \cdot 2^{-32} \approx 2^{-17}$. This is an event that will certainly occur in practice. However, the Blowfish weak keys only lead to detectable weaknesses in reduced-round versions of the cipher. There are no known weak keys for the full Blowfish cipher. \item In \cite[section 2.5]{RFC2451}, it is suggested to negotiate the number of rounds of a cipher. We consider this to be a very bad idea. The number of rounds is integral to the cipher specifications and should not be changed at will. Even for ciphers that are specified with a variable number of rounds, the determination of the number of rounds should not be left up to the individual system administrators. The IPsec standard should specify the number of rounds for those ciphers. [I agree that this algorithm spec ought not encourage negotiation of the number of rounds, without specifying a minimum for each cipher, although this gets us into the crypto strength value judgement arena again. Also, the inclusion of 3DES in this table is inappropriate as it is a 48 round algorithm, period. So, yes, there is definite room for improvement in this RFC.] \item \cite[section 2.5]{RFC2451} proposes the use of RC5. We urge caution in the use of this cipher. It uses some new ideas that have not been fully analyzed or understood by the cryptographic community. The original RC5 as proposed (with 12 rounds) was broken, and in response to that the recommended number of rounds was increased to 16. We feel that further research into the use of data-dependent rotations is required before RC5 is used in fielded systems. [RC5 is not required by IPsec implementations. In the IETF spirit of flexible parameterization of implementations, vendors are free to offer any additional algorithms in addition to the required default. In general, the IETF is not prepared to make value judgements about these algorithms and so one may see RFCs that specify a variety of additional algorithms.] \item \cite[section 2.4]{RFC2406} specifies that the ESP padding should pad the plaintext to a length so that the overall ciphertext length is both a multiple of the block size and a multiple of 4. If a block cipher of unusual block size is used (e.g., 15 bytes), then this can require up to 59 bytes of padding. This padding rule works best for block sizes that are a multiple of 4, which fortunately is the case for most block ciphers. [this padding rule is based primarily on IP packet alignment considerations, not on common block cipher sizes! This is stated in the text.] \item \cite[p.\ 6, point a]{RFC2406} states that the padding computations of the ESP payload with regard to the block size of the cipher apply to the payload data, excluding the IV (if present), Pad Length, and Next Header fields. This would imply that the Pad Length and Next Header fields are not being encrypted. Yet the rest of the specification is clear that the Pad Length and Next Header field are to be encrypted, which is what should happen. The text of point a should be made consistent with the rest of the text. [The text says "…the padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields." The comma after "IV" is meat to terminate the scope of the word "exclusive," and thus the intent is to include the pad length and next header fields. The term "payload" in ESP applies to a set of data not including the latter two fields, so the sentence is, technically, unambiguous, and it is consistent with the terms employed in the figure in section 2. But, I admit the wording could be improved.] \item There is a document that defines the NULL encryption algorithm used in ESP \cite{RFC2410}, but no document that defines the NULL authentication algorithm, which is also used by ESP \cite[section 5]{RFC2406}. [good point. Another RFC publication opportunity!] \item The NULL cipher specifies an IV length of zero \cite{RFC2410}. This would seem to imply that the NULL cipher is used in CBC mode, which is clearly not the case. The NULL cipher is in fact used in ECB mode, which does not require an IV. Therefore, no IV length should be specified. [use of the NULL cipher in ECB mode would be inconsistent with the guidance in FIPS 82, and thus CBC mode is intended, to preserve the confidentiality characteristics inherent in this cipher :-).] \end{enumerate} \section{Conclusions} The IPsec system should be simplified significantly. This can be done without loss of functionality or performance. There are also some security weaknesses that should be fixed. [the extensive comments above illustrate that the proposed changes to IPsec would change the functionality, contrary to the claim made here. One might argue about the importance of some of this functionality, but several examples have been provided to illustrate application contexts that the authors of this report did not consider in their analysis. Several misunderstandings of some RFCs also were noted.] Due to its high complexity, we have not been able to analyze IPsec as thoroughly as we would have liked. After simplification, a new security analysis should be performed. I have not reviewed the ISAKMP/IKE comments. However, I agree that this protocol is very complex. Much of the complexity results of incremental enhancement and a reluctance on the part of developers to discard older versions of code. " -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 09:05:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GH0o711807 for ipng-dist; Wed, 16 Feb 2000 09:00:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GH0g011800 for ; Wed, 16 Feb 2000 09:00:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09712 for ; Wed, 16 Feb 2000 09:00:42 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25574 for ; Wed, 16 Feb 2000 09:00:41 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id IAA19279; Wed, 16 Feb 2000 08:52:52 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <38AA920D.D74E023D@nortelnetworks.com> References: <200002160451.XAA0000006455@quarry.zk3.dec.com> <38AA920D.D74E023D@nortelnetworks.com> Date: Wed, 16 Feb 2000 08:54:27 -0800 To: "Brian Haberman" From: Steve Deering Subject: Re: draft-ietf-ipngwg-scoped-routing-02.txt Cc: Jim Bound , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:03 AM -0500 2/16/00, Brian Haberman wrote: >I put the "If... to be realized" comment in there to emphasize that >there is a performance impact, but if we as a WG are serious >about scoped addresses then this impact should be acceptable. The impact is no different than that required to prevent forwarding of packets with link-local source addresses or invalid source addresses such as multicast, loopback, or unspecified addresses. Such source- address filtering is a SHOULD requirement for IPv4 (see RFC 1812, section 5.3.7), and a MUST requirement for IPv6. And given the heightened concern about source-address spoofing arising from the recent attacks on prominent web sites, we are likely to see even more demand for source-address checking by routers. > > Also in the above should you not reiterate at this point in the draft > > that a multisited router will have to keep forwarding tables for each > > site-interface it supports? > >Good point. I can add such a statement. Shouldn't that be per-site, not per-site-interface? 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 Feb 16 09:10:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GH9NO11829 for ipng-dist; Wed, 16 Feb 2000 09:09:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GH9F011822 for ; Wed, 16 Feb 2000 09:09:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA11236 for ; Wed, 16 Feb 2000 09:09:15 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00334 for ; Wed, 16 Feb 2000 09:09:14 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA20084; Wed, 16 Feb 2000 09:02:06 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200002161502.KAA0000028624@quarry.zk3.dec.com> References: <200002161502.KAA0000028624@quarry.zk3.dec.com> Date: Wed, 16 Feb 2000 09:03:40 -0800 To: Jim Bound From: Steve Deering Subject: Re: draft-ietf-ipngwg-scoped-routing-02.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:02 AM -0500 2/16/00, Jim Bound wrote: >Hint: vendors build a config switch in their v6 implementation that never >permits a source address of lesser scope to be used with a dst address >of greater scope. This means scope exceeded cannot happen at the >router. Jim, Your conclusion that "scope exceeded cannot happen at the router" is incorrect, because there is no way to guarantee that all sources will have the configuration switch set as you wish, nor that all sources will obey the configuration switch (e.g., sources using "raw" transmission interfaces). I.e., routers cannot depend on sources being "well-behaved". 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 Feb 16 09:15:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GHClg11848 for ipng-dist; Wed, 16 Feb 2000 09:12:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GHCc011841 for ; Wed, 16 Feb 2000 09:12:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA22944 for ; Wed, 16 Feb 2000 09:12:38 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02399 for ; Wed, 16 Feb 2000 09:12:37 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 48563975; Wed, 16 Feb 2000 12:12:37 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 1CC03775; Wed, 16 Feb 2000 12:12:37 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000005037; Wed, 16 Feb 2000 12:12:36 -0500 (EST) From: Jim Bound Message-Id: <200002161712.MAA0000005037@quarry.zk3.dec.com> To: Steve Deering Cc: "Brian Haberman" , Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scoped-routing-02.txt In-reply-to: Your message of "Wed, 16 Feb 2000 08:54:27 PST." Date: Wed, 16 Feb 2000 12:12:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi steve, >Shouldn't that be per-site, not per-site-interface? yep.. good catch steve that is what was in my head but not my words. good point about src filtering another IPv6 advantage.... thx /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 Feb 16 09:18:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GHHfU11870 for ipng-dist; Wed, 16 Feb 2000 09:17:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GHHW011863 for ; Wed, 16 Feb 2000 09:17:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA01027 for ; Wed, 16 Feb 2000 09:17:32 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05508 for ; Wed, 16 Feb 2000 09:17:32 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id E7BCA5786D; Wed, 16 Feb 2000 11:17:30 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id E2DA254610; Wed, 16 Feb 2000 11:17:30 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id BA079BC4CA; Wed, 16 Feb 2000 11:17:23 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 5C08EB2A42; Wed, 16 Feb 2000 11:17:23 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000016773; Wed, 16 Feb 2000 12:17:29 -0500 (EST) From: Jim Bound Message-Id: <200002161717.MAA0000016773@quarry.zk3.dec.com> To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scoped-routing-02.txt In-reply-to: Your message of "Wed, 16 Feb 2000 09:03:40 PST." Date: Wed, 16 Feb 2000 12:17:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, >At 10:02 AM -0500 2/16/00, Jim Bound wrote: >>Hint: vendors build a config switch in their v6 implementation that never >>permits a source address of lesser scope to be used with a dst address >>of greater scope. This means scope exceeded cannot happen at the >>router. > >Jim, > >Your conclusion that "scope exceeded cannot happen at the router" is >incorrect, because there is no way to guarantee that all sources will >have the configuration switch set as you wish, nor that all sources will >obey the configuration switch (e.g., sources using "raw" transmission >interfaces). I.e., routers cannot depend on sources being "well-behaved". We can gurantee it if the customer mandates that this switch be set by all hosts which is the mantra I will begin to preach in the open market. I will also add that routers should have such a switch too. If they don't turn it on then your right but if they all "obey" the mantra it will work at least for early deployment. We have many cases of non-ietf defined behavior that is working quite well in the industry like ingress filtering, etherchannel, etc.. we can also do this with IPv6 Host systems. /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 Feb 16 10:09:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GI60Q11911 for ipng-dist; Wed, 16 Feb 2000 10:06:00 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GI5o011904 for ; Wed, 16 Feb 2000 10:05:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA01847 for ; Wed, 16 Feb 2000 10:05:50 -0800 (PST) Received: from fb01.eng00.mindspring.net (fb01.eng00.mindspring.net [207.69.229.19]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28711 for ; Wed, 16 Feb 2000 11:05:47 -0700 (MST) Received: from ix.netcom.com (user-33qsd2r.dialup.mindspring.com [199.174.52.91]) by fb01.eng00.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA25408; Wed, 16 Feb 2000 13:04:11 -0500 (EST) Message-ID: <38AB0026.E50A914B@ix.netcom.com> Date: Wed, 16 Feb 2000 11:53:10 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Ignatios Souvatzis CC: Jim Bound , ipng@sunroof.eng.sun.com, members@ipv6forum.com Subject: Re: INFO: RESPONSE: A Cryptographic Evaluation of IPsec References: <200002161409.JAA0000016352@quarry.zk3.dec.com> <20000216151755.E27517@theory.cs.uni-bonn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios and all, A text version would be nice. Is that avalible? Ignatios Souvatzis wrote: > On Wed, Feb 16, 2000 at 09:09:04AM -0500, Jim Bound wrote: > > Folks, > > > > >From mail yesterday below. > > Stephen Kent's response to the Counterpane IPsec Evaluation at: > > ftp://206.152.163.3/pub/ipsec_kent_reply.doc > > This looks like TeX from a Mac (or other CR-only line break) machine, > embedded in a MS Word document... can somebody please decode it? > > (TeX would be fine, but it seems to have been reorderd by the Word block > processing...) > > Regards, > -is > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 10:51:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GImPn12027 for ipng-dist; Wed, 16 Feb 2000 10:48:25 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GImK012020 for ; Wed, 16 Feb 2000 10:48:21 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA02708 for ipng@sunroof.eng.sun.com; Wed, 16 Feb 2000 10:46:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GDXr011585 for ; Wed, 16 Feb 2000 05:33:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA24524 for ; Wed, 16 Feb 2000 05:33:54 -0800 (PST) Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [130.155.191.233]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12001 for ; Wed, 16 Feb 2000 05:33:51 -0800 (PST) Received: from isc.org (marka@localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.8.5/8.8.5) with ESMTP id AAA13916; Thu, 17 Feb 2000 00:30:55 +1100 (EST) Message-Id: <200002161330.AAA13916@bsdi.dv.isc.org> To: Francis Dupont Cc: Yoshinobu Inoue , bound@zk3.dec.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Wed, 16 Feb 2000 12:15:09 BST." <200002161115.MAA16679@givry.inria.fr> Date: Thu, 17 Feb 2000 00:30:44 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > RFC2553 says inet_pton() don't support non-standard IPv4 addr > forms. (such as. 10.1 for 10.0.0.1) > > => I believe these non-standard IPv4 address forms should be > garbage collected... I am in favor of a little statement or > a reference about what is the textual form of an IPv4 address > (in fact we need this too for IPv4 compatible IPv6 addresses > which are usually represented as ::. RFC 2373 > uses but does not define the "standard IPv4 representation" > then perhaps it is not enough to add a reference to it? I think this is perfectly clear. The description below does not allow for the other forms. RFC2373, Section 2.2. 3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). > > 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 > -------------------------------------------------------------------- -- Mark Andrews, Nominum Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.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 Feb 16 11:07:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GJ4wI12084 for ipng-dist; Wed, 16 Feb 2000 11:04:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GJ4n012077 for ; Wed, 16 Feb 2000 11:04:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28466 for ; Wed, 16 Feb 2000 11:04:47 -0800 (PST) Received: from srv-cvp02.sdxplc.com (plum.sdxplc.com [194.202.233.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07066 for ; Wed, 16 Feb 2000 12:04:46 -0700 (MST) Received: from nt1-3.sdxplc.com (nt1-3.sdxplc.com [172.16.2.5]) by srv-cvp02.sdxplc.com (Dr Solomon's SMTPRS 2.0.15) with ESMTP id ; Wed, 16 Feb 2000 19:00:38 +0000 Received: by nt1-3.sdxplc.com with Internet Mail Service (5.5.2650.21) id <12SPW9BP>; Wed, 16 Feb 2000 19:03:30 -0000 Message-Id: <47C58C0CC8E2D111873600805FB756EC35CFF7@nt1-3.sdxplc.com> From: Victor Inzani To: "'Jeff Williams '" , "'Ignatios Souvatzis '" Cc: "'ipng@sunroof.eng.sun.com '" , "'members@ipv6forum.com '" Subject: RE: INFO: RESPONSE: A Cryptographic Evaluation of IPsec Date: Wed, 16 Feb 2000 19:03:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF78B0.82C40588" 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_01BF78B0.82C40588 Content-Type: text/plain; charset="ISO-8859-1" A text version would be v. useful. -----Original Message----- From: Jeff Williams To: Ignatios Souvatzis Cc: Jim Bound; ipng@sunroof.eng.sun.com; members@ipv6forum.com Sent: 16/02/00 19:53 Subject: Re: INFO: RESPONSE: A Cryptographic Evaluation of IPsec Ignatios and all, A text version would be nice. Is that avalible? Ignatios Souvatzis wrote: > On Wed, Feb 16, 2000 at 09:09:04AM -0500, Jim Bound wrote: > > Folks, > > > > >From mail yesterday below. > > Stephen Kent's response to the Counterpane IPsec Evaluation at: > > ftp://206.152.163.3/pub/ipsec_kent_reply.doc > > This looks like TeX from a Mac (or other CR-only line break) machine, > embedded in a MS Word document... can somebody please decode it? > > (TeX would be fine, but it seems to have been reorderd by the Word block > processing...) > > Regards, > -is > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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_01BF78B0.82C40588 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: INFO: RESPONSE: A Cryptographic Evaluation of IPsec

A text version would be v. useful.

-----Original Message-----
From: Jeff Williams
To: Ignatios Souvatzis
Cc: Jim Bound; ipng@sunroof.eng.sun.com; = members@ipv6forum.com
Sent: 16/02/00 19:53
Subject: Re: INFO: RESPONSE: A Cryptographic = Evaluation of IPsec

Ignatios and all,

  A text version would be nice.  Is that = avalible?

Ignatios Souvatzis wrote:

> On Wed, Feb 16, 2000 at 09:09:04AM -0500, Jim = Bound wrote:
> > Folks,
> >
> > >From mail yesterday below.
> > Stephen Kent's response to the Counterpane = IPsec Evaluation at:
> > ftp://206.152.163.3/pub/ipsec_kent_reply.doc
>
> This looks like TeX from a Mac (or other = CR-only line break) machine,
> embedded in a MS Word document... can somebody = please decode it?
>
> (TeX would be fine, but it seems to have been = reorderd by the Word
block
>  processing...)
>
> Regards,
>         = -is
> = --------------------------------------------------------------------
> 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
> = --------------------------------------------------------------------

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA = Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas = 75208


---------------------------------------------------------------= -----
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_01BF78B0.82C40588-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 12:52:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1GKle512141 for ipng-dist; Wed, 16 Feb 2000 12:47:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1GKlH012134 for ; Wed, 16 Feb 2000 12:47:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA13095 for ; Wed, 16 Feb 2000 12:47:15 -0800 (PST) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06867 for ; Wed, 16 Feb 2000 12:46:44 -0800 (PST) Received: by itesec.hsc.fr (Postfix) id CD30311125; Wed, 16 Feb 2000 21:46:32 +0100 (CET) Received: by itesec.hsc.fr (Postfix) id CD30311125; Wed, 16 Feb 2000 21:46:32 +0100 (CET) Date: Wed, 16 Feb 2000 21:46:35 +0100 From: Jean-Jacques Bernard To: Jeff Williams Cc: Ignatios Souvatzis , Jim Bound , ipng@sunroof.eng.sun.com, members@ipv6forum.com Subject: Re: INFO: RESPONSE: A Cryptographic Evaluation of IPsec Message-ID: <20000216214635.A13525@kuching.hsc.fr> Mail-Followup-To: Jeff Williams , Ignatios Souvatzis , Jim Bound , ipng@sunroof.eng.sun.com, members@ipv6forum.com References: <200002161409.JAA0000016352@quarry.zk3.dec.com> <20000216151755.E27517@theory.cs.uni-bonn.de> <38AB0026.E50A914B@ix.netcom.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" X-Mailer: Mutt 1.0.1i In-Reply-To: <38AB0026.E50A914B@ix.netcom.com>; from jwkckid1@ix.netcom.com on Wed, Feb 16, 2000 at 11:53:10AM -0800 X-Operating-System: OpenBSD 2.6 X-Organization: Herve Schauer Consultants Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii A text version. Sorry for the references which disappeared (complaint to teTeX and GhostScript :). Use the original document (www.counterpane.com/ipsec.html) for references. Jean-Jacques -- Jean-Jacques Bernard *-*-* HSC *-*-* Network Security Consultant --mYCpIKhGyMATD0i+ Content-Type: text/plain Content-Disposition: attachment; filename="ipsec.txt" Executive summary IPsec is a set of protocols that provides communication security for comput-ers using IP-based communication networks. It provides authentication and confidentiality services on a packet level. To support the IPsec security, a keymanagement protocol called ISAKMP is used. ISAKMP uses public-key cryptographic techniques to set up keys between the different parties to be used withIPsec. Both IPsec and ISAKMP are too complex. [a protocol is too complex onlyrelative to a specified set of requirements that are satisfied by a simpler protocol. To substantiate this observation, one ought to define the requirements that onebelieves the protocol is trying top satisfy, and then offer a simpler protocol.] This high complexity leads to errors. We have found security flaws in bothIPsec and ISAKMP, and expect that there are many more. We expect any actual implementation to contain many more errors, some of which will cause securityweaknesses. These protocols give the impression of having been designed by a committee: they try to be everything for everybody at the cost of complexity.For normal standards, that is bad enough; for security systems, it is catastrophic. In our opinion, the complexity of both IPsec and ISAKMP can be reduced bya large factor without a significant loss of functionality. IPsec is in better shape than ISAKMP. The description and definitions arereasonably clear. A careful implementation of IPsec can achieve a good level of security. Unfortunately, IPsec by itself is not a very useful protocol. Use on alarge scale requires the key management functions of ISAKMP. [while I would tend to agree with this observation, I should note that a non-trivial number ofIPsec implementations, used in constrained contexts, are manually keyed.] ISAKMP is currently not in a suitable state for implementation. Major workwill be required to get it to that point. There are many security-critical errors, as well as many unnecessary cross-dependencies within the protocol. Theseshould all be eliminated before a new evaluation is done. Based on our analysis, we recommend that IPsec and ISAKMP not be usedfor confidential information. At the moment we cannot recommend a direct alternative. Some applications might be able to use SSL [?], which in ouropinion is a much better protocol that provides a much higher level of security when used appropriately. 1 Contents 2 Chapter 1 Introduction At the request of NSA, Counterpane has conducted a security review of theIPsec and ISAKMP security protocols. This evaluation is based on RFCs 2401-2411 and RFC 2451. The Oakley protocol is only an informational RFC; it is notpart of the standard and is not used in ISAKMP. RFC documents are available from ftp:ftp.isi.edu/in-notes/rfc.txt.As states: "The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, thesecurity offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards.Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations,and computer security practices. Thus IPsec is only one part of an overall system security architecture." This evaluation only deals with the IPsec andISAKMP specifications and is not directly concerned with any of the other factors. However, we do comment on aspects of the specifications that affectother security factors. IPsec and ISAKMP are highly complex systems. Unfortunately, we cannotgive a sufficiently detailed description of these systems in this document to allow the reader to understand our comments without being familiar with IPsecand ISAKMP. Our comments frequently refer to specific places in the RFC documents for ease of reference.The rest of this report is structured as follows. Chapter ?? gives some general comments. Chapter ?? discusses the IPsec protocols that handle bulkdata. Chapter ?? discusses the ISAKMP generic definitions. Chapter ?? talks about the IPsec Domain of Interpretation which gives more details on how thegeneric ISAKMP structure applies to the IPsec protocols. Finally, chapter ?? discusses the IKE protocol that is the default key management protocol usedwith ISAKMP. Chapter 2 General comments 2.1 Complexity Complexity is the biggest enemy of security. This might seem an odd statementin the light of the many fielded systems that exhibit critical security failures for very simple reasons. It is true nonetheless. The simple failures are simple toavoid, and often simple to fix. The problem is not that we do not know how to solve them; it is that this knowledge is often not applied. Complexity, however,is a different beast because we do not really know how to handle it. Designing any software system is always a matter of weighing various require-ments. These include functionality, efficiency, political acceptability, security, backward compatibility, deadlines, flexibility, ease of use, and many more. Theunspoken requirement is often the complexity. If the system gets too complex, it becomes too difficult, and therefore too expensive, to make. As fulfilling moreof the requirements usually involves a more complex design, many systems end up with a design that is as complex as the designers and implementors canreasonably handle. Virtually all software is developed using a try-and-fix methodology. Smallpieces are implemented, tested, fixed, and tested again. Several of these small pieces are combined into a larger module, and this module is tested, fixed, andtested again. The end result is software that more or less functions as expected, although we are all familiar with the high frequency of functional failures of software systems. This process of making fairly complex systems and implementing them witha try-and-fix methodology has a devastating effect on the security. The central reason is that you cannot test for security. Therefore, security bugs are notdetected during the development process in the same way that functional bugs are. Suppose a reasonably sized program is developed without any testing atall during development and quality control. We feel confident in stating that the result will be a completely useless program; most likely it will not perform 1Usually several iterations are required. any of the desired functions correctly. Yet this is exactly what we get from thetry-and-fix methodology when we look at security. The only reasonable way to "test" the security of a security product is toperform security reviews on it. A security review is a manual process; it is relatively expensive in terms of time and effort and it will never be able toshow that the product is in fact secure. [this seems to ignore the approaches usually employed for high assurance system design and implementation , i.e.,careful design and review coupled with rigid development procedures, all prior to testing.]The more complex the system is, the harder a security evaluation becomes. A more complex system will have more security-related errors in the specification,design, and implementation. We claim that the number of errors and difficulty of the evaluation are not linear functions of the complexity, but in fact growmuch faster. For the sake of simplicity, let us assume the system has n different options,each with two possible choices. Then there are n(n - 1)/2 = O(n2) different pairs of options that could interact in unexpected ways, and 2n different config-urations altogether. Each possible interaction can lead to a security weakness, and the number of possible complex interactions that involve several optionsis huge. As each interaction can produce a security weakness, we expect that the number of actual security weaknesses grows very rapidly with increasingcomplexity. The same holds for the security evaluation. For a system with a moderatenumber of options, checking all the interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thusthe difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknessesand a more difficult security analysis unavoidably results in insecure systems. In actual systems, the situation is not quite so bad; there are often optionsthat are "orthogonal" in that they have no relation or interaction with each other. This occurs, for example, if the options are on different layers in thecommunication system, and the layers are separated by a well-defined interface that does not "show" the options on either side. For this very reason, such aseparation of a system into relatively independent modules with clearly defined interfaces is a hallmark of good design. Good modularization can dramaticallyreduce the "effective" complexity of a system without the need to eliminate important features. Options within a single module can of course still have in-teractions that need to be analyzed, so the number of options per module should be minimized. Modularization works well when used properly, but most actualsystems still include cross-dependencies where options in different modules do affect each other. Cracking contest can be seen as a cheap way of getting other people to do a security analysis. The big problem is interpreting the results. If the prize is not claimed, it does not imply that any competent analysis was done and came up empty. We use n as the measure of the complexity. This seems reasonable, as the length of the system specification and the implementation is proportional to n. A more complex system loses on all fronts. It contains more weaknesses tostart with, it is much harder to analyze, and it is much harder to implement without introducing security-critical errors in the implementation.Complexity not only makes it virtually impossible to create a secure implementation, it also makes the system extremely hard to manage. The peoplerunning the actual system typically do not have a thorough understanding of the security issues involved. Configuration options should therefore be kept toa minimum, and the options should provide a very simple model to the user. Complex combinations of options are very likely to be configured erroneously,which results in a loss of security. The stories in and illustrate howmanagement of complex systems is often the weakest link. Both IPsec and ISAKMP are too complex to be secure. The design obviouslytries to support many different situations with different options. We feel very strongly that the resulting system is well beyond the level of complexity thatcan be implemented securely with current methodologies. 2.2 Stating what is achieved A security analysis evaluates the security aspects of a system. To be able togive any sensible answer, it should be clear what properties the system claims to have. That is, the system documentation should clearly state what securityproperties are achieved. This can be seen as the functional specification of the security properties. This applies not only to the entire system, but also to theindividual modules. At each module or function, the security properties should be specified.A good comparison is the testing of a product. The testing verifies that the product performs according to the functional specifications. Without specifi-cations, the testers might have some interesting comments, but they can never give a real answer.Without security specifications, the first task of the security analysis is to create descriptions of the security properties achieved, based on the perceivedintentions of the system designer. The subsequent evaluation might then turn up problems of the form "this function does not achieve the properties thatwe think it should have." The obvious answer will be: "but that is not the properties that I designed it to have." Very quickly the discussion moves awayfrom the actual security into what was meant. The overall result is a security evaluation that might point out some potential weaknesses, but that will hardlyhelp in improving the security. The IPsec and ISAKMP protocols do not specify clearly which security prop-erties they claim to achieve. [RFCs 2401, 2402, and 2406 clearly state the security services offered by the AH and ESP protocols.] The same holds for themodules and functions. [modules are not specified by these standards; they are implementation artifacts.] We recommend that each function, module, and pro-tocol be extended to include clear specifications regarding the security-related functionality they achieve. We feel that unless this is done, it will not be possible to perform an adequate security evaluation on a system of this complexity. Chapter 3 Bulk data handling In this chapter we discuss the methods used to handle the encryption and au-thentication of the bulk data, as specified in . Togetherthese documents specify the IPsec protocol. They specify the actual encryption and authentication of packets, assuming that symmetric keys have already beenexchanged. We refer the reader to sections 1-4.2 for an overview of this part of IPsec and the relevant terminology. 3.1 Functionality IPsec is capable of providing authentication and confidentiality services on apacket level. The security configuration of an IPsec implementation is done centrally, presumably by the system administrator. [In some environments, asingle administrator might control the configuration of each IPsec implementation, or each user might have some control over it. The latter would tend to becharacterized as a distributed management paradigm, not a central one. Also, two IPsec peers communicate ONLY if both agree on the security parametersfor the SA, i.e., there is suitable overlap in the SPDs. In that sense too, security configuration is distributed.]IPsec is very suitable for creating a VPN over the Internet, improved security for dial-in connections to portables, restricting access to parts of a network, etc.These are very much network-level functions. IPsec by itself does not supply application-level security. Authentication links the packet to the security gate-way of the originating network, the originating host, or possibly the originating user, but not to the application in question or the data the application washandling when it sent the packet. [true, but for many applications, application layer security is not needed, and its implementation might well be accorded lessassurance than the network layer security provided by IPsec. This paragraph seems to suggest that there is some important benefit to linking data to an ap-plication, through an application-specific security mechanism. There are good examples of where this is true, e.g., e-mail and directories. However, unless there are application-specific security semantics that cannot be captured by use of anapplication security protocol, your own arguments about simplicity, as well as a number of arguments re assurance, argue against proliferation of applicationsecurity protocols. The IPsec functionality can significantly increase the security of the network.It is not a panacea for all security problems, and applications that require security services will typically have to use other security systems in additionto IPsec. [I might disagree with the term "typically" here. A lot depends on the application, where IPsec is implemented, etc.] 3.2 Complexity Our biggest criticism is that IPsec is too complex. There are too many optionsthat achieve the same or similar properties. [if they were completely equivalent this would be a good basis for simplifying IPsec. However, there are subtledifferences that have resulted in the proliferation of options you address below.] 3.2.1 Options IPsec suffers from an abundance of options. For example, two hosts that wantto authenticate IP packets can use four different modes: transport/AH, tunnel/AH, transport/ESP with NULL encryption, and tunnel/ESP with NULLencryption. The differences between these options, both in functionality and performance, are minor.In particular, the following options seem to create a great deal of needless complexity: 1. There are two modes that can be used: transport mode and tunnel mode.In transport mode, the IP header of the packet is left untouched. AH authenticates both the IP header and the packet payload. ESP encryptsand authenticates the payload, but not the header. The lack of header authentication in transport/ESP is a real weakness, as it allows variousmanipulations to be performed. In tunnel mode, the full original IP packet (including headers) is used as the payload in a new IP packet with newheaders. The same AH or ESP functions are used. As the original header is now included in the ESP authentication, the transport/ESP authenti-cation weakness no longer exists. Transport mode provides a subset of the functionality of tunnel mode. Theonly advantage that we can see to transport mode is that it uses a somewhat smaller bandwidth. However, the tunnel mode could be extendedin a straightforward way with a specialized header-compression scheme that we will explain shortly. This would achieve virtually the same per-formance as transport mode without introducing an entirely new mode. We therefore recommend that the transport mode be eliminated. [trans-port mode and tunnel mode address fundamentally different requirements, from a networking point of view. When security gateways are involved,the use of tunnel mode is an absolute requirement, whereas it is a minor (and rarely used) feature for communications between end systems. Aproposal to make all traffic tunnel mode, and to try to offset the added overhead through compression, seems to ignore the IPCOMP facility thatis already available to IPsec implementations. Today, transport mode is used primarily to carry L2TP traffic, although this is primarily an effi-ciency issue.] 2. There are two protocols: AH and ESP. AH provides authentication, andESP provides encryption, authentication, or both. In transport mode, AH provides a stronger authentication than ESP can provide, as it also au-thenticates the IP header. One of the standard modes of operation would seem to be to use both AH and ESP in transport mode. [although thismode is required to be supported, it seems to be rarely used today. A plausible, near-term use for AH is to provide integrity and authenticityfor IPsec traffic between an end system and a first-hop intermediary. For example, AH can be used between a host inside an enclave and a securitygateway at the perimeter, to allow the SG to control what traffic leaves the enclave, without granting the SG access to plaintext traffic. This, andsimilar concatenated SA examples, motivate retention of AH. One could achieve a similar effect with (authentication-only) ESP tunnels, but withincreased bandwidth and processing overhead.] In tunnel mode, the authentication that ESP provides is good enough (it includes the IP header),and AH is typically not combined with ESP [?, section 4.5]. [the example above shows why one might wish to use AH for the outer header, but mostlikely with ESP in transport mode.] (Implementations are not required to support nested tunnels that would allow ESP and AH to both be used.) The AH protocol [?] authenticates the IP headers of the lower layers. [AHauthenticates the IP header at the SAME layer, in many respects. AH was originally described as an IP (v4) option. In IPv6, AH is viewed aspart of the AH header, and may appear before other header extensions (see section 4.1 of RFC 2401). I agree that AH represents ugly layering,but it's not as bad as you suggest here.] This creates all kind of problems, as some header fields change in transit. As a result, the AH protocol needsto be aware of all data formats used at lower layers so that these mutable fields can be avoided. [this is an inaccurate characterization, especiallygiven the status of AH re IPv6. Don't think of AH as a transport protocol. It isn't.] This is a very ugly construction, and one that will createmore problems when future extensions to the IP protocol are made that create new fields that the AH protocol is not aware of. [RFC 2402 explainshow to deal with new IP header fields in v6 (see section 3.3.3.1.2.2). The existence of a mutability flag in such extensions makes processing rela-tively straightforward.] Also, as some header fields are not authenticated, the receiving application still cannot rely on the entire packet. To fullyunderstand the authentication provided by AH, an application needs to take into account the same complex IP header parsing rules that AH uses.The complex definition of the functionality that AH provides can easily lead to security-relevant errors. The tunnel/ESP authentication avoids this problem, but uses more band-width. [but it does not provide exactly the same features, as noted above, so the alternative is not quite equivalent.] The extra bandwidth require-ment can be reduced by a simple specialized compression scheme: for some suitably chosen set of IP header fields X, a single bit in the ESPheader indicates whether the X fields in the inner IP header are identicalto the corresponding fields in the outer header. The fields in question are then removed to reduce the payload size. This compression should be ap-plied after computing the authentication but before any encryption. The authentication is thus still computed on the entire original packet. Thereceiver reconstitutes the original packet using the outer header fields, and verifies the authentication. A suitable choice of the set of header fields Xallows tunnel/ESP to achieve virtually the same low message expansion as transport/AH. We conclude that eliminating transport mode allows the elimination ofthe AH protocol as well, without loss of functionality. [counter examples provided above suggest that this claim is a bit overstated.] 3. The standard defines two categories of machines: hosts and security gate-ways. Hosts can use transport mode, but security gateways must always use tunnel mode. Eliminating transport mode would also allow this dis-tinction to be eliminated. Various computers could of course still function as hosts or security gateways, but these different uses would no longeraffect the protocol. 4. The ESP protocol allows the payload to be encrypted without being au-thenticated. In virtually all cases, encryption without authentication is not useful. The only situation in which it makes sense not to use authen-tication in the ESP protocol is when the authentication is provided by a subsequent application of the AH protocol (as is done in transport modebecause ESP authentication in transport mode is not strong enough). [this is one example of when one might not need authentication with ESP, but itis not the only one. In general, if there is a higher layer integrity and/or authentication function in place, providing integrity/authentication in IPsecis redundant, both in terms of space and processing. The authentication field for ESP or AH is 12 bytes. For applications where packet sizes arequite small, and for some environments where packet size is of critical importance, e.g., packet voice in a wireless environment, ESP w/o au-thentication may be appropriate. This is especially true if the application protocol embodies an authentication mechanism. This might happen if 1A trivial generalization is to have several flag bits, each controlling a set of IP header fields. The application protocol wants to offer uniform protection irrespective ofthe lower layers. Admittedly, this might also cause the application to offer confidentiality as well, but depending on the application, the choices ofwhat security services are being offered may vary.] Without the transport mode to worry about, ESP should always provide its own authentication.We recommend that ESP authentication always be used, and only encryption be made optional. [the question of authentication as an intrinsic partof ESP is independent of mode, i.e., whether one choose to provide authentication as a part of ESP is not determined by the choice of transportvs. tunnel mode.] We can thus remove three of the four operational modes without any sig-nificant loss of functionality. [sorry, can't agree, given the counter examples above.] 3.2.2 Undesirable options There are existing combinations of options that are undesirable. These pose aproblem when non-experts have to configure an IPsec installation. Given the fact that experts are rare and usually have better things to do, most IPsecinstallations will be configured by non-experts. [yes, we were aware of this concern. However, there is always a tradeoff between adopting the "we knowwhat's best for you" approach, vs. the "you can screw it up if you want to approach." We opted for a point somewhere along this spectrum, but not ateither end.] 1. In transport mode, use of ESP provides authentication of the payload only.The authentication excludes the IP headers of the packet. The result is a data stream that is advertised as "authenticated" for which critical piecesof information (such as the source and destination IP number) are not authenticated. Unless the system administrator is intimately familiar withthe different forms of authentication used by IPsec, it is quite likely that the administrator will assume that the authentication protects the entirepacket. The combination of transport mode and the ESP protocol (without the AH protocol) should therefore not be allowed. [The IP source anddestination address are covered by the TCP checksum, which is covered by the ESP integrity check, so this does limit (a tiny bit) the ability tochange these values without detection. A more significant observation is that transport mode IPsec SAs will probably always use source and/ordestination IP addresses as part of the selector set. In such cases, tampering with the either address will result in a failed authentication check.] 2. The standard allows ESP to be used with the NULL encryption, suchthat it provides only authentication. The authentication provided by ESP in transport mode is less functional than the authentication provided byAH, at a similar cost. If transport mode is retained, either the EPS ESP authentication should be extended or the use of ESP with only authenti-cation should be forbidden and replaced by the use of AH. [ESP authentication is more efficient to compute than AH, because of the selectiveIP header coverage provided by AH. Thus there is good reason to allow authentication-only ESP as an alternative to AH. This point was debatedby the group and, with implementation experience, vendors came to agree that this is true.] 3. The ESP protocol can provide encryption without authentication. Thisdoes not make much sense in an application. It protects the application against passive eavesdroppers, but provides no protection against activeattacks that are often far more devastating. Again, this mode can lure non-expert users into using an unsafe configuration that they think issecure. Encryption without authentication should be forbidden. [as noted above, there are examples where this feature set for ESP is attractive.] 3.2.3 Orthogonality IPsec also suffers from a lack of orthogonality. The AH and ESP protocols canbe used together, but should only be used in one particular order. In transport mode, ESP by itself provides only partial authentication of the IP packet, andusing AH too is advisable. [not in most cases, as noted above.] In tunnel mode the ESP protocol authenticates the inner headers, so use of AH is no longerrequired. These interdependencies between the choices demonstrate that these options are not independent of each other. [true, but who says that this is acritical criteria? TCP and IP are not orthogonal either, e.g., note the TCP checksum covering parts of the IP header.] 3.2.4 Compatibility The IPsec protocols are also hampered by the compatibility requirements. Asimple problem is the TOS field in the IP header. Although this is supposed to be unchanged during the transmission of a packet (accordingto the IP specifications), some routers are known to change this field. IPsec chose to exclude the TOS field from the authentication provided by the AHprotocol to avoid errors introduced by such rogue routers. The result is that, in transport/AH packets that have an authenticated header, the TOS field is notauthenticated. This is clearly unexpected from the application point of view, which might want to rely on the correct value of the TOS field. This problemdoes not occur in tunnel mode. [it is unfortunate that cisco chose to not follow the specs here, and in several other places. I agree that an unenlightened system administrator might be surprised in this case. But, in practice, the effect is minimal. Your example cites transport mode, which means that the TOS bitsare being acted upon by the end system. If end systems really paid attention to these bits in the first place, cisco would not have been able to corrupt themwith impunity! The reason that these bits are being re-used by the ECN folks is because hosts have never made use of them. Still, going forward, one shouldpay attention to this vulnerability.] A more complex compatibility problem is the interaction between fragmen-tation and IPsec [?, appendix B]. This is a complex area, but a typical IPsec implementation has to perform specialized processing to facilitate the properbehavior of higher-level protocols in relation to fragmentation. Strictly speaking, fragmentation is part of the communication layer below the IPsec layer, andin an ideal world it would be transparent to IPsec. Compatibility requirements with existing protocols (such as TCP) force IPsec to explicitly handle fragmen-tation issues, which adds significantly to the overall complexity. Unfortunately, there does not seem to be an elegant solution to this problem. [The require-ment here is the same that arises whenever an intermediate system adds info to a packet, or when a smaller MTU intermediate system is traversed. IPsec in anSG is doing what a router along a path would do if the "other side" network were smaller. IPsec in a host is doing what the NIC would do if the LAN MTUchanged. The real complexity arises when we wish to do this optimally, at a security gateway or a BITS or BITW implementation, in cases where differentSAs use different combinations of AH and ESP, or different algorithms, etc.] 3.2.5 Conclusion The overall result is that IPsec bulk data handing is overly complex. In ouropinion it is possible to define an equivalent system that is far less complex. 3.3 Order of operations 3.3.1 Introduction When both encryption and authentication are provided, IPsec performs the en-cryption first, and authenticates the ciphertext. In our opinion, this is the wrong order. Going by the "Horton principle" [?], the protocol should authenticatewhat was meant, not what was said. The "meaning" of the ciphertext still depends on the decryption key used. Authentication should thus be applied to theplaintext (as it is in SSL), and not to the ciphertext.[The order of processingis intentional. It is explicitly designed to allow a receiver to discard a packet as quickly as possible, in the event of DoS attacks, as you acknowledge below. Thesuggestion that this concern be addressed by the addition of a secondary MAC seems to violate the spirit of simplicity that this document espouses so strongly,and the specific proposed fix is not strong enough to warrant its incorporation. Moreover, this ordering allows parallel processing at a receiver, as a means ofincreasing throughput and reducing delay.] This does not always lead to a direct security problem. In the case of theESP protocol, the encryption key and authentication key are part of a single ESP key in the SA. A successful authentication shows that the packet wassent by someone who knew the authentication key. The recipient trusts the sender to encrypt that packet with the other half of the ESP key, so that thedecrypted data is in fact the same as the original data that was sent. The exact argument why this is secure gets to be very complicated, and requiresspecial assumptions about the key agreement protocol. For example, suppose an attacker can manipulate the key agreement protocol used to set up the SA insuch a way that the two parties get an agreement on the authentication key but a disagreement on the encryption key. When this is done, the data transmittedwill be authenticated successfully, but decryption takes place with a different key than encryption, and all the plaintext data is still garbled. [The fundamentalassumption is that an ESP SA that employs both encryption and an HMAC will have the keys bound together, irrespective of the means by which they aregenerated. This assumption probably could be better stated in the RFCs.] In other situations, the wrong order does lead to direct security weaknesses. 3.3.2 An attack on IPsec Suppose two hosts have a manually keyed transport-mode AH-protocol SA,which we will call SAah. Due to the manual keying, the AH protocol does not provide any replay protection. These two hosts now negotiate a transport-mode encryption-only ESP SA (which we will call SAesp1) and use this to send information using both SAesp1 and SAah. The application can expect to getconfidentiality and authentication on this channel, but no replay protection. When the immediate interaction is finished, SAesp1 is deleted. A few hourslater, the two hosts again negotiate a transport-mode encryption-only ESP SA (SAesp2), and the receiver chooses the same SPI value for SAesp2 as was usedfor SAesp1. Again, data is transmitted using both SAesp2 and SAah. The attacker now introduces one of the packets from the first exchange. This packetwas encrypted using SAesp1 and authenticated using SAah. The receiver checks the authentication and finds it valid. (As replay protection is not enabled, thesequence number field is ignored.) The receiver then proceeds to decrypt the packet using SAesp2, which presumably has a different decryption key thenSAesp1. The end result is that the receiver accepts the packet as valid, decrypts it with the wrong key, and presents the garbled data to the application. Clearly,the authentication property has been violated. [this attack is not a criticism of the choice of ESP operation ordering, but rather the notion of applying AHand ESP (encryption only) in a particular order, as allowed by RFC 2401. The specific combination of keying operations described here, though not prohibitedby 2401, does not seem likely to occur in practice. Specifically, if an IPsec implementation supports automated key management, as described above forthe ESP SAs, then it is highly unlikely that the AH SA would be manually keyed. The push to retain manual keying as a base facility for IPsec is waning,and most implementations have IKE available. Under these circumstances, this vulnerability is unlikely to be realized.] 3.3.3 Other considerations Doing the encryption first and authentication later allows the recipient to dis-card packets with erroneous authentication faster, without the overhead of the decryption. This helps the computer cope with denial-of-service attacks in whicha large number of fake packets eat up a lot of CPU time. We question whether this would be the preferred mode of attack against a TCP/IP-enabled computer.If this property is really important, a 1- or 2-byte MAC (Message Authentication Code) on the ciphertext could be added. The MAC code allows the recipientto rapidly discard virtually all bogus packets at the cost of an additional MAC computation per packet. [a one or two byte MAC provides so little protectionthat this does not seem to be an attractive counter-proposal. Also, as noted above, it adds complexity ] 3.3.4 Conclusion The ordering of encryption and authentication in IPsec is wrong. Authenticationshould be applied to the plaintext of the payload, and encryption should be applied after that. 3.4 Security Associations A Security Association (SA) is a simplex "connection' that affords security ser-vices to the traffic carried by it [?, section 4]. The two computers on either side of the SA store the mode, protocol, algorithms, and keys used in the SA.Each SA is used only in one direction; for bidirectional communications two SAs are required. Each SA implements a single mode and protocol; if two protocols(such as AH and ESP) are to be applied to a single packet, two SAs are required. Most of our aforementioned comments also affect the SA system; the use oftwo modes and two protocols make the SA system more complex than necessary. There are very few (if any) situations in which a computer sends an IPpacket to a host, but no reply is ever sent. [we have a growing number of apps where this functionality may be appropriate. For example, broadcast packetvideo feeds and secure time feeds are unidirectional.] There are also very few situations in which the traffic in one direction needs to be secured, but the trafficin the other direction does not need to be secured. It therefore seems that in virtually all practical situations, SAs occur in pairs to allow bidirectional securedcommunications. In fact, the IKE protocol negotiates SAs in pairs. [IKE has not always been well coordinated with IPsec, unfortunately. This is why wehave to have null encryption and null authentication algorithms. So, I don't think one should cite IKE behavior as a basis for making SAs bi-directional. Iagree that the vast majority of examples that we see now are full duplex, but we have example where this may not apply, as noted above.]This would suggest that it is more logical to make an SA a bidirectional "connection" between two machines. This would halve the number of SAs inthe overall system. It would also avoid asymmetric security configurations, which we think are undesirable (see section ??). [The SPI that is used as aprimary de-multiplexing value, must be chosen locally, by the receiver, so having bi-directional SAs probably won't change the size of the SAD substantially.Specifically, how do you envision that a switch to bi-directionality would simplify implementations?] 3.5 Security policies The security policies are stored in the SPD (Security Policy Database). Forevery packet that is to be sent out, the SPD is checked to find how the packet is to be processed. The SPD can specify three actions: discard the packet, letthe packet bypass IPsec processing, or apply IPsec processing. In the last case, the SPD also specifies which SAs should be used (if suitable SAs have alreadybeen set up) or specifies with what parameters new SAs should be set up to be used.The SPD seems to be a very flexible control mechanism that allows a very fine-grained control over the security processing of each packet. Packets areclassified according to a large number of selectors, and the SPD can match some or all selectors to determine the appropriate action. Depending on theSPD, this can result in either all traffic between two computers being carried on a single SA, or a separate SA being used for each application, or even eachTCP connection. Such a very fine granularity has disadvantages. There is a significantly increased overhead in setting up the required SAs, and more trafficanalysis information is made available to the attacker. At the same time we do not see any need for such a fine-grained control. [a lot of customers forIPsec products disagree!] The SPD should specify whether a packet should be discarded, should bypass any IPsec processing, requires authentication, orrequires authentication and encryption. Whether several packets are combined on the same SA is not important. [yes it is. By allowing an administratorthe ability to select the granularity of protection, one can control the level of partial traffic flow confidentiality offered between security gateways. Also,fine-grained access control allows an admin to allow some forms of connections through the gateway, while rejecting others. Access control is often the primary,underlying motivation for using IPsec. A number of attacks become possible if one cannot tightly bind the authentication provided by IPsec to the accesscontrol decision. Also, given the computational costs of SA establishment via IKE, it is important to allow an administrator to select the granularity of SAs.]The same holds for the exact choice of cryptographic algorithm: any good algorithm will do. There are two reasons for this. First of all, nobody everattacks a system by cryptanalysis. Instead, attacks are made on the users, implementation, management, etc. Any reasonable cryptographic algorithmwill provide adequate protection. The second reason is that there are very efficient and secure algorithms available. Two machines should negotiate thestrongest algorithm that they are allowed. There is no reason to select individual algorithms on an application-by-application basis. [if one were to employ ESP without authentication, because a specific higher layer protocol provided itsown authentication, and maybe because the application employed FEC, then one might well imagine using different encryption algorithms, or different modes(e.g., block vs. stream) for different SAs. while I agree that the focus on algorithm agility may be overstated, it does allow communicating parties toselect a higher quality algorithm, relative to the mandated default, if they both support that algorithm.]In our opinion, management of the IPsec protocols can be simplified by letting the SPD contain policies formulated at such a higher level. As we argued in section, simplification will strengthen the actual system. [examples providedabove illustrate why fine-grained access control is important.] It would be nice if the same high-level approach could be done in relationto the choice of SA end-points. As there currently does not seem to be a reliable automatic method of detecting IPsec-enabled security gateways, we donot see a practical alternative to manual configuration of these parameters. It is questionable whether automatic detection of IPsec-enabled gateways is possibleat all. Without some initial knowledge of the other side, any detection and negotiation algorithm can be subverted by an active attacker. [the authorsidentify a good problem, but it is hardly an unsolvable one. A proposal was put forth (by Bob Moscowtiz, over a year ago) to include records in the DNSanalogous to MX records. When one tried to establish an SA to a host "behind" an SG, fetching this record would direct the initiator to an appropriate SG. Thissolves the SG discovery problem. Other approaches have been put forth in the more recent BBN work on security policy management, which forms the basisfor a new IETF WG, chaired by Luis Sanchez. The fact that none of the approaches has been deployed says more about the priorities of IPsec vendorsand early adopters than about the intractability of the problem. The other part of the problem is verifying that an SG is authorized to represent the SA target.Here too, various approaches have been described on the IPsec mailing list.] 3.6 General comments This section contains general comments that came up during our evaluation ofIPsec. 1. In [?, p. 22], several fields in the SAD are required for all implementations,but only used in some of them. It does not make sense to require the presence of fields within an implementation. Only the external behavior ofthe system should be standardized. [the SAD defined in 2401 is nominal, as the text explains. An implementation is not required to implement thesefields, but must exhibit behavior consistent with the presence of these fields. We were unable to specify external behavior without reference to aconstruct of this sort. The SPD has the same property.] 2. According to [?, p. 23], an SA can be either for transport mode, tunnelmode, or "wildcard," in which case the sending application can choose the mode on a packet-by-packet basis. Much of the rest of the text doesnot seem to take this possibility into account. It also appears to us to be needless complexity that will hardly every be used, and is never a neces-sity. We have already argued that transport mode should be eliminated, which implies that this option is removed too. If transport mode is to beretained, we would certainly get rid of this option. [I agree, but at least one knowledgeable WG member was quite adamant about this. So, chalkit up to the committee process!] 3. IPsec does not allow replay protection on an SA that was established usingmanual key management techniques. This is a strange requirement. We realize that the replay protection limits the number of packets that can betransmitted with the SA to 2 32 - 1. Still, there are applications that have a low data rate where replay protection is important and manual keyingis the easiest solution. [elsewhere this critique argues for not presenting options in a standard that can be misconfigured. Yet here, the authorsmake an argument for just such an option! The WG decided that there was too great a chance that a manually keyed SA would fail to maintaincounter state across key lifetime and thus made a value judgement to ban anti-replay in this context.] 4. [?, section 5.2.1, point 3] suggests that an implementation can find thematching SPD entry for a packet using back-pointers from the SAD entries. In general this will not work correctly. Suppose the SPD containstwo rules: the first one outlaws all packets to port X, and the second oneallows all incoming packets that have been authenticated. An SA is set up for this second rule. The sender now sends a packet on this SA addressedto port X. This packet should be refused as it matches the first SPD rule.However, the backpointer from the SA points to the second rule in the SPD, which allows the packet. This shows that back-pointers from theSA do not always point to the appropriate rule, and that this is not a proper method of finding the relevant SPD entry. [this is point #3 andis applied only after points #1 and #2. Since point #1 calls for a liner search of the SPD, the packet would be rejected, as required. Thus point#3 is not in error.] 5. The handling of ICMP messages as described in [?, section 6] is unclearto us. It states that an ICMP message generated by a router must not be forwarded over a transport-mode SA, but transport mode SAs can onlyoccur in hosts. By definition, hosts do not forward packets, and a router never has access to a transport-mode SA. [the text in the beginning ofsection 6 is emphasizing that an SA from a router to a host or security gateway, must be a tunnel mode SA, vs. a transport mode SA. If we didn'tmake this clear, someone might choose to establish a transport mode SA from an intermediate system, and this would cause the source addresschecks to fail under certain circumstances, as noted by the text.] The text further suggests that unauthenticated ICMP messages should bedisregarded. This creates problems. Let us envision two machines that are geographically far apart and have a tunnel-mode SA set up. Thereare probably a dozen routers between these two machines that forward the packets. None of these routers knows about the existence of the SA.Any ICMP messages relating to the packets that are sent will be unauthenticated and unencrypted. Simply discarding these ICMP messagesresults in a loss of IP functionality. This problem is mentioned, but the text claims this is due to the routers not implementing IPsec. Even ifthe routers implement IPsec, they still cannot send authenticated ICMP messages about the tunnel unless they themselves set up an SA with thetunnel end-point for the purpose of sending the ICMP packet. The tunnel end-point in turn wants to be sure the source is a real router. Thisrequires a generic public-key infrastructure, which does not exist. [RFC 2401 clearly states the dangers associated with blindly accepting unau-thenticated ICMP messages, and the functionality problems associated with discarding such messages. System administrators are provided withthe ability to make this tradeoff locally. The first step to addressing this problem is the addition of IPsec into routers, as stated in the RFC. Onlythen does one face the need to have a PKI that identifies routers. Yes, this second PKI does not exist, but a subset of it (at BGP routers) mightbe established if the S-BGP technology is deployed. These are the routers most likely to issue ICMP PMTU messages. So, the answer here is thatthe specifications allow site administrators to make security/functionality tradeoffs, locally. The longer term solution described would require routersto implement IPsec, so that they can send authenticated ICMP messages. Yes, this would require a PKI, but such a PKI may arise for other reasons.] As far as we understand this problem, this is a fundamental compatibilityproblem with the existing IP protocol that does not have a good solution. 6. [?, section 6.1.2.1] lists a number of possible ways of handling ICMPPMTU messages. An option that is not mentioned is to keep a limited history of packets that were sent, and to match the header inside the PMTUpacket to the history list. This can identify the host where the packet that was too large originated. [the approach suggested by the authors wasrejected as imposing too much of a burden on an SG. section 6.1.2.1 offers options (not suggestions) for an SG to respond to ICMP PMTU messages,including heuristics to employ when not enough information is present in the returned header. These options may not as responsive as a strategythat caches traffic on each SA, but they are modest in the overhead imposed. Also, an SA that carries a wide range of traffic (not fine-grained)might not benefit from a limited traffic history, as the traffic that caused the ICMP might well be from a host whose traffic has been flushed fromthe "limited history."] 7. [?, section 7] mentions that each auditable event in the AH and ESP specifications lists a minimum set of information that should be includedin the audit-log entry. Not all auditable events defined in [?] include that information.[you're right. Exactly one auditable event in 2406 doesnot specify the list of data that SHOULD be audited. We'll fix that in the next pass. Furthermore, auditable events in [?] do not specifysuch a minimum list of information. [there are exactly 3 events defined as auditable in 2401, one of which overlaps with 2406. So, to be moreprecise, the other 2 auditable events defined in 2401 ought to have the minimum data requirements defined. Another good point that we will fixin the next pass.] The documentation should be reviewed to ensure that a minimum list of audit-log information is specified with each auditableevent. 8. Various algorithm specifications require the implementation to reject knownweak keys. For example, the DES-CBC encryption algorithm specifications [?] requires that DES weak keys are rejected. It is questionable whether this actually increases security. It might very well be that the extra code that this requires creates more security problems due to bugsthan are solved by rejecting weak keys. Weak keys are not really a problem in most situations. For DES, it isfar less work for an attacker to do an exhaustive search over all possible keys than to wait for an SA that happens to use a weak key. After all,the easiest way for the attacker to detect the weak keys is to try them all. Weak-key rejection is only required for algorithms where detectingthe weak key class by the weak cipher properties is significantly less work than trying all the weak keys in question. We recommend that the weak-key elimination requirement be removed.Encryption algorithms that have large classes of weak keys that introduce security weaknesses should simply not be used. [I tend to agree with thisanalysis. The argument for weak key checking was made by folks who don't understand the cryptographic issues involved, but who are persistent andloud, e.g., Bill Simpson. Ted T'so (co-chair of the WG) and I discussed this problem, and tried to explain it to the list, but were unsuccessful.Another flaw in the committee process.] 9. The only mandatory encryption algorithm in ESP is DES-CBC. Due tothe very limited key length of DES, this cannot be considered to be very secure. We strongly urge that this algorithm not be standardized but bereplaced by a stronger alternative. The most obvious candidate is tripleDES. Blowfish could be used as an interim high-speed solution.2 Theupcoming AES standard will presumably gain quick acceptance and probably become the default encryption method for most systems. [DES as adefault was mandated because of pressure from vendors who, at the time, could not get export permission for 3DES. Triple DES or AES will cer2On a Pentium CPU, Blowfish is about six to seven times faster than triple-DES. tainly augment DES as additional, mandatory defaults, and may replaceit in the future. ] 10. The insistence on randomly selected IV values in [?] seems to be overkill.It is true that a counter would provide known low Hamming-weight input differentials to the block cipher. All reasonable block ciphers are secureenough against this type of attack. Use of a random generator results in an increased risk of an implementation error that will lead to low-entropyor constant IV values; such an error would typically not be found during testing. [In practice the IV is usually acquired from previous ciphertextoutput, as suggested in the text for CBC mode ciphers, which is easy to acquire and not likely to result in significant complexity. In hardwareassisted environment an RNG is usually available anyway. In a high assurance hardware implementation, the crypto chip would generate the IV.] 11. Use of a block cipher with a 64-bit block size should in general be limited to at most 2 32 block encryptions per key. This is due to the birthday paradox. After 232 blocks we can expect one collision.3 In CBC mode,two equal ciphertexts give the attacker the XOR of two blocks of the plaintext. The specifications for the DES-CBC encryption algorithm [?]should mention this, and require that any SA using such an algorithm limit the total amount of data encrypted by a single key to a suitablevalue. 12. The preferred mode for using a block cipher in ESP seems to be CBC mode. This is probably the most widely used cipher mode, but it has somedisadvantages. As mentioned earlier, a collision gives direct information about the relation of two plaintext blocks. Furthermore, in hardware im-plementations each of the encryptions has to be done in turn. This gives a limited parallelism, which hinders high-speed hardware implementations.[first, this is not an intrinsic part of the architecture; one can define different modes for use with existing or different algorithms if the WG is somotivated. Second, current hardware is available at speeds higher than the associated packet processing capability of current IPsec devices, sothis does not appear to be a problem for the near term. Transition to AES will decrease the processing burden (relative to 3DES), which mayrender this concern less serious.] Although not used very often, the counter mode seems to be preferable.The ciphertext of block i is formed as Ci = Pi *EK(i), where i is the blocknumber that needs to be sent at the start of the packet. 4 After more than 232 blocks counter mode also reveals some information about the plaintext,but this is less than what occurs in CBC. The big advantage of counter mode is that hardware implementations can parallelize the encryption and 3To get a 10-6 probability of a collision it should be limited to about 222 blocks. 4If replay protection is always in use, then the starting i-value could be formed as 232 times the sequence number. This saves eight bytes per packet. decryption process, thus achieving a much higher throughput. [earlierthe authors criticize IPsec for a lack of orthogonality, but introducing interdependence between the anti-replay counter and encryption wouldcertainly violate the spirit of the earlier criticism! Counter mode versions of algorithms can be added to the list easily if there is sufficient vendorsupport.] 13. [?, section 2.3] states that Blowfish has weak keys, but that the likelihoodof generating one is very small. We disagree with these statements. The likelihood of getting two equal 32-bit values in any one 256-entry S-boxis about * 256 2 ** 2-32 *2-17. This is an event that will certainly occur in practice. However, the Blowfish weak keys only lead to detectableweaknesses in reduced-round versions of the cipher. There are no known weak keys for the full Blowfish cipher. 14. In [?, section 2.5], it is suggested to negotiate the number of rounds of acipher. We consider this to be a very bad idea. The number of rounds is integral to the cipher specifications and should not be changed at will.Even for ciphers that are specified with a variable number of rounds, the determination of the number of rounds should not be left up to theindividual system administrators. The IPsec standard should specify the number of rounds for those ciphers. [I agree that this algorithm spec oughtnot encourage negotiation of the number of rounds, without specifying a minimum for each cipher, although this gets us into the crypto strengthvalue judgement arena again. Also, the inclusion of 3DES in this table is inappropriate as it is a 48 round algorithm, period. So, yes, there isdefinite room for improvement in this RFC.] 15. [?, section 2.5] proposes the use of RC5. We urge caution in the use ofthis cipher. It uses some new ideas that have not been fully analyzed or understood by the cryptographic community. The original RC5 asproposed (with 12 rounds) was broken, and in response to that the recommended number of rounds was increased to 16. We feel that furtherresearch into the use of data-dependent rotations is required before RC5 is used in fielded systems. [RC5 is not required by IPsec implementations.In the IETF spirit of flexible parameterization of implementations, vendors are free to offer any additional algorithms in addition to the requireddefault. In general, the IETF is not prepared to make value judgements about these algorithms and so one may see RFCs that specify a variety ofadditional algorithms.] 16. [?, section 2.4] specifies that the ESP padding should pad the plaintextto a length so that the overall ciphertext length is both a multiple of the block size and a multiple of 4. If a block cipher of unusual block sizeis used (e.g., 15 bytes), then this can require up to 59 bytes of padding. This padding rule works best for block sizes that are a multiple of 4, whichfortunately is the case for most block ciphers. [this padding rule is based 23 primarily on IP packet alignment considerations, not on common blockcipher sizes! This is stated in the text.] 17. [?, p. 6, point a] states that the padding computations of the ESP payloadwith regard to the block size of the cipher apply to the payload data, excluding the IV (if present), Pad Length, and Next Header fields. Thiswould imply that the Pad Length and Next Header fields are not being encrypted. Yet the rest of the specification is clear that the Pad Lengthand Next Header field are to be encrypted, which is what should happen. The text of point a should be made consistent with the rest of the text.[The text says "the padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields." The commaafter "IV" is meat to terminate the scope of the word "exclusive," and thus the intent is to include the pad length and next header fields. The term"payload" in ESP applies to a set of data not including the latter two fields, so the sentence is, technically, unambiguous, and it is consistentwith the terms employed in the figure in section 2. But, I admit the wording could be improved.] 18. There is a document that defines the NULL encryption algorithm usedin ESP [?], but no document that defines the NULL authentication algorithm, which is also used by ESP [?, section 5]. [good point. AnotherRFC publication opportunity!] 19. The NULL cipher specifies an IV length of zero [?]. This would seem toimply that the NULL cipher is used in CBC mode, which is clearly not the case. The NULL cipher is in fact used in ECB mode, which does notrequire an IV. Therefore, no IV length should be specified. [use of the NULL cipher in ECB mode would be inconsistent with the guidance inFIPS 82, and thus CBC mode is intended, to preserve the confidentiality characteristics inherent in this cipher :-).] 3.7 Conclusions The IPsec system should be simplified significantly. This can be done withoutloss of functionality or performance. There are also some security weaknesses that should be fixed. [the extensive comments above illustrate that the pro-posed changes to IPsec would change the functionality, contrary to the claim made here. One might argue about the importance of some of this functionality,but several examples have been provided to illustrate application contexts that the authors of this report did not consider in their analysis. Several misunder-standings of some RFCs also were noted.] Due to its high complexity, we have not been able to analyze IPsec as thor-oughly as we would have liked. After simplification, a new security analysis should be performed. 24 I have not reviewed the ISAKMP/IKE comments. However, I agree thatthis protocol is very complex. Much of the complexity results of incremental enhancement and a reluctance on the part of developers to discard older versionsof code. 25 --mYCpIKhGyMATD0i+-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 16:07:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H02MS12274 for ipng-dist; Wed, 16 Feb 2000 16:02:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H02D012267 for ; Wed, 16 Feb 2000 16:02:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA27940 for ; Wed, 16 Feb 2000 16:02:13 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA25131 for ; Wed, 16 Feb 2000 17:02:09 -0700 (MST) 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 XA18763; Thu, 17 Feb 2000 10:58:31 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Mark.Andrews@nominum.com Cc: Francis Dupont , Yoshinobu Inoue , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-Reply-To: Your message of "Thu, 17 Feb 2000 00:30:44 +1100." <200002161330.AAA13916@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Feb 2000 10:58:26 +1100 Message-Id: <8573.950745506@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Feb 2000 00:30:44 +1100 From: Mark.Andrews@nominum.com Message-ID: <200002161330.AAA13916@bsdi.dv.isc.org> | I think this is perfectly clear. The description below does | not allow for the other forms. | | RFC2373, Section 2.2. | | 3. An alternative form that is sometimes more convenient when | dealing with a mixed environment of IPv4 and IPv6 nodes is | x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values | of the six high-order 16-bit pieces of the address, and the | 'd's are the decimal values of the four low-order 8-bit pieces | of the address (standard IPv4 representation). If you're reading that out of the x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address wording, then one would also have to conclude that ::1.2.3.4 is invalid, as that doesn't have the x's for the high order 16 bit pieces. On the other hand if, as I think we all do, allow the x's to be omitted (::) (as is specified elsewhere, but not here explicitly) then I think you could also read that to allow "unnecessary" d's to be deleted as well. On the other hand, if it is "standard IPv4 representation" that is supposed to require all 4 decimal digits, then I think that fails, as being an undefined term (which I think is where this discussion originated). By convention - one could almost call it standard - 10.1 has been acceptable just about anywhere 10.0.0.1 was intended (and contrary to what has sometimes been claimed, there's nothing classful or classless about this, it is just a notational convention - perhaps more likely to be useful in a classful environment, but that's all ... 10.1.5 works too after all (meaning 10.1.0.5)). But please don't read this message as implying support for continuing that abbreviated form of IPv4 addressing in IPv6 addresses - I don't think IPv6 literal addresses should be used almost anywhere at all, and I certainly don't think we need to make notational shorthands to make them easier to use (I'd be happy if we required all 32 hex digits, and the 7 interspersed colons, and allowed no shortened forms at all...) But the spec does need to be clear on what is acceptable, and what is not, and I don't think any good is done out of taking slightly imprecise language, and just claimimg it is precise enough - just fix it when the doc is revised. 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 Feb 16 16:49:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H0kuc12332 for ipng-dist; Wed, 16 Feb 2000 16:46:56 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H0kq012325 for ; Wed, 16 Feb 2000 16:46:52 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id QAA02916 for ipng@sunroof.eng.sun.com; Wed, 16 Feb 2000 16:45:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H0hJ012313 for ; Wed, 16 Feb 2000 16:43:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA07615 for ; Wed, 16 Feb 2000 16:43:19 -0800 (PST) Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [130.155.191.233]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA14889 for ; Wed, 16 Feb 2000 17:43:16 -0700 (MST) Received: from isc.org (marka@localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.8.5/8.8.5) with ESMTP id LAA16570; Thu, 17 Feb 2000 11:38:45 +1100 (EST) Message-Id: <200002170038.LAA16570@bsdi.dv.isc.org> To: Robert Elz Cc: Mark.Andrews@nominum.com, Francis Dupont , Yoshinobu Inoue , bound@zk3.dec.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: non-standard IPv4 form support in getaddrinfo() In-reply-to: Your message of "Thu, 17 Feb 2000 10:58:26 +1100." <8573.950745506@munnari.OZ.AU> Date: Thu, 17 Feb 2000 11:38:31 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Thu, 17 Feb 2000 00:30:44 +1100 > From: Mark.Andrews@nominum.com > Message-ID: <200002161330.AAA13916@bsdi.dv.isc.org> > > | I think this is perfectly clear. The description below does > | not allow for the other forms. > | > | RFC2373, Section 2.2. > | > | 3. An alternative form that is sometimes more convenient when > | dealing with a mixed environment of IPv4 and IPv6 nodes is > | x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values > | of the six high-order 16-bit pieces of the address, and the > | 'd's are the decimal values of the four low-order 8-bit pieces > | of the address (standard IPv4 representation). > > If you're reading that out of the > x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values > of the six high-order 16-bit pieces of the address, and the > 'd's are the decimal values of the four low-order 8-bit pieces > of the address > wording, then one would also have to conclude that ::1.2.3.4 is invalid, > as that doesn't have the x's for the high order 16 bit pieces. On the > other hand if, as I think we all do, allow the x's to be omitted (::) > (as is specified elsewhere, but not here explicitly) then I think you could > also read that to allow "unnecessary" d's to be deleted as well. The combination with compression is specified just below the quoted text. The compression syntax is specified in the preceeding paragraph to the one I quoted. I can't see how anyone can say that ::10.1 is legal if they read RFC2373, Section 2.2. I know I had to ask myself if the other forms were legal when implementing inet_pton() but the answer was clearly there. However it can't hurt to say the other IPv4 literal address forms (octal, hexadecimal, less than 4 elements) are excluded. > > On the other hand, if it is "standard IPv4 representation" that is supposed > to require all 4 decimal digits, then I think that fails, as being an > undefined term (which I think is where this discussion originated). The discussion started from the assertion that the addresses were ::, :: would be a better description. > > By convention - one could almost call it standard - 10.1 has been acceptable > just about anywhere 10.0.0.1 was intended (and contrary to what has > sometimes been claimed, there's nothing classful or classless about this, > it is just a notational convention - perhaps more likely to be useful in > a classful environment, but that's all ... 10.1.5 works too after all (meanin > g > 10.1.0.5)). Agreed. > > But please don't read this message as implying support for continuing that > abbreviated form of IPv4 addressing in IPv6 addresses - I don't think IPv6 > literal addresses should be used almost anywhere at all, and I certainly > don't think we need to make notational shorthands to make them easier to > use (I'd be happy if we required all 32 hex digits, and the 7 interspersed > colons, and allowed no shortened forms at all...) > > But the spec does need to be clear on what is acceptable, and what is not, > and I don't think any good is done out of taking slightly imprecise > language, and just claimimg it is precise enough - just fix it when the > doc is revised. > > kre Mark -- Mark Andrews, Nominum Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.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 Feb 16 18:41:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H2YOI12458 for ipng-dist; Wed, 16 Feb 2000 18:34:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H2YF012451 for ; Wed, 16 Feb 2000 18:34:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA26282 for ; Wed, 16 Feb 2000 18:34:14 -0800 (PST) Received: from assaris.sics.se (assail.s3.kth.se [130.237.43.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA26431 for ; Wed, 16 Feb 2000 18:34:13 -0800 (PST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id DAA62633; Thu, 17 Feb 2000 03:34:09 +0100 (CET) (envelope-from assar) To: ipng@sunroof.eng.sun.com Subject: getaddrinfo with numeric port number and hints->ai_socktype == 0 From: Assar Westerlund Date: 17 Feb 2000 03:34:08 +0100 Message-ID: <5l3dqso8v3.fsf@assaris.sics.se> Lines: 68 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What should be the behaviour of these two programs? It seems rather limited and unuseful for the first program a) to return EAI_SERVICE, when it's basically the same as program b). I think that all socket types should be considered as supported for a numeric servname. The only text I could find in rfc2553 on this matter is the definition of the EAI_SERVICE error code: EAI_SERVICE servname not supported for ai_socktype It is useful to be able to specify a service/port number numerically, for example, when looking up the service with getservbyname() or equivalent and having a numeric fallback in case the particular host does not have that mapping configured or when accepting explicit port numbers as arguments from the user. Comments? /assar ---------------------------------------------------------------------- /* a) */ #include #include #include int main(int argc, char **argv) { struct addrinfo hints; struct addrinfo *ai, *a; int ret; memset (&hints, 0, sizeof(hints)); ret = getaddrinfo ("localhost", "7", &hints, &ai); if(ret) { printf("failed: %s\n", gai_strerror(ret)); return 1; } for (a = ai; a != NULL; a = a->ai_next) printf ("family = %d, socktype = %d\n", a->ai_family, a->ai_socktype); return 0; } ---------------------------------------------------------------------- /* b) */ #include #include #include int main(int argc, char **argv) { struct addrinfo hints; struct addrinfo *ai, *a; int ret; memset (&hints, 0, sizeof(hints)); ret = getaddrinfo ("localhost", "echo", &hints, &ai); if(ret) { printf("failed: %s\n", gai_strerror(ret)); return 1; } for (a = ai; a != NULL; a = a->ai_next) printf ("family = %d, socktype = %d\n", a->ai_family, a->ai_socktype); return 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 Wed Feb 16 18:50:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H2lso12522 for ipng-dist; Wed, 16 Feb 2000 18:47:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H2li012515 for ; Wed, 16 Feb 2000 18:47:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA27956 for ; Wed, 16 Feb 2000 18:47:44 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01009 for ; Wed, 16 Feb 2000 18:47:43 -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 LAA19299; Thu, 17 Feb 2000 11:47:33 +0900 (JST) To: Assar Westerlund cc: ipng@sunroof.eng.sun.com In-reply-to: assar's message of 17 Feb 2000 03:34:08 +0100. <5l3dqso8v3.fsf@assaris.sics.se> 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: getaddrinfo with numeric port number and hints->ai_socktype == 0 From: itojun@iijlab.net Date: Thu, 17 Feb 2000 11:47:33 +0900 Message-ID: <19297.950755653@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What should be the behaviour of these two programs? It seems rather >limited and unuseful for the first program a) to return EAI_SERVICE, >when it's basically the same as program b). I think that all socket >types should be considered as supported for a numeric servname. If I remember correctly, with numeric port number you need to somehow specify you need either UDP or TCP. In some cases port numbers are not the same for TCP and UDP (in some cases only one of them are in the table) so it is not very good to set port # to "7" blindly for both entries. 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 Wed Feb 16 18:58:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H2uvQ12557 for ipng-dist; Wed, 16 Feb 2000 18:56:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H2um012550 for ; Wed, 16 Feb 2000 18:56:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA03198 for ; Wed, 16 Feb 2000 18:56:49 -0800 (PST) Received: from assaris.sics.se (assail.s3.kth.se [130.237.43.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03860 for ; Wed, 16 Feb 2000 18:56:47 -0800 (PST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id DAA62788; Thu, 17 Feb 2000 03:56:37 +0100 (CET) (envelope-from assar) To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype == 0 References: <19297.950755653@coconut.itojun.org> From: Assar Westerlund Date: 17 Feb 2000 03:56:36 +0100 In-Reply-To: itojun@iijlab.net's message of "Thu, 17 Feb 2000 11:47:33 +0900" Message-ID: <5lwvo47d0b.fsf@assaris.sics.se> Lines: 20 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > If I remember correctly, with numeric port number you need to somehow > specify you need either UDP or TCP. Why shouldn't we assume that the programmer actually knows what (s)he is doing? If you want udp or tcp you can specify it in `hints.ai_socktype'. If you _do_ want both, should you have to perform two (at least) calls to getaddrinfo? > In some cases port numbers are > not the same for TCP and UDP (in some cases only one of them are > in the table) so it is not very good to set port # to > "7" blindly for both entries. Yes, but since we're not going to look them up in services (or equivalent), we might as well trust the programmer. Should you not be able to create sockets even the ports you're using are not listed in services? /assar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 16 19:55:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H3rL912611 for ipng-dist; Wed, 16 Feb 2000 19:53:21 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H3rA012604 for ; Wed, 16 Feb 2000 19:53:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA26558 for ; Wed, 16 Feb 2000 19:53:09 -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 UAA26426 for ; Wed, 16 Feb 2000 20:53:08 -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 MAA20271; Thu, 17 Feb 2000 12:52:52 +0900 (JST) To: Assar Westerlund cc: ipng@sunroof.eng.sun.com In-reply-to: assar's message of 17 Feb 2000 03:56:36 +0100. <5lwvo47d0b.fsf@assaris.sics.se> 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: getaddrinfo with numeric port number and hints->ai_socktype == 0 From: itojun@iijlab.net Date: Thu, 17 Feb 2000 12:52:52 +0900 Message-ID: <20269.950759572@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> If I remember correctly, with numeric port number you need to somehow >> specify you need either UDP or TCP. >Why shouldn't we assume that the programmer actually knows what (s)he >is doing? If you want udp or tcp you can specify it in >`hints.ai_socktype'. If you _do_ want both, should you have to >perform two (at least) calls to getaddrinfo? This may be KAME implementation issue, not the spec problem. I couldn't find explicit mention in RFC2553, nor X/Open spec. NRL (= BIND9 = BIND8 = glibc) and KAME behaves the same against the situation, both will raise error. De-facto? The problem here is (I believe) that RFC2553 does not specify well enough how should we glob the input on which case. By "enough" I mean a specification which gives us uniform behavior. I really would like to see more examples on how it should behave. Things gets more interesting if we think about AF_LOCAL and other families... 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 Wed Feb 16 21:09:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H56gT12688 for ipng-dist; Wed, 16 Feb 2000 21:06:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H56O012676 for ; Wed, 16 Feb 2000 21:06:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA03993 for ; Wed, 16 Feb 2000 21:06:23 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA12215 for ; Wed, 16 Feb 2000 21:06:23 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Feb 2000 21:05:00 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Wed, 16 Feb 2000 21:05:00 -0800 Message-ID: <3D2036E25376D31197A100805FEAD89206AB71F5@RED-MSG-02> From: Brian Zill To: "'Assar Westerlund'" , itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: RE: getaddrinfo with numeric port number and hints->ai_socktype = = 0 Date: Wed, 16 Feb 2000 21:04:57 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why shouldn't we assume that the programmer actually knows what (s)he > is doing? If you want udp or tcp you can specify it in > `hints.ai_socktype'. If you _do_ want both, should you have to > perform two (at least) calls to getaddrinfo? Yes, this was one of the issues that came up a couple of weeks ago in a thread I started called "Clarifications wanted on basic API (RFC 2553)" (started 1/28). I had the same interpretation that you did, if you leave things unspecified going into getaddrinfo, they will be unspecified coming out unless there was reason to limit them (i.e. if you ask for a service name that is only valid for TCP and not UDP the record coming out will have the ai_socktype set to SOCK_STREAM instead of left unspecified). Today for IPv4, the socket call is responsible for verifying that you gave it a valid triple of address family, socket type and protocol, and will pick a default for you if you leave things unspecified (e.g. lots of people call socket(AF_INET, SOCK_STREAM, 0) instead of explicitly putting IP_PROTOCOL_TCP in the last argument). Thus, I felt the right thing to do was to pass the unspecified values on through getaddrinfo so that the user would eventually call the kernel with them. According to Itojun's mail, however, KAME apparantly enumerates all the possible combinations for you and gives you a seperate addrinfo record for each! He wrote: > When KAME getaddrinfo is called with the following parameter: > host = "foo.internet.host" > serv = "daytime" > hints.ai_family = PF_UNSPEC > hints.ai_socktype = hints.ai_protocol = 0 > the code would return the following four entries: > AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET, port 13, SOCK_DGRAM, IPPROTO_UDP > AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET6, port 13, SOCK_DGRAM, IPPROTO_UDP > Past KAME code returned SOCK_STREAM only (2 entries), like: > AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP > Which behavior the spec prefer? I replied: We don't do either of those. You're right, the spec isn't clear here at all and we're doing quite different things. For your example (assuming foo.internet.host resolves to both a v4 and a v6 address) we'll return two entries: AF_INET6, port 13, socktype 0, protocol 0 AF_INET, port 13, socktype 0, protocol 0 Thus leaving it up to the socket call. If the user wants something specific, they need to specify it in the hints passed to getaddrinfo, just as they specify it in the socket arguments for IPv4 today. There appears to be no way to get this behavior from KAME. I think the working group needs to decide upon a behavior here. I would think the different records coming out of getaddrinfo would differ only in address (type and value) returned and that ai_socktype and ai_protocol would be the same for all. This makes round-robining or failover between multiple servers easy for client code. BTW, as for your original question... > I think that all socket types should be considered as supported for a numeric servname. So do I. That's exactly how we do it. Otherwise you'd have to perform extraneous service lookups - and, as you point out, are limited to binding/connecting to sockets with ports that are in the services database! Upon reflection, I think this just adds to the argument that enumerating the unspecified socktypes and protocols is the wrong thing to do. Because they're inherently incompatible. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 16 21:32:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H5T8M12726 for ipng-dist; Wed, 16 Feb 2000 21:29:08 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H5St012719 for ; Wed, 16 Feb 2000 21:28:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA05348 for ; Wed, 16 Feb 2000 21:28:54 -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 WAA23134 for ; Wed, 16 Feb 2000 22:28:53 -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 OAA21400; Thu, 17 Feb 2000 14:28:40 +0900 (JST) To: Brian Zill cc: "'Assar Westerlund'" , ipng@sunroof.eng.sun.com In-reply-to: bzill's message of Wed, 16 Feb 2000 21:04:57 PST. <3D2036E25376D31197A100805FEAD89206AB71F5@RED-MSG-02> 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: getaddrinfo with numeric port number and hints->ai_socktype = = 0 From: itojun@iijlab.net Date: Thu, 17 Feb 2000 14:28:40 +0900 Message-ID: <21398.950765320@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >According to Itojun's mail, however, KAME apparantly enumerates all the >possible combinations for you and gives you a seperate addrinfo record for >each! He wrote: >> When KAME getaddrinfo is called with the following parameter: >> host = "foo.internet.host" >> serv = "daytime" >> hints.ai_family = PF_UNSPEC >> hints.ai_socktype = hints.ai_protocol = 0 >> the code would return the following four entries: >> AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP >> AF_INET, port 13, SOCK_DGRAM, IPPROTO_UDP >> AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP >> AF_INET6, port 13, SOCK_DGRAM, IPPROTO_UDP >> Past KAME code returned SOCK_STREAM only (2 entries), like: >> AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP >> AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP >> Which behavior the spec prefer? >I replied: >We don't do either of those. You're right, the spec isn't clear here at all >and we're doing quite different things. For your example (assuming >foo.internet.host resolves to both a v4 and a v6 address) we'll return two >entries: > AF_INET6, port 13, socktype 0, protocol 0 > AF_INET, port 13, socktype 0, protocol 0 Just checking, your example is when you passed "daytime" as servname, not "13"? If I pass - servname = "daytime" (registered as 13/tcp and 13/udp) - hints.ai_family = PF_UNSPEC - hints.ai_socktype = 0 I can think of three behaviors. since "daytime = port 13" is valid only for TCP and UDP, I would think getaddrinfo should give some guidance to the caller. behavior 1: (current KAME) AF_INET6, port 13, socktype SOCK_STREAM, protocol IPPROTO_TCP AF_INET6, port 13, socktype SOCK_DGRAM, protocol IPPROTO_UDP AF_INET, port 13, socktype SOCK_STREAM, protocol IPPROTO_TCP AF_INET, port 13, socktype SOCK_DGRAM, protocol IPPROTO_UDP behavior 2: (I thought you would do this) AF_INET6, port 13, socktype SOCK_STREAM, protocol 0 AF_INET6, port 13, socktype SOCK_DGRAM, protocol 0 AF_INET, port 13, socktype SOCK_STREAM, protocol 0 AF_INET, port 13, socktype SOCK_DGRAM, protocol 0 behavior 3: (your example) AF_INET6, port 13, socktype 0, protocol 0 AF_INET, port 13, socktype 0, protocol 0 If we do not glob ai_socktype like behavior 3, it looks to me to be incompatible with cases with servname "ftp" (21/tcp, not udp), where behavior 1-3 will return the following: behavior 1: (current KAME) AF_INET6, port 21, socktype SOCK_STREAM, protocol IPPROTO_TCP AF_INET, port 21, socktype SOCK_STREAM, protocol IPPROTO_TCP behavior 2: (I thought you would do this) AF_INET6, port 21, socktype SOCK_STREAM, protocol 0 AF_INET, port 21, socktype SOCK_STREAM, protocol 0 behavior 3: (do you do this?) AF_INET6, port 21, socktype 0, protocol 0 AF_INET, port 21, socktype 0, protocol 0 We really need some clarification about what is opaque for getaddrinfo and what is not. - It looks to me that PF_UNSPEC is clearly one of items which is NOT opaque. - ai_socktype = 0 is not clear enough for me. RFC2553 says "the caller accepts any socket type". it says nothing about what getaddrinfo should do. For me it looks to be "getaddrinfo should glob it" and it is the behavior we have now in KAME. 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 Wed Feb 16 21:54:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H5qDA12757 for ipng-dist; Wed, 16 Feb 2000 21:52:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H5q4012750 for ; Wed, 16 Feb 2000 21:52:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA06594 for ; Wed, 16 Feb 2000 21:52:02 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA28992 for ; Wed, 16 Feb 2000 22:51:58 -0700 (MST) 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 FA28646; Thu, 17 Feb 2000 16:48:50 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: itojun@iijlab.net Cc: Brian Zill , "'Assar Westerlund'" , ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype = = 0 In-Reply-To: Your message of "Thu, 17 Feb 2000 14:28:40 +0900." <21398.950765320@coconut.itojun.org> Date: Thu, 17 Feb 2000 16:48:30 +1100 Message-Id: <13926.950766510@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Feb 2000 14:28:40 +0900 From: itojun@iijlab.net Message-ID: <21398.950765320@coconut.itojun.org> This is not directly to the point, but ... | If we do not glob ai_socktype like behavior 3, it looks to me to be | incompatible with cases with servname "ftp" (21/tcp, not udp), According to iana/assignments/port-numbers ... ftp-data 20/tcp File Transfer [Default Data] ftp-data 20/udp File Transfer [Default Data] ftp 21/tcp File Transfer [Control] ftp 21/udp File Transfer [Control] The theory always was that a port number was assigned for both TCP and UDP usage, and then the protocol could decide how to use it. Aside from the noise protocols (daytime, chargen, etc) I think only the DNS actually makes use of both protocols for its port, but that was still the theory. The BSD assignments (in the 500) range messed that up a bit, and your average BSD services file lists only TCP for FTP (and UDP for TFTP, thogh again, 69/tcp is assigned to tftp by the IANA), but that's just leaving out the variations that aren't generally used. It would certainly be a mistake to do anything which would deped upon the "unused" protocol being missing - applications do need to specify the protocol they want to use, and not rely upon finding it from the service name. This means, I think, that I believe Brian's implementation makes a little more sense. 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 Feb 16 22:07:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1H64Q112796 for ipng-dist; Wed, 16 Feb 2000 22:04:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1H64E012789 for ; Wed, 16 Feb 2000 22:04:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA12378 for ; Wed, 16 Feb 2000 22:04:11 -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 XAA02058 for ; Wed, 16 Feb 2000 23:04:10 -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 PAA21957; Thu, 17 Feb 2000 15:01:22 +0900 (JST) To: Robert Elz cc: Brian Zill , "'Assar Westerlund'" , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 17 Feb 2000 16:48:30 +1100. <13926.950766510@munnari.OZ.AU> 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: getaddrinfo with numeric port number and hints->ai_socktype = = 0 From: itojun@iijlab.net Date: Thu, 17 Feb 2000 15:01:22 +0900 Message-ID: <21955.950767282@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is not directly to the point, but ... I agree, my comment is not directly related to getaddrinfo discussion, > | If we do not glob ai_socktype like behavior 3, it looks to me to be > | incompatible with cases with servname "ftp" (21/tcp, not udp), >According to iana/assignments/port-numbers ... >ftp-data 20/tcp File Transfer [Default Data] >ftp-data 20/udp File Transfer [Default Data] >ftp 21/tcp File Transfer [Control] >ftp 21/udp File Transfer [Control] Just checking, have you ever seen ftp client/server that works on top of UDP layer? RFC959 do refer TCP, but not UDP. I believe the above assignments just mean that they are "reserved".... 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 Feb 17 07:11:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HF4PJ13104 for ipng-dist; Thu, 17 Feb 2000 07:04:25 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HF47013097 for ; Thu, 17 Feb 2000 07:04:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA05672 for ; Thu, 17 Feb 2000 07:03:28 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06302 for ; Thu, 17 Feb 2000 07:03:27 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id 8DAB49A947; Thu, 17 Feb 2000 09:03:26 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id 85ED490D83; Thu, 17 Feb 2000 09:03:26 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 714A24FB02; Thu, 17 Feb 2000 09:03:19 -0600 (CST) Received: from flume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 084F14C902; Thu, 17 Feb 2000 09:03:19 -0600 (CST) Received: from whitestar.zk3.dec.com by flume.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000009440; Thu, 17 Feb 2000 10:03:25 -0500 (EST) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA21561; Thu, 17 Feb 2000 10:03:24 -0500 Message-Id: <38AC0DBC.30E24984@zk3.dec.com> Date: Thu, 17 Feb 2000 10:03:24 -0500 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: itojun@iijlab.net Cc: Assar Westerlund , ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype == 0 References: <20269.950759572@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> If I remember correctly, with numeric port number you need to somehow > >> specify you need either UDP or TCP. > >Why shouldn't we assume that the programmer actually knows what (s)he > >is doing? If you want udp or tcp you can specify it in > >`hints.ai_socktype'. If you _do_ want both, should you have to > >perform two (at least) calls to getaddrinfo? > > This may be KAME implementation issue, not the spec problem. > I couldn't find explicit mention in RFC2553, nor X/Open spec. > Here is what XNS 5.2 states: If a specific socket type is not given (for example, a value of zero) and the service name could be interpreted as valid with multiple supported socket types, the implementation will attempt to resolve the service name for all supported socket types and, in absense of errors, all possible successful results will be returned. A non-zero socket type value will limit the returned information to values with the specified socket type. I am currently working on supporting this in our implementation. > NRL (= BIND9 = BIND8 = glibc) and KAME behaves the same against the > situation, both will raise error. De-facto? > > The problem here is (I believe) that RFC2553 does not specify well > enough how should we glob the input on which case. > By "enough" I mean a specification which gives us uniform behavior. > I really would like to see more examples on how it should behave. You are right. Hopefully 2552bis will specify this better and then sync up with XNS so both specs will be identical in their definitions. -vlad > > Things gets more interesting if we think about AF_LOCAL and other > families... > > 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 > -------------------------------------------------------------------- -- +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 17 07:18:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HFGU813127 for ipng-dist; Thu, 17 Feb 2000 07:16:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HFGL013120 for ; Thu, 17 Feb 2000 07:16:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA19418 for ; Thu, 17 Feb 2000 07:16:22 -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 HAA12840 for ; Thu, 17 Feb 2000 07:16:19 -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 PA20818; Fri, 18 Feb 2000 02:13:30 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: itojun@iijlab.net Cc: Brian Zill , "'Assar Westerlund'" , ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype = = 0 In-Reply-To: Your message of "Thu, 17 Feb 2000 15:01:22 +0900." <21955.950767282@coconut.itojun.org> Date: Fri, 18 Feb 2000 02:13:30 +1100 Message-Id: <22073.950800410@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Feb 2000 15:01:22 +0900 From: itojun@iijlab.net Message-ID: <21955.950767282@coconut.itojun.org> | Just checking, have you ever seen ftp client/server that works on top | of UDP layer? RFC959 do refer TCP, but not UDP. I believe the above | assignments just mean that they are "reserved".... No, the protocol uses only TCP. The uses are "reserved" in the sense that when port numbers were allocted (in the old days anyway) both udp and tcp were assigned the same number, and then the protocol can choose which to use, and when. I could imagine that sometime in the future a protocol enhancement to FTP might add some UDP elements. I have no idea what for, but the possibility is always there. The point was that you can't assume that you can take just a host name and "ftp" and return something which a naive application can use to make a correct tcp (control) connection - the ftp application has to know that TCP is the transport protocol to be used for this application protocol. Given that the application must know this, and cannot rely upon someone else providing that information, having the application either provide it to the library in the hints, or supply it later, with the library providing no hints, and either the application filling in the missing bits, or leaving it to the kernel to add them seems like the better solution to me. Unless the application exxpressly asks for a UDP assignment when calling getaddrinfo() for "ftp", I think it is a mistake to return that (whatever is in the services file). That helps no-one. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 17 08:04:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HG0rG13217 for ipng-dist; Thu, 17 Feb 2000 08:00:53 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HG0g013210 for ; Thu, 17 Feb 2000 08:00:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA24069 for ; Thu, 17 Feb 2000 08:00:43 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05493 for ; Thu, 17 Feb 2000 08:00:42 -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 AAA27536; Fri, 18 Feb 2000 00:57:38 +0900 (JST) To: Robert Elz cc: Brian Zill , "'Assar Westerlund'" , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Fri, 18 Feb 2000 02:13:30 +1100. <22073.950800410@munnari.OZ.AU> 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: getaddrinfo with numeric port number and hints->ai_socktype = = 0 From: itojun@iijlab.net Date: Fri, 18 Feb 2000 00:57:38 +0900 Message-ID: <27534.950803058@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The point was that you can't assume that you can take just a host name >and "ftp" and return something which a naive application can use to >make a correct tcp (control) connection - the ftp application has to >know that TCP is the transport protocol to be used for this application >protocol. Given that the application must know this, and cannot >rely upon someone else providing that information, having the application >either provide it to the library in the hints, or supply it later, >with the library providing no hints, and either the application filling in >the missing bits, or leaving it to the kernel to add them seems like >the better solution to me. I don't see what you are arguing here. We have /etc/services table, which is the only data source getaddrinfo (or getservbyname) can trust. When we have "ftp" entry with tcp only in there (which was the example I meant), getaddrinfo have no idea if it is usable for udp as well. 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 Feb 17 08:42:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HGeLA13315 for ipng-dist; Thu, 17 Feb 2000 08:40:21 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HGeC013308 for ; Thu, 17 Feb 2000 08:40:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA00282 for ; Thu, 17 Feb 2000 08:40:12 -0800 (PST) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26928 for ; Thu, 17 Feb 2000 08:40:10 -0800 (PST) Received: from sture.lysator.liu.se (nisse@sture.lysator.liu.se [130.236.254.21]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id RAA08921; Thu, 17 Feb 2000 17:33:14 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA17307; Thu, 17 Feb 2000 17:33:10 +0100 (MET) To: itojun@iijlab.net Cc: Robert Elz , Brian Zill , "'Assar Westerlund'" , ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype = = 0 References: <27534.950803058@coconut.itojun.org> From: nisse@lysator.liu.se (Niels Möller) Date: 17 Feb 2000 17:33:10 +0100 In-Reply-To: itojun@iijlab.net's message of "Fri, 18 Feb 2000 00:57:38 +0900" Message-ID: Lines: 30 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > I don't see what you are arguing here. > > We have /etc/services table, which is the only data source getaddrinfo > (or getservbyname) can trust. When we have "ftp" entry with tcp only > in there (which was the example I meant), getaddrinfo have no idea > if it is usable for udp as well. I think the point was this: A portable ftp application should work both on a system with only ftp-by-tcp listed in /etc/services, and on a system that lists both ftp-by-tcp and ftp-by-udp (or do you think the latter system is broken? I think it is reasonable to have /etc/services include reserved but currently not commonly used ports). So the application has to *know* that the ftp protocol uses tcp, and apply that knowledge at some time before calling socket(). It can't *rely* on getaddrinfo knowing that. One way is apply that knowledge is by using the hints argument to getaddrinfo, and then pass the values from getaddrinfo to socket() unmodified. Another is to massage the information from getaddrinfo before calling socket(), e.g. by explicitly saying SOCKET_STREAM, IPPROTO_TCP, ignoring some of the data returned by getaddrinfo. And Assar's original question was about the behaviour when an application asks for a *numerical* port. I think it makes a lot of sense in this case to not consult /etc/services at all. /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 Thu Feb 17 08:56:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HGrmE13401 for ipng-dist; Thu, 17 Feb 2000 08:53:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HGrd013394 for ; Thu, 17 Feb 2000 08:53:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04035 for ; Thu, 17 Feb 2000 08:53:39 -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 IAA04550 for ; Thu, 17 Feb 2000 08:53:36 -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 QA20321; Fri, 18 Feb 2000 03:51:46 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: nisse@lysator.liu.se (Niels Mvller) Cc: itojun@iijlab.net, Brian Zill , "'Assar Westerlund'" , ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype = = 0 In-Reply-To: Your message of "17 Feb 2000 17:33:10 BST." Date: Fri, 18 Feb 2000 03:51:45 +1100 Message-Id: <23671.950806305@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 17 Feb 2000 17:33:10 +0100 From: nisse@lysator.liu.se (Niels Mvller) Message-ID: | I think the point was this: Yes, exactly. Thanks. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 17 08:59:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HGwVE13420 for ipng-dist; Thu, 17 Feb 2000 08:58:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HGwL013413 for ; Thu, 17 Feb 2000 08:58:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29815 for ; Thu, 17 Feb 2000 08:58:21 -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 JAA02522 for ; Thu, 17 Feb 2000 09:58:20 -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.04) with ESMTP id BAA28682; Fri, 18 Feb 2000 01:58:17 +0900 (JST) To: nisse@lysator.liu.se (Niels Mller) cc: Robert Elz , Brian Zill , "'Assar Westerlund'" , ipng@sunroof.eng.sun.com In-reply-to: nisse's message of 17 Feb 2000 17:33:10 +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: getaddrinfo with numeric port number and hints->ai_socktype = = 0 From: itojun@iijlab.net Date: Fri, 18 Feb 2000 01:58:17 +0900 Message-ID: <28680.950806697@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I don't see what you are arguing here. >> We have /etc/services table, which is the only data source getaddrinfo >> (or getservbyname) can trust. When we have "ftp" entry with tcp only >> in there (which was the example I meant), getaddrinfo have no idea >> if it is usable for udp as well. >I think the point was this: A portable ftp application should work >both on a system with only ftp-by-tcp listed in /etc/services, and on >a system that lists both ftp-by-tcp and ftp-by-udp (or do you think >the latter system is broken? I think it is reasonable to have >/etc/services include reserved but currently not commonly used ports). I see, I gave a bad example. I still believe getaddrinfo should glob ai_socktype for non-numeric. When I call getaddrinfo with hostname = "10.1.1.1" servname = "echo" ai_family = PF_UNSPEC ai_socktype = 0 I would like to try all the possibilities below: AF_INET, 10.1.1.1, ai_socktype = SOCK_STREAM, port 7 AF_INET, 10.1.1.1, ai_socktype = SOCK_DGRAM, port 7 not just: AF_INET, 10.1.1.1, ai_socktype = 0, port 7 >And Assar's original question was about the behaviour when an >application asks for a *numerical* port. I think it makes a lot of >sense in this case to not consult /etc/services at all. KAME getaddrinfo does not consult /etc/services. Since KAME getaddrinfo's mindset is with "ai_socktype should be globbed", numeric port does not give me any indication of the right ai_socktype to return. it is ambiguous to it and it would raise error. In other words, KAME getaddrinfo believes that it is not consistent to do the following: - treat ai_socktype as opaque when servname is numeric - globbing ai_socktype when servname is non-numeric 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 Feb 17 09:07:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HH4E513449 for ipng-dist; Thu, 17 Feb 2000 09:04:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HH3e013442 for ; Thu, 17 Feb 2000 09:03:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02424 for ; Thu, 17 Feb 2000 09:03:41 -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 KAA05745 for ; Thu, 17 Feb 2000 10:03:39 -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 CAA28861 for ; Fri, 18 Feb 2000 02:03:38 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Fri, 18 Feb 2000 01:58:17 JST. <28680.950806697@coconut.itojun.org> 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: getaddrinfo with numeric port number and hints->ai_socktype = = 0 From: itojun@iijlab.net Date: Fri, 18 Feb 2000 02:03:38 +0900 Message-ID: <28859.950807018@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > KAME getaddrinfo does not consult /etc/services. > Since KAME getaddrinfo's mindset is with "ai_socktype should be > globbed", numeric port does not give me any indication of the right > ai_socktype to return. it is ambiguous to it and it would raise error. > > In other words, KAME getaddrinfo believes that it is not consistent > to do the following: > - treat ai_socktype as opaque when servname is numeric > - globbing ai_socktype when servname is non-numeric I think I wasn't clear enough. The point I would like to make here is the following: - RFC2553 does not give indication about how far getaddrinfo should glob the result. It should be made more clear on 2553bis. - I think it makes more sense to glob ai_socktype with non-numeric socktype. Vladislav's quote from X/Net looks like globbing ai_socktype is what X/Net prefers. - when we glob ai_socktype, numeric servname with ai_socktype = 0 is ambiguous, and it makes more sense to raise error - I'm happy to be convinced otherwise ("ai_socktype is opaque"). if majority thinks so. 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 Feb 17 10:29:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HIQWB13540 for ipng-dist; Thu, 17 Feb 2000 10:26:32 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HIQR013533 for ; Thu, 17 Feb 2000 10:26:28 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA03296 for ipng@sunroof.eng.sun.com; Thu, 17 Feb 2000 10:24:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HEUM013061 for ; Thu, 17 Feb 2000 06:30:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA14555 for ; Thu, 17 Feb 2000 06:30:23 -0800 (PST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13421 for ; Thu, 17 Feb 2000 07:30:21 -0700 (MST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE7B@monza.broadswitch.com> From: Thomas Eklund To: "'Brian E Carpenter'" , ipng Subject: RE: [Fwd: Re: Is IPv6 died - reply from Brian Carpenter] Date: Thu, 17 Feb 2000 15:30:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, February 15, 2000 10:36 PM > To: ipng > Subject: [Fwd: Re: Is IPv6 died - reply from Brian Carpenter] > > > This bounced from th list for no good reason > > -------- Original Message -------- > Subject: Re: Is IPv6 died - reply from Brian Carpenter > Date: Tue, 15 Feb 2000 15:05:05 -0600 > From: Brian E Carpenter > Organization: IBM > To: Fred Baker > CC: Yakov Rekhter ,Mounir Eddabbabi > ,ipng@sunroof.eng.sun > References: <4.1.20000211125911.0460dbb0@flipper.cisco.com> > > Fred, > > Fred Baker wrote: > > > > At 12:08 PM 2/11/00 -0800, Yakov Rekhter wrote: > > >IPv6 addresses will aggregate better than IPv4 addresses, > because we > > >have the luxury of enough bits to do aggregator-based > address assignment. > > > > One thing we want to think about, Brian. I am concluding > that to deploy > > this, what we want to do is take the 490 transit AS's in > the world, and > > given them each a TLA, and use one TLA for all the > multi-homed systems > > (ballpark 5400 of them in today's Internet if I understand > the numbers). > > What that means is that the IP6 route table typically has in it: > > > > - a TLA route for each transit provider other than myself > (490 minus one) > > - said multihomed routes (5400) > > - various routes within myself or to my customers (how big > are you?) > > - various routes advertised across bilateral connections from other > > providers (what bilateral agreements do you choose > to write?) > > > > It seems to me that this is pretty contained and well within the > > capabilities of current routing protocols. > > I couldn't agree more. > > > > > My point is that 6to4 isn't going to scale one bit better than ip4 > > addressing, which it mimics, and trying to start from the tier one > > providers (the current plan) isn't working and I don't see any real > > difference between 6 or 8 TLA routes vs 500. > > 6to4 is certainly not intended to be anything but a transition tool. > I agree that if we could persuade the major transit providers to get > on board, life would be wonderful. > > > > > Somebody's going to say "you mean sub-TLA, right?" No, I > mean TLA. The > > premise of the addressing plan is that you get an address > from a central > > provider who can delegate a sub-TLA to you, and you in turn delegate > > customer prefixes to your customers, who in turn delegate > subnets. I'm > > suggesting that all you should need to demonstrate in order > to be the first > > guy in that food chain is that you are a transit as - that > you have people > > you could delegate sub-TLAs to. According to > > http://www.telstra.net/ops/bgptable.html there are 490 > such, which seems to > > me a very reasonable number. > > Indeed > > > > >Let's say that NAT and RSIP delay the evil day, but not for ever, > > >and they don't work in all market segments. > > > > Specifically, VoIP over NAT is interesting, as a telephone > is essentially a > > server - it activates when you call it - and therefore like > any server has > > to have a consistently available address any time someone > wants to call it. > Agree here as well but you will have problem with roaming (in case of telephony) if you use NAT based solutions with private addresses and IPv4 you that may lead you on the IPv6 track even faster. You want a personal ipaddress and that lead to IPv6 based solutions. /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 Thu Feb 17 10:29:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HIRfx13549 for ipng-dist; Thu, 17 Feb 2000 10:27:41 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HIRa013542 for ; Thu, 17 Feb 2000 10:27:36 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA03326 for ipng@sunroof.eng.sun.com; Thu, 17 Feb 2000 10:26:05 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HEjk013074 for ; Thu, 17 Feb 2000 06:45:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA04285 for ; Thu, 17 Feb 2000 06:45:47 -0800 (PST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21160 for ; Thu, 17 Feb 2000 07:45:45 -0700 (MST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE7D@monza.broadswitch.com> From: Thomas Eklund To: "'Matt Crawford'" , RMi Cc: ipng@sunroof.eng.sun.com Subject: RE: Question to IPv6 over Ethernet Date: Thu, 17 Feb 2000 15:45:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What I miss is the 802.1Q VLANs... I would love to see a draft hos subnetbased and protocol based Virtual LAN's use the SiteLocal addresses in IPv6. Whats your opinion Matt? /Thomas > -----Original Message----- > From: Matt Crawford [mailto:crawdad@fnal.gov] > Sent: Tuesday, February 15, 2000 5:01 PM > To: RMi > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Question to IPv6 over Ethernet > > > > Why there is not a RFC to transmission of IPv6 Packets over > > IEEE 802.3-Ethernet Networks (with LLC-sublayer) as well as > > RFC2019, 2464, 2467, etc. ? > > Nobody wanted it. Speaking from my own experience, having two ways > of doing IPv4 over ethernet did more harm than good. > ______________________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Feb 17 10:31:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HITQC13562 for ipng-dist; Thu, 17 Feb 2000 10:29:26 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HITG013553 for ; Thu, 17 Feb 2000 10:29:17 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA03355 for ipng@sunroof.eng.sun.com; Thu, 17 Feb 2000 10:27:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HGJ8013250 for ; Thu, 17 Feb 2000 08:19:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25401 for ; Thu, 17 Feb 2000 08:19:08 -0800 (PST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10179 for ; Thu, 17 Feb 2000 09:19:06 -0700 (MST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE87@monza.broadswitch.com> From: Thomas Eklund To: "'Thomas Narten'" , Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Autconfiguration RFC Date: Thu, 17 Feb 2000 17:19:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an old email from me on the mobile ip listbut I forgot to ask you if you would like to you add a chapter in the autoconfiguration RFC about this... Something like a fault tolerant autoconf using DHCP...: ///There are though some easy tricks you can do, and that is to have a pool of static addresses that could be autoconfigured with DHCP. So when you autoconfigure using ND and get a conflict when you do your DAD, you do a stateful DHCP request from this pool. This is a very nice way of solving the problem. This is how I have done it./// This is mostly guidelines how you build your network but I think it would be good to have. Whats you opinion Thomas? Regards 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 Thu Feb 17 13:10:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HL2pN13728 for ipng-dist; Thu, 17 Feb 2000 13:02:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HL25013721 for ; Thu, 17 Feb 2000 13:02:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11916 for ; Thu, 17 Feb 2000 13:00:59 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22357 for ; Thu, 17 Feb 2000 13:00:56 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id OAA07590; Thu, 17 Feb 2000 14:59:47 -0600 (CST) Date: Thu, 17 Feb 2000 14:59:47 -0600 (CST) From: David Borman Message-Id: <200002172059.OAA07590@frantic.bsdi.com> To: assar@sics.se, itojun@iijlab.net Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype == 0 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been thinking about this, and I've changed my mind a few times over the course of the discussion. :-) Before trying to answer what should be returned with a numeric service number an no sockettype, the questions in my mind are: o What is the purpose of getaddrinfo(), i.e. what is the primary use for information returned by getaddrinfo()? o If getaddrinfo() just calls getservby{name,port}(), should it blindly propogate the symantics of those routines? o What is the purpose of calling getaddrinfo() with a service name, but without specifying a socket type? I pulled down the current copy of tcp/udp port assignments, to see what combinations are there. At the top, it states: Ports are used in the TCP [RFC793] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port. The contact port is sometimes called the "well-known port". To the extent possible, these same port assignments are used with the UDP [RFC768]. For the majority of assignments, the same number is assigned to the same name for both TCP and UDP. You have cases where the same protocol provides both TCP and UDP service: echo 7/tcp echo 7/udp Cases where both the TCP and UDP port number are assigned, but the protocol only uses the TCP port: ftp 21/tcp ftp 21/udp Other cases where both the TCP and UDP port number are assigned, but the protocol only uses the UDP port: tftp 69/tcp tftp 69/udp And, there are other cases, where one protocol has the TCP port assignment, and another protocol has the UDP port assignment: shell 514/tcp syslog 514/udp As to using getaddrinfo() with a service name, my understanding is that it's main purpose in life is to provide a protocol independent method for an application, given a service or address/service, to get the information necessary to create a socket, then issue a bind()/listen()/ accept() or connect() call, and be able to do something useful with the socket. To that end, if getaddrinfo() can't return a non-zero ai_socktype field, the information is not useful, because you can't specify a type of 0 on a socket() call. So, following that logic: 1) In the returned addrinfo structures, if a servname was specified, then ai_socktype cannot be returned as 0. Thus, if the ai_socktype cannot be determined because of ambiguity, an error should be returned. I'll argue as others have that the calling application has to know whether it can handle a SOCK_STREAM or SOCK_DGRAM socket, so it should fill in that information when making the getaddrinfo() call, it shouldn't just leave hints.ai_socktype zero. The only question in my mind is if an application can handle both SOCK_STREAM and SOCK_DGRAM (like for the "echo" service), should it be able to get the necessary information in one getaddrinfo() call for both protocols, or should it need to make two separate getaddrinfo() calls, one for SOCK_STREAM and one for SOCK_DGRAM? The more I think about it, the only reason I can see for allowing hints.ai_socktype = 0 is to provide a short cut to avoid having to call getaddrinfo() twice, once for each socket type. The Bind 8.2.1 version of getaddrinfo() (which I wrote), fails on numerical service names if hints.ai_socktype is not specified. I can't see blindly returning both a SOCK_STREAM and SOCK_DGRAM structure, given the above line of thinking. Currently, the getaddrinfo() in Bind, given a service name, will look up the service name using getservbyname(), and if the protocol isn't specified, getservbyname() just returns the first name match. Thus, if you wrote an tftp client and called getaddrinfo() for "tftp" without specifying a socket type, and you used the results for creating your socket, things would work as long as the udp port was the first tftp service listed in /etc/services. But if someone added "tftp 69/tcp" in /etc/services before the "tftp 69/udp" entry, then your tftp application would break. That seems like a bad thing to me. So, I'd actually be inclined to go the other direction, and modify getaddrinfo() to fail any service name lookup in which the hints.socktype was left unspecified. That way you'd have deterministic behavior. The application would fail from the beginning, rather than working for awhile, and then breaking when someone added the "tftp 69/tcp" entry in /etc/services. -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 Feb 17 13:50:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HLllV13764 for ipng-dist; Thu, 17 Feb 2000 13:47:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HLlc013757 for ; Thu, 17 Feb 2000 13:47:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01518 for ; Thu, 17 Feb 2000 13:47:37 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20701 for ; Thu, 17 Feb 2000 14:47:37 -0700 (MST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA22162; Thu, 17 Feb 2000 16:44:42 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA35628; Thu, 17 Feb 2000 16:44:43 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA20217; Thu, 17 Feb 2000 16:44:37 -0500 Message-Id: <200002172144.QAA20217@rotala.raleigh.ibm.com> To: Thomas Eklund cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Autconfiguration RFC In-Reply-To: Message from Thomas Eklund of "Thu, 17 Feb 2000 17:19:03 +0100." <45AFD48D077ED211BB4700A0C9DCE8FD15AE87@monza.broadswitch.com> Date: Thu, 17 Feb 2000 16:44:37 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Eklund writes: > This is an old email from me on the mobile ip listbut I forgot to ask you if > you would like to you add a chapter in the autoconfiguration RFC about > this... Something like a fault tolerant autoconf using DHCP...: > ///There are though some easy tricks you can do, and that is to have a pool > of > static addresses that could be autoconfigured with DHCP. > So when you autoconfigure using ND and get a conflict when you do your DAD, > you do a stateful DHCP request from this pool. This is a very nice way of > solving the problem. > This is how I have done it./// The premise here is that duplicate addresses will occur often enough in practice that the protocols need to take some steps to automatically recover from their occurance. In the past, the sense I've had from the WG was that there was insufficient motivation to do this. I.e, duplicates aren't expected to be common, and when they occur, they aren't that easy to fix automatically anyway. For example, if the duplicate addresses are on the same link, isn't the implication that the link-layer addresses are also duplicated? If so, duplicate IP addresses are the least of your worries. Also, DHCP uses the MAC address to identify itself to the DHCP server. If there are duplicate addresses, there would appear to be significant risk that the DHCP server would now get requests from different nodes, but for the same identifier. Again, this is likely to cause problems. How does your DHCP approach deal with this problem? 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 Thu Feb 17 14:02:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1HLvrF13791 for ipng-dist; Thu, 17 Feb 2000 13:57:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1HLvi013784 for ; Thu, 17 Feb 2000 13:57:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA23575 for ; Thu, 17 Feb 2000 13:57:44 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA24615 for ; Thu, 17 Feb 2000 13:57:43 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Feb 2000 13:57:02 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Thu, 17 Feb 2000 13:56:45 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21B90@RED-MSG-50> From: Richard Draves To: "'Thomas Narten'" , Thomas Eklund Cc: "'IPng List'" Subject: RE: Autconfiguration RFC Date: Thu, 17 Feb 2000 13:56:41 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... Also, DHCP > uses the MAC address to identify itself to the DHCP server. If there > are duplicate addresses, there would appear to be significant risk > that the DHCP server would now get requests from different nodes, but > for the same identifier. Again, this is likely to cause problems. How > does your DHCP approach deal with this problem? I thought DCHPv6 uses the client link-local address to identify the client, not the MAC address. (Strictly speaking, the identity is a pair - client link-local address and DHCPv6 relay address if there is a relay involved.) So DHCPv6 can't be used to assign a link-local address. 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 Feb 18 03:54:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IBq9214137 for ipng-dist; Fri, 18 Feb 2000 03:52:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IBq1014130 for ; Fri, 18 Feb 2000 03:52:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA23535 for ; Fri, 18 Feb 2000 03:52:00 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02663 for ; Fri, 18 Feb 2000 03:51:59 -0800 (PST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA00859; Fri, 18 Feb 2000 06:52:20 -0500 Message-Id: <200002181152.GAA00859@hygro.adsl.duke.edu> To: Richard Draves cc: Thomas Eklund , "'IPng List'" Subject: Re: Autconfiguration RFC In-Reply-To: Message from Richard Draves of "Thu, 17 Feb 2000 13:56:41 PST." <4D0A23B3F74DD111ACCD00805F31D8101CA21B90@RED-MSG-50> Date: Fri, 18 Feb 2000 06:52:20 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > I thought DCHPv6 uses the client link-local address to identify the client, > not the MAC address. (Strictly speaking, the identity is a pair - client > link-local address and DHCPv6 relay address if there is a relay > involved.) You are right, of course, but the distinction doesn't change my point. Since the link-local address is derived algorithmically from the IEEE identifier (i.e., MAC address), two interfaces with the same MAC address will generate the same link-local address. Also, DAD only detects duplicates among nodes on the same link, in which case the DHCPv6 relay address, link-local address pair doesn't really dismambiguate the two interfaces. Actually, it's slighly more complicated in DHCP. Its not the (relay address, link-local address) pair that identifies a binding, its the (link, link-local address). The relay agent address identifies the link a client is on, but if a link has multiple relay agents, they all identify the same link, and the DHCP server should understand that. Otherwise, a DHCP server would allocate multiple sets of bindings for the same client, if different DHCP requests from that client happened to go through different relay agents. 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 Fri Feb 18 03:59:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IBwrl14172 for ipng-dist; Fri, 18 Feb 2000 03:58:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IBwi014165 for ; Fri, 18 Feb 2000 03:58:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA20486 for ; Fri, 18 Feb 2000 03:58:43 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04441 for ; Fri, 18 Feb 2000 03:58:42 -0800 (PST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA00933; Fri, 18 Feb 2000 06:59:06 -0500 Message-Id: <200002181159.GAA00933@hygro.adsl.duke.edu> To: Thomas Eklund cc: ipng@sunroof.eng.sun.com Subject: Re: Autconfiguration RFC In-Reply-To: Message from Thomas Eklund of "Fri, 18 Feb 2000 11:13:31 +0100." <45AFD48D077ED211BB4700A0C9DCE8FD15AE94@monza.broadswitch.com> Date: Fri, 18 Feb 2000 06:59:06 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But if you look at my answer to Thomas, this is feasable in enviroments > where you generate your link-identifier temporary (which you do in > wireless)... Ahh... I was assuming the interface token was derived from the IEEE identifier. But isn't it the case with wireless devices that you *DO* have an identifier from which to generate an interface token that is likely to be globally unique? Also, which type of devices are you talking about, and shouldn't they have an "IPv6 over foobar wireless devices" in which this stuff gets nailed down? > But the question is how do we configure the interface with the same mac with > different ipaddresses? First, it need to be established that this is even useful. If two devices share the same MAC, won't (in general) bad things happen that one wants to avoid? > But this could be summarized in a draft "User-token in IPv6" Indeed! 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 Fri Feb 18 08:17:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IGF7S14299 for ipng-dist; Fri, 18 Feb 2000 08:15:07 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IGEw014292 for ; Fri, 18 Feb 2000 08:14:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29610 for ; Fri, 18 Feb 2000 08:14:58 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15090 for ; Fri, 18 Feb 2000 08:14:57 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id E3CF3578DD; Fri, 18 Feb 2000 10:14:56 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id E15E354601; Fri, 18 Feb 2000 10:14:56 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id B51024FB0F; Fri, 18 Feb 2000 10:14:49 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 44C224C901; Fri, 18 Feb 2000 10:14:49 -0600 (CST) Received: from whitestar.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000005535; Fri, 18 Feb 2000 11:14:50 -0500 (EST) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA21789; Fri, 18 Feb 2000 11:14:46 -0500 Message-Id: <38AD6FF5.5049AB70@zk3.dec.com> Date: Fri, 18 Feb 2000 11:14:45 -0500 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: David Borman Cc: ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype == 0 References: <200002172059.OAA07590@frantic.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David I am playing "devil's advocate" here because I agree with you that we need to make getaddrinfo() more deterministic. The whole idea of the 'hints' is that they limit what getaddrinfo() returns. So, logic follows that if the limitation is not specified (hints->ai_socktype == 0), then all supported values should be returned. If the application does not specify the socket type then it means one of two things: 1. The application does not care can support all types. 2. There is a bug in the application that should be fixed. The same thing goes for the address family. -vlad David Borman wrote: > > I've been thinking about this, and I've changed my mind a few > times over the course of the discussion. :-) > > Before trying to answer what should be returned with a numeric service > number an no sockettype, the questions in my mind are: > o What is the purpose of getaddrinfo(), i.e. what is the > primary use for information returned by getaddrinfo()? > o If getaddrinfo() just calls getservby{name,port}(), > should it blindly propogate the symantics of those routines? > o What is the purpose of calling getaddrinfo() with > a service name, but without specifying a socket type? > > I pulled down the current copy of tcp/udp port assignments, to > see what combinations are there. At the top, it states: > > Ports are used in the TCP [RFC793] to name the ends of logical > connections which carry long term conversations. For the purpose of > providing services to unknown callers, a service contact port is > defined. This list specifies the port used by the server process as > its contact port. The contact port is sometimes called the > "well-known port". > > To the extent possible, these same port assignments are used with the > UDP [RFC768]. > > For the majority of assignments, the same number is assigned to the > same name for both TCP and UDP. You have cases where the same > protocol provides both TCP and UDP service: > echo 7/tcp > echo 7/udp > > Cases where both the TCP and UDP port number are assigned, but > the protocol only uses the TCP port: > ftp 21/tcp > ftp 21/udp > > Other cases where both the TCP and UDP port number are assigned, > but the protocol only uses the UDP port: > tftp 69/tcp > tftp 69/udp > > And, there are other cases, where one protocol has the TCP port > assignment, and another protocol has the UDP port assignment: > shell 514/tcp > syslog 514/udp > > As to using getaddrinfo() with a service name, my understanding is that > it's main purpose in life is to provide a protocol independent method > for an application, given a service or address/service, to get the > information necessary to create a socket, then issue a bind()/listen()/ > accept() or connect() call, and be able to do something useful with the > socket. To that end, if getaddrinfo() can't return a non-zero ai_socktype > field, the information is not useful, because you can't specify a type of > 0 on a socket() call. So, following that logic: > > 1) In the returned addrinfo structures, if a servname was > specified, then ai_socktype cannot be returned as 0. Thus, > if the ai_socktype cannot be determined because of ambiguity, > an error should be returned. > > I'll argue as others have that the calling application has to know > whether it can handle a SOCK_STREAM or SOCK_DGRAM socket, so it should > fill in that information when making the getaddrinfo() call, it shouldn't > just leave hints.ai_socktype zero. The only question in my mind is if > an application can handle both SOCK_STREAM and SOCK_DGRAM (like for the > "echo" service), should it be able to get the necessary information in > one getaddrinfo() call for both protocols, or should it need to make two > separate getaddrinfo() calls, one for SOCK_STREAM and one for SOCK_DGRAM? > > The more I think about it, the only reason I can see for allowing > hints.ai_socktype = 0 is to provide a short cut to avoid having to call > getaddrinfo() twice, once for each socket type. > > The Bind 8.2.1 version of getaddrinfo() (which I wrote), fails on > numerical service names if hints.ai_socktype is not specified. I can't > see blindly returning both a SOCK_STREAM and SOCK_DGRAM structure, given > the above line of thinking. > > Currently, the getaddrinfo() in Bind, given a service name, will > look up the service name using getservbyname(), and if the protocol > isn't specified, getservbyname() just returns the first name match. > Thus, if you wrote an tftp client and called getaddrinfo() for "tftp" > without specifying a socket type, and you used the results for > creating your socket, things would work as long as the udp port > was the first tftp service listed in /etc/services. But if someone > added "tftp 69/tcp" in /etc/services before the "tftp 69/udp" entry, > then your tftp application would break. That seems like a bad thing > to me. So, I'd actually be inclined to go the other direction, and > modify getaddrinfo() to fail any service name lookup in which the > hints.socktype was left unspecified. That way you'd have deterministic > behavior. The application would fail from the beginning, rather than > working for awhile, and then breaking when someone added the "tftp 69/tcp" > entry in /etc/services. > > -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 > -------------------------------------------------------------------- -- +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 08:22:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IGLBu14354 for ipng-dist; Fri, 18 Feb 2000 08:21:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IGL2014347 for ; Fri, 18 Feb 2000 08:21:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA07713 for ; Fri, 18 Feb 2000 08:21:02 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18225 for ; Fri, 18 Feb 2000 08:21:00 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 7DECB708; Fri, 18 Feb 2000 11:21:00 -0500 (EST) Received: from flume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 4C85E5C5 for ; Fri, 18 Feb 2000 11:21:00 -0500 (EST) Received: from whitestar.zk3.dec.com by flume.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000028846; Fri, 18 Feb 2000 11:21:00 -0500 (EST) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA21794; Fri, 18 Feb 2000 11:20:59 -0500 Message-Id: <38AD716B.E7FC75F0@zk3.dec.com> Date: Fri, 18 Feb 2000 11:20:59 -0500 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: Clarifications wanted on Basic API (RFC 2553) References: <3D2036E25376D31197A100805FEAD892712FF1@RED-MSG-02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hope it's not too late to add to this, but I was just looking/fixing our implementation of getaddrinfo() and had a question. Suppose the user specified the nodename and AI_PASSIVE flag when calling getaddrinfo(). What would be the correct behavior: 1. Return a EAI_BADFLAGS. 2. Ignore the AI_PASSIVE flag, and return the address that the nodename resolves to. (our current implementation) 3. Ignore the nodename and return an unspecified address. Thanks -vlad +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 09:26:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IHOKD14452 for ipng-dist; Fri, 18 Feb 2000 09:24:20 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IHOB014445 for ; Fri, 18 Feb 2000 09:24:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA28817 for ; Fri, 18 Feb 2000 09:24:11 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15246 for ; Fri, 18 Feb 2000 10:24:10 -0700 (MST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id LAA10337; Fri, 18 Feb 2000 11:23:46 -0600 (CST) Date: Fri, 18 Feb 2000 11:23:46 -0600 (CST) From: David Borman Message-Id: <200002181723.LAA10337@frantic.bsdi.com> To: vlad@zk3.dec.com Subject: Re: Clarifications wanted on Basic API (RFC 2553) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Fri, 18 Feb 2000 11:20:59 -0500 > From: Vladislav Yasevich > Subject: Re: Clarifications wanted on Basic API (RFC 2553) > > Hope it's not too late to add to this, but I was just looking/fixing our > implementation of getaddrinfo() and had a question. > > Suppose the user specified the nodename and AI_PASSIVE flag when calling > getaddrinfo(). What would be the correct behavior: > 1. Return a EAI_BADFLAGS. > 2. Ignore the AI_PASSIVE flag, and return the address that the > nodename resolves to. (our current implementation) > 3. Ignore the nodename and return an unspecified address. You wouldn't want to ignore it, because it is perfectly reasonable for an application to start up a passive connection limited to one specific address. The nodename should be one of the local IP addresses, though, to be useful (i.e, you can't bind to someone elses address), but I don't think that getaddrinfo() should be trying to enforce that. If it isn't a local address, the application will discover that when the bind() fails. The AI_PASSIVE bit only affects things when nodename is NULL, so yes, if nodename != NULL, you effectivly ignore the AI_PASSIVE bit. -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 Fri Feb 18 09:39:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IHahG14504 for ipng-dist; Fri, 18 Feb 2000 09:36:43 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IHac014497 for ; Fri, 18 Feb 2000 09:36:38 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA03897 for ipng@sunroof.eng.sun.com; Fri, 18 Feb 2000 09:35:07 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IADi014105 for ; Fri, 18 Feb 2000 02:13:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA21164 for ; Fri, 18 Feb 2000 02:13:43 -0800 (PST) Received: from monza.broadswitch.com ([195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21162 for ; Fri, 18 Feb 2000 03:13:43 -0700 (MST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE94@monza.broadswitch.com> From: Thomas Eklund To: "'Richard Draves'" , "'narten@raleigh.ibm.com'" Cc: ipng@sunroof.eng.sun.com, "'bound@zk3.dec.com'" Subject: RE: Autconfiguration RFC Date: Fri, 18 Feb 2000 11:13:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Thursday, February 17, 2000 10:57 PM > To: 'Thomas Narten'; Thomas Eklund > Cc: 'IPng List' > Subject: RE: Autconfiguration RFC > > > > ... Also, DHCP > > uses the MAC address to identify itself to the DHCP server. If there > > are duplicate addresses, there would appear to be significant risk > > that the DHCP server would now get requests from different > nodes, but > > for the same identifier. Again, this is likely to cause > problems. How > > does your DHCP approach deal with this problem? > > I thought DCHPv6 uses the client link-local address to > identify the client, > not the MAC address. (Strictly speaking, the identity is a > pair - client > link-local address and DHCPv6 relay address if there is a > relay involved.) And in most case these two are exactly the same... > > So DHCPv6 can't be used to assign a link-local address. But if you look at my answer to Thomas, this is feasable in enviroments where you generate your link-identifier temporary (which you do in wireless)... Another thing you can do to solve the problem is to send it to the link-local broadcast address and with right ipaddress. Then would both conflicting interfaces receive that packet but the one with right IP address would get it and the other would not. But the question is how do we configure the interface with the same mac with different ipaddresses? In other words in ethernet in case of a conflict during DAD: - request an IP address from the DHCP server - the server sends out the response on the link local broadcast address with a new option which includes a usertoken... - the right host hear it and autoconfigures the stateful address. The usertoken is 64 bit long and is assigned in the home-network on the format simliar to IMSI or NAI but optimized for IPv6's EUI-64. This means that you would always have a uniqueue identfier (l3 identifier) on the link... But this could be summarized in a draft "User-token in IPv6" If people think that its worth continuing with? /Thomas > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 09:52:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IHnoj14606 for ipng-dist; Fri, 18 Feb 2000 09:49:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IHnd014599 for ; Fri, 18 Feb 2000 09:49:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20837 for ; Fri, 18 Feb 2000 09:49:38 -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 JAA06724 for ; Fri, 18 Feb 2000 09:49:37 -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 LAA02339; Fri, 18 Feb 2000 11:49:32 -0600 (CST) Message-Id: <200002181749.LAA02339@gungnir.fnal.gov> To: Thomas Eklund Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Question to IPv6 over Ethernet In-reply-to: Your message of Thu, 17 Feb 2000 15:45:43 +0100. <45AFD48D077ED211BB4700A0C9DCE8FD15AE7D@monza.broadswitch.com> Date: Fri, 18 Feb 2000 11:49:32 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Eklund: > What I miss is the 802.1Q VLANs... > > I would love to see a draft hos subnetbased and protocol based Virtual LAN's > use the SiteLocal addresses in IPv6. > > Whats your opinion Matt? Well, what do you want to do over 802.1Q? The MTU is 4 bytes smaller, but a router advertisement can take care of that, if there is a router. Is there some sensible interaction between the flow label and the priority or the VLAN ID? Or between the address scope and the VLAN ID? I can't imagine someone wanting the subnetting to be different for global and site-local addressing, but then there are people out there with some perverse wants. It's my impression that the NIC interacts with the network infrastructure to learn that .1Q (and .1p?) features are present, so at least an addendum or trivial update to 2464 might be in order. Did you just volunteer? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 13:18:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1ILElE14911 for ipng-dist; Fri, 18 Feb 2000 13:14:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1ILEa014904 for ; Fri, 18 Feb 2000 13:14:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA25911 for ; Fri, 18 Feb 2000 13:14:36 -0800 (PST) Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22303 for ; Fri, 18 Feb 2000 14:14:34 -0700 (MST) Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id VAA13248 for ; Fri, 18 Feb 2000 21:12:50 GMT Received: from US-TR-EXCH-1.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id VAA07650 ; Fri, 18 Feb 2000 21:15:55 GMT Received: by us-tr-exch-1.tr.unisys.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Feb 2000 16:14:39 -0500 Message-ID: <236F133B43F4D211A4B00090273C79DC0EABE9@us-rv-exch-2.rsvl.unisys.com> From: "Sellers, Julian P" To: ipng@sunroof.eng.sun.com Subject: MAC-Derived Interface-id Date: Fri, 18 Feb 2000 16:14:31 -0500 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 I have a requirement that IPv6 addresses be configurable per application. It would be very convenient to configure for an application a 16-bit value that would replace the FFFE in the middle of the MAC-derived EUI-64 interface-id. These V6 addresses would be just as unique as those with the FFFE (but I wouldn't mind setting the univeral/local bit if that were required). This uniqueness property is nice because 1) I also have to allow multiple interfaces to the same network, and 2) it would eliminate most conflicts with manually configured V6 addresses of other nodes on the same network. When RFC 2373 (Addr Arch) describes the formation of EUI-64 identifiers from MAC addresses, it refers to an IEEE document called "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority." I'm trying to find a copy of that to see if I can find any reason why I shouldn't form interface-ids from MAC addresses with other than FFFE in the middle. Does anyone know of a reason why I should not do that? It sure seems better than ::1, ::2, etc. Julian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 13:45:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1ILhQt14950 for ipng-dist; Fri, 18 Feb 2000 13:43:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1ILhH014943 for ; Fri, 18 Feb 2000 13:43:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12331 for ; Fri, 18 Feb 2000 13:43:15 -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 NAA05938 for ; Fri, 18 Feb 2000 13:43:14 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA22699; Fri, 18 Feb 2000 22:38:59 +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 WAA19736; Fri, 18 Feb 2000 22:38:59 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id WAA26684; Fri, 18 Feb 2000 22:40:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200002182140.WAA26684@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Jean-Michel COMBES , Jacinto Vieira , ipng@sunroof.eng.sun.com Subject: Re: Ipv6 Internet Browser In-reply-to: Your message of Wed, 16 Feb 2000 22:55:17 +0900. <9956.950709317@coconut.itojun.org> Date: Fri, 18 Feb 2000 22:40:06 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: It is also very useful to install IPv6/v4 dual stack proxy web server on your computer. By doing so you can use your favorite (IPv4-only) web browser to access IPv6 web servers. => perhaps this is the best solution because you can't easily get the sources of a good browser... Francis.Dupont@enst-bretagne.fr PS: with high level languages to recompile/relink the browser with an IPv6 capable version of the language is usually enough. I did this with MMM written in O'CAML (now MMM is dead) and I know Grail works well with an IPv6 Python (get the Python socket library at ftp.logique.jussieu.fr:/pub/distrib/ylg/socket6-1.2.tgz and try?) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 13:52:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1ILp8b14987 for ipng-dist; Fri, 18 Feb 2000 13:51:08 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1ILou014969 for ; Fri, 18 Feb 2000 13:50:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA28874 for ; Fri, 18 Feb 2000 13:50:54 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09589 for ; Fri, 18 Feb 2000 14:50:54 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA04319; Fri, 18 Feb 2000 15:50:44 -0600 (CST) Message-Id: <200002182150.PAA04319@gungnir.fnal.gov> To: "Sellers, Julian P" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: MAC-Derived Interface-id In-reply-to: Your message of Fri, 18 Feb 2000 16:14:31 EST. <236F133B43F4D211A4B00090273C79DC0EABE9@us-rv-exch-2.rsvl.unisys.com> Date: Fri, 18 Feb 2000 15:50:44 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have a requirement that IPv6 addresses be configurable per application. > It would be very convenient to configure for an application a 16-bit value > that would replace the FFFE in the middle of the MAC-derived EUI-64 > interface-id. These V6 addresses would be just as unique as those with the > FFFE (but I wouldn't mind setting the univeral/local bit if that were > required). The FFFE is there as part of an IEEE-defined mapping from their old 48-bit identifiers to the new EUI-64 format. Manufacturers can and do issue 64-bit identifiers with the values 0000-FFFD in that position. However, if you flip the universal/local bit, you're OK. You get no promise that some entireley different node on the link (or some other application on your node!) isn't inventing its own "local" identifiers, of course, and they could just possibly collide, so you'd be well advised to do DAD on each new address. > When RFC 2373 (Addr Arch) describes the formation of EUI-64 identifiers from > MAC addresses, it refers to an IEEE document called "Guidelines for 64-bit > Global Identifier (EUI-64) Registration Authority." I'm trying to find a > copy of that to see if I can find any reason why I shouldn't form > interface-ids from MAC addresses with other than FFFE in the middle. http://grouper.ieee.org/groups/802/secmail/msg00396.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 14:09:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IM6XE15027 for ipng-dist; Fri, 18 Feb 2000 14:06:33 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IM6N015020 for ; Fri, 18 Feb 2000 14:06:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA02200 for ; Fri, 18 Feb 2000 14:06:22 -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 OAA16652 for ; Fri, 18 Feb 2000 14:06:21 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA15368; Fri, 18 Feb 2000 23:03:41 +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 XAA19938; Fri, 18 Feb 2000 23:03:41 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id XAA26906; Fri, 18 Feb 2000 23:04:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200002182204.XAA26906@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: David Borman cc: vlad@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of Fri, 18 Feb 2000 11:23:46 CST. <200002181723.LAA10337@frantic.bsdi.com> Date: Fri, 18 Feb 2000 23:04:48 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Date: Fri, 18 Feb 2000 11:20:59 -0500 > From: Vladislav Yasevich > Subject: Re: Clarifications wanted on Basic API (RFC 2553) > > Hope it's not too late to add to this, but I was just looking/fixing our > implementation of getaddrinfo() and had a question. > > Suppose the user specified the nodename and AI_PASSIVE flag when calling > getaddrinfo(). What would be the correct behavior: > 1. Return a EAI_BADFLAGS. > 2. Ignore the AI_PASSIVE flag, and return the address that the > nodename resolves to. (our current implementation) > 3. Ignore the nodename and return an unspecified address. You wouldn't want to ignore it, because it is perfectly reasonable for an application to start up a passive connection limited to one specific address. => this is less useful with IPv6 but is not uncommon. The AI_PASSIVE bit only affects things when nodename is NULL, so yes, if nodename != NULL, you effectivly ignore the AI_PASSIVE bit. => I don't understand why you don't take the AI_PASSIVE bit into account and bind() the socket to the address of the nodename? 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 Feb 18 14:46:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1IMhZw15105 for ipng-dist; Fri, 18 Feb 2000 14:43:35 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1IMhQ015098 for ; Fri, 18 Feb 2000 14:43:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA25414 for ; Fri, 18 Feb 2000 14:43:27 -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 OAA03936 for ; Fri, 18 Feb 2000 14:43:25 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA44901; Fri, 18 Feb 2000 23:43:19 +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 XAA20259; Fri, 18 Feb 2000 23:43:18 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id XAA27313; Fri, 18 Feb 2000 23:44:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200002182244.XAA27313@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Sellers, Julian P" cc: ipng@sunroof.eng.sun.com Subject: Re: MAC-Derived Interface-id In-reply-to: Your message of Fri, 18 Feb 2000 16:14:31 EST. <236F133B43F4D211A4B00090273C79DC0EABE9@us-rv-exch-2.rsvl.unisys.com> Date: Fri, 18 Feb 2000 23:44:27 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I have a requirement that IPv6 addresses be configurable per application. => I believe ports are here for this purpose? It would be very convenient to configure for an application a 16-bit value that would replace the FFFE in the middle of the MAC-derived EUI-64 interface-id. => you can do what you want when the global bit is reset/reversed. It sure seems better than ::1, ::2, etc. => I'd prefer this (1, 2, ...) because this is so simple (:-). In fact you can do anything when you need far less than 3037000499 addresses! 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 Feb 18 19:36:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1J3XwG15349 for ipng-dist; Fri, 18 Feb 2000 19:33:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1J3Xn015342 for ; Fri, 18 Feb 2000 19:33:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA17978 for ; Fri, 18 Feb 2000 19:33:48 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08360 for ; Fri, 18 Feb 2000 19:33:48 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 64537508; Fri, 18 Feb 2000 22:33:48 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 441B4728; Fri, 18 Feb 2000 22:33:48 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000007814; Fri, 18 Feb 2000 22:33:47 -0500 (EST) From: Jim Bound Message-Id: <200002190333.WAA0000007814@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: getaddrinfo with numeric port number and hints->ai_socktype = = 0 In-reply-to: Your message of "Fri, 18 Feb 2000 02:03:38 +0900." <28859.950807018@coconut.itojun.org> Date: Fri, 18 Feb 2000 22:33:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun and WG List, As I said when we started the rfc2553bis discussion we will be in synch with XNS 5.2 100%, except in one place right now on truncation we previously discussed. So do not worry about that, in fact assume it. Also this spec will not discuss the use of AF_LOCAL and AF_UNIX as I said previously. But we should make sure we do nothing with getaddrinfo that would negatively impacts its use. > I think I wasn't clear enough. > The point I would like to make here is the following: > - RFC2553 does not give indication about how far getaddrinfo should > glob the result. It should be made more clear on 2553bis. > - I think it makes more sense to glob ai_socktype with non-numeric > socktype. Vladislav's quote from X/Net looks like globbing > ai_socktype is what X/Net prefers. > - when we glob ai_socktype, numeric servname with ai_socktype = 0 is > ambiguous, and it makes more sense to raise error > - I'm happy to be convinced otherwise ("ai_socktype is opaque"). > if majority thinks so. Now the bad news about all this discussion. RFC2553 pretty much just lifted getaddrinfo from the IEEE POSIX Committee now referenced as the Austin Group and who works with XNS Team. We cannot alter at this time the syntax or semantics of getaddrinfo so it is not RFC 2553's fault for lack of specification here. We just globbed it into RFC 2553 with some editing and some new flags (which is OK). The IETF and this working group don't own this API. It is like someone in ETSI tweaking TCP or UDP. We have to be careful here. We did not have this problem with getipnodebyname we invented that and gave it to XNS. What I need to do is speak with Chris Harding offline and see what the rules are here and get back to you. I am sure we can come to some agreement. But I think we need to understand we cannot specify the behavior of this API and what is returned within the datatypes based on assuming knowledge of things like /etc/services, they are not dejure standards and are implementation defined. Where we can specify we pretty much have at this point. Getaddrinfo obviously needs to nail this down so the basics are implemented for the behavior we needed for getipbnodebyname, the fact that it does much more is serendipity and not an action from this IETF WG. Again I have to speak with Chris who knows the XNS and Austin Group logistics and what we can do and cannot do. 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 Feb 18 21:19:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1J5Gvc15409 for ipng-dist; Fri, 18 Feb 2000 21:16:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1J5Gm015402 for ; Fri, 18 Feb 2000 21:16:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA03018 for ; Fri, 18 Feb 2000 21:16:46 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA28642 for ; Fri, 18 Feb 2000 21:16:46 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id D0E6B534; Sat, 19 Feb 2000 00:16:45 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 9F42677E; Sat, 19 Feb 2000 00:16:45 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000021209; Sat, 19 Feb 2000 00:16:45 -0500 (EST) From: Jim Bound Message-Id: <200002190516.AAA0000021209@quarry.zk3.dec.com> To: David Borman Cc: vlad@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of "Fri, 18 Feb 2000 11:23:46 CST." <200002181723.LAA10337@frantic.bsdi.com> Date: Sat, 19 Feb 2000 00:16:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, >The AI_PASSIVE bit only affects things when nodename is NULL, so >yes, if nodename != NULL, you effectivly ignore the AI_PASSIVE bit. I think we should add this text to the specification. Do you agree? thanks /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 Sat Feb 19 22:36:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1K6YKG15718 for ipng-dist; Sat, 19 Feb 2000 22:34:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1K6Y8015711 for ; Sat, 19 Feb 2000 22:34:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA24511 for ; Sat, 19 Feb 2000 22:34:06 -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 XAA01963 for ; Sat, 19 Feb 2000 23:34:05 -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 PAA07602 for ; Sun, 20 Feb 2000 15:34:03 +0900 (JST) To: 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: sizeof(sockaddr_in6) % 8 != 0 (more on 2553) From: itojun@iijlab.net Date: Sun, 20 Feb 2000 15:34:03 +0900 Message-ID: <7600.951028443@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some of BSD folks came to notice that sizeof(sockaddr_in6) is not multiple of 8. This is usually sized 28 bytes. (without sa_len) >struct sockaddr_in6 { > sa_family_t sin6_family; /* AF_INET6 */ > in_port_t sin6_port; /* transport layer port # */ > uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ > struct in6_addr sin6_addr; /* IPv6 address */ > uint32_t sin6_scope_id; /* set of interfaces for a scope */ >}; (with sa_len) >struct sockaddr_in6 { > uint8_t sin6_len; /* length of this struct */ > sa_family_t sin6_family; /* AF_INET6 */ > in_port_t sin6_port; /* transport layer port # */ > uint32_t sin6_flowinfo; /* IPv6 flow information */ > struct in6_addr sin6_addr; /* IPv6 address */ > uint32_t sin6_scope_id; /* set of interfaces for a scope */ >}; If we use packed structs, this will generate unaligned data on 64bit architectures. One example is SIOCGIFCONF (kernel returns all the addresses configured to the interfaces). On 64bit architectures (like alpha), we can no longer use pointers to parse the result from SIOCGIFCONF, we need to memcpy() beforehand. I admit packed structs are not a good API choice, but SIOCGIFCONF has been there. We can't just nuke it, and it looks more sane to return IPv6 address with it. It is also true that, for packed structs, we cannot really be sure about alignment constraints. 2553 cares about alignment of sin6_addr member, but not the packed structs. > The ordering of elements in this structure is specifically designed > so that when sin6_addr field is aligned on a 64-bit boundary, the > start of the structure will also be aligned on a 64-bit boundary. > This is done for optimum performance on 64-bit architectures. Possible breakage sceneario would be: - we have a binary compiled before IPv6. it parses returned structure from SIOCGIFCONF by using pointers. - replace the kernel with IPv6-ready kernel. - see the binary dies with alignment violation. There are multiple ways to escape from this problem: 1. change ioctl # for SIOCGIFCONF, old one kept as OSIOCGIFCONF (which ignores IPv6 addresses) 2. add extra member to sockaddr_in6 to align it 3. broken appliation should die, leave it as is My questions are: - did it discussed in the past? - is there any standards/whatever for SIOCGIFCONF? Is there any material talked about it? (or no vendor UNIXes are using SIOCGIFCONF?) - is it legal for *a platform* to add extra member for padding, like: >struct sockaddr_in6 { > uint8_t sin6_len; /* length of this struct */ > sa_family_t sin6_family; /* AF_INET6 */ > in_port_t sin6_port; /* transport layer port # */ > uint32_t sin6_flowinfo; /* IPv6 flow information */ > struct in6_addr sin6_addr; /* IPv6 address */ > uint32_t sin6_scope_id; /* set of interfaces for a scope */ > uint32_t sin6_zero; /* padding */ <--- >}; - is it worth including the above into 2553bis? - if not, could we add some warning into it? like: >Note that struct sockaddr_in6 is normally sized 28 bytes, from the definition >presented in the above. This may raise alingment issues if we use it in >packed structs, on top of architecture with requires 8 byte alignment. 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 Sun Feb 20 16:35:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1L0Wvr16047 for ipng-dist; Sun, 20 Feb 2000 16:32:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L0Wl016040 for ; Sun, 20 Feb 2000 16:32:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA17064 for ; Sun, 20 Feb 2000 16:32:46 -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 RAA22666 for ; Sun, 20 Feb 2000 17:32:45 -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 JAA18259 for ; Mon, 21 Feb 2000 09:32:39 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Sun, 20 Feb 2000 15:34:03 JST. <7600.951028443@coconut.itojun.org> 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: sizeof(sockaddr_in6) % 8 != 0 (more on 2553) From: itojun@iijlab.net Date: Mon, 21 Feb 2000 09:32:39 +0900 Message-ID: <18257.951093159@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - is it legal for *a platform* to add extra member for padding, > like: >>struct sockaddr_in6 { >> uint8_t sin6_len; /* length of this struct */ >> sa_family_t sin6_family; /* AF_INET6 */ >> in_port_t sin6_port; /* transport layer port # */ >> uint32_t sin6_flowinfo; /* IPv6 flow information */ >> struct in6_addr sin6_addr; /* IPv6 address */ >> uint32_t sin6_scope_id; /* set of interfaces for a scope */ >> uint32_t sin6_zero; /* padding */ <--- >>}; > - is it worth including the above into 2553bis? Just to be clear: I'm actually not in favor of the above change, actually I wouldn't do it(changing definition in this LATE stage is very harmful). I just would like to know how people solved this for other 64bit-ready operating systems with SIOCGIFCONF, and tried to list possible solutions. 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 Sun Feb 20 17:39:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1L1bpt16091 for ipng-dist; Sun, 20 Feb 2000 17:37:51 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L1bg016084 for ; Sun, 20 Feb 2000 17:37:43 -0800 (PST) Received: from gharonda (awe185-51.AWE.Sun.COM [192.29.185.51]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA11707; Sun, 20 Feb 2000 17:37:41 -0800 (PST) Message-Id: <200002210137.RAA11707@jurassic.eng.sun.com> Date: Sun, 20 Feb 2000 17:39:36 -0800 (PST) From: Mukesh Kacker Reply-To: Mukesh Kacker Subject: Re: sizeof(sockaddr_in6) % 8 != 0 (more on 2553) To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com, mukesh@jurassic.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TObddKIRgUCPA469LooSow== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >To: 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: Re: sizeof(sockaddr_in6) % 8 != 0 (more on 2553) >From: itojun@iijlab.net >Date: Mon, 21 Feb 2000 09:32:39 +0900 > > I just would like to know how people solved this for > other 64bit-ready operating systems with SIOCGIFCONF, and tried to > list possible solutions. > Itojun, I have not clearly understood the constraints you are working with (on alpha ?) but I can offer some general trivia based on experiences with Solaris code which supports many different ABIs (and I will not bore you/list with details of those) but they do affect the design of data structures. Firstly the assertion you use in the subject line sizeof(sockaddr_in6) % 8 != 0 is not really what determines/constraints its alignment, it is the constraint imposed by the "largest alignment" member in it. Thus it is conceivable that even if you increase it to be a multiple of 8, and it still starts with a 4 byte aligned (but not 8 byte aligned boundary) on some architectures so I will advise being careful. Another factor is that the boundary used by the star of the kernel buffers when ioctl data is copied from user to kernel land. The design of data structures is affected by the ABI constraints and anything that embeds such a data structure also has to be careful with padding etc. For example, Solaris 64-bit kernel runs both ILP32 and LP64 user level applications (effectively supporting two ABIs) and therefore has to be careful that after data copies from either userland buffers, into the LP64 kernel it will see them the same way. That may or may not be a factor in your environment. Having that binary compatibility was a constraint for us. Those were general principles, I can roughly tell you what we do in the those specific instances, but I am not sure how much of that will apply to your case (and I do not want another religious battle about the one true design of SIOCG* data structures :-) just reporting what we have). We do define a new ioctl API (SIOCGLIFCONF - extra L in ioctl name) which has larger sockaddr's. Also, to take care of alignment and storage constraints we use the new sockaddr_storage data structure which, on architectures where it is supported, gets 8 byte aligned. The technique to force that alignment is specific to our implementation and uses hidden fields etc to achieve that. Some of the SIOCG* ioctl data structures that embed sockaddr_storage are carefully designed so that it falls on 64-bit boundary even if it is on architectures where the ABI does not guarantee it (e.g. Intel IA32 ILP32 architecture) so that when they get copied into a LP64 kernel, they get processed an an indentical manner for ILP32 and LP64 environments. I can send you (or anyone else) the headers which can be perused to understand atleast the experience of one vendor and will not pollute the list with it. (Our headers support Sparc and Intel 32 and 64 bit ABIs and are atleast portable enough for those). If you have specific questions on alignment feel free to ask offline and I will keep it away from the list as often these issues take up way too many interations to get across :-) -Mukesh Kacker Solaris Internet Engineering mukesh.kacker@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 Feb 20 17:56:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1L1sDs16118 for ipng-dist; Sun, 20 Feb 2000 17:54:13 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L1s3016111 for ; Sun, 20 Feb 2000 17:54:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA28861; Sun, 20 Feb 2000 17:54:02 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05828; Sun, 20 Feb 2000 17:54:00 -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 KAA19131; Mon, 21 Feb 2000 10:53:59 +0900 (JST) To: Mukesh Kacker cc: ipng@sunroof.eng.sun.com In-reply-to: Mukesh.Kacker's message of Sun, 20 Feb 2000 17:39:36 PST. <200002210137.RAA11707@jurassic.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: Re: sizeof(sockaddr_in6) % 8 != 0 (more on 2553) From: itojun@iijlab.net Date: Mon, 21 Feb 2000 10:53:59 +0900 Message-ID: <19129.951098039@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If you have specific questions on alignment feel free to ask offline >and I will keep it away from the list as often these issues take >up way too many interations to get across :-) Thanks for your reply, I'll email you privately on this. I may need to describe gory details... 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 Sun Feb 20 22:12:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1L6AZ516209 for ipng-dist; Sun, 20 Feb 2000 22:10:35 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L6AF016201 for ; Sun, 20 Feb 2000 22:10:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA00193 for ; Sun, 20 Feb 2000 22:10:12 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00863 for ; Sun, 20 Feb 2000 23:10:07 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 21 Feb 2000 11:48:14 +0530 Received: from muralia.future.futsoft.com ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA03544; Mon, 21 Feb 2000 11:30:40 +0530 Received: by localhost with Microsoft MAPI; Mon, 21 Feb 2000 11:41:31 +0530 Message-Id: <01BF7C60.99129620.muralia@future.futsoft.com> From: Murali Krishna Ch Reply-To: "muralia@future.futsoft.com" To: "ipng@sunroof.eng.sun.com" Cc: "users@ipv6.org" Subject: TCP over IPv6 Date: Mon, 21 Feb 2000 11:41:30 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Is there any new implementation/RFCs for TCP for IPv6, like UDP6 over IPv6? If not, should we enhance TCP to work with IPv6 stack? thanks and regards, murali. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 20 22:19:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1L6J4216231 for ipng-dist; Sun, 20 Feb 2000 22:19:04 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L6Ir016224 for ; Sun, 20 Feb 2000 22:18:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA08659 for ; Sun, 20 Feb 2000 22:18:51 -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 XAA02815 for ; Sun, 20 Feb 2000 23:18:51 -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 PAA22767; Mon, 21 Feb 2000 15:16:59 +0900 (JST) To: "muralia@future.futsoft.com" cc: "ipng@sunroof.eng.sun.com" , "users@ipv6.org" In-reply-to: muralia's message of Mon, 21 Feb 2000 11:41:30 +0530. <01BF7C60.99129620.muralia@future.futsoft.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: TCP over IPv6 From: itojun@iijlab.net Date: Mon, 21 Feb 2000 15:16:59 +0900 Message-ID: <22765.951113819@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Is there any new implementation/RFCs for TCP for IPv6, like UDP6 over IPv6? If not, >should we enhance TCP to work with IPv6 stack? > >thanks and regards, TCP should work just fine on top of IPv6. the only thing you need to change in the packet manipulation is pseudo header checksum. this is documend in rfc2460 chapter 8. (if you would like to support tcp over IPv6 jumbogram, you'll need lots of fixes) 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 Sun Feb 20 23:32:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1L7Uht16284 for ipng-dist; Sun, 20 Feb 2000 23:30:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L7UY016277 for ; Sun, 20 Feb 2000 23:30:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA24158 for ; Sun, 20 Feb 2000 23:30:35 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA11641 for ; Sun, 20 Feb 2000 23:30:35 -0800 (PST) Received: from inferno.india.hp.com (inferno.india.hp.com [15.10.43.143]) by palrel1.hp.com (Postfix) with ESMTP id 501D91C2; Sun, 20 Feb 2000 23:30:30 -0800 (PST) Received: from india.hp.com (rgelpc276.rgv.hp.com [15.81.94.112]) by inferno.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.1) id NAA03949; Mon, 21 Feb 2000 13:08:57 +0530 (IST) Message-ID: <38B0E987.2CA2829F@india.hp.com> Date: Sun, 20 Feb 2000 23:30:15 -0800 From: Gururaj A Organization: Hewlett Packard. X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "muralia@future.futsoft.com" Cc: "ipng@sunroof.eng.sun.com" , "users@ipv6.org" Subject: Re: TCP over IPv6 References: <01BF7C60.99129620.muralia@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk refer RFC 2147 Guru Murali Krishna Ch wrote: > Hi > > Is there any new implementation/RFCs for TCP for IPv6, like UDP6 over IPv6? If not, > should we enhance TCP to work with IPv6 stack? > > thanks and regards, > murali. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Feb 21 09:52:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1LHork16673 for ipng-dist; Mon, 21 Feb 2000 09:50:53 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1LHog016666 for ; Mon, 21 Feb 2000 09:50:43 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA08149 for ; Mon, 21 Feb 2000 09:50:42 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16859 for ; Mon, 21 Feb 2000 09:50:37 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id LAA18987; Mon, 21 Feb 2000 11:49:13 -0600 (CST) Date: Mon, 21 Feb 2000 11:49:13 -0600 (CST) From: David Borman Message-Id: <200002211749.LAA18987@frantic.bsdi.com> To: Francis.Dupont@enst-bretagne.fr Subject: Re: Clarifications wanted on Basic API (RFC 2553) Cc: ipng@sunroof.eng.sun.com, vlad@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Francis Dupont > Subject: Re: Clarifications wanted on Basic API (RFC 2553) > Date: Fri, 18 Feb 2000 23:04:48 +0100 ... > The AI_PASSIVE bit only affects things when nodename is NULL, so > yes, if nodename != NULL, you effectivly ignore the AI_PASSIVE bit. > > => I don't understand why you don't take the AI_PASSIVE bit into account > and bind() the socket to the address of the nodename? Sorry, I guess I wasn't clear. The AI_PASSIVE bit is only there to specify for getaddrinfo() what to fill in for the address when nodename == NULL. So, if nodename is not NULL, getaddrinfo() effectivly ignores the AI_PASSIVE bit. The calling application would of course do its normal bind()/listen()/accept(). -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 Mon Feb 21 09:52:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1LHnqY16664 for ipng-dist; Mon, 21 Feb 2000 09:49:52 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1LHng016657 for ; Mon, 21 Feb 2000 09:49:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA29846 for ; Mon, 21 Feb 2000 09:49:42 -0800 (PST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24269 for ; Mon, 21 Feb 2000 10:49:40 -0700 (MST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id CAA16506; Tue, 22 Feb 2000 02:42:42 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id CAA13043; Tue, 22 Feb 2000 02:42:41 +0900 (JST) Received: from localhost (ppp130.isl.rdc.toshiba.co.jp [133.196.10.130]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id CAA01542; Tue, 22 Feb 2000 02:42:38 +0900 (JST) Date: Tue, 22 Feb 2000 02:44:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis Update overview of assumptions, goals, etc. In-Reply-To: In your message of "Fri, 04 Feb 2000 23:52:36 +0900" References: <200002040131.UAA0000012259@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 105 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 04 Feb 2000 23:52:36 +0900, >>>>> JINMEI Tatuya said: >>> Hmm, if you mean some definitions (e.g. macro names of new flags) that >>> are related to 2553bis, I'll try to clarify them ASAP, and will send >>> the result to this list before revising our draft. >> Whoops. If you want to add macros and other needs for parsing thats >> cool. But I was thinking the text we need to put in rfc2553bis that may >> be needed so an api developer has a clue. > I see, thanks for the clarification. I'll discuss it in the KAME team > and send some text to this list. It would contain an overview of the > new address format and relationship between textual addresses and > values in the sin6_scope_id field. Sorry for the delay. Howe about the following text? It would be added to Section 6.4 and 6.5 of RFC2553. I'll attach the text itself with some original parts of the draft to supplement the context. I didn't mention the precise format of the extended format of IPv6 scoped addresses. Instead, I just referred to our draft in order to avoid duplicated description. However, if it doesn't make sense, I'll revise the text with the specific format. The text might still be unclear. If so, please let me know. I'll try to make the text clearer in response to comments. As for the precise format, we've discussed it with Brian (Zill@MSR), Rich (Draves@MSR), Francis (Dupont@INRIA), and some KAME guys, and almost agreed on the following format: % that is, - the delimiter character is `%' - the scope_id part is placed after the address with the delimiter. I'm going to revise our draft with this format and will soon post it to the list. Thanks. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 6.4 Protocol-Independent Nodename and Service Name Translation page 27: The nodename and servname arguments are pointers to null-terminated strings or NULL. One or both of these two arguments must be a non- NULL pointer. In the normal client scenario, both the nodename and servname are specified. In the normal server scenario, only the servname is specified. A non-NULL nodename string can be either a node name or a numeric host address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address, [addition:] which includes an extended address format for a scoped IPv6 address[Refer to the scopedaddr-format draft]). ... page 28, 2nd paragraph: socket() function. In each addrinfo structure the ai_addr member points to a filled-in socket address structure whose length is specified by the ai_addrlen member. [addition:] If the nodename is a textual IPv6 scoped address with a scope identifier, getaddrinfo() sets the appropriate numeric number for the scope identifer to the sin6_scope_id field of each returned sockaddr_in6 structure. For a zero or positive numeric scope identifier, getaddrinfo() simply copies the value to the sin6_scope_id field, and lets the kernel validate the value. If the scope identifier is given as a string (e.g. an interface name), getaddrinfo() first translates it into an according numeric number, and then sets the number to the sin6_scope_id field. The mapping between the string to the numeric number is implementation dependent. Getaddrinfo() returns the EAI_NONAME error when the translation fails. It also returns the same error code if the scope identifier is a negative number. If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, then the caller plans to use the returned socket address ... 6.5 Socket Address Structure to Nodename and Service Name ... If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be located in the DNS, the numeric form of the host's address is returned instead of its name (e.g., by calling inet_ntop() instead of getipnodebyaddr()). [addition:] Moreover, if sa points to a sockaddr_in6 structure for an IPv6 scoped address and the sin6_scope_id field of the structure has a non-zero value, the returned numeric form should be in the extended format, that is, the address is followed by a scope identifier according to the value of the sin6_scope_id field with the delimiter character. The scope identifier is either the numeric number of the sin6_scope_id field or an implementation specific string (e.g. an interface name) of the sin6_scope_id field. If sa points to a sockaddr_in6 structure for an IPv6 global address with a non-zero value of the sin6_scope_id field, getnameinfo() simply ignores the sin6_scope_id field and just returns the numeric form of the global address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 22 10:14:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1MIBlY17421 for ipng-dist; Tue, 22 Feb 2000 10:11:47 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1MIBh017414 for ; Tue, 22 Feb 2000 10:11:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA04962 for ipng@sunroof.eng.sun.com; Tue, 22 Feb 2000 10:10:08 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L2PI016136; Sun, 20 Feb 2000 18:25:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA26580; Sun, 20 Feb 2000 18:25:17 -0800 (PST) From: kame@kame.net Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA11469; Sun, 20 Feb 2000 18:25:17 -0800 (PST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA29267; Mon, 21 Feb 2000 11:25:13 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA18069; Mon, 21 Feb 2000 11:25:12 +0900 (JST) Received: from iijlab.net (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id LAA07411; Mon, 21 Feb 2000 11:25:12 +0900 (JST) Date: Mon, 21 Feb 2000 11:25:52 +0900 (JST) Message-Id: <20000221.112552.41631947.kazu@iijlab.net> To: kame-related-people:; Subject: KAME 03/2000 -> 03/2002 X-Mailer: Mew version 1.95b27 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are glad to announce the extension of the term of the KAME project to March 2002. The KAME project originally planned to close its activities in March 2000. Since the next two years are very important for deployment of IPv6 and the responsibility of the KAME project has become larger, we have negotiated the sponsor companies of the KAME project for the extension and reached consensus. For the next two years, the KAME project will continue the current coding activities. We will also concentrate on the deployment of IPv6. // The KAME 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 Feb 22 10:14:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1MICXf17430 for ipng-dist; Tue, 22 Feb 2000 10:12:33 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1MICS017423 for ; Tue, 22 Feb 2000 10:12:29 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA04992 for ipng@sunroof.eng.sun.com; Tue, 22 Feb 2000 10:10:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L2PI016136; Sun, 20 Feb 2000 18:25:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA26580; Sun, 20 Feb 2000 18:25:17 -0800 (PST) From: kame@kame.net Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA11469; Sun, 20 Feb 2000 18:25:17 -0800 (PST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA29267; Mon, 21 Feb 2000 11:25:13 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA18069; Mon, 21 Feb 2000 11:25:12 +0900 (JST) Received: from iijlab.net (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id LAA07411; Mon, 21 Feb 2000 11:25:12 +0900 (JST) Date: Mon, 21 Feb 2000 11:25:52 +0900 (JST) Message-Id: <20000221.112552.41631947.kazu@iijlab.net> To: kame-related-people:; Subject: KAME 03/2000 -> 03/2002 X-Mailer: Mew version 1.95b27 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are glad to announce the extension of the term of the KAME project to March 2002. The KAME project originally planned to close its activities in March 2000. Since the next two years are very important for deployment of IPv6 and the responsibility of the KAME project has become larger, we have negotiated the sponsor companies of the KAME project for the extension and reached consensus. For the next two years, the KAME project will continue the current coding activities. We will also concentrate on the deployment of IPv6. // The KAME project From owner-ngtrans@sunroof.eng.sun.com Sun Feb 20 18:25:29 2000 X-Unix-From: owner-ngtrans@sunroof.eng.sun.com Sun Feb 20 18:25:29 2000 Return-Path: Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13000 for ; Sun, 20 Feb 2000 18:25:28 -0800 (PST) From: owner-ngtrans@sunroof.eng.sun.com Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1L2PRF16143; Sun, 20 Feb 2000 18:25:27 -0800 (PST) Date: Sun, 20 Feb 2000 18:25:27 -0800 (PST) Message-Id: <200002210225.e1L2PRF16143@sunroof.eng.sun.com> To: owner-ngtrans@sunroof.eng.sun.com Subject: BOUNCE ngtrans@sunroof.eng.sun.com: Non-member submission from [kame@kame.net] Content-Length: 1931 Status: RO X-Status: $$$T X-UID: 0000000009 From owner-ngtrans Sun Feb 20 18:25:19 2000 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1L2PI016136; Sun, 20 Feb 2000 18:25:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA26580; Sun, 20 Feb 2000 18:25:17 -0800 (PST) From: kame@kame.net Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA11469; Sun, 20 Feb 2000 18:25:17 -0800 (PST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA29267; Mon, 21 Feb 2000 11:25:13 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA18069; Mon, 21 Feb 2000 11:25:12 +0900 (JST) Received: from iijlab.net (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id LAA07411; Mon, 21 Feb 2000 11:25:12 +0900 (JST) Date: Mon, 21 Feb 2000 11:25:52 +0900 (JST) Message-Id: <20000221.112552.41631947.kazu@iijlab.net> To: kame-related-people:; Subject: KAME 03/2000 -> 03/2002 X-Mailer: Mew version 1.95b27 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are glad to announce the extension of the term of the KAME project to March 2002. The KAME project originally planned to close its activities in March 2000. Since the next two years are very important for deployment of IPv6 and the responsibility of the KAME project has become larger, we have negotiated the sponsor companies of the KAME project for the extension and reached consensus. For the next two years, the KAME project will continue the current coding activities. We will also concentrate on the deployment of IPv6. // The KAME 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 Feb 22 10:29:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1MIRII17471 for ipng-dist; Tue, 22 Feb 2000 10:27:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1MIRA017464 for ; Tue, 22 Feb 2000 10:27:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA00007 for ; Tue, 22 Feb 2000 10:27:09 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05427 for ; Tue, 22 Feb 2000 10:27:08 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 5B17F353; Tue, 22 Feb 2000 13:27:08 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 3FE2D56A; Tue, 22 Feb 2000 13:27:08 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000003253; Tue, 22 Feb 2000 13:27:07 -0500 (EST) From: Jim Bound Message-Id: <200002221827.NAA0000003253@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: UPDATE rfc2553bis Update for IPv6 Extended address scope Date: Tue, 22 Feb 2000 13:27:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi JINMEI, Changed subject so I can identify this mail as different for me. I am fine with the attached and the referencing of your draft that is much wiser. So I will use this text for 1st draft of 2553bis as we evolve. thanks /jim -------------------------------------- As for the precise format, we've discussed it with Brian (Zill@MSR), Rich (Draves@MSR), Francis (Dupont@INRIA), and some KAME guys, and almost agreed on the following format: % that is, - the delimiter character is `%' - the scope_id part is placed after the address with the delimiter. I'm going to revise our draft with this format and will soon post it to the list. 6.4 Protocol-Independent Nodename and Service Name Translation page 27: The nodename and servname arguments are pointers to null-terminated strings or NULL. One or both of these two arguments must be a non- NULL pointer. In the normal client scenario, both the nodename and servname are specified. In the normal server scenario, only the servname is specified. A non-NULL nodename string can be either a node name or a numeric host address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address, [addition:] which includes an extended address format for a scoped IPv6 address[Refer to the scopedaddr-format draft]). ... page 28, 2nd paragraph: socket() function. In each addrinfo structure the ai_addr member points to a filled-in socket address structure whose length is specified by the ai_addrlen member. [addition:] If the nodename is a textual IPv6 scoped address with a scope identifier, getaddrinfo() sets the appropriate numeric number for the scope identifer to the sin6_scope_id field of each returned sockaddr_in6 structure. For a zero or positive numeric scope identifier, getaddrinfo() simply copies the value to the sin6_scope_id field, and lets the kernel validate the value. If the scope identifier is given as a string (e.g. an interface name), getaddrinfo() first translates it into an according numeric number, and then sets the number to the sin6_scope_id field. The mapping between the string to the numeric number is implementation dependent. Getaddrinfo() returns the EAI_NONAME error when the translation fails. It also returns the same error code if the scope identifier is a negative number. If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, then the caller plans to use the returned socket address ... 6.5 Socket Address Structure to Nodename and Service Name ... If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be located in the DNS, the numeric form of the host's address is returned instead of its name (e.g., by calling inet_ntop() instead of getipnodebyaddr()). [addition:] Moreover, if sa points to a sockaddr_in6 structure for an IPv6 scoped address and the sin6_scope_id field of the structure has a non-zero value, the returned numeric form should be in the extended format, that is, the address is followed by a scope identifier according to the value of the sin6_scope_id field with the delimiter character. The scope identifier is either the numeric number of the sin6_scope_id field or an implementation specific string (e.g. an interface name) of the sin6_scope_id field. If sa points to a sockaddr_in6 structure for an IPv6 global address with a non-zero value of the sin6_scope_id field, getnameinfo() simply ignores the sin6_scope_id field and just returns the numeric form of the global address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 22 11:50:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1MJlRU17609 for ipng-dist; Tue, 22 Feb 2000 11:47:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1MJlI017602 for ; Tue, 22 Feb 2000 11:47:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA21707 for ; Tue, 22 Feb 2000 11:47:18 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22777 for ; Tue, 22 Feb 2000 11:47:17 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id NAA23111; Tue, 22 Feb 2000 13:45:45 -0600 (CST) Date: Tue, 22 Feb 2000 13:45:45 -0600 (CST) From: David Borman Message-Id: <200002221945.NAA23111@frantic.bsdi.com> To: bound@zk3.dec.com Subject: Re: Clarifications wanted on Basic API (RFC 2553) Cc: ipng@sunroof.eng.sun.com, vlad@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Jim Bound > Subject: Re: Clarifications wanted on Basic API (RFC 2553) > Date: Sat, 19 Feb 2000 00:16:43 -0500 > > Dave, > > >The AI_PASSIVE bit only affects things when nodename is NULL, so > >yes, if nodename != NULL, you effectivly ignore the AI_PASSIVE bit. > > I think we should add this text to the specification. > Do you agree? I don't think so. The text seems pretty clear to me: If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, then the caller plans to use the returned socket address structure in a call to bind(). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE bit is not set in the ai_flags member of the hints structure, then the returned socket address structure will be ready for a call to connect() (for a connection-oriented protocol) or either connect(), sendto(), or sendmsg() (for a connectionless protocol). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to the loopback address. The first paragraph is when AI_PASSIVE is set and nodename == NULL, the second is when AI_PASSIVE is not set and nodename == NULL. However, perhaps it isn't clear enough since the topic is being discussed. I'll offer this rewording which combines both paragraphs, and makes it clearer that the AI_PASSIVE bit only applies when nodename == NULL. If the nodename argument is a NULL pointer, then the AI_PASSIVE bit in the ai_flags member of the hints structure determines how to fill in the IP address portion of the socket address structure. In this case, if the AI_PASSIVE bit is set, then the caller plans to use the returned socket address structure in a call to bind(), and the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE bit is not set then the returned socket address structure will be ready for a call to connect() (for a connection- oriented protocol) or either connect(), sendto(), or sendmsg() (for a connectionless protocol), and the IP address portion of the socket address structure will be set to the loopback address. -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 Tue Feb 22 19:07:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1N2ufN17885 for ipng-dist; Tue, 22 Feb 2000 18:56:41 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1N2uX017878 for ; Tue, 22 Feb 2000 18:56:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA12199 for ; Tue, 22 Feb 2000 18:56:33 -0800 (PST) From: lonelyforever@263.net Received: from mta1.263.net ([202.96.44.43]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA27627 for ; Tue, 22 Feb 2000 18:55:33 -0800 (PST) Received: by mta1.263.net (Postfix, from userid 60001) id BDD4A1C3D9F99; Wed, 23 Feb 2000 10:59:14 +0800 (CST) MIME-Version: 1.0 Message-Id: <38B34D02.05706@mta1> Date: Wed, 23 Feb 2000 10:59:14 +0800 (CST) To: ipng@sunroof.eng.sun.com Subject: What happen? X-Priority: 3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Have you ever encountered some problem like this: we have two machines directly connected. both of the boxes use the kernel 2.2.13. Strange thing happens here. Sometimes they disconnected.But after one of the machines reboot, they worked all right until the next day --- they broke again !! something like AT ONCE ONE DAY reboot--------work---------reboot--work-- ..... //faint Do you have any good ideas? _____________________________________________ Ê׶¼ÔÚÏß--ÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net @263.netÖйú×î´óµÄÔÚÏßÓÊ¾Ö http://freemail.263.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 Tue Feb 22 20:20:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1N4FWY17946 for ipng-dist; Tue, 22 Feb 2000 20:15:32 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1N4FN017939 for ; Tue, 22 Feb 2000 20:15:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA23542 for ; Tue, 22 Feb 2000 20:15:23 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA05943 for ; Tue, 22 Feb 2000 21:15:22 -0700 (MST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id 745689A8D6; Tue, 22 Feb 2000 22:15:22 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id 6D8DB90D82; Tue, 22 Feb 2000 22:15:22 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 4A1F94FB01; Tue, 22 Feb 2000 22:15:15 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id E3EE94C901; Tue, 22 Feb 2000 22:15:14 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000031358; Tue, 22 Feb 2000 23:15:21 -0500 (EST) From: Jim Bound Message-Id: <200002230415.XAA0000031358@quarry.zk3.dec.com> To: David Borman Cc: ipng@sunroof.eng.sun.com, vlad@zk3.dec.com, bound@zk3.dec.com Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of "Tue, 22 Feb 2000 13:45:45 CST." <200002221945.NAA23111@frantic.bsdi.com> Date: Tue, 22 Feb 2000 23:15:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dave, If the nodename argument is a NULL pointer, then the AI_PASSIVE bit in the ai_flags member of the hints structure determines how to fill in the IP address portion of the socket address structure. In this case, if the AI_PASSIVE bit is set, then the caller plans to use the returned socket address structure in a call to bind(), and the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE bit is not set then the returned socket address structure will be ready for a call to connect() (for a connection- oriented protocol) or either connect(), sendto(), or sendmsg() (for a connectionless protocol), and the IP address portion of the socket address structure will be set to the loopback address. I will put this in the next update of the draft. thanks /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 Feb 22 23:00:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1N6uBm18020 for ipng-dist; Tue, 22 Feb 2000 22:56:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1N6u0018013 for ; Tue, 22 Feb 2000 22:56:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA27795 for ; Tue, 22 Feb 2000 22:55:56 -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 WAA01589 for ; Tue, 22 Feb 2000 22:55:55 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 22 Feb 2000 22:50:51 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Tue, 22 Feb 2000 22:50:51 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21C10@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" , JINMEI Tatuya / ???? Cc: ipng@sunroof.eng.sun.com Subject: RE: UPDATE rfc2553bis Update for IPv6 Extended address scope Date: Tue, 22 Feb 2000 22:50:43 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [addition:] > Moreover, if sa points to a sockaddr_in6 structure for an IPv6 > scoped address and the sin6_scope_id field of the structure has > a non-zero value, the returned numeric form should be in the > extended format, that is, the address is followed by a scope > identifier according to the value of the sin6_scope_id field with > the delimiter character. The scope identifier is either the numeric > number of the sin6_scope_id field or an implementation specific > string (e.g. an interface name) of the sin6_scope_id field. If sa > points to a sockaddr_in6 structure for an IPv6 global address with > a non-zero value of the sin6_scope_id field, getnameinfo() simply > ignores the sin6_scope_id field and just returns the numeric form > of the global address. I would prefer if sin6_scope_id is stringified independently of the address. (Or if the scope-id is translated to a non-numeric scope-id name, then do that for link-local & site-local addresses but otherwise treat the scope-id & address as opaque.) It's simpler and more open to future evolution. 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 Wed Feb 23 02:17:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NAFcW18125 for ipng-dist; Wed, 23 Feb 2000 02:15:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NAFT018118 for ; Wed, 23 Feb 2000 02:15:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA27788 for ; Wed, 23 Feb 2000 02:15:27 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01510 for ; Wed, 23 Feb 2000 02:15:27 -0800 (PST) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id TAA28112; Wed, 23 Feb 2000 19:05:41 +0900 (JST) Date: Wed, 23 Feb 2000 19:17:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: lonelyforever@263.net Cc: ipng@sunroof.eng.sun.com Subject: Re: What happen? In-Reply-To: In your message of "Wed, 23 Feb 2000 10:59:14 +0800 (CST)" <38B34D02.05706@mta1> References: <38B34D02.05706@mta1> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 23 Feb 2000 10:59:14 +0800 (CST), >>>>> lonelyforever@263.net said: > Have you ever encountered some problem like this: > we have two machines directly connected. > both of the boxes use the kernel 2.2.13. > Strange thing happens here. > Sometimes they disconnected.But after one of the machines reboot, > they worked all right until the next day --- they broke again !! > something like > AT ONCE ONE DAY > reboot--------work---------reboot--work-- ..... //faint > Do you have any good ideas? First of all, please tell us your platform more precisely (which OS, which version, which architecture...). I guess your OS is linux, but it is not clear from the above text. Secondly, this list would not be suitable for such an implemetation-specific question (I'm not even sure if your question is really related to IPv6). Better places would be - IPv6 users mailing list: users@ipv6.org - Implementation specific mailing list (if any) 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 Feb 23 09:48:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NHjtk18648 for ipng-dist; Wed, 23 Feb 2000 09:45:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NHji018641 for ; Wed, 23 Feb 2000 09:45:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA23499 for ; Wed, 23 Feb 2000 09:45:43 -0800 (PST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05597 for ; Wed, 23 Feb 2000 09:45:42 -0800 (PST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id CAA15581; Thu, 24 Feb 2000 02:38:49 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id CAA03351; Thu, 24 Feb 2000 02:38:49 +0900 (JST) Received: from localhost (ppp130.isl.rdc.toshiba.co.jp [133.196.10.130]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id CAA19435; Thu, 24 Feb 2000 02:38:46 +0900 (JST) Date: Thu, 24 Feb 2000 02:41:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: RE: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Tue, 22 Feb 2000 22:50:43 -0800" <4D0A23B3F74DD111ACCD00805F31D8101CA21C10@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA21C10@RED-MSG-50> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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, 22 Feb 2000 22:50:43 -0800, >>>>> Richard Draves said: >> If sa >> points to a sockaddr_in6 structure for an IPv6 global address with >> a non-zero value of the sin6_scope_id field, getnameinfo() simply >> ignores the sin6_scope_id field and just returns the numeric form >> of the global address. > I would prefer if sin6_scope_id is stringified independently of the address. > (Or if the scope-id is translated to a non-numeric scope-id name, then do > that for link-local & site-local addresses but otherwise treat the scope-id > & address as opaque.) It's simpler and more open to future evolution. I see. Since we let getaddrinfo() treat scope-id and adress as opaque, it would be natural to apply the same rule to getnameinfo(). If no one opposes this, I'll revise the text. (Sorry for revising so soon...) 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 Feb 23 09:48:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NHjgX18639 for ipng-dist; Wed, 23 Feb 2000 09:45:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NHjW018632 for ; Wed, 23 Feb 2000 09:45:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20658 for ; Wed, 23 Feb 2000 09:45:31 -0800 (PST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24597 for ; Wed, 23 Feb 2000 10:45:30 -0700 (MST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id CAA15577; Thu, 24 Feb 2000 02:38:35 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id CAA03347; Thu, 24 Feb 2000 02:38:35 +0900 (JST) Received: from localhost (ppp130.isl.rdc.toshiba.co.jp [133.196.10.130]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id CAA19429; Thu, 24 Feb 2000 02:38:33 +0900 (JST) Date: Thu, 24 Feb 2000 02:41:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Tue, 22 Feb 2000 13:27:06 -0500" <200002221827.NAA0000003253@quarry.zk3.dec.com> References: <200002221827.NAA0000003253@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 22 Feb 2000 13:27:06 -0500, >>>>> Jim Bound said: > Changed subject so I can identify this mail as different for me. > I am fine with the attached and the referencing of your draft that is > much wiser. So I will use this text for 1st draft of 2553bis as we > evolve. Thanks. Since some clarifications are still necessary (as you see in this list), I'll revise the text a bit and post it again. Sorry for bothering you, but I'll try to do that as soon 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 Wed Feb 23 09:49:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NHlmK18657 for ipng-dist; Wed, 23 Feb 2000 09:47:48 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NHlf018650 for ; Wed, 23 Feb 2000 09:47:42 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA06365 for ipng@sunroof.eng.sun.com; Wed, 23 Feb 2000 09:46:05 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NEGU018173 for ; Wed, 23 Feb 2000 06:16:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA13332 for ; Wed, 23 Feb 2000 06:16:30 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15584 for ; Wed, 23 Feb 2000 06:16:30 -0800 (PST) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id C796C673; Wed, 23 Feb 2000 09:16:29 -0500 (EST) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BAF094DE for ; Wed, 23 Feb 2000 09:16:29 -0500 (EST) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Feb 2000 09:16:28 -0500 Message-ID: From: "Powell, Ken" To: "'ipng@sunroof.eng.sun.com'" Subject: RFC 2462: Possible Denial of Service Attack Date: Wed, 23 Feb 2000 09:15:23 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I recently ran some experiments in our lab to see how our IPv6 implementation responds to sudden network topology changes. In the course of these experiments, I caused the prefix from one LAN (LAN A) to be advertised on the other LAN (LAN B). As expected, all communications between LAN A and LAN B died immediately. The hosts on LAN B treated the hosts on LAN A as on-link. I could not restore communications until both the preferred and valid LAN A prefix lifetimes expired on LAN B's host systems. I was able to force the preferred lifetime to zero by reconfiguring a router to send advertisements with near-zero lifetimes, but the valid lifetime couldn't be reduced below two hours. This behavior follows RFC 2462 section 5.5.3: 1) If the received Lifetime is greater than 2 hours or greater than StoredLifetime, update the stored Lifetime of the corresponding address. 2) If the StoredLifetime is less than or equal to 2 hours and the received Lifetime is less than or equal to StoredLifetime, ignore the prefix, unless the Router Advertisement from which this Prefix Information option was obtained has been authenticated (e.g., via IPSec [RFC2402]). If the Router Advertisement was authenticated, the StoredLifetime should be set to the Lifetime in the received option. 3) Otherwise, reset the stored Lifetime in the corresponding address to two hours. Obviously I could easily reset IPv6 on each of the three hosts in our lab to clear this problem. I'm concerned about something like this happening on a corporate network where LAN B has hundreds of client nodes connected to servers that reside on LAN A. Assuming nobody bothered to configure ipsec on the network yet, a malicious attacker could disrupt all the clients by sending a router advertisement on LAN B with LAN A's prefix. I know of nothing a network administrator can do to recover in less than two hours short of resetting IPv6 on each of the client systems (probably with reboots). The above rules from RFC 2462 were intended to block a denial of service attack where a single router advertisement could be used to cause all prefixes to expire. It looks like these same rules make the attack I outlined more effective than it otherwise would be. Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 23 09:52:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NHpmj18729 for ipng-dist; Wed, 23 Feb 2000 09:51:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NHpW018710 for ; Wed, 23 Feb 2000 09:51:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09647 for ; Wed, 23 Feb 2000 09:51:31 -0800 (PST) Received: from ziggy.stardust.com (ns.stardust.com [205.184.205.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28068 for ; Wed, 23 Feb 2000 10:51:32 -0700 (MST) Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA14143 for ; Wed, 23 Feb 2000 09:49:59 -0800 Message-Id: <3.0.5.32.20000223094925.00a39470@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 23 Feb 2000 09:49:25 -0800 To: ipng@sunroof.eng.sun.com From: Marty Bickford Subject: Global IPv6 Summit: Cisco's CTO to Keynote Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e1NHpX018711 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Folks, Please pardon this announcement, but I hope you can all attend the summit. ------------------ Global IPv6 Summit - http://www.stardust.com/ipv6summit/ ------------------ When: March 13-16 Where: Telluride, Colorado USA Judy Estrin, Cisco's CTO is the opening keynote for the Global IPv6 Summit. The Global IPv6 Summit is the industry's gathering on IPv6 adoption, innovation and opportunity. The conference, workshops and IPv6 Forum meetings are March 13-16, 2000 in the beautiful resort town of Telluride, Colorado USA at the conference center in Mountain Village. In this intimate setting (space is limited to 200 people) you will be able to pose questions and debate with the leaders in this technology. Register today for only $895 at http://www.stardust.com/ipv6summit/ At the summit we will focus on the deployments of IPv6 around the world, explore why wireless and home networking technology demands IPv6, and examine how IPv6 is presenting opportunities for application vendors, service providers, content providers and enterprise network engineers. Sessions will focus on ---------------------- - The Coming Tidal Wave of Applications - The Industry's Roadmap - "IPv6-Ready" Platforms and Routers - IPv6 Around the World - ISP Commercial Deployment - IPv6 Customers - IPv6 Standards - IPv6 Forum Meetings Who should attend? We expect the mix of summit attendees to include CEO's, CIO's, CTO's, network engineers, architects, developers, scientists, researchers, network managers and others who are responsible for networks and network technology. Attendance is limited to 200 people. Featured Keynote ---------------- The New Internet presented by Judy Estrin, CTO of Cisco Systems The promise of the New Internet is communications ubiquity; our appliances, networks, electronic equipment, cars and even clothes will communicate with us and with each other. But IPv6 is required for us to realize the full potential of the global network. Judy Estrin is Chief Technology Officer and Senior Vice President at Cisco Systems. She is responsible for strategic technology planning and business development including investments and acquisitions, consulting engineering and advanced Internet projects, as well as legal and government affairs. Speakers will Represent ----------------------- @Home, 3Com, Advanced Systems Consulting, Cisco Systems, Compaq, Ericsson-Telebit, InfiniBand Trade Association, Internet-Standard.com, MCI WorldCom, Microsoft, NetworkWorld, Nokia, Nortel Networks, NTT, Sun, Telia, Thomson-CSF, UCAID, UMTS Forum, UNAM, US Navy, and Viagénie. Sponsors -------- The Global IPv6 Summit is graciously sponsored by 3Com, Cisco, Compaq, Microsoft, Motorola, Nokia, Nortel Networks, Qwest, Sun Microsystems and Teleglobe. Viagénie is sponsoring a free IPv6 tutorial on March 13th for registered summit attendees. Please email me or call with any questions at (408)879-8080. Thanks, Marty --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.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 Feb 23 10:17:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NIEIQ18828 for ipng-dist; Wed, 23 Feb 2000 10:14:18 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NIE9018821 for ; Wed, 23 Feb 2000 10:14:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA15389 for ; Wed, 23 Feb 2000 10:14:07 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21226 for ; Wed, 23 Feb 2000 10:14:07 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA01951; Wed, 23 Feb 2000 10:14:02 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200001290148.UAA0000019317@quarry.zk3.dec.com> References: <200001290148.UAA0000019317@quarry.zk3.dec.com> Date: Wed, 23 Feb 2000 10:15:52 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Re: Use of IP6.INT Cc: Bob Hinden Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Based on the email exchange a couple weeks ago, regarding placing the new bitstring-based reverse DNS lookup tree under .arpa instead of .int, we appear to have rough consensus that such a change would create no technical problems and negligible deployment or operational impact at this point. Therefore, the chairs propose to tell the IAB and IESG that we are willing to make such a change in draft-ietf-ipngwg-dns-lookups-nn.txt, if they request it. If there are any previously unvoiced (un-emailed?) objections to doing that, please speak up *now*. By the way, of the two proposed suffixes (.ip6.arpa or .in6-addr.arpa), are there any good reasons to prefer one over the other? 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 Wed Feb 23 10:27:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NIP4Q18887 for ipng-dist; Wed, 23 Feb 2000 10:25:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NIOu018880 for ; Wed, 23 Feb 2000 10:24:56 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA02036 for ; Wed, 23 Feb 2000 10:24:55 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27429 for ; Wed, 23 Feb 2000 10:24:54 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA24680; Wed, 23 Feb 2000 13:21:37 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA33104; Wed, 23 Feb 2000 13:21:40 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id NAA01924; Wed, 23 Feb 2000 13:20:22 -0500 Message-Id: <200002231820.NAA01924@rotala.raleigh.ibm.com> To: Steve Deering cc: ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: Use of IP6.INT In-Reply-To: Message from Steve Deering of "Wed, 23 Feb 2000 10:15:52 PST." Date: Wed, 23 Feb 2000 13:20:22 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > By the way, of the two proposed suffixes (.ip6.arpa or .in6-addr.arpa), > are there any good reasons to prefer one over the other? the former is 5 less bytes. Consider all the bandwidth we'll be saving for future generations. :-) 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 Wed Feb 23 11:09:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NJ7Cn18957 for ipng-dist; Wed, 23 Feb 2000 11:07:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NJ71018950 for ; Wed, 23 Feb 2000 11:07:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA27737 for ; Wed, 23 Feb 2000 11:07:00 -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 LAA21462 for ; Wed, 23 Feb 2000 11:07:00 -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 NAA06828; Wed, 23 Feb 2000 13:06:44 -0600 (CST) Message-Id: <200002231906.NAA06828@gungnir.fnal.gov> To: "Powell, Ken" Cc: "'ipng@sunroof.eng.sun.com'" From: "Matt Crawford" Subject: Re: RFC 2462: Possible Denial of Service Attack In-reply-to: Your message of Wed, 23 Feb 2000 09:15:23 EST. Date: Wed, 23 Feb 2000 13:06:44 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I know of nothing a network administrator can do to recover in > less than two hours short of resetting IPv6 on each of the > client systems (probably with reboots). You could mitigate the damage by having your routers provide proxy neighbor discovery service for the other prefixes. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 23 13:59:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1NLuiq19188 for ipng-dist; Wed, 23 Feb 2000 13:56:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1NLuX019181 for ; Wed, 23 Feb 2000 13:56:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA14869 for ; Wed, 23 Feb 2000 13:56:31 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20255 for ; Wed, 23 Feb 2000 14:56:31 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA08169; Wed, 23 Feb 2000 15:43:10 -0600 (CST) Message-Id: <200002232143.PAA08169@gungnir.fnal.gov> To: Steve Deering Cc: ipng@sunroof.eng.sun.com, Bob Hinden From: "Matt Crawford" Subject: Re: Use of IP6.INT In-reply-to: Your message of Wed, 23 Feb 2000 10:15:52 PST. Date: Wed, 23 Feb 2000 15:43:10 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > By the way, of the two proposed suffixes (.ip6.arpa or .in6-addr.arpa), > are there any good reasons to prefer one over the other? If it's not decided before I'm done with the current rev. of the document, I'll just leave the placeholder domain ... damn-the-bit-misers-full-speed-ahead.arpa -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 24 00:59:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1O8uUZ19690 for ipng-dist; Thu, 24 Feb 2000 00:56:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1O8uL019683 for ; Thu, 24 Feb 2000 00:56:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA02187 for ; Thu, 24 Feb 2000 00:56:21 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09879 for ; Thu, 24 Feb 2000 01:56:21 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id JAA20033; Thu, 24 Feb 2000 09:48:40 +0100 (MET) Date: Thu, 24 Feb 2000 09:48:40 +0100 From: Ignatios Souvatzis To: Steve Deering Cc: ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: Use of IP6.INT Message-ID: <20000224094840.A19979@theory.cs.uni-bonn.de> References: <200001290148.UAA0000019317@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from deering@cisco.com on Wed, Feb 23, 2000 at 10:15:52AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Feb 23, 2000 at 10:15:52AM -0800, Steve Deering wrote: > By the way, of the two proposed suffixes (.ip6.arpa or .in6-addr.arpa), > are there any good reasons to prefer one over the other? ip6.arpa, please. Sometimes you just need to type this in manually. Regards, -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 24 02:07:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1OA5IM19760 for ipng-dist; Thu, 24 Feb 2000 02:05:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1OA58019753 for ; Thu, 24 Feb 2000 02:05:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA14453 for ; Thu, 24 Feb 2000 02:05:06 -0800 (PST) Received: from lycoris.hoshino.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09810 for ; Thu, 24 Feb 2000 02:05:02 -0800 (PST) Received: from localhost (localhost.tahi.org [127.0.0.1]) by lycoris.hoshino.tahi.org (8.8.8/8.8.8) with ESMTP id TAA17137 for ; Thu, 24 Feb 2000 19:05:01 +0900 (JST) (envelope-from hoshino@tahi.org) To: ipng@sunroof.eng.sun.com Subject: TAHI IPv6/IPsec conformance test suites and reports From: Hiroshi_Hoshino@yokogawa.co.jp X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000224190501I.hoshino@tahi.org> Date: Thu, 24 Feb 2000 19:05:01 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ##This is a resend mail. (my mail may be lost in space...) Hi there, TAHI Project has opened the IPv6/IPsec conformance test suites and test reports about KAME IPv6/IPsec network code (http://www.kame.net/) at the following web site: http://www.tahi.org/release/ : test suites http://www.tahi.org/report/ : test reports about KAME Changes from the previous release of the IPv6 conformance test suites: The Test Tool (Release-0.6): - new kernel patch - Ported : FreeBSD 3.4 - bug fix The Test Program (Release-0.6): - IPSec AH and ESP for IPv6 : New !! - IPv6 over IPv4 Tunnel : New !! The following test report done with the test sutes are opened: - kame-20000214-freebsd228-stable ---- TAHI Project http://www.tahi.org/ contact@tahi.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 24 09:34:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1OHWEI19985 for ipng-dist; Thu, 24 Feb 2000 09:32:14 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1OHW9019978 for ; Thu, 24 Feb 2000 09:32:10 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA07676 for ipng@sunroof.eng.sun.com; Thu, 24 Feb 2000 09:30:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1O6sl019596 for ; Wed, 23 Feb 2000 22:54:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA00361 for ; Wed, 23 Feb 2000 22:54:45 -0800 (PST) Received: from lycoris.hoshino.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA14896 for ; Wed, 23 Feb 2000 22:54:45 -0800 (PST) Received: from localhost (localhost.tahi.org [127.0.0.1]) by lycoris.hoshino.tahi.org (8.8.8/8.8.8) with ESMTP id PAA16850 for ; Thu, 24 Feb 2000 15:54:44 +0900 (JST) (envelope-from hoshino@tahi.org) To: ipng@sunroof.eng.sun.com Subject: TAHI IPv6/IPsec conformance test suites and reports From: contact@tahi.org X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000224155443N.hoshino@tahi.org> Date: Thu, 24 Feb 2000 15:54:43 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, TAHI Project has opened the IPv6/IPsec conformance test suites and test reports about KAME IPv6/IPsec network code (http://www.kame.net/) at the following web site: http://www.tahi.org/release/ : test suites http://www.tahi.org/report/ : test reports about KAME Changes from the previous release of the IPv6 conformance test suites: The Test Tool (Release-0.6): - new kernel patch - Ported : FreeBSD 3.4 - bug fix The Test Program (Release-0.6): - IPSec AH and ESP for IPv6 : New !! - IPv6 over IPv4 Tunnel : New !! The following test report done with the test sutes are opened: - kame-20000214-freebsd228-stable ---- TAHI 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 Thu Feb 24 09:59:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1OHvLI20027 for ipng-dist; Thu, 24 Feb 2000 09:57:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1OHvC020020 for ; Thu, 24 Feb 2000 09:57:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA26876 for ; Thu, 24 Feb 2000 09:57:11 -0800 (PST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23342 for ; Thu, 24 Feb 2000 09:57:07 -0800 (PST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id CAA00493; Fri, 25 Feb 2000 02:50:10 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id CAA13560; Fri, 25 Feb 2000 02:50:10 +0900 (JST) Received: from localhost (ppp130.isl.rdc.toshiba.co.jp [133.196.10.130]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id CAA27600; Fri, 25 Feb 2000 02:50:08 +0900 (JST) Date: Fri, 25 Feb 2000 02:50:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: RE: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Thu, 24 Feb 2000 02:41:28 +0900" References: <4D0A23B3F74DD111ACCD00805F31D8101CA21C10@RED-MSG-50> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 24 Feb 2000 02:41:28 +0900, >>>>> JINMEI Tatuya said: >>> If sa >>> points to a sockaddr_in6 structure for an IPv6 global address with >>> a non-zero value of the sin6_scope_id field, getnameinfo() simply >>> ignores the sin6_scope_id field and just returns the numeric form >>> of the global address. >> I would prefer if sin6_scope_id is stringified independently of the address. >> (Or if the scope-id is translated to a non-numeric scope-id name, then do >> that for link-local & site-local addresses but otherwise treat the scope-id >> & address as opaque.) It's simpler and more open to future evolution. > I see. Since we let getaddrinfo() treat scope-id and adress as opaque, > it would be natural to apply the same rule to getnameinfo(). > If no one opposes this, I'll revise the text. (Sorry for revising so > soon...) Since I've seen no objection, I'd like to revise the text for getnameinfo() according to the Rich's suggestion. Please use the following instead of one I posted before. I'd apologize for the change in a short period. Thanks, === text start ===== Moreover, if the sin6_scope_id field of the structure has a non-zero value, the returned numeric form should be in the extended format, that is, the address is followed by a scope identifier according to the value of the sin6_scope_id field with the delimiter character. The scope identifier is either the numeric number of the sin6_scope_id field or an implementation specific string (e.g. an interface name) of the sin6_scope_id field. Note that this translation is applied to IPv6 global addresses as well, although the result would be semantically invalid. === text end ===== JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 24 10:06:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1OI4Ar20072 for ipng-dist; Thu, 24 Feb 2000 10:04:10 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1OI3w020065 for ; Thu, 24 Feb 2000 10:03:58 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA07715 for ipng@sunroof.eng.sun.com; Thu, 24 Feb 2000 10:02:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1OFoI019908 for ; Thu, 24 Feb 2000 07:50:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28185 for ; Thu, 24 Feb 2000 07:50:18 -0800 (PST) Received: from calypso.urec.cnrs.fr (calypso.urec.cnrs.fr [194.57.137.114]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02489 for ; Thu, 24 Feb 2000 08:50:16 -0700 (MST) Received: from urec.cnrs.fr (IDENT:root@calypso [194.57.137.114]) by calypso.urec.cnrs.fr (8.9.3/jtpda-5.3.1) with ESMTP id QAA11428 for ipng@sunroof.eng.sun.com; Thu, 24 Feb 2000 16:50:10 +0100 Message-Id: <200002241550.QAA11428@calypso.urec.cnrs.fr> Date: Thu, 24 Feb 2000 16:50:10 +0100 Subject: Re: Use of IP6.INT MIME-Version: 1.0 X-Mailer: IMHO for Roxen Content-Transfer-Encoding: 8bit To: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset=iso-8859-1 From: Bernard Tuy Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ====BT: I support the same choice for the same reason. +B.Tuy. --- | On Wed, Feb 23, 2000 at 10:15:52AM -0800, Steve Deering wrote: | > By the way, of the two proposed suffixes (.ip6.arpa or .in6-addr.arpa), | > are there any good reasons to prefer one over the other? | | ip6.arpa, please. Sometimes you just need to type this in manually. | | Regards, | -is | -- | * Progress (n.): The process through which Usenet has evolved from | smart people in front of dumb terminals to dumb people in front of | smart terminals. -- obs@burnout.demon.co.uk (obscurity) | -------------------------------------------------------------------- | IETF IPng Working Group Mailing List | IPng Home Page: http://playground.sun.com/ipng | FTP archive: ftp://playground.sun.com/pub/ipng | Direct all administrative requests to majordomo@sunroof.eng.sun.com | -------------------------------------------------------------------- | A bientôt, +Bernard Tuy. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 25 05:20:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PDIE021118 for ipng-dist; Fri, 25 Feb 2000 05:18:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PDI5021111 for ; Fri, 25 Feb 2000 05:18:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA01906 for ; Fri, 25 Feb 2000 05:18:04 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06844 for ; Fri, 25 Feb 2000 05:18:03 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id DBBC25C3; Fri, 25 Feb 2000 08:18:02 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id B0631609; Fri, 25 Feb 2000 08:18:02 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id IAA0000014271; Fri, 25 Feb 2000 08:18:01 -0500 (EST) From: Jim Bound Message-Id: <200002251318.IAA0000014271@yquarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Fri, 25 Feb 2000 02:50:04 +0900." Date: Fri, 25 Feb 2000 08:18:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI, >Since I've seen no objection, I'd like to revise the text for >getnameinfo() according to the Rich's suggestion. Please use the >following instead of one I posted before. I'd apologize for the >change in a short period. Its only been two days. I need to see some consensus or silence on this for a few more days. Folks could be offline that I need to be sure have seen this change. So far only Richard has sent mail and you agreed. Not enough for me. Moreover, if the sin6_scope_id field of the structure has a non-zero value, the returned numeric form should be in the extended format, that is, the address is followed by a scope identifier according to the value of the sin6_scope_id field with the delimiter character. The scope identifier is either the numeric number of the sin6_scope_id field or an implementation specific string (e.g. an interface name) of the sin6_scope_id field. Note that this translation is applied to IPv6 global addresses as well, although the result would be semantically invalid. Are you saying here and elsewhere that the ai_addr value will be more than IPv6 address? If so I think I disagree. /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 Feb 25 05:33:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PDVcf21147 for ipng-dist; Fri, 25 Feb 2000 05:31:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PDVT021140 for ; Fri, 25 Feb 2000 05:31:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA00168 for ; Fri, 25 Feb 2000 05:31:30 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13212 for ; Fri, 25 Feb 2000 05:31:29 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id 072A19A8C5; Fri, 25 Feb 2000 07:31:29 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id 016C190D83; Fri, 25 Feb 2000 07:31:28 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id E4FF44FB09; Fri, 25 Feb 2000 07:31:21 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 80E644C901; Fri, 25 Feb 2000 07:31:21 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id IAA0000016827; Fri, 25 Feb 2000 08:31:27 -0500 (EST) From: Jim Bound Message-Id: <200002251331.IAA0000016827@yquarry.zk3.dec.com> To: Jim Bound Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Fri, 25 Feb 2000 08:18:01 EST." <200002251318.IAA0000014271@yquarry.zk3.dec.com> Date: Fri, 25 Feb 2000 08:31:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk whoops I mean't sin6_addr? /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 Feb 25 08:54:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PGpgm21223 for ipng-dist; Fri, 25 Feb 2000 08:51:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PGpX021216 for ; Fri, 25 Feb 2000 08:51:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12637 for ; Fri, 25 Feb 2000 08:51:33 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12133 for ; Fri, 25 Feb 2000 09:51:31 -0700 (MST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 4B2A8200; Fri, 25 Feb 2000 11:51:31 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id DD111269; Fri, 25 Feb 2000 11:51:30 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000025995; Fri, 25 Feb 2000 11:51:29 -0500 (EST) From: Jim Bound Message-Id: <200002251651.LAA0000025995@yquarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Fri, 25 Feb 2000 02:50:04 +0900." Date: Fri, 25 Feb 2000 11:51:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI, Here is my issue. I incorrectly thought you were applying this to AI_NUMERIC too and sorry for that I was working on the API draft and renumbered the sections in my formatter by mistake. Thats why I thought you were doing this for getaddrinfo. Have to just look at 2553 now. But. Applications that do not understand scopes nor care should not get back scope+address. I think if one wants this behavior we need another flag? Another option is to specify if a "name" is not found then don't return the address and go use getaddrinfo? /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 Feb 25 09:11:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PH8Or21255 for ipng-dist; Fri, 25 Feb 2000 09:08:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PH8F021248 for ; Fri, 25 Feb 2000 09:08:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA17022 for ; Fri, 25 Feb 2000 09:08:15 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07538 for ; Fri, 25 Feb 2000 09:08:12 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id C879C57941; Fri, 25 Feb 2000 11:08:07 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id C608C54601 for ; Fri, 25 Feb 2000 11:08:07 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id BE5CA4FB08; Fri, 25 Feb 2000 11:08:00 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 751EA4C902 for ; Fri, 25 Feb 2000 11:08:00 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000000340; Fri, 25 Feb 2000 12:08:06 -0500 (EST) From: Jim Bound Message-Id: <200002251708.MAA0000000340@yquarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: Site Identifiers and IPv6 Multisited Applications Nodes Date: Fri, 25 Feb 2000 12:08:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, In rfc2373.txt 2.1 Addressing Model IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node. It is wise to permit the last sentence and many network application in fact to identify a node or connection by its address. Like DNS and DHCP. Do we realize what we have done here? We are telling applications that exist on a multisited node that it must replicate the data for a site like in 2face DNS or change their application to be site-aware for the database key lookup. I am not convinced that the application vendors who are ISVs are going to be too happy about this or the vendors who ship network apps like DNS and DHCP. I think we need to poll applications vendors and get their reading on what we have done here. It may be too painful for them and the market. Comments? 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 Feb 25 09:22:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PHJbd21280 for ipng-dist; Fri, 25 Feb 2000 09:19:37 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PHJS021273 for ; Fri, 25 Feb 2000 09:19:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA23969 for ; Fri, 25 Feb 2000 09:19:28 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29650 for ; Fri, 25 Feb 2000 10:19:26 -0700 (MST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id 5F5D99A8DE; Fri, 25 Feb 2000 11:19:26 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id 59F2B90D86 for ; Fri, 25 Feb 2000 11:19:26 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 4B9DA4FB08; Fri, 25 Feb 2000 11:19:19 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id ECBFA4C901 for ; Fri, 25 Feb 2000 11:19:18 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000002007; Fri, 25 Feb 2000 12:19:25 -0500 (EST) From: Jim Bound Message-Id: <200002251719.MAA0000002007@yquarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: Another way to support Site-Local Addresses Date: Fri, 25 Feb 2000 12:19:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is anyone interested in working on such a draft as below with me. We don't have to have it ready until IETF 48 in Pittsburgh so we have time to work on it. Objective of the Draft: Using Kre's archtype model that we can embed site-identifiers in IPv6 addresses we develop a draft that proposes to use 2bytes of the IPv6 adddres (could use 1byte if we believe sites will not be greater than 256) which would heuristically determine based on net admin org/site administrator what the site identifier would be based on the adddress. Rules to try and achieve: 1. Site-Local addresses are to contain a site-identifier which is unique across all sites of an organization. 2. Orgs cannot connect a new site from mergers or the like to the existing site "set" without first renumbering those site addresses. Benefits of working on this draft: 1. Simplify the concept of site-identifier for IPv6 Addresses so it is inherent in the address of an interface. We should follow the rules specified in draft-ietf-ipngwg-scoped-routing-02.txt by Brian Haberman. 2. Permits what we know now as Multisited nodes to not have to replicate data or other identifiers for sitelocal addresses the site-identifier part would be unique across an Organization. I am here assuming site is below organization as an abstraction. 3. Applications for IPv6 do not have to be affected by sitelocal addresses. This part stays transparent to IPv6 at least. 4. getipnodebyname is not dead and we do not need to parse site-identifiers on command lines or in our APIs. Clearly though we move to recommend to use getaddrinfo for other benefits. I can't do this by myself and am looking for co-authors. I think it imperative we do this work and present it as an alternative to the current direction to resolve this within the IETF. p.s. Kre - Love to have you help us with this if you still think its a good idea? 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 Feb 25 09:51:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PHmTh21337 for ipng-dist; Fri, 25 Feb 2000 09:48:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PHmJ021330 for ; Fri, 25 Feb 2000 09:48:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA24073 for ; Fri, 25 Feb 2000 09:48:19 -0800 (PST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07486 for ; Fri, 25 Feb 2000 09:48:17 -0800 (PST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id CAA14642; Sat, 26 Feb 2000 02:41:18 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id CAA23095; Sat, 26 Feb 2000 02:41:18 +0900 (JST) Received: from localhost (ppp131.isl.rdc.toshiba.co.jp [133.196.10.131]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id CAA03349; Sat, 26 Feb 2000 02:41:15 +0900 (JST) Date: Sat, 26 Feb 2000 02:31:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Fri, 25 Feb 2000 08:18:01 -0500" <200002251318.IAA0000014271@yquarry.zk3.dec.com> References: <200002251318.IAA0000014271@yquarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 60 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 25 Feb 2000 08:18:01 -0500, >>>>> Jim Bound said: >> Since I've seen no objection, I'd like to revise the text for >> getnameinfo() according to the Rich's suggestion. Please use the >> following instead of one I posted before. I'd apologize for the >> change in a short period. > Its only been two days. I need to see some consensus or silence on this > for a few more days. Folks could be offline that I need to be sure have > seen this change. So far only Richard has sent mail and you agreed. > Not enough for me. > Moreover, if the sin6_scope_id field of the structure has a > non-zero value, the returned numeric form should be in the extended > format, that is, the address is followed by a scope identifier > according to the value of the sin6_scope_id field with the > delimiter character. The scope identifier is either the numeric > number of the sin6_scope_id field or an implementation specific > string (e.g. an interface name) of the sin6_scope_id field. Note > that this translation is applied to IPv6 global addresses as well, > although the result would be semantically invalid. > Are you saying here and elsewhere that the ai_addr value will be more > than IPv6 address? If so I think I disagree. Sorry for the lack of context, but I meant the above text was applied only to returned values of getnameinfo(), that is, a string. For example, the followings are the intention of the above text: struct sockaddr_in6 sa6; sa6.sin6_addr = inet_pton("2001::1"); /* just for an example */ sa6.sin6_scope_id = 100; /* I'm not sure if 100 is valid. */ getnameinfo(&sa6, buf); /* this is a conceptual usage of getaddrinfo(). */ printf("%s\n", buf); The result should be: 2001::1%100 In the previous text, the return value of getnameinfo() would be: 2001;:1 i.e it should ignore the scope_id part. Rich's suggestion was that getnameinfo() should treat the sin6_scope_id field just as opaque, which I agreed. I didn't intend any changes of the semantics of ai_addr. ====== In any case, I didn't mean that we got a consensus with silence only in a few days. If anyone would oppose the change, I'd like to listen to the opinion, and would obey the final result. I sent the revised text just for convenience of further edition and discussion. I'd apologize in advance if it was complacent. 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 Feb 25 15:18:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PNGOn21709 for ipng-dist; Fri, 25 Feb 2000 15:16:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PNGG021702 for ; Fri, 25 Feb 2000 15:16:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA07686 for ; Fri, 25 Feb 2000 15:16:17 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA16133 for ; Fri, 25 Feb 2000 16:15:56 -0700 (MST) 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 XA08411; Sat, 26 Feb 2000 10:07:03 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-Reply-To: Your message of "Fri, 25 Feb 2000 12:08:06 CDT." <200002251708.MAA0000000340@yquarry.zk3.dec.com> Date: Sat, 26 Feb 2000 10:06:57 +1100 Message-Id: <21811.951520017@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 25 Feb 2000 12:08:06 -0500 From: Jim Bound Message-ID: <200002251708.MAA0000000340@yquarry.zk3.dec.com> | 2.1 Addressing Model | | IPv6 addresses of all types are assigned to interfaces, not nodes. | An IPv6 unicast address refers to a single interface. Since each | interface belongs to a single node, any of that node's interfaces' | unicast addresses may be used as an identifier for the node. | | It is wise to permit the last sentence and many network application in | fact to identify a node or connection by its address. Like DNS and | DHCP. | | Do we realize what we have done here? Jim, maybe you could explain what you'e seeing as a problem there, because at the minute, I just don't see it? To me this just looks like the current practice with IPv4 addresses (when you need to identify a node, pick one of its addresses). Or is the problem that a link-local or site-local address might qualify as "any of the node's interfaces' unicast addresses" ? That I suspect might lead to some problems - perhaps a few extra words requiring an address of the widest scope available on the host? 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 Feb 25 16:26:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1Q0MEv21754 for ipng-dist; Fri, 25 Feb 2000 16:22:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1Q0M6021747 for ; Fri, 25 Feb 2000 16:22:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA29324 for ; Fri, 25 Feb 2000 16:22:05 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23289 for ; Fri, 25 Feb 2000 16:22:05 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 367934F9; Fri, 25 Feb 2000 19:22:05 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 16868630; Fri, 25 Feb 2000 19:22:05 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id TAA0000007618; Fri, 25 Feb 2000 19:22:04 -0500 (EST) From: Jim Bound Message-Id: <200002260022.TAA0000007618@yquarry.zk3.dec.com> To: Robert Elz Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-reply-to: Your message of "Sat, 26 Feb 2000 10:06:57 +1100." <21811.951520017@munnari.OZ.AU> Date: Fri, 25 Feb 2000 19:22:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | 2.1 Addressing Model | | IPv6 addresses of all types are assigned to interfaces, not nodes. | An IPv6 unicast address refers to a single interface. Since each | interface belongs to a single node, any of that node's interfaces' | unicast addresses may be used as an identifier for the node. | | It is wise to permit the last sentence and many network application in | fact to identify a node or connection by its address. Like DNS and | DHCP. | | Do we realize what we have done here? >Jim, maybe you could explain what you'e seeing as a problem there, >because at the minute, I just don't see it? To me this just looks >like the current practice with IPv4 addresses (when you need to >identify a node, pick one of its addresses). Or is the problem >that a link-local or site-local address might qualify as "any of the >node's interfaces' unicast addresses" ? That I suspect might lead >to some problems - perhaps a few extra words requiring an address of >the widest scope available on the host? Yes I was terse. I figured I would start there. First yes it is like IPv4 when you want to identify a node just use the address. Here I was stating the obvious (though some disagree with this). My statement "Do we realize what we have done here?" was really in reference to the site-local address and from that the need for a site identifier. Let me take a few steps back OK. A multisited sever is one which has link connections to different sites. In each of those sites we cannot be guranteed that the site-local addresses in those sites are not duplicated. Because of the above an Application like DNS or DHCP, or a NASTRAN application that distributes computational elements to nodes on multiple networks in a discrete manufacturing customer site (my company has these types of customers) identifying the nodes by addresses and within their database, in the case of IPv6 with site-local addresses for a multisited node has ramifications that must be addressed within IPv6 and does not occur with IPv4. Either the application must replicate the database, queue, whatever the state for each site link it communicates on, OR change its key to access and identify nodes (which are clients) to hold a site-identifier with the address. Ergo DNS would have to contain a site identifier with the address entry (AAAA or A6). Or as I said have to separate databases for each link (or set of links) in a site. This is a significant change to the operation for Application vendors or those who provide infrastructure with products like BIND or DHCP. So when I said "do we realize what we have done" I mean do we realize: 1. That a site-local cannot uniquely identify a node to a multisited server and this breaks what I put out from rfc2373. 2. That we have greatly affected applications that operate as I state above. This is why I think we owe IPv6 another look at embedding site-identifiers inside the IPv6 address as you suggested and this time not have a mail discussion but a real proposed draft if we (those that join me) can accomplish this task and make it work and then have it discussed by the working group. Sorry for being long winded but did that help? 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 Feb 25 17:11:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1Q18X421796 for ipng-dist; Fri, 25 Feb 2000 17:08:33 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1Q18O021789 for ; Fri, 25 Feb 2000 17:08:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA07018 for ; Fri, 25 Feb 2000 17:08:24 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA00087 for ; Fri, 25 Feb 2000 18:08:22 -0700 (MST) 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 BA20393; Sat, 26 Feb 2000 12:05:42 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-Reply-To: Your message of "Fri, 25 Feb 2000 19:22:04 CDT." <200002260022.TAA0000007618@yquarry.zk3.dec.com> Date: Sat, 26 Feb 2000 12:05:41 +1100 Message-Id: <23583.951527141@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 25 Feb 2000 19:22:04 -0500 From: Jim Bound Message-ID: <200002260022.TAA0000007618@yquarry.zk3.dec.com> | Sorry for being long winded but did that help? Well, yes, I think i understand the problem - and yes, there are some problems with site addressing that haven't been sorted out. I'm not sure that attaching the problem to that one sentence in 2373 is exactly how I would have come at it though. 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 Feb 25 20:03:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1Q40rS21877 for ipng-dist; Fri, 25 Feb 2000 20:00:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1Q40g021870 for ; Fri, 25 Feb 2000 20:00:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10970 for ; Fri, 25 Feb 2000 20:00:41 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA02732 for ; Fri, 25 Feb 2000 20:00:40 -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 MAA15505; Sat, 26 Feb 2000 12:55:56 +0900 (JST) To: Jim Bound cc: Robert Elz , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Fri, 25 Feb 2000 19:22:04 EST. <200002260022.TAA0000007618@yquarry.zk3.dec.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: Site Identifiers and IPv6 Multisited Applications Nodes From: itojun@iijlab.net Date: Sat, 26 Feb 2000 12:55:56 +0900 Message-ID: <15503.951537356@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (snip) >So when I said "do we realize what we have done" I mean do we realize: > > 1. That a site-local cannot uniquely identify a node to a multisited > server and this breaks what I put out from rfc2373. > 2. That we have greatly affected applications that operate as > I state above. > >This is why I think we owe IPv6 another look at embedding >site-identifiers inside the IPv6 address as you suggested and this time >not have a mail discussion but a real proposed draft if we (those that >join me) can accomplish this task and make it work and then have it >discussed by the working group. > >Sorry for being long winded but did that help? The above story is not special for site-local address, I believe. We already have other scoped address: link-locals. The above looks exactly the same story with link-local addresses. - a server connected to multiple links need to disambiguate links, since there can be fe80::1%link1 and fe80::1%link2 - sin6_scope_id disambiguates them Putting site identification into site-local address is one of the solution that works. I took your saying as "put site identification into DNS database, wire address format, and other things as well, is it correct? We will see packets with, say, fec0:1::abcd:efgh on ip6_dst on the wire. I think I'm okay with this, as long as routers can be configured not to forward them across different sites. (fec0:1::1 <-> fec0:2::1 should not be able to communicate directly) Another solution is to always use scoped address notation when you make a database. - distinguish sites by sin6_scope_id - DNS resolver for multi-sited server needs to be improved, so that it would fill in appropriate site identifier into sin6_scope_id. (NOTE: getipnodebyname is not useful for multi-scope boundary, as we have discussed. we need to use getaddrinfo) DNS server for site A --128bit---> resolver --128bit + site id A--> apps DNS server for site B --128bit---> resolver --128bit + site id B--> apps (AAAA, or A6) (sockaddr_in6) - applications will hold addresses in jinmei format (fec0::1%cisco) into database Since we need to solve multi-liked this way, I think solving site-local case with same way has a merit. Easiest workaround for "site-unaware servers on multi-sited node" is to run multiple servers, one for each site. This solves many of typical cases. 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 Sat Feb 26 08:43:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1QGeqR22527 for ipng-dist; Sat, 26 Feb 2000 08:40:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1QGeg022519 for ; Sat, 26 Feb 2000 08:40:43 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05600; Sat, 26 Feb 2000 08:40:42 -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 IAA14294; Sat, 26 Feb 2000 08:40:41 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA12502; Sun, 27 Feb 2000 01:31:17 +0900 (JST) Date: Sun, 27 Feb 2000 01:42:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: a tiny comment on the ip6_hdr structure (rfc2292bis) User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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 Hi, I'd like to comment on the definition of the ip6_hdr structure in rfc2292bis-01. The definition is as follows. struct ip6_hdr { union { struct ip6_hdrctl { uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 24 bits flow-ID */ uint16_t ip6_un1_plen; /* payload length */ uint8_t ip6_un1_nxt; /* next header */ uint8_t ip6_un1_hlim; /* hop limit */ } ip6_un1; uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */ } ip6_ctlun; struct in6_addr ip6_src; /* source address */ struct in6_addr ip6_dst; /* destination address */ }; But the length of the flow label field is now 20 bits, so the comment on the ip6_un1_flow member should be /* 4 bits version, 8 bits TC, 20 bits flow-ID */ Also, it might be useful to define an additional member to access the lower 4 bits of the traffic class field. 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 Feb 26 08:43:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1QGgd422536 for ipng-dist; Sat, 26 Feb 2000 08:42:39 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1QGgT022529 for ; Sat, 26 Feb 2000 08:42:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA21927 for ; Sat, 26 Feb 2000 08:42:29 -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 JAA28357 for ; Sat, 26 Feb 2000 09:42:27 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA12498; Sun, 27 Feb 2000 01:31:09 +0900 (JST) Date: Sun, 27 Feb 2000 01:42:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Fri, 25 Feb 2000 11:51:29 -0500" <200002251651.LAA0000025995@yquarry.zk3.dec.com> References: <200002251651.LAA0000025995@yquarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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 >>>>> On Fri, 25 Feb 2000 11:51:29 -0500, >>>>> Jim Bound said: > I incorrectly thought you were applying this to AI_NUMERIC too and sorry > for that I was working on the API draft and renumbered the sections in > my formatter by mistake. Thats why I thought you were doing this for > getaddrinfo. Have to just look at 2553 now. I see. > Applications that do not understand scopes nor care should not get back > scope+address. I think if one wants this behavior we need another flag? Hmm, I personally think that such applications could use inet_ntop() instead of getnameinfo() and that getnameinfo() should treat sockaddrs just as opaque. However, I don't oppose introducing an additional flag to getnameinfo(), e.g. NI_WITHOUTSCOPE. > Another option is to specify if a "name" is not found then don't return > the address and go use getaddrinfo? Sorry, I can't understand this. What do you mean by "go use getaddrinfo"? 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 Feb 26 18:18:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1R2Fcp22906 for ipng-dist; Sat, 26 Feb 2000 18:15:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1R2FT922899 for ; Sat, 26 Feb 2000 18:15:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA23357 for ; Sat, 26 Feb 2000 18:15:29 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06483 for ; Sat, 26 Feb 2000 18:15:29 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id BEA3857918; Sat, 26 Feb 2000 20:15:28 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id B750954602; Sat, 26 Feb 2000 20:15:28 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id B0015BC4E7; Sat, 26 Feb 2000 20:15:21 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 514BDB2A42; Sat, 26 Feb 2000 20:15:21 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000017893; Sat, 26 Feb 2000 21:15:23 -0500 (EST) From: Jim Bound Message-Id: <200002270215.VAA0000017893@yquarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-reply-to: Your message of "Sat, 26 Feb 2000 12:55:56 +0900." <15503.951537356@coconut.itojun.org> Date: Sat, 26 Feb 2000 21:15:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Thanks for the dialogue. A draft will be produced to embed the addresses I hope by June 2000 and maybe before. Not going to get into it now as its just an idea, and a few of us will put the energy and time into working it as engineers, and then bring it to the IETF. I speak at various functions and talk to the press about IPv6. Here is what I am recommending regarding this whole issue at this point it does not relfect my companies views or the views of the IPv6 Forum. 1. For now use caution with site-local addresses. 2. DO NOT USE LINK-LOCAL ADDRESSES for user applications their purpose is to be used by network wire control functions for node discovery in IPv6. I say lots of other stuff but these are relative to the mail response you sent. Of course there are a lot more words that go with the two sentences. /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 Sat Feb 26 18:20:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1R2JmR22924 for ipng-dist; Sat, 26 Feb 2000 18:19:48 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1R2Jc922917 for ; Sat, 26 Feb 2000 18:19:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA22736 for ; Sat, 26 Feb 2000 18:19:38 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07081 for ; Sat, 26 Feb 2000 18:19:38 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 56D9741B; Sat, 26 Feb 2000 21:19:37 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 348D677E; Sat, 26 Feb 2000 21:19:37 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000018256; Sat, 26 Feb 2000 21:19:36 -0500 (EST) From: Jim Bound Message-Id: <200002270219.VAA0000018256@yquarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-reply-to: Your message of "Sat, 26 Feb 2000 12:55:56 +0900." <15503.951537356@coconut.itojun.org> Date: Sat, 26 Feb 2000 21:19:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Also I say: ALL ISVs move to getaddrinfo/getnameinfo now. Even if we find alternative solution to scoping (as you pointed out) these APIs will support your software for the future better, because of their breadth and extended argument types. /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 Sat Feb 26 19:46:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1R3iLp22966 for ipng-dist; Sat, 26 Feb 2000 19:44:21 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1R3iA922959 for ; Sat, 26 Feb 2000 19:44:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA24875 for ; Sat, 26 Feb 2000 19:44:10 -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 UAA01144 for ; Sat, 26 Feb 2000 20:44:08 -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 MAA06483; Sun, 27 Feb 2000 12:39:00 +0900 (JST) To: Jim Bound cc: Robert Elz , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Sat, 26 Feb 2000 21:15:23 EST. <200002270215.VAA0000017893@yquarry.zk3.dec.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: Site Identifiers and IPv6 Multisited Applications Nodes From: itojun@iijlab.net Date: Sun, 27 Feb 2000 12:39:00 +0900 Message-ID: <6481.951622740@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I speak at various functions and talk to the press about IPv6. Here is >what I am recommending regarding this whole issue at this point it does >not relfect my companies views or the views of the IPv6 Forum. > >1. For now use caution with site-local addresses. > >2. DO NOT USE LINK-LOCAL ADDRESSES for user applications their purpose is to >be used by network wire control functions for node discovery in IPv6. > >I say lots of other stuff but these are relative to the mail response >you sent. Of course there are a lot more words that go with the two >sentences. I personally agree with the above two items, scoped addresses put novice users into confusion. I have been telling prople, or writing webpage, which means similar things. 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 Sat Feb 26 19:47:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1R3jsH22976 for ipng-dist; Sat, 26 Feb 2000 19:45:54 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1R3jg922969 for ; Sat, 26 Feb 2000 19:45:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA25718 for ; Sat, 26 Feb 2000 19:45:40 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA16817 for ; Sat, 26 Feb 2000 19:45:40 -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 MAA06509; Sun, 27 Feb 2000 12:40:30 +0900 (JST) To: Jim Bound cc: Robert Elz , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Sat, 26 Feb 2000 21:19:36 EST. <200002270219.VAA0000018256@yquarry.zk3.dec.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: Site Identifiers and IPv6 Multisited Applications Nodes From: itojun@iijlab.net Date: Sun, 27 Feb 2000 12:40:30 +0900 Message-ID: <6507.951622830@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >ALL ISVs move to getaddrinfo/getnameinfo now. Even if we find >alternative solution to scoping (as you pointed out) these APIs will >support your software for the future better, because of their breadth >and extended argument types. the proposal I've posted one mail ago will use getaddrinfo. anyway, it's good to hear that more people is using getaddrinfo. 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 Sat Feb 26 19:53:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1R3q3223011 for ipng-dist; Sat, 26 Feb 2000 19:52:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1R3ps923004 for ; Sat, 26 Feb 2000 19:51:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA25078 for ; Sat, 26 Feb 2000 19:51:54 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17452 for ; Sat, 26 Feb 2000 19:51:53 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 807AF57818; Sat, 26 Feb 2000 21:51:53 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 7928054603; Sat, 26 Feb 2000 21:51:53 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 8CFDEBC4E2; Sat, 26 Feb 2000 21:51:46 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 24D82B2A42; Sat, 26 Feb 2000 21:51:46 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000030482; Sat, 26 Feb 2000 22:51:52 -0500 (EST) From: Jim Bound Message-Id: <200002270351.WAA0000030482@yquarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-reply-to: Your message of "Sun, 27 Feb 2000 12:39:00 +0900." <6481.951622740@coconut.itojun.org> Date: Sat, 26 Feb 2000 22:51:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I personally agree with the above two items, scoped addresses put novice users into confusion. I have been telling prople, or writing webpage, which means similar things. Very well put. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 27 06:32:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1RETRg23256 for ipng-dist; Sun, 27 Feb 2000 06:29:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1RETG923249 for ; Sun, 27 Feb 2000 06:29:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA10711 for ; Sun, 27 Feb 2000 06:29:16 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09821 for ; Sun, 27 Feb 2000 07:29:15 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA11733; Sun, 27 Feb 2000 08:22:14 -0600 (CST) Message-Id: <200002271422.IAA11733@gungnir.fnal.gov> To: itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-reply-to: Your message of Sun, 27 Feb 2000 12:39:00 +0900. <6481.951622740@coconut.itojun.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11729.951661333.1@gungnir.fnal.gov> Date: Sun, 27 Feb 2000 08:22:14 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >2. DO NOT USE LINK-LOCAL ADDRESSES for user applications their purpose is to > >be used by network wire control functions for node discovery in IPv6. Whatever happened to our dentist? Farewell to zeroconf? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 27 12:48:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1RKkEL23399 for ipng-dist; Sun, 27 Feb 2000 12:46:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1RKk6923392 for ; Sun, 27 Feb 2000 12:46:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA22791 for ; Sun, 27 Feb 2000 12:46:05 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA00508 for ; Sun, 27 Feb 2000 13:46:04 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 27 Feb 2000 12:43:15 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Sun, 27 Feb 2000 12:43:15 -0800 Message-ID: From: Christian Huitema To: Matt Crawford , itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: RE: Site Identifiers and IPv6 Multisited Applications Nodes Date: Sun, 27 Feb 2000 12:43:14 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, just a short question. What happens if your dentist uses more than one wire, e.g. the torture chair and its equipent on 1394, the computers on 10baseT, and, hopefully, a zeroconfig IPv6 router in between? -----Original Message----- From: Matt Crawford [mailto:crawdad@fnal.gov] Sent: Sunday, February 27, 2000 6:22 AM To: itojun@iijlab.net Cc: Jim Bound; ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes > >2. DO NOT USE LINK-LOCAL ADDRESSES for user applications their purpose is to > >be used by network wire control functions for node discovery in IPv6. Whatever happened to our dentist? Farewell to zeroconf? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Feb 27 14:15:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1RMAD123454 for ipng-dist; Sun, 27 Feb 2000 14:10:13 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1RM9Y923447 for ; Sun, 27 Feb 2000 14:09:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA17925 for ; Sun, 27 Feb 2000 14:08:50 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25682 for ; Sun, 27 Feb 2000 14:08:49 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 3CB41479; Sun, 27 Feb 2000 17:08:49 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 1DF7F4DC; Sun, 27 Feb 2000 17:08:49 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000008252; Sun, 27 Feb 2000 17:08:48 -0500 (EST) From: Jim Bound Message-Id: <200002272208.RAA0000008252@yquarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Sun, 27 Feb 2000 01:42:47 +0900." Date: Sun, 27 Feb 2000 17:08:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi JINMEI, Let me step back here. getaddrinfo essentially returns an address and other stuff when you give the function a name. getnameinfo essentially returns a name from an address. The issue for getnameinfo is that if NI_NUMERICHOST is set: FROM RFC 2553: If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be located in the DNS, the numeric form of the host's address is returned instead of its name (e.g., by calling inet_ntop() instead of getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is returned if the host's name cannot be located in the DNS. If what comes back is FEC0::1%123 (meaning the address and site identifier) in char *host field. What does an application do with this string now? It can't be passed as an address to any application I am aware of running today? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 27 14:19:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1RMIIT23476 for ipng-dist; Sun, 27 Feb 2000 14:18:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1RMI9923469 for ; Sun, 27 Feb 2000 14:18:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA25181 for ; Sun, 27 Feb 2000 14:18:09 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27056 for ; Sun, 27 Feb 2000 14:18:10 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 9818757882; Sun, 27 Feb 2000 16:18:09 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 90C5754602; Sun, 27 Feb 2000 16:18:09 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 95235BC4ED; Sun, 27 Feb 2000 16:18:02 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 2CA9AB2A43; Sun, 27 Feb 2000 16:18:02 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000009614; Sun, 27 Feb 2000 17:18:08 -0500 (EST) From: Jim Bound Message-Id: <200002272218.RAA0000009614@yquarry.zk3.dec.com> To: "Matt Crawford" Cc: itojun@iijlab.net, Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-reply-to: Your message of "Sun, 27 Feb 2000 08:22:14 CST." <200002271422.IAA11733@gungnir.fnal.gov> Date: Sun, 27 Feb 2000 17:18:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >2. DO NOT USE LINK-LOCAL ADDRESSES for user applications their purpose is to >> >be used by network wire control functions for node discovery in IPv6. > >Whatever happened to our dentist? They got into the web. >Farewell to zeroconf? Different set of issues. zeroconf will still work out of the box which it its point. With caution one can use site-local addresses too. But one should really just go get a global one from ones ISP. /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 Feb 28 00:29:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1S8ROH23657 for ipng-dist; Mon, 28 Feb 2000 00:27:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1S8RF923650 for ; Mon, 28 Feb 2000 00:27:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA04168 for ; Mon, 28 Feb 2000 00:27:14 -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 AAA20607 for ; Mon, 28 Feb 2000 00:27:13 -0800 (PST) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA17025; Mon, 28 Feb 2000 17:16:15 +0900 (JST) Date: Mon, 28 Feb 2000 17:27:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Sun, 27 Feb 2000 17:08:48 -0500" <200002272208.RAA0000008252@yquarry.zk3.dec.com> References: <200002272208.RAA0000008252@yquarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 27 Feb 2000 17:08:48 -0500, >>>>> Jim Bound said: > getaddrinfo essentially returns an address and other stuff when you give > the function a name. > getnameinfo essentially returns a name from an address. > The issue for getnameinfo is that if NI_NUMERICHOST is set: > FROM RFC 2553: > If the flag bit NI_NUMERICHOST is set, or if the host's name cannot > be > located in the DNS, the numeric form of the host's address is > returned > instead of its name (e.g., by calling inet_ntop() instead of > getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is > returned if the host's name cannot be located in the DNS. > If what comes back is FEC0::1%123 (meaning the address and site > identifier) in char *host field. > What does an application do with this string now? It can't be passed as > an address to any application I am aware of running today? It can, if the applications use the extended getaddrinfo() to handle the new format for scoped addresses. I think we can assume that if we had the extended getnameinfo() then getaddrinfo() would also be extended. So the problematic case would occur in applications that do not use getaddrinfo() for hostname to address translation. It is my understanding that we would recommend applications to use getaddrinfo() in a 2553bis era, thus I don't think it does really matter. However, if we seriously care about the issue, we could introduce an additional flag (say, NI_WITHSCOPE) to getnameinfo() and disable the flag by default. What do you (and others) think? 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 Mon Feb 28 01:32:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1S9UCC23739 for ipng-dist; Mon, 28 Feb 2000 01:30:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1S9U2923732 for ; Mon, 28 Feb 2000 01:30:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA06693 for ; Mon, 28 Feb 2000 01:29:59 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27764 for ; Mon, 28 Feb 2000 02:29:59 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA12298; Mon, 28 Feb 2000 10:22:55 +0100 (MET) Date: Mon, 28 Feb 2000 10:22:54 +0100 From: Ignatios Souvatzis To: Christian Huitema Cc: Matt Crawford , itojun@iijlab.net, Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes Message-ID: <20000228102254.A12263@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from huitema@microsoft.com on Sun, Feb 27, 2000 at 12:43:14PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Feb 27, 2000 at 12:43:14PM -0800, Christian Huitema wrote: > Well, just a short question. What happens if your dentist uses more than one > wire, e.g. the torture chair and its equipent on 1394, the computers on > 10baseT, and, hopefully, a zeroconfig IPv6 router in between? In this case, link-local addresses wouldn't really help him. His router will have to detect the mutliple interfaces and assign /64 prefixes from either a global address space (if available) or the site-local space to them, and let the end nodes autoconfigure. The interesting question is, how do the devices detect each other? But thats a higher protocol layer. Regards, -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 28 07:19:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SFGR124015 for ipng-dist; Mon, 28 Feb 2000 07:16:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SFG3924008 for ; Mon, 28 Feb 2000 07:16:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA20449 for ; Mon, 28 Feb 2000 07:15:23 -0800 (PST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26139 for ; Mon, 28 Feb 2000 08:15:22 -0700 (MST) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id KAA02958; Mon, 28 Feb 2000 10:13:46 -0500 (EST) Message-Id: <200002281513.KAA02958@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Fri, 25 Feb 2000 12:19:24 EST." <200002251719.MAA0000002007@yquarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Feb 2000 10:13:46 -0500 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > Objective of the Draft: > > Using Kre's archtype model that we can embed site-identifiers in IPv6 > addresses we develop a draft that proposes to use 2bytes of the IPv6 > adddres (could use 1byte if we believe sites will not be greater than > 256) which would heuristically determine based on net admin org/site > administrator what the site identifier would be based on the adddress. > > Rules to try and achieve: > > 1. Site-Local addresses are to contain a site-identifier which is > unique across all sites of an organization. > 2. Orgs cannot connect a new site from mergers or the like to > the existing site "set" without first renumbering those site > addresses. If the goal is to add an 8-16 bit site id in the site local prefix between FEC0::/10 and FEC0::/48, then why not make it 24 bits? 32 bits? 38 bits? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 28 08:36:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SGYLC24084 for ipng-dist; Mon, 28 Feb 2000 08:34:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SGXu924077 for ; Mon, 28 Feb 2000 08:33:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA23268 for ; Mon, 28 Feb 2000 08:33:15 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04076 for ; Mon, 28 Feb 2000 08:33:15 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 601A8578A8; Mon, 28 Feb 2000 10:33:15 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 58C7854602; Mon, 28 Feb 2000 10:33:15 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 728E4BC4E6; Mon, 28 Feb 2000 10:33:08 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 0524FB2A42; Mon, 28 Feb 2000 10:33:07 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000021340; Mon, 28 Feb 2000 11:33:13 -0500 (EST) From: Jim Bound Message-Id: <200002281633.LAA0000021340@yquarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Mon, 28 Feb 2000 17:27:53 +0900." Date: Mon, 28 Feb 2000 11:33:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> If what comes back is FEC0::1%123 (meaning the address and site >> identifier) in char *host field. > >> What does an application do with this string now? It can't be passed as >> an address to any application I am aware of running today? > >It can, if the applications use the extended getaddrinfo() to handle >the new format for scoped addresses. I think we can assume that if we >had the extended getnameinfo() then getaddrinfo() would also be >extended. So the problematic case would occur in applications that do >not use getaddrinfo() for hostname to address translation. > >It is my understanding that we would recommend applications to use >getaddrinfo() in a 2553bis era, thus I don't think it does really >matter. However, if we seriously care about the issue, we could >introduce an additional flag (say, NI_WITHSCOPE) to getnameinfo() and >disable the flag by default. > >What do you (and others) think? But I am still asking another question. The programmer now has returned sitting in a string from getnamefino: FEC0::1%123 This can't be passed to any function as a dst address. What function parses the above string so: sin6_addr = FEC0::1 sin6_scope_id = 123 getaddrinfo? /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 Feb 28 09:07:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SH5iU24151 for ipng-dist; Mon, 28 Feb 2000 09:05:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SH5J924132 for ; Mon, 28 Feb 2000 09:05:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA28513 for ; Mon, 28 Feb 2000 09:04:38 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21491 for ; Mon, 28 Feb 2000 09:04:38 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 445C5104C3F; Mon, 28 Feb 2000 11:04:38 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 3C0F2FB101; Mon, 28 Feb 2000 11:04:38 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 59C67BC4E9; Mon, 28 Feb 2000 11:04:31 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id E839BB2A44; Mon, 28 Feb 2000 11:04:30 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000027203; Mon, 28 Feb 2000 12:04:36 -0500 (EST) From: Jim Bound Message-Id: <200002281704.MAA0000027203@yquarry.zk3.dec.com> To: Steve Blake Cc: ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Mon, 28 Feb 2000 10:13:46 EST." <200002281513.KAA02958@castillo.torrentnet.com> Date: Mon, 28 Feb 2000 12:04:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If the goal is to add an 8-16 bit site id in the site local prefix between >FEC0::/10 and FEC0::/48, then why not make it 24 bits? 32 bits? 38 bits? Thanks for the input we will recall this mail as we proceed. 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 Mon Feb 28 09:08:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SH7lP24172 for ipng-dist; Mon, 28 Feb 2000 09:07:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SH7I924156 for ; Mon, 28 Feb 2000 09:07:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA13567 for ; Mon, 28 Feb 2000 09:06:37 -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 KAA29052 for ; Mon, 28 Feb 2000 10:06:35 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA18904; Tue, 29 Feb 2000 01:55:41 +0900 (JST) Date: Tue, 29 Feb 2000 02:07:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Mon, 28 Feb 2000 11:33:13 -0500" <200002281633.LAA0000021340@yquarry.zk3.dec.com> References: <200002281633.LAA0000021340@yquarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 52 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, >>>>> On Mon, 28 Feb 2000 11:33:13 -0500, >>>>> Jim Bound said: >> It is my understanding that we would recommend applications to use >> getaddrinfo() in a 2553bis era, thus I don't think it does really >> matter. However, if we seriously care about the issue, we could >> introduce an additional flag (say, NI_WITHSCOPE) to getnameinfo() and >> disable the flag by default. >> >> What do you (and others) think? > But I am still asking another question. The programmer now has returned > sitting in a string from getnamefino: > FEC0::1%123 > This can't be passed to any function as a dst address. What function > parses the above string so: > sin6_addr = FEC0::1 > sin6_scope_id = 123 > getaddrinfo? Yes, it's getaddrinfo(). According to the additional text for getaddrinfo() that I posted here last week: If the nodename is a textual IPv6 scoped address with a scope identifier, getaddrinfo() sets the appropriate numeric number for the scope identifer to the sin6_scope_id field of each returned sockaddr_in6 structure. For a zero or positive numeric scope identifier, getaddrinfo() simply copies the value to the sin6_scope_id field, and lets the kernel validate the value. Conceptually, the relationship between getaddrinfo() and getnameinfo() is as the following figure: ----getaddrinfo---> fec0::1%123 {sin6_addr = fec0::1, sin6_scope_id = 123} <---getnameinfo---- I'm afraid the text was unclear enough due to my poor English. If so, please let me know. Then I'll try to make it clearer. Thanks, 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 Mon Feb 28 09:41:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SHdvX24241 for ipng-dist; Mon, 28 Feb 2000 09:39:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SHdl924234 for ; Mon, 28 Feb 2000 09:39:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA23906 for ; Mon, 28 Feb 2000 09:39:46 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11032 for ; Mon, 28 Feb 2000 09:39:45 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 24CC51520B0; Mon, 28 Feb 2000 11:39:45 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 20744148506; Mon, 28 Feb 2000 11:39:45 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 07C8D4FB07; Mon, 28 Feb 2000 11:39:38 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 9CB5E4C901; Mon, 28 Feb 2000 11:39:37 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000032441; Mon, 28 Feb 2000 12:39:43 -0500 (EST) From: Jim Bound Message-Id: <200002281739.MAA0000032441@yquarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Tue, 29 Feb 2000 02:07:14 +0900." Date: Mon, 28 Feb 2000 12:39:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> FEC0::1%123 > >> This can't be passed to any function as a dst address. What function >> parses the above string so: > >> sin6_addr = FEC0::1 >> sin6_scope_id = 123 > >> getaddrinfo? > >Yes, it's getaddrinfo(). According to the additional text for >getaddrinfo() that I posted here last week: > If the nodename is a textual IPv6 scoped address with a scope > identifier, getaddrinfo() sets the appropriate numeric number > for the scope identifer to the sin6_scope_id field of each returned > sockaddr_in6 structure. For a zero or positive numeric scope > identifier, getaddrinfo() simply copies the value to the > sin6_scope_id field, and lets the kernel validate the value. Understand that. Nit: Above you say "kernel" I think you mean "user space" I believe KAME code does DNS processing and get***info calls in user space? Not the kernel unless it is BITS. >Conceptually, the relationship between getaddrinfo() and getnameinfo() >is as the following figure: > > ----getaddrinfo---> >fec0::1%123 {sin6_addr = fec0::1, sin6_scope_id = 123} > <---getnameinfo---- Lets take this example: User types: telnet FEC0::1%123 (not that I recommend this) First call will be to getnameinfo or getaddrinfo? I think getaddrinfo as inet_pton will not work on the above string and AI_NUMERIC will have to be set? >I'm afraid the text was unclear enough due to my poor English. If so, >please let me know. Then I'll try to make it clearer. Not at all your english is fine at my end. It is the sequence. thanks /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 Feb 28 10:57:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SItnA24368 for ipng-dist; Mon, 28 Feb 2000 10:55:49 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SItj924361 for ; Mon, 28 Feb 2000 10:55:45 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA09606 for ipng@sunroof.eng.sun.com; Mon, 28 Feb 2000 10:54:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1RD6Y923232 for ; Sun, 27 Feb 2000 05:06:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA10756 for ; Sun, 27 Feb 2000 05:06:34 -0800 (PST) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14255 for ; Sun, 27 Feb 2000 05:06:33 -0800 (PST) Received: from southrelay03.raleigh.ibm.com (southrelay03.raleigh.ibm.com [9.37.3.210]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA61734 for ; Sun, 27 Feb 2000 07:50:26 -0600 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by southrelay03.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id IAA93022 for ; Sun, 27 Feb 2000 08:06:15 -0500 Message-Id: <200002271306.IAA93022@southrelay03.raleigh.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 2042 ; Sun, 27 Feb 2000 06:07:19 MST Date: Sun, 27 Feb 00 14:06:31 CET From: "Bert Wijnen" To: ipng@sunroof.eng.sun.com Subject: FYI - 4 week IETF Last Call on endpoint MIB Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, normally these get posted to the WG list too, but since this was a Design Team effort... oh well, you have 3+ weeks left. Since this is related to how IPv6 addresses get represented in MIBs (in fact any IP address), it is of relevance to this WG. Your ADs plust some WG members have been involved in the discussions. I assume they did represent your WG well, but this is your chance to read and comment. I am not subscribed to this list. I would prefer that if any discussion takes place, that the mibs@ops.ietf.org list is the place to do that. If you do it here, then I hope that your ADs or other WG members will pass it on to me or the mibs list. Thanks, Bert ------------- following is a copy ---------------- Date: Mon, 21 Feb 2000 10:30:17 -0500 From: The IESG To: IETF-Announce: ; SUBJECT: Last Call: Textual Conventions for Internet Network Addresses to Proposed Standard Reply-to: iesg@ietf.org The IESG has received a request to consider Textual Conventions for Internet Network Addresses as a Proposed Standard. This has been reviewed in the IETF on the mibs@ops.ietf.org mailing list, but is not the product of an IETF Working Group. This was produced by a Design Team that was formed by the Internet and Operations and Management ADs. This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 21, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ops-endpoint-mib-07.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 28 12:45:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SKhVj24566 for ipng-dist; Mon, 28 Feb 2000 12:43:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SKh7924559 for ; Mon, 28 Feb 2000 12:43:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA02274 for ; Mon, 28 Feb 2000 12:42:25 -0800 (PST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06864 for ; Mon, 28 Feb 2000 13:42:24 -0700 (MST) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id PAA11235; Mon, 28 Feb 2000 15:40:52 -0500 (EST) Message-Id: <200002282040.PAA11235@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Mon, 28 Feb 2000 12:04:36 EST." <200002281704.MAA0000027203@yquarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Feb 2000 15:40:51 -0500 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > >If the goal is to add an 8-16 bit site id in the site local prefix between > >FEC0::/10 and FEC0::/48, then why not make it 24 bits? 32 bits? 38 bits? > > Thanks for the input we will recall this mail as we proceed. If it makes sense to make the site id field larger to avoid collisions at multi-site nodes (and the consequent renumbering), then why not go all the way and make site ids globally unique? In other words, assign them via registries, perhaps leaving a large block free for local assignment, and with site_id == 0 remaining the zeroconf default. There are 38 bits available so they should not be scarce (given that SOHO networks have no use for anything other than the site_id == 0 default), and it is likely that they would be inexpensive to lease. Put another way, why not add globally unique, stable, portable (and non-aggregatable) addresses as a formal part of the IPv6 addressing architecture? And move the special treatment of site-local addresses out of the forwarding plane and into the configuration and routing protocol planes? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 28 14:42:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SMeol24696 for ipng-dist; Mon, 28 Feb 2000 14:40:50 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SMed924689 for ; Mon, 28 Feb 2000 14:40:39 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with SMTP id e1SMedL20148; Mon, 28 Feb 2000 14:40:39 -0800 (PST) Date: Mon, 28 Feb 2000 14:37:53 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a tiny comment on the ip6_hdr structure (rfc2292bis) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 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 > But the length of the flow label field is now 20 bits, so the comment > on the ip6_un1_flow member should be > > /* 4 bits version, 8 bits TC, 20 bits flow-ID */ I'll fix it. > Also, it might be useful to define an additional member to access the > lower 4 bits of the traffic class field. Wouldn't it make more sense to define macros to access the flow id and TC out of a uint32_t? We had such macros in a previous version dealing with flow id and priority (I don't recall if it was in the basic or the advanced API). The problem with 4 bit wide fields is that they are not very portable. 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 Feb 28 15:35:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SNXMV24751 for ipng-dist; Mon, 28 Feb 2000 15:33:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SNWQ924744 for ; Mon, 28 Feb 2000 15:32:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA02409 for ; Mon, 28 Feb 2000 15:31:46 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA16417 for ; Mon, 28 Feb 2000 16:31:45 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Feb 2000 15:28:46 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Mon, 28 Feb 2000 15:28:45 -0800 Message-ID: From: Brian Zill To: Christian Huitema , Matt Crawford , itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: RE: Site Identifiers and IPv6 Multisited Applications Nodes Date: Mon, 28 Feb 2000 15:28:41 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is why we need site-local addresses. > -----Original Message----- > From: Christian Huitema [mailto:huitema@microsoft.com] > Sent: Sunday, 27 February, 2000 12:43 > To: Matt Crawford; itojun@iijlab.net > Cc: Jim Bound; ipng@sunroof.eng.sun.com > Subject: RE: Site Identifiers and IPv6 Multisited Applications Nodes > > > Well, just a short question. What happens if your dentist > uses more than one > wire, e.g. the torture chair and its equipent on 1394, the > computers on > 10baseT, and, hopefully, a zeroconfig IPv6 router in between? > > -----Original Message----- > From: Matt Crawford [mailto:crawdad@fnal.gov] > Sent: Sunday, February 27, 2000 6:22 AM > To: itojun@iijlab.net > Cc: Jim Bound; ipng@sunroof.eng.sun.com > Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes > > > > >2. DO NOT USE LINK-LOCAL ADDRESSES for user applications > their purpose is > to > > >be used by network wire control functions for node > discovery in IPv6. > > Whatever happened to our dentist? > Farewell to zeroconf? > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mon Feb 28 15:46:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1SNiOj24788 for ipng-dist; Mon, 28 Feb 2000 15:44:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1SNiF924781 for ; Mon, 28 Feb 2000 15:44:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26524 for ; Mon, 28 Feb 2000 15:44:14 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21771 for ; Mon, 28 Feb 2000 15:44:14 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09532; Mon, 28 Feb 2000 15:41:34 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [163.154.34.36]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA89005; Mon, 28 Feb 2000 15:41:19 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (SGI-SGI-8.9.3/8.9.3) id PAA05677; Mon, 28 Feb 2000 15:42:04 -0800 (PST) From: Sam Manthorpe Message-Id: <200002282342.PAA05677@bossette.engr.sgi.com> Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes To: bzill@microsoft.com (Brian Zill) Date: Mon, 28 Feb 2000 15:42:03 -0800 (PST) Cc: huitema@microsoft.com (Christian Huitema), crawdad@fnal.gov (Matt Crawford), itojun@iijlab.net, bound@zk3.dec.com (Jim Bound), ipng@sunroof.eng.sun.com In-Reply-To: from "Brian Zill" at Feb 28, 2000 03:28:41 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, Brian Zill wrote: > This is why we need site-local addresses. I may have missed something, not having much time to follow this list recently, but what are the mechanisms for `zeroconf' allocation of site-local addresses and uniqueness guarantee of such autoconfiged site-locals? I wasn't aware that there were any. -- Sam > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@microsoft.com] > > Sent: Sunday, 27 February, 2000 12:43 > > To: Matt Crawford; itojun@iijlab.net > > Cc: Jim Bound; ipng@sunroof.eng.sun.com > > Subject: RE: Site Identifiers and IPv6 Multisited Applications Nodes > > > > > > Well, just a short question. What happens if your dentist > > uses more than one > > wire, e.g. the torture chair and its equipent on 1394, the > > computers on > > 10baseT, and, hopefully, a zeroconfig IPv6 router in between? > > > > -----Original Message----- > > From: Matt Crawford [mailto:crawdad@fnal.gov] > > Sent: Sunday, February 27, 2000 6:22 AM > > To: itojun@iijlab.net > > Cc: Jim Bound; ipng@sunroof.eng.sun.com > > Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes > > > > > > > >2. DO NOT USE LINK-LOCAL ADDRESSES for user applications > > their purpose is > > to > > > >be used by network wire control functions for node > > discovery in IPv6. > > > > Whatever happened to our dentist? > > Farewell to zeroconf? > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI, Core Protocols -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 28 16:10:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T07wl24816 for ipng-dist; Mon, 28 Feb 2000 16:07:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T07j924809 for ; Mon, 28 Feb 2000 16:07:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA01754 for ; Mon, 28 Feb 2000 16:07:44 -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 RAA03800 for ; Mon, 28 Feb 2000 17:07:44 -0700 (MST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Feb 2000 16:05:01 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Mon, 28 Feb 2000 16:05:01 -0800 Message-ID: From: Christian Huitema To: "'Jim Bound'" , Steve Blake Cc: ipng@sunroof.eng.sun.com Subject: RE: Another way to support Site-Local Addresses Date: Mon, 28 Feb 2000 16:04:55 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If the goal is to add an 8-16 bit site id in the site local prefix between >FEC0::/10 and FEC0::/48, then why not make it 24 bits? 32 bits? 38 bits? The larger the better -- would allow for random assignment while minimizing risks of collisions... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 28 16:24:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T0Mco24845 for ipng-dist; Mon, 28 Feb 2000 16:22:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T0MT924838 for ; Mon, 28 Feb 2000 16:22:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA05101 for ; Mon, 28 Feb 2000 16:22:29 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08931 for ; Mon, 28 Feb 2000 16:22:29 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 2F01D427; Mon, 28 Feb 2000 19:22:29 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 150BD55D; Mon, 28 Feb 2000 19:22:29 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id TAA0000022249; Mon, 28 Feb 2000 19:22:28 -0500 (EST) From: Jim Bound Message-Id: <200002290022.TAA0000022249@yquarry.zk3.dec.com> To: Steve Blake Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Mon, 28 Feb 2000 15:40:51 EST." <200002282040.PAA11235@castillo.torrentnet.com> Date: Mon, 28 Feb 2000 19:22:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, That was a mouthful and an idea I need to go off in a corner and put my engineering hat on and think about... If I agree and it will work that is pretty awesome. thanks /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 Feb 28 19:43:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T3foV24971 for ipng-dist; Mon, 28 Feb 2000 19:41:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T3ff924964 for ; Mon, 28 Feb 2000 19:41:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA14740 for ; Mon, 28 Feb 2000 19:41:40 -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 UAA22400 for ; Mon, 28 Feb 2000 20:41:35 -0700 (MST) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA20523; Tue, 29 Feb 2000 12:30:39 +0900 (JST) Date: Tue, 29 Feb 2000 12:42:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Mon, 28 Feb 2000 12:39:43 -0500" <200002281739.MAA0000032441@yquarry.zk3.dec.com> References: <200002281739.MAA0000032441@yquarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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: 67 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 28 Feb 2000 12:39:43 -0500, >>>>> Jim Bound said: >> If the nodename is a textual IPv6 scoped address with a scope >> identifier, getaddrinfo() sets the appropriate numeric number >> for the scope identifer to the sin6_scope_id field of each returned >> sockaddr_in6 structure. For a zero or positive numeric scope >> identifier, getaddrinfo() simply copies the value to the >> sin6_scope_id field, and lets the kernel validate the value. > Understand that. > Nit: Above you say "kernel" I think you mean "user space" I believe KAME > code does DNS processing and get***info calls in user space? Yes, KAME implements get***info in user space, but what I meant in the above text was that getaddrinfo() does not validate the numeric value of the portion. For example, even if "123" is not a valid (e.g. site) scope identifier as a node, getaddrinfo() itself would not fail and just copy the value to sin6_scope_id field of a sockaddr_in6 structure. The user would notice the invalidity when the structure is passed to the kernel by a succeeding system call. So I might have written the text as follows: For a zero or positive numeric scope identifier, getaddrinfo() simply copies the value to the sin6_scope_id field, and lets the kernel validate the value when the structure is passed to the kernel by a succeeding system call. >> Conceptually, the relationship between getaddrinfo() and getnameinfo() > Lets take this example: > User types: telnet FEC0::1%123 (not that I recommend this) > First call will be to getnameinfo or getaddrinfo? getaddrinfo(). > I think getaddrinfo as inet_pton will not work on the above string and > AI_NUMERIC will have to be set? Ah, I think I get your concern. This is the KAME's behavior: KAME's getaddrinfo() first tries to translate a given string as a numeric form regardless of the AI_NUMERICHOST flag. If the translation succeeds, the function just returns the result. Otherwise, it then tries to resolve the string as an FQDN unless AI_NUMERICHOST is set. FEC0::1%123 in the above example would be covered in the first process. Although the implementation doesn't process the string exactly as specified in the spec (i.e. it first tries the numeric case), it would not be a problem because the string "fec0::1%123" (or even just "fec0::1") is invalid as a domain name. >> I'm afraid the text was unclear enough due to my poor English. If so, >> please let me know. Then I'll try to make it clearer. > Not at all your english is fine at my end. It is the sequence. Okay, thanks. 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 Mon Feb 28 20:35:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T4XnY25022 for ipng-dist; Mon, 28 Feb 2000 20:33:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T4Xe925015 for ; Mon, 28 Feb 2000 20:33:40 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA08943; Mon, 28 Feb 2000 20:33:38 -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 UAA05732; Mon, 28 Feb 2000 20:33:37 -0800 (PST) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id NAA20789; Tue, 29 Feb 2000 13:24:21 +0900 (JST) Date: Tue, 29 Feb 2000 13:35:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: a tiny comment on the ip6_hdr structure (rfc2292bis) In-Reply-To: In your message of "Mon, 28 Feb 2000 14:37:53 -0800 (PST)" References: User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) 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 Mon, 28 Feb 2000 14:37:53 -0800 (PST), >>>>> Erik Nordmark said: >> Also, it might be useful to define an additional member to access the >> lower 4 bits of the traffic class field. > Wouldn't it make more sense to define macros to access the flow id and TC > out of a uint32_t? It might be. The macros could be IP6_GET_TC(ip6, class) IP6_SET_TC(ip6, class) for example? > We had such macros in a previous version dealing with flow id > and priority (I don't recall if it was in the basic or the advanced API). I think it was in the advanced API, but the oldest version that I have is draft-stevens-advanced-api-04, in which I can't find such definitions. > The problem with 4 bit wide fields is that they are not very portable. Indeed, so it would be a good idea to define generic macros to access such fields. 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 Mon Feb 28 22:37:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T6ZTb25115 for ipng-dist; Mon, 28 Feb 2000 22:35:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T6ZI925108 for ; Mon, 28 Feb 2000 22:35:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA17523 for ; Mon, 28 Feb 2000 22:35:16 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA11346 for ; Mon, 28 Feb 2000 23:34:17 -0700 (MST) 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 GA06174; Tue, 29 Feb 2000 17:23:57 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Steve Blake Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-Reply-To: Your message of "Mon, 28 Feb 2000 15:40:51 CDT." <200002282040.PAA11235@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Feb 2000 17:23:51 +1100 Message-Id: <3874.951805431@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 28 Feb 2000 15:40:51 -0500 From: Steve Blake Message-ID: <200002282040.PAA11235@castillo.torrentnet.com> | If it makes sense to make the site id field larger to avoid collisions at | multi-site nodes (and the consequent renumbering), then why not go all the | way and make site ids globally unique? That has been suggested before, and certainly hasn't been ruled out. How to assign these ids (random from a large space and rely upon probabilities, assigned from a registry, ...) was something that was never really discussed, because we didn't ever get to the stage of agreeing to do any kind of id. In hindsight, that might have been a mistake - leaving the details to later and attempting to agree upon a general principle leaves too much room for feelings of unease "but how will... that isn't specified yet ... then Idon't like this idea much, drop it" type responses. Perhaps this time, if this is to go round the mill one more time, it will be better to do a complete spec, starting with the trivial details, and not worry so much about wasting time on something which might end up in the dustbin later. 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 Feb 29 00:51:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T8nrw25204 for ipng-dist; Tue, 29 Feb 2000 00:49:53 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T8nT925197 for ; Tue, 29 Feb 2000 00:49:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA00252 for ; Tue, 29 Feb 2000 00:48: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 AAA11120 for ; Tue, 29 Feb 2000 00:48:40 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA25802; Tue, 29 Feb 2000 09:45: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 JAA26463; Tue, 29 Feb 2000 09:45:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA54254; Tue, 29 Feb 2000 09:47:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200002290847.JAA54254@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes In-reply-to: Your message of Fri, 25 Feb 2000 12:08:06 EST. <200002251708.MAA0000000340@yquarry.zk3.dec.com> Date: Tue, 29 Feb 2000 09:47:33 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Folks, In rfc2373.txt 2.1 Addressing Model IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node. It is wise to permit the last sentence and many network application in fact to identify a node or connection by its address. Like DNS and DHCP. Do we realize what we have done here? => I think we have to add "in the zone" in order to solve this issue (it should be in the future "zone document" :-). We are telling applications that exist on a multisited node that it must replicate the data for a site like in 2face DNS or change their application to be site-aware for the database key lookup. => a multisited node is already a strange thing then don't expect to have nothing a bit special to do with this beast... Regards Francis.Dupont@enst-bretagne.fr PS: I believe Itojun's suggession is the best one (as usual). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 29 01:03:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T91KD25273 for ipng-dist; Tue, 29 Feb 2000 01:01:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T91B925266 for ; Tue, 29 Feb 2000 01:01:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA24378 for ; Tue, 29 Feb 2000 01:01:10 -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 CAA18359 for ; Tue, 29 Feb 2000 02:00:57 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA17263; Tue, 29 Feb 2000 09:57: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 JAA26692; Tue, 29 Feb 2000 09:57:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA54323; Tue, 29 Feb 2000 09:59:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200002290859.JAA54323@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of Fri, 25 Feb 2000 12:19:24 EST. <200002251719.MAA0000002007@yquarry.zk3.dec.com> Date: Tue, 29 Feb 2000 09:59:48 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Using Kre's archtype model that we can embed site-identifiers in IPv6 addresses we develop a draft that proposes to use 2bytes of the IPv6 adddres (could use 1byte if we believe sites will not be greater than 256) which would heuristically determine based on net admin org/site administrator what the site identifier would be based on the adddress. => I am *not* in favor of this if the site-local address format is not changed too in the address architecture document, ie. I think it is bad to have "internal" and "external" formats for site-local addresses (this was tried for link-local addresses and has been shown to be a bad idea). I have nothing against an embedded site-identifier if this is in addressing specs and site-identifiers are (near) globally unique (mobility needs this). Rules to try and achieve: 1. Site-Local addresses are to contain a site-identifier which is unique across all sites of an organization. => this already exists for site-local socket addresses (sin6_scope_id). Benefits of working on this draft: 4. getipnodebyname is not dead and we do not need to parse site-identifiers on command lines or in our APIs. Clearly though we move to recommend to use getaddrinfo for other benefits. => for me this is a last attempt to save getipnodebyname() but getipnodebyname() was killed when you decided to not modify it (in fact it is killed only for multisited nodes). 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 Feb 29 01:19:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1T9HXr25330 for ipng-dist; Tue, 29 Feb 2000 01:17:33 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T9HI925323 for ; Tue, 29 Feb 2000 01:17:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA04208; Tue, 29 Feb 2000 01:17:18 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA23746; Tue, 29 Feb 2000 02:17:16 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA19140; Tue, 29 Feb 2000 10:17:15 +0100 (MET) Date: Tue, 29 Feb 2000 10:17:15 +0100 From: Ignatios Souvatzis To: Erik Nordmark Cc: "JINMEI Tatuya / ?$B?@L@C#:H?(B" , ipng@sunroof.eng.sun.com Subject: Re: a tiny comment on the ip6_hdr structure (rfc2292bis) Message-ID: <20000229101715.A19114@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from Erik.Nordmark@eng.sun.com on Mon, Feb 28, 2000 at 02:37:53PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Feb 28, 2000 at 02:37:53PM -0800, Erik Nordmark wrote: > > > > But the length of the flow label field is now 20 bits, so the comment > > on the ip6_un1_flow member should be > > > > /* 4 bits version, 8 bits TC, 20 bits flow-ID */ > > I'll fix it. > > > Also, it might be useful to define an additional member to access the > > lower 4 bits of the traffic class field. > > Wouldn't it make more sense to define macros to access the flow id and TC > out of a uint32_t? Yes, please. Much better than bitfields. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 29 06:36:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1TEYKD25485 for ipng-dist; Tue, 29 Feb 2000 06:34:20 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1TEY2925478 for ; Tue, 29 Feb 2000 06:34:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA11728 for ; Tue, 29 Feb 2000 06:34:03 -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 GAA23792 for ; Tue, 29 Feb 2000 06:34:02 -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 IAA25818 for ; Tue, 29 Feb 2000 08:33:41 -0600 (CST) Message-Id: <200002291433.IAA25818@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of Mon, 28 Feb 2000 16:04:55 PST. Date: Tue, 29 Feb 2000 08:33:41 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >If the goal is to add an 8-16 bit site id in the site local prefix between > >FEC0::/10 and FEC0::/48, then why not make it 24 bits? 32 bits? 38 bits? > > The larger the better -- would allow for random assignment while minimizing > risks of collisions... No, the larger the better -- it'll prevent the next idea for sticking some weird bits in the middle of the address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 29 06:37:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1TEaSq25494 for ipng-dist; Tue, 29 Feb 2000 06:36:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1TEaF925487 for ; Tue, 29 Feb 2000 06:36:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA10199 for ; Tue, 29 Feb 2000 06:36:15 -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 GAA24748 for ; Tue, 29 Feb 2000 06:36:14 -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 IAA25836 for ; Tue, 29 Feb 2000 08:35:54 -0600 (CST) Message-Id: <200002291435.IAA25836@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of Mon, 28 Feb 2000 15:40:51 EST. <200002282040.PAA11235@castillo.torrentnet.com> Date: Tue, 29 Feb 2000 08:35:54 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Put another way, why not add globally unique, stable, portable (and > non-aggregatable) addresses as a formal part of the IPv6 addressing > architecture? Such a small nose ... such a big camel! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 29 10:30:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1TISVB25687 for ipng-dist; Tue, 29 Feb 2000 10:28:31 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1TISR925680 for ; Tue, 29 Feb 2000 10:28:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA10395 for ipng@sunroof.eng.sun.com; Tue, 29 Feb 2000 10:26:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1TGrm925598 for ; Tue, 29 Feb 2000 08:53:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA28731 for ; Tue, 29 Feb 2000 08:53:48 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06165 for ; Tue, 29 Feb 2000 08:53:47 -0800 (PST) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 5A9E0751; Tue, 29 Feb 2000 11:53:46 -0500 (EST) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 433A76D6 for ; Tue, 29 Feb 2000 11:53:46 -0500 (EST) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Feb 2000 11:53:45 -0500 Message-ID: From: "Powell, Ken" To: "'Matt Crawford'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: RFC 2462: Possible Denial of Service Attack Date: Tue, 29 Feb 2000 11:53:43 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I know of nothing a network administrator can do to recover in > > less than two hours short of resetting IPv6 on each of the > > client systems (probably with reboots). > > You could mitigate the damage by having your routers provide proxy > neighbor discovery service for the other prefixes. > > Matt I had to think about this idea for a while. It think it could work, but only if the router provides support for this. Has anyone implemented such support? Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 29 14:17:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1TMG1925857 for ipng-dist; Tue, 29 Feb 2000 14:16:02 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1TMFv925850 for ; Tue, 29 Feb 2000 14:15:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id OAA10948 for ipng@sunroof.eng.sun.com; Tue, 29 Feb 2000 14:14:16 -0800 (PST) Received: from audeen.eng.sun.com (audeen [129.146.86.142]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e1T4fF925044 for ; Mon, 28 Feb 2000 20:41:15 -0800 (PST) Received: from audeen (audeen [129.146.86.142]) by audeen.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA04284; Mon, 28 Feb 2000 20:39:34 -0800 (PST) Message-Id: <200002290439.UAA04284@audeen.eng.sun.com> Date: Mon, 28 Feb 2000 20:39:33 -0800 (PST) From: Carl Williams Reply-To: Carl Williams Subject: IPv6 Wireless and Mobility Roundtable To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Cc: carlw@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4v7C11to7We7KvWr6pR5DQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4m sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 Wireless and Mobility Roundtable ===================================== Connectathon 2000 is presenting a roundtable discussion on IPv6 Wireless and Mobility as part of the interoperability testing event this year. The roundtable is being cosponsored with the IPv6 Forum. The panel will contain key individuals leading the standards, research and/or implementation efforts in IPv6 and Wireless protocols. The discussion is open to anyone. An email invitation is being sent out to the Mobile IP and IPv6 IETF working group members to participate in the audience. Members of the audience will have an opportunity to ask questions to the panel on topics relating to IPv6 and Wireless. Round Table Discussion: IPv6 for Wireless and Mobility The wireless cellular industry, particularly as it prepares to deploy 2.5G and 3G services has been touted as the "killer application" for IPv6. An obvious first consideration to support this notion is the sheer number of devices expected to come on-line via cellular technologies. Predictions range from 600 million to 1 billion at the turn of 4 to 5 years. Managing such a large and sudden influx of devices connected via highly dynamic and unreliable links is a task far more challenging than any the Internet has faced to date. The panel will explore how IPv6 can rise to the challenge, as well as its remaining deficiencies. The following features of IPv6 are some of the topics (but not limited to) that will be discussed at the roundtable: - How can IPv6 streamline the routing infrastructure? IPv6 may have a better chance than IPv4 at route aggregation, because of better initial assignment of address ranges and because of its provisions for renumbering. What remains to be done? - Role of autoconfiguration for mobile networking. Mobile and wireless devices need to bootstrap all configuration information based on a secure token or on a cryptographic identity. The rest should be automatic. This is particularly relevant when considering other wireless technologies like Bluetooth that will need to interact with cellular, and in which the automatic configuration requirements apply to a collection of devices. - How can IPv6 improve the security infrastructure? IPv6 does mandate IPsec, but how practical or deployable is it in a cellular environment? - Can Mobile IP simplify the future Internet? Does IPv6 provide other mechanisms to deal with mobility? Is it better handled at a layer other than layer 3 (as in Mobile IP)? - What is the interaction between IPv6 and cellular telephone standards? There seems to be little more than lip service to IPv6 on the part of next generation cellular consortiums like 3GPP, 3GPP2, and MWIF. Do they have valid concerns? - Issues with supporting 500 Million IP Wireless Devices. What is the right addressing scheme that needs to be used? Are E.164 based addresses more appropriate for cellular than EUI-64 (more common with LAN hardware)? - The IPv6 header is twice as large as its IPv4 counterpart, but routers should have a much easier time processing and forwarding packets. The above issues apply to both the core network as well as to the wireless devices. Members of the audience can raise any topic regarding IPv6 for Mobility or Wireless at this roundtable. Discussion is not limited to those topics above. Roundtable Panel Charlie Perkins Robert Hinden Nokia Research Laboratories Nokia Steve Deering Martin Korling Cisco Systems Ericsson Research Erik Nordmark Dave Johnson Sun Microsystems Carnegie Mellon University Brian Zill Jun-ichiro Hagino Microsoft Research Internet Initiative Japan Inc. Mihai Mateescu Mobile and Broadband Wireless Communications of GMD Date, Time and Place Monday, March 6, 2000 4:00pm-6:00pm Crowne Plaza Hotel 282 Almaden Blvd San Jose, CA Phone # for Crowne Plaza: (408) 998-0400 The roundtable discussion will take place in the Crowne Plaza Hotel Ballroom. You do *not* need to RSVP to attend the roundtable. Just show up at the Crowne Plaza Hotel Ballroom. There is no registration required for participating. While admission to the IPv6 Wireless and Mobility roundtable is free and open to all, only registered participants of Connectathon will be allowed into the testing halls. Mobile IP Dinner ================ Some members of the panel will be joining Connectathon participants for dinner after the event at a local San Jose restaurant. If you are interested in attending the dinner you *must* RSVP John Hird at jrh@eng.sun.com. You will be responsible for the cost of your dinner. More information about where the dinner will be provided at the roundtable event. There will be limited room so the RSVP will be on a first come basis. Ericsson Presentation ===================== A presentation by Ericsson will be made on their Mobile IPv6 research implementation immediately preceding the roundtable in the same room (Crowne Plaza Hotel Ballroom) from 3:00pm-3:45pm. Conny Larsson of Ericsson Research will be presenting. Again, this is open to anyone. Abstract of talk by Conny Larsson, Ericsson Research: The Ericsson Mobile IPv6 implementation is a free implementation using FreeBSD and the KAME IPv6 implementation. It has been implemented as part of a research project at Ericsson. It consists of three parts; the Correspondent Node, the Home Agent and the Mobile Node. In addition, two applications are offered for configuration and retrieving statistical information. This talk will go over the Ericsson Research Mobile IPv6 implementation. References: www.connectathon.org - for more information on Connectathon 2000. www.ipv6forum.com - for more information on the Worldwide consortium of leading Internet vendors, Research & Education Networks. Connectathon 2000 participants performing interoperability testing for the Mobile IP, IPv6, Mobile IPv6 and/or DIAMETER protocols: Apple Computer, Inc., Cisco Systems, Inc., Carnegie Mellon University, Ericsson Inc., ENST (Ecole National Superieure des Telecommunications) Bretagne, Hewlett-Packard Company, Hitachi, Ltd., IBM Corporation, KAME Project, MCI Worldcom, Microsoft Corporation, NEC Corporation, Nokia Research Center, SCO Ltd., Sun Microsystems, Inc., Silicon Graphics, Inc., TAHI, Toshiba Corporation, University of New Hampshire, Mobile and Broadband Wireless Communications of GMD -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 29 19:28:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e213QNe26293 for ipng-dist; Tue, 29 Feb 2000 19:26:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e213QD926286 for ; Tue, 29 Feb 2000 19:26:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA21440 for ; Tue, 29 Feb 2000 19:26:12 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22747 for ; Tue, 29 Feb 2000 19:26:11 -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 MAA12037; Wed, 1 Mar 2000 12:26:03 +0900 (JST) To: "Powell, Ken" cc: "'Matt Crawford'" , "'ipng@sunroof.eng.sun.com'" In-reply-to: Ken.Powell's message of Tue, 29 Feb 2000 11:53:43 EST. 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: RFC 2462: Possible Denial of Service Attack From: itojun@iijlab.net Date: Wed, 01 Mar 2000 12:26:03 +0900 Message-ID: <12035.951881163@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > I know of nothing a network administrator can do to recover in >> > less than two hours short of resetting IPv6 on each of the >> > client systems (probably with reboots). >> You could mitigate the damage by having your routers provide proxy >> neighbor discovery service for the other prefixes. >I had to think about this idea for a while. It think it could work, >but only if the router provides support for this. Has anyone >implemented such support? Do you mean proxy neighbor discovery support by "such support"? There are (at least, KAME does), but you may need to configure tons of proxy NDP entries for this ... of course, you may be able to automate if the trouble looks very popular. 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 Tue Feb 29 19:44:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e213gSk26330 for ipng-dist; Tue, 29 Feb 2000 19:42:28 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e213g8926315 for ; Tue, 29 Feb 2000 19:42:09 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with SMTP id e213g8L12697; Tue, 29 Feb 2000 19:42:08 -0800 (PST) Date: Tue, 29 Feb 2000 11:40:03 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes To: itojun@iijlab.net Cc: Jim Bound , Robert Elz , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <15503.951537356@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Easiest workaround for "site-unaware servers on multi-sited node" > is to run multiple servers, one for each site. This solves many of > typical cases. Do the APIs we've specified have the needed features to run one server application per site on a multi-sited node? An application can bind to in6addr_any and some port but that would not restrict the server to only handle connections/datagrams from one site. 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 Feb 29 19:44:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e213gTZ26331 for ipng-dist; Tue, 29 Feb 2000 19:42:29 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e213g9926318 for ; Tue, 29 Feb 2000 19:42:10 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with SMTP id e213g9L12706; Tue, 29 Feb 2000 19:42:09 -0800 (PST) Date: Tue, 29 Feb 2000 11:50:15 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes To: Jim Bound Cc: itojun@iijlab.net, Robert Elz , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200002270215.VAA0000017893@yquarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > 1. For now use caution with site-local addresses. Agreed. > 2. DO NOT USE LINK-LOCAL ADDRESSES for user applications their purpose is to > be used by network wire control functions for node discovery in IPv6. There might be zeroconf and ad-hoc networking situations where the only IPv6 address you have is a link-local address. Thus I don't think we should recommend that applications explicitly fail to communicate using link-local addresses. Applications should never prefer a link-local address over a larger scope address, and they should use caution when there is only a link-local address to use. 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 Feb 29 19:51:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e213oAL26375 for ipng-dist; Tue, 29 Feb 2000 19:50:10 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e213nk926365 for ; Tue, 29 Feb 2000 19:49:46 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA21472 for ; Tue, 29 Feb 2000 19:49:05 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29470 for ; Tue, 29 Feb 2000 19:49:05 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id B26C29A86C; Tue, 29 Feb 2000 21:49:04 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id AAABF90D85; Tue, 29 Feb 2000 21:49:04 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id C2FF9BC4C4; Tue, 29 Feb 2000 21:48:57 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 690F8B2A43; Tue, 29 Feb 2000 21:48:57 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000021705; Tue, 29 Feb 2000 22:49:03 -0500 (EST) From: Jim Bound Message-Id: <200003010349.WAA0000021705@yquarry.zk3.dec.com> To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Tue, 29 Feb 2000 09:59:48 +0100." <200002290859.JAA54323@givry.rennes.enst-bretagne.fr> Date: Tue, 29 Feb 2000 22:49:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, Thanks for you input we will consider it as we work out the details. /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 Feb 29 20:02:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e2141Fk26394 for ipng-dist; Tue, 29 Feb 2000 20:01:15 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e21415926387 for ; Tue, 29 Feb 2000 20:01:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA24138; Tue, 29 Feb 2000 20:01:03 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA03018; Tue, 29 Feb 2000 20:01:02 -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 NAA12638; Wed, 1 Mar 2000 13:01:00 +0900 (JST) To: Erik Nordmark cc: Jim Bound , Robert Elz , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Tue, 29 Feb 2000 11:40:03 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: Site Identifiers and IPv6 Multisited Applications Nodes From: itojun@iijlab.net Date: Wed, 01 Mar 2000 13:01:00 +0900 Message-ID: <12636.951883260@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Easiest workaround for "site-unaware servers on multi-sited node" >> is to run multiple servers, one for each site. This solves many of >> typical cases. >Do the APIs we've specified have the needed features to run >one server application per site on a multi-sited node? >An application can bind to in6addr_any and some port but that >would not restrict the server to only handle connections/datagrams >from one site. (assume this multi-sited server has fec0::1%site0, fec0::1%site1, and fec0::1%site2) I thought of binding to more specific address, like: daemon 1 binds to fec0::1%site0 daemon 2 binds to fec0::1%site1 daemon 3 binds to fec0::1%site2 Given that the interpretation of sin6_scope_id is determined by sin6_addr, I think binding to ::%site0 is not a good idea. "::" does not give context to sin6_scope_id portion... 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 --------------------------------------------------------------------