From owner-ipng@sunroof.eng.sun.com Mon Dec 1 09:40:36 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA06612 for ipng-dist; Mon, 1 Dec 1997 09:37:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA06605 for ; Mon, 1 Dec 1997 09:37:41 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA23943 for ; Mon, 1 Dec 1997 09:37:38 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA10326 for ; Mon, 1 Dec 1997 09:37:18 -0800 (PST) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA27728; Mon, 1 Dec 1997 12:21:22 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06997; Mon, 1 Dec 1997 12:21:14 -0500 Message-Id: <199712011721.AA06997@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, Alan Halachmi , ipng@sunroof.eng.sun.com Subject: (IPng 4992) Re: change IPv6 DNS records.... In-Reply-To: Your message of "Wed, 26 Nov 1997 17:01:45 EST." Date: Mon, 01 Dec 1997 12:21:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >i believe AAAA records represent an immense scaling problem Please tell us why technically and operationaly so we can discuss it as an IETF WG? 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 Dec 1 10:12:08 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA06699 for ipng-dist; Mon, 1 Dec 1997 10:09:03 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id KAA06692 for ; Mon, 1 Dec 1997 10:08:58 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id KAA09236 for ; Mon, 1 Dec 1997 10:08:58 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17045; Mon, 1 Dec 1997 10:08:40 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id DAA05485 for ; Sat, 29 Nov 1997 03:21:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA22649 for ; Sat, 29 Nov 1997 03:21:12 -0800 Received: from ceres.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id DAA02146 for ; Sat, 29 Nov 1997 03:21:15 -0800 (PST) Received: (from mailer@localhost) by ceres.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) id UAA29209 for ; Sat, 29 Nov 1997 20:33:45 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by ceres.backyard.wide.toshiba.co.jp via smap (V1.3) id sma029207; Sat Nov 29 20:33:35 1997 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) with ESMTP id UAA19145 for ; Sat, 29 Nov 1997 20:22:02 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 4993) Multicast destination and routing header X-Mailer: Mew version 1.91 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19971129201922M.jinmei@backyard.wide.toshiba.co.jp> Date: Sat, 29 Nov 1997 20:19:22 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 970918 Lines: 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In RFC1883(and in the new drafts), I saw the following restriction on using the type-0 routing header: Multicast addresses must not appear in a Routing header of Type 0, or in the IPv6 Destination Address field of a packet carrying a Routing header of Type 0. But if we follow the algorithm after the statement, we'll accept such a packet when the segments left field of the routing header is 0. The algorithm says that if Segments Left = 0 { proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header } that is, if the segments left is 0, the packet is simply accepted. Is it a right behavior? If not, it seems to me that we should check the IPv6 destination address before processing the packet. For example, the above algorithm should be if Segments Left = 0 { if IPv6 Destination Address is multicast { discard the packet } else { proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header } } Or do I miss something? If anyone know the answer, please let me know. Thanks in advance, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.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 Dec 1 10:22:19 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA06784 for ipng-dist; Mon, 1 Dec 1997 10:19:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA06777 for ; Mon, 1 Dec 1997 10:19:01 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA07004 for ; Mon, 1 Dec 1997 10:18:57 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA04499 for ; Mon, 1 Dec 1997 10:19:03 -0800 (PST) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA06576; Mon, 1 Dec 1997 12:08:50 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06362; Mon, 1 Dec 1997 12:08:32 -0500 Message-Id: <199712011708.AA06362@wasted.zk3.dec.com> To: Daniel Karrenberg Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com, RIPE Local Internet Registries WG , RIPE IPv6 WG , Rob Blokzijl , hinden@ipsilon.com, "Mike O'Dell" , deering@cisco.com, Kim Hubbard , David Conrad , Jon Postel , bound@zk3.dec.com Subject: (IPng 4994) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Wed, 26 Nov 1997 18:05:00 +0100." <9711261705.AA03735@ncc.ripe.net> Date: Mon, 01 Dec 1997 12:08:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel, Have you or someone from RIPE participated on the IPng mailing list? Have you or someone from RIPE participated in the IPng WG meetings at the last three IETF meetings? The reason I ask is because we have done technical analysis on this and have had much discussion. I think discussing the reason for going with a 13bit TLA needs to be brought out more and doing and checking that is prudent. But the architecture and reasoning has had many technical discussions. I would like to understand as a WG member if you or RIPE did not agree with the results (which I would think we would have heard before now) or if you or RIPE have not been part of these open public discussions. It could be we need to point to the mail archives and the GSE reasoning paper done by Thomas Narten, Lixia Zhang, et al from whence this essential proposal came from based on a WG meeting in Mountain View about a year ago? I am trying to understand if this is an educational effort on our part as a WG group? 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 Dec 1 11:34:45 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA06963 for ipng-dist; Mon, 1 Dec 1997 11:31:43 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id LAA06956 for ; Mon, 1 Dec 1997 11:31:32 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id LAA05314 for ; Mon, 1 Dec 1997 11:31:15 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17255; Mon, 1 Dec 1997 11:30:57 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA06925 for ; Mon, 1 Dec 1997 11:23:15 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA27990 for ; Mon, 1 Dec 1997 11:23:10 -0800 Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA13418 for ; Mon, 1 Dec 1997 11:22:44 -0800 (PST) Received: from x25.ripe.net by ncc.ripe.net with SMTP id AA09965 (5.65a/NCC-2.41); Mon, 1 Dec 1997 20:19:03 +0100 Message-Id: <9712011919.AA09965@ncc.ripe.net> To: bound@zk3.dec.com Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com, RIPE Local Internet Registries WG , RIPE IPv6 WG , Rob Blokzijl , hinden@ipsilon.com, "Mike O'Dell" , deering@cisco.com, Kim Hubbard , David Conrad , Jon Postel Subject: (IPng 4996) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of Mon, 01 Dec 1997 12:08:32 EST. <199712011708.AA06362@wasted.zk3.dec.com> References: <199712011708.AA06362@wasted.zk3.dec.com> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 Date: Mon, 01 Dec 1997 20:19:01 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quick answer: > bound@zk3.dec.com writes: > Daniel, > > Have you or someone from RIPE participated on the IPng mailing list? > > Have you or someone from RIPE participated in the IPng WG meetings at > the last three IETF meetings? Yes we have. I personally have not been in Memphis, hoever none of us was able to be at the interim meeting. To my knowledge the draft under discussion was written less than two IETFs ago. I personally was not able to be at all IPnG meetings at the last few IETFs because of conflicts with other things. I have however voiced my concerns about this particular issue to Miek O'Dell while the discussion was going on. But all that is besides the point really. > The reason I ask is because we have done technical analysis on this and > have had much discussion. I have seen some of this discussion. I am afraid I have seen no documented discussion revealing the reasoning behind fixing the TLA length and fixing it at 13 bits. Frankly I have been surprised by the sudden speed of the provider based addressing standardisation. What I have voiced are concerns based on our experience with setting up and operating address space registries as well as providing coordination services to ISPs. My main point is that fixing the TLA length and fixing it at 13 bits has such far-reaching consequences that it needs to be supported by a solid technical argument which I cannot find in the drafts nor in any other source available to me. I think the draft should at least point to a solid reference supporting this. I expect a lot of entropy down the road if this is not supported well. > I think discussing the reason for going with a 13bit TLA needs to be > brought out more and doing and checking that is prudent. But the > architecture and reasoning has had many technical discussions. I would > like to understand as a WG member if you or RIPE did not agree with the > results (which I would think we would have heard before now) or if you > or RIPE have not been part of these open public discussions. It could > be we need to point to the mail archives and the GSE reasoning paper done > by Thomas Narten, Lixia Zhang, et al from whence this essential proposal > came from based on a WG meeting in Mountain View about a year ago? > I am trying to understand if this is an educational effort on our part > as a WG group? It is both educational and principal. Major design decisions should be somewhat transparent to a wider audience. Standardising TLA length in fact puts significant constraints on operations, business models and address space allocation policies just to name a few issues. This needs to be justified somewhat more than just saying "it is standardised like this". The reasons have to be accessible more widely than just the IPnG WG. Note that I am not at issue with the underlying architecture. It is about fixing the boundary and fixing it at a particular value. If there is a solid technical reason for it, then document it. Documenting it will make the standard a stronger document and will prevent a lot of discussion about the repercussions. If there is no solid technical reason to do so then then do not fix these values. If a (proposed) standard does not document this reasoning or at least points to it, it is seriously flawed. This is not a definition of a type field in some application protocol header. It is much more critical. Does that answer your question? Daniel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 1 12:05:10 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA07018 for ipng-dist; Mon, 1 Dec 1997 12:02:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA07011 for ; Mon, 1 Dec 1997 12:01:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA10812 for ; Mon, 1 Dec 1997 12:01:55 -0800 Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA06671 for ; Mon, 1 Dec 1997 12:01:57 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id OAA08069; Mon, 1 Dec 1997 14:58:03 -0500 (EST) Date: Mon, 1 Dec 1997 14:58:03 -0500 (EST) From: Scott Bradner Message-Id: <199712011958.OAA08069@newdev.harvard.edu> To: bound@zk3.dec.com, Daniel.Karrenberg@ripe.net Subject: (IPng 4997) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard Cc: davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, mo@uunet.uu.net, postel@isi.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel said: I have seen some of this discussion. I am afraid I have seen no documented discussion revealing the reasoning behind fixing the TLA length and fixing it at 13 bits. Frankly I have been surprised by the sudden speed of the provider based addressing standardisation. last year in regards to what is now RFC 2050 I asked the lawyers that do work for the IESG what restrictions in flexibility we (the IETF) have in the area of defining rules and technology that restricts ISP practices. I was told that the only time we can be restrictive is when there is no other technically reasonable option - I support Daniel here, if this field is to be restricted to a specific length then we must have very good technical reasons for doing so. Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 1 19:00:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id SAA07522 for ipng-dist; Mon, 1 Dec 1997 18:56:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA07512 for ; Mon, 1 Dec 1997 18:55:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA11459 for ; Mon, 1 Dec 1997 18:55:31 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA12142 for ; Mon, 1 Dec 1997 18:55:30 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA13655; Tue, 2 Dec 1997 02:54:01 GMT Received: from brianh.hursley.ibm.com (lig32-226-52-180.us.lig-dial.ibm.com [32.226.52.180]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with SMTP id CAA25910; Tue, 2 Dec 1997 02:53:51 GMT Message-Id: <348374C4.15BC@hursley.ibm.com> Date: Tue, 02 Dec 1997 02:39:00 +0000 From: Brian E Carpenter Reply-To: brian@hursley.ibm.com Organization: IBM Internet Division X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: Scott Bradner Cc: bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, mo@uunet.uu.net, postel@isi.edu Subject: (IPng 4998) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard References: <199712011958.OAA08069@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Try "The length of the TLA field is fixed at a relatively small size so as to guarantee that the default-free routing table is certain not to exceed a size known to be technically feasible." If that is untrue, then we can't justify the fixed size. Brian Carpenter >-- Scott Bradner wrote: > > Daniel said: > I have seen some of this discussion. I am afraid I have seen no > documented discussion revealing the reasoning behind fixing the TLA > length and fixing it at 13 bits. Frankly I have been surprised by the > sudden speed of the provider based addressing standardisation. > > last year in regards to what is now RFC 2050 I asked the lawyers that > do work for the IESG what restrictions in flexibility we (the IETF) have > in the area of defining rules and technology that restricts ISP practices. > I was told that the only time we can be restrictive is when there is > no other technically reasonable option - I support Daniel here, if this > field is to be restricted to a specific length then we must have > very good technical reasons for doing so. > > Scott > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 04:00:15 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id DAA07780 for ipng-dist; Tue, 2 Dec 1997 03:57:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id DAA07773 for ; Tue, 2 Dec 1997 03:57:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA27307 for ; Tue, 2 Dec 1997 03:57:19 -0800 Received: from solen.ce.chalmers.se (solen.ce.chalmers.se [129.16.20.244]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id DAA22437 for ; Tue, 2 Dec 1997 03:57:25 -0800 (PST) Received: from cepc59.ce.chalmers.se (otel@cepc59.ce.chalmers.se [129.16.20.188]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id MAA28502 for ; Tue, 2 Dec 1997 12:57:15 +0100 (MET) From: Otel Florian-Daniel Received: (from otel@localhost) by cepc59.ce.chalmers.se (8.8.7/8.8.5) id MAA00484; Tue, 2 Dec 1997 12:58:21 +0100 Date: Tue, 2 Dec 1997 12:58:21 +0100 Message-Id: <199712021158.MAA00484@cepc59.ce.chalmers.se> To: ipng@sunroof.eng.sun.com Subject: (IPng 4999) IGMPv6 specs. X-Mailer: VM 6.34 under 20.2 XEmacs Lucid Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello everybody, I would like to know if there is any paper clarifying the use of IGMP Group Membership Reduction packet (i.e. the specs for "IGMPv6"). Thanks in advance, Florian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 04:14:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id EAA07818 for ipng-dist; Tue, 2 Dec 1997 04:11:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA07811 for ; Tue, 2 Dec 1997 04:11:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA28382 for ; Tue, 2 Dec 1997 04:11:40 -0800 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA26568 for ; Tue, 2 Dec 1997 04:11:48 -0800 (PST) Received: from rodan.UU.NET by relay3.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdsei17706; Tue, 2 Dec 1997 07:11:07 -0500 (EST) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdsei26087; Tue, 2 Dec 1997 07:11:01 -0500 (EST) Message-Id: To: brian@hursley.ibm.com cc: Scott Bradner , bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, mo@UU.NET, postel@isi.edu Subject: (IPng 5000) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-reply-to: Your message of "Tue, 02 Dec 1997 02:39:00 GMT." <348374C4.15BC@hursley.ibm.com> Date: Tue, 02 Dec 1997 07:11:00 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk brian's reason is exactly the goal which was in mind: to bound the maximum complexity of the default-free region at values believed to be viable with some margin. the margin is important because even routers normally though to be "default-free" will probably carry a significant number of more-specific prefixes for optimizing paths, both internal to a TLA and between TLAs. and note, once again, the issue is not the size of the default-free region, but the complexity of the topology, which determines how many copies of the full default-free region one must examine before arriving at the forwarding table with one entry per TLA. it is now routine to see an announced prefix 15 times via different paths, only one of which must be selected for use. the complexity of the topology is only expected to increase, both internally and externally, so it is not unreasonable to attempt to bound the size of the set as that is the only parameter which is in any sense "tunable". as for 13 - anything smaller was felt to be clearly too small, and it becomes harder and harder to argue for bigger numbers in light of the complexity management which is mandatory. if anyone expects a magic formula which says "13" and not something else, you won't get it. what is very clear is that it is pretty easy for it to to "too big", and then it eats into the other topology bits which have their own set of long arguments. would 14 work - certainly. Like everything else, 13 is an engineering compromise - chosen to balance one set of considerations against a bunch of others, and after ruminating over it a long time, the consensus was 13 was the best choice. and as someone else pointed out, the TLA space can be expanded laterally into other reserved areas, so there are more available. now, to look at things from a different vantage point.... I think one deep issue here is that the IPv6 address design, in some sense, appears to threaten the existing registries. the design assumes that each TLA act as a registry for its region of the address space, leaving the registries to only allocate TLAs, which will be infrequent. just so. but given the work required to run a registry, existing registries with good track records would be in an excellent position to compete for the right to provide registration services for *any* TLA or delegation within a TLA, not just ones they assigned. this is a natural fall-out of attempting to provide an addressing structure which can pave the way for making the network self-organizing. if that were really the case, unlike today, there would be little need for registry organizations (little - not "no", but little) which use humans clerical workers to execute a simple resource allocation algorithm for the world's largest distributed computer. -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 04:38:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id EAA07868 for ipng-dist; Tue, 2 Dec 1997 04:36:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA07861 for ; Tue, 2 Dec 1997 04:36:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA00484 for ; Tue, 2 Dec 1997 04:35:58 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA03620 for ; Tue, 2 Dec 1997 04:36:05 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA20086; Tue, 2 Dec 1997 07:35:51 -0500 (EST) Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA32560; Tue, 2 Dec 1997 07:35:53 -0500 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23888; Tue, 2 Dec 1997 07:35:50 -0500 Message-Id: <348400A6.41C6@raleigh.ibm.com> Date: Tue, 02 Dec 1997 07:35:50 -0500 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 3.01 (X11; I; AIX 1) Mime-Version: 1.0 To: otel@ce.chalmers.se Cc: IPng Subject: (IPng 5001) Re: IGMPv6 specs. References: <199712021158.MAA00484@cepc59.ce.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Florian, There is no current draft for IGMPv6. 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 Dec 2 04:53:17 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id EAA07889 for ipng-dist; Tue, 2 Dec 1997 04:50:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA07882 for ; Tue, 2 Dec 1997 04:50:32 -0800 (PST) From: bmanning@ISI.EDU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA01591 for ; Tue, 2 Dec 1997 04:50:29 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA07870 for ; Tue, 2 Dec 1997 04:50:37 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id EAA28571; Tue, 2 Dec 1997 04:49:54 -0800 (PST) Posted-Date: Tue, 2 Dec 1997 04:48:36 -0800 (PST) Message-Id: <199712021248.AA04171@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 2 Dec 1997 04:48:37 -0800 Subject: (IPng 5002) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard To: mo@uu.net (Mike O'Dell) Date: Tue, 2 Dec 1997 04:48:36 -0800 (PST) Cc: brian@hursley.ibm.com, sob@harvard.edu, bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, mo@uu.net, postel@ISI.EDU In-Reply-To: from "Mike O'Dell" at Dec 2, 97 07:11:00 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Before we wander too far down this path, there was a very interesting paper at the last sigcom in which the authors managed to shrink the size of the then current routing table (~40k routes) into less than 200K of memory. In short, I differ from Mike in that my values for "believed to be viable" differ, apparently wildly, from his and brians. I'm unconvinced that this will remain a true, long term technological argument. I'd like to see something besides, "too hard with 1990's technologies". "Long time" ought to have a better spec than say, Internet Dog Years? > > brian's reason is exactly the goal which was in mind: > > to bound the maximum complexity of the default-free region > at values believed to be viable with some margin. > > Like everything else, 13 is an engineering compromise - chosen > to balance one set of considerations against a bunch of others, > and after ruminating over it a long time, the consensus was > 13 was the best choice. > -- --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 Dec 2 09:15:02 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA08075 for ipng-dist; Tue, 2 Dec 1997 09:12:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA08068 for ; Tue, 2 Dec 1997 09:11:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA20814 for ; Tue, 2 Dec 1997 09:11:49 -0800 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA09731 for ; Tue, 2 Dec 1997 07:32:36 -0800 (PST) Received: from rodan.UU.NET by relay5.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdsew09759; Tue, 2 Dec 1997 10:32:11 -0500 (EST) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdsew00938; Tue, 2 Dec 1997 10:31:43 -0500 (EST) Message-Id: To: bmanning@ISI.EDU cc: mo@UU.NET (Mike O'Dell), brian@hursley.ibm.com, sob@harvard.edu, bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, postel@ISI.EDU Subject: (IPng 5003) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-reply-to: Your message of "Tue, 02 Dec 1997 07:08:28 PST." <199712021508.AA13335@zed.isi.edu> Date: Tue, 02 Dec 1997 10:31:43 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i've read Pink, et al. it has to do with quick forwarding, not the computation which decides what goes in the forwarding table given all the possibilities to chose from. (longest match covering, AS path selection, etc, etc, etc) and i would love to be wrong - but even being wrong by a lot doesn't change the number of bits by a large amount given the way the size participates in the compuations. -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 09:47:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA08131 for ipng-dist; Tue, 2 Dec 1997 09:43:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA08124 for ; Tue, 2 Dec 1997 09:42:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA03412 for ; Tue, 2 Dec 1997 09:42:47 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA16990 for ; Tue, 2 Dec 1997 09:42:04 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA02322; Tue, 2 Dec 1997 09:41:31 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <348400A6.41C6@raleigh.ibm.com> References: <199712021158.MAA00484@cepc59.ce.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Dec 1997 09:42:35 -0800 To: otel@ce.chalmers.se, Brian Haberman From: Steve Deering Subject: (IPng 5004) Re: IGMPv6 specs. Cc: IPng Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am in the process of producing an IGMP-equivalent spec for IPv6, based on the version 2 IGMP spec for IPv4. I tried to get it done by the ID deadline, but didn't manage to finish it in time (and then, after missing the deadline, I put it aside to work on other things). I hope to finish it this week. At 3:58 AM -0800 12/2/97, Otel Florian-Daniel wrote: > I would like to know if there is any paper clarifying the use of IGMP > Group Membership Reduction packet (i.e. the specs for "IGMPv6"). The "Group Membership Reduction" message is the same as the "Leave Group" message in version 2 IGMP for IPv4. The name was changed for spurious reasons, and it's going to change again. I propose to use the following names for the IGMP-equivalent message types: Multicast Listener Query = IGMP Membership Query Multicast Listener Report = IGMP Membership Report Multicast Listener Done = IGMP Leave Group Also, for IPv6, the IGMP-equivalent messages are part of ICMPv6. I propose to call the IGMP part of ICMPv6 "Multicast Listener Discovery" (MLD), by analogy to the "Neighbor Discovery" (ND) part of ICMPv6. The term "IGMP" has become overloaded/ambiguous in IPv4, in that the IGMP Protocol (IP Protocol 2) includes not only the listener discovery messages (query/report/ leave), but also the multicast traceroute messages and DVMRP and PIM routing messages. I suggest that, for IPv6, Next Header value 2 should continue to be used for those other purposes. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 2 10:24:34 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA08212 for ipng-dist; Tue, 2 Dec 1997 10:21:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA08205 for ; Tue, 2 Dec 1997 10:20:57 -0800 (PST) From: bmanning@ISI.EDU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA18627 for ; Tue, 2 Dec 1997 10:20:51 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA29901 for ; Tue, 2 Dec 1997 07:09:49 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id HAA00796; Tue, 2 Dec 1997 07:09:25 -0800 (PST) Posted-Date: Tue, 2 Dec 1997 07:08:28 -0800 (PST) Message-Id: <199712021508.AA13335@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 2 Dec 1997 07:08:29 -0800 Subject: (IPng 5005) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard To: mo@uu.net (Mike O'Dell) Date: Tue, 2 Dec 1997 07:08:28 -0800 (PST) Cc: bmanning@ISI.EDU, mo@uu.net, brian@hursley.ibm.com, sob@harvard.edu, bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, postel@ISI.EDU In-Reply-To: from "Mike O'Dell" at Dec 2, 97 09:12:49 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > bill, > > i'm surprised by your remark. > i thought you have been around long enough to understand this. > we've been over all this before. > > the complexity of that computation is driven by two things - > the cardinality of the set of visible nodes in the global topology graph, > and the complexity of the topology connecting those nodes. > (note that "node" here does not imply a router but whole networks). > > of these two things, we cannot readily control the edge topology of the > graph, so we are only left with controlling the cardinality of the node set of > the graph if we wish to influence that complexity. > > of course, you can argue that we don't need to care about the problem - > that somehow processors will keep getting fast enough fast enough to > retain reasonable convergence times. > > but then you are betting on a race between two exponentials - > and are making the bet that the smaller exponent will win. > > i know *i* don't want to wager the future on that bet. > > -mo My argument is that the basic premise that the assumptions wrt the cardinality of the set of visable nodes in the topology graph -may- be wrong. Other than that, I agree with you. Chalk it up to a fit of Noel-Stev syndrome. With a bit of rest, I'm sure it will pass. (and I do recommend "Small Forwarding Tables for Fast Routing Lookup" from SigCom'97, which is one more reason why I think these arguments just might be off) -- --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 Dec 2 10:25:21 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA08221 for ipng-dist; Tue, 2 Dec 1997 10:22:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA08214 for ; Tue, 2 Dec 1997 10:21:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA19261 for ; Tue, 2 Dec 1997 10:21:40 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA08706 for ; Tue, 2 Dec 1997 07:30:21 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id KAA08355; Tue, 2 Dec 1997 10:28:21 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id KAA03753; Tue, 2 Dec 1997 10:28:16 -0500 (EST) Date: Tue, 2 Dec 1997 10:28:16 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971202102814.ZM3751@seawind.bellcore.com> In-Reply-To: bmanning@isi.edu "(IPng 5002) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard" (Dec 2, 4:48am) References: <199712021248.AA04171@zed.isi.edu> X-Mailer: Z-Mail (5.0.0 30July97) To: bmanning@isi.edu, mo@uu.net (Mike O'Dell) Subject: (IPng 5006) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard Cc: brian@hursley.ibm.com, sob@harvard.edu, bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, postel@isi.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Dec 2, 4:48am, bmanning@isi.edu wrote: > In short, I differ from Mike in that my values for "believed to be viable" > differ, apparently wildly, from his and brians. I'm unconvinced that > this will remain a true, long term technological argument. I'd like to > see something besides, "too hard with 1990's technologies". "Long time" > ought to have a better spec than say, Internet Dog Years? Bill, What you say is true. Technology is going to progress, and at some point in the future we may convince ourselves that we can safely handle 1,000,000 TLAs instead of 10,000. However: 1) We are not there yet. Andrew Brodnik et al demonstrated that one can efficiently compress today's routing tables in the cache of a Pentium chip. But their algorithm has yet to be implemented in commercial routers. 2) There is more to scaling than routers' caches. Compressing the tables in cache memory mainly allows you to switch packets faster than if your tables were kept in a slow RAM. It does not reduce route flaps, or the complexity of the topology. 3) In any case, we are taking decision today based on today's technology. As I pointed out, there is plenty of address space reserved for further use. If the technology does evolve, then it will be time to open more space. In short, limiting the size of TLA to 13 bits looks like a reasonable cut, today. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 2 10:39:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA08260 for ipng-dist; Tue, 2 Dec 1997 10:35:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA08253 for ; Tue, 2 Dec 1997 10:34:59 -0800 (PST) From: bmanning@ISI.EDU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA24835 for ; Tue, 2 Dec 1997 10:34:54 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA16948 for ; Tue, 2 Dec 1997 07:48:14 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id HAA01691; Tue, 2 Dec 1997 07:47:47 -0800 (PST) Posted-Date: Tue, 2 Dec 1997 07:46:51 -0800 (PST) Message-Id: <199712021546.AA27737@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 2 Dec 1997 07:46:51 -0800 Subject: (IPng 5007) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard To: huitema@bellcore.com (Christian Huitema) Date: Tue, 2 Dec 1997 07:46:51 -0800 (PST) Cc: bmanning@ISI.EDU, mo@uu.net, brian@hursley.ibm.com, sob@harvard.edu, bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, postel@ISI.EDU In-Reply-To: <971202102814.ZM3751@seawind.bellcore.com> from "Christian Huitema" at Dec 2, 97 10:28:16 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) We are not there yet. Andrew Brodnik et al demonstrated that one can > efficiently compress today's routing tables in the cache of a Pentium > chip. But their algorithm has yet to be implemented in commercial > routers. True. But how far off can that be? :) > 2) There is more to scaling than routers' caches. Compressing the tables > in cache memory mainly allows you to switch packets faster than if your > tables were kept in a slow RAM. It does not reduce route flaps, or > the complexity of the topology. One of the interesting side effects from the paper is the construct that appears to allow the creation of a true default free router i.e. one that has the ability to carry the total IPv4 space as host routes. a 13bit TLA does not reduce route flap nor moderate the complexity of the topology, which appear to have moved into the critical path. a 13bit TLA does give some breathing room by sanctioning a level of proxy aggregation. This method allows ISPs to lie to each other about the stability of their internal infrastructure, which is the current model for reducing the dynamics of the routing system. (Is it just me or is there really a joke being perpetrated by the attempts to present a stable routing infrastructure with dynamic routing protocols? :) > 3) In any case, we are taking decision today based on today's technology. > As I pointed out, there is plenty of address space reserved for further > use. If the technology does evolve, then it will be time to open > more space. Fine. Then this might be best served as a BCP and not standards track? Or are the concerns rasied by everyone but me strong enough to push this into the standards track? What I find interesting is that this particular addressing scheme has had less field time than the previous addressing scheme. Will there be yet another scheme fall out of the woodwork? Is there a reason why these schemes can't co-exist? And I'm not sure that the extra space will be available. Are you? > > In short, limiting the size of TLA to 13 bits looks like a reasonable cut, > today. Ok. I just thought I'd say my piece. > > -- > Christian Huitema > -- --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 Dec 2 11:09:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA08285 for ipng-dist; Tue, 2 Dec 1997 11:05:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA08278 for ; Tue, 2 Dec 1997 11:05:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA07076 for ; Tue, 2 Dec 1997 11:05:03 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA08423 for ; Tue, 2 Dec 1997 11:04:58 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA22477; Tue, 2 Dec 1997 13:03:19 -0600 Message-Id: <199712021903.NAA22477@gungnir.fnal.gov> To: bmanning@ISI.EDU Cc: iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net From: "Matt Crawford" Subject: (IPng 5008) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-reply-to: Your message of Tue, 02 Dec 1997 07:46:51 PST. <199712021546.AA27737@zed.isi.edu> Date: Tue, 02 Dec 1997 13:03:19 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Remember the mantra we've all been chanting ever since Palo Alto: "It's not the size of the forwarding table; it's the amount of computation it takes to produce it." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 13:07:00 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA08384 for ipng-dist; Tue, 2 Dec 1997 12:59:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA08377 for ; Tue, 2 Dec 1997 12:59:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA21071 for ; Tue, 2 Dec 1997 12:59:14 -0800 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA08905 for ; Tue, 2 Dec 1997 06:17:59 -0800 (PST) Received: from rodan.UU.NET by relay1.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdser12927; Tue, 2 Dec 1997 09:17:04 -0500 (EST) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdseq15523; Tue, 2 Dec 1997 09:12:49 -0500 (EST) Message-Id: To: bmanning@isi.edu cc: mo@uu.net (Mike O'Dell), brian@hursley.ibm.com, sob@harvard.edu, bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@cisco.com, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, postel@isi.edu Subject: (IPng 5009) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-reply-to: Your message of "Tue, 02 Dec 1997 04:48:36 PST." <199712021248.AA04171@zed.isi.edu> Date: Tue, 02 Dec 1997 09:12:49 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bill, i'm surprised by your remark. i thought you have been around long enough to understand this. we've been over all this before. the problem is not now, nor has it ever been, the size of the forwarding table measured in any unit - routes, bytes, feet, or kilograms. (yes, there have been a few episodes where gross inadequacies of popular hardware created *serious* tactical headaches, but don't confuse that with the underlying problem.) the fundamental problem is the complexity of the computation which produces the forwarding table from many, many of copies various subsets of the global routing information. the complexity of that computation is driven by two things - the cardinality of the set of visible nodes in the global topology graph, and the complexity of the topology connecting those nodes. (note that "node" here does not imply a router but whole networks). of these two things, we cannot readily control the edge topology of the graph, so we are only left with controlling the cardinality of the node set of the graph if we wish to influence that complexity. of course, you can argue that we don't need to care about the problem - that somehow processors will keep getting fast enough fast enough to retain reasonable convergence times. but then you are betting on a race between two exponentials - and are making the bet that the smaller exponent will win. i know *i* don't want to wager the future on that bet. -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 13:50:32 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA08438 for ipng-dist; Tue, 2 Dec 1997 13:47:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA08431 for ; Tue, 2 Dec 1997 13:47:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA01656 for ; Tue, 2 Dec 1997 13:47:34 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA00058 for ; Tue, 2 Dec 1997 05:55:41 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id OAA18894; Tue, 2 Dec 1997 14:55:32 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA01799; Tue, 2 Dec 1997 14:55:31 +0100 (MET) Message-Id: <199712021355.OAA01799@givry.inria.fr> From: Francis Dupont To: otel@ce.chalmers.se cc: ipng@sunroof.eng.sun.com Subject: (IPng 5010) Re: IGMPv6 specs. In-reply-to: Your message of Tue, 02 Dec 1997 12:58:21 +0100. <199712021158.MAA00484@cepc59.ce.chalmers.se> Date: Tue, 02 Dec 1997 14:55:27 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I would like to know if there is any paper clarifying the use of IGMP Group Membership Reduction packet (i.e. the specs for "IGMPv6"). => I have adapted a version of IGMPv2 draft (now it is RFC 2236) for IPv6. There is a difference between old ICMPv6 specs and it, obviously old ICMPv6 specs are too old and in the current draft there is nothing about the Group Membership Management. I don't know if an IGMPv6 spec is in the ASAP plan (ask next week :-) but I think the RFC 2236 should be the good spec for today. Regards Francis.Dupont@inria.fr PS: the problem is the destination address of reduction packets, isn't it ? PPS: I can send my draft to you but it is only a large cut and replace in the ICMPv2 draft with near no not-obvious things... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 3 07:14:47 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA09274 for ipng-dist; Wed, 3 Dec 1997 07:12:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA09267 for ; Wed, 3 Dec 1997 07:11:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA07562 for ; Wed, 3 Dec 1997 07:11:52 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA27470 for ; Wed, 3 Dec 1997 07:11:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20276; Wed, 3 Dec 1997 10:11:47 -0500 (EST) Message-Id: <199712031511.KAA20276@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5011) I-D ACTION:draft-ietf-ipngwg-addrconf-v2-01.txt Date: Wed, 03 Dec 1997 10:11:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson, T. Narten Filename : draft-ietf-ipngwg-addrconf-v2-01.txt Pages : 25 Date : 02-Dec-97 This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addrconf-v2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addrconf-v2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addrconf-v2-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971202094016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addrconf-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addrconf-v2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971202094016.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 3 08:47:07 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA09435 for ipng-dist; Wed, 3 Dec 1997 08:44:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA09428 for ; Wed, 3 Dec 1997 08:44:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA06674 for ; Wed, 3 Dec 1997 08:44:03 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA16002 for ; Wed, 3 Dec 1997 08:44:08 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id LAA18936 for ; Wed, 3 Dec 1997 11:43:57 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA34938 for ; Wed, 3 Dec 1997 11:43:59 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17476; Wed, 3 Dec 1997 11:43:52 -0500 Message-Id: <9712031643.AA17476@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5012) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-01.txt In-Reply-To: Your message of "Wed, 03 Dec 1997 10:11:46 EST." <199712031511.KAA20276@ns.ietf.org> Date: Wed, 03 Dec 1997 11:43:52 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, this draft makes the following changes over v2-00.txt: 1) Some minor wordsmithing. 2) The processing of prefix options with lifetimes between 0 and 2 hours has been changed to match option 3) in the note I sent out under the subject: (IPng 4861) RAs with 0 lifetime prefix (take II). Subsequent email suggested that there was a slight preference for this approach over the other proposals. Hopefully we'll be able to reach consensus in DC on which approach to use. In the meantime, please feel free to check the wording (I've included it, since its relatively short). Here are the rules related to the processing of received Prefix-Information options: For each Prefix-Information option in the Router Advertisement: a) If the Autonomous flag is not set, silently ignore the Prefix Information option. b) If the prefix is the link-local prefix, silently ignore the Prefix Information option. c) If the preferred lifetime is greater than the valid lifetime, silently ignore the Prefix Information option. A node MAY wish to log a system management error in this case. d) If the prefix advertised does not match the prefix of an address | already in the list, and the Valid Lifetime is not 0, form an | address (and add it to the list) by appending the interface | identifier to the prefix as described below. | e) If the advertised prefix matches the prefix of an autoconfigured | address (i.e., one obtained via stateless or stateful address | autoconfiguration) in the list of addresses associated with the | interface, the specific action to perform depends on the Valid | Lifetime in the received advertisement and the Lifetime | associated with the previously autoconfigured address (which we | call StoredLifetime in the discussion that follows): 1) If the received Lifetime is greater than 2 hours or greater | than StoredLifetime, form an address (and add it to the list) | by appending the interface identifier to the prefix as | described below. | 2) If the StoredLifetime is less than 2 hours and the received | Lifetime is less than StoredLifetime, ignore the prefix. | 3) Otherwise, reset the Lifetime in the received advertisement to | 2 hours and form an address (and add it to the list) by | appending the interface identifier to the prefix as described | below. | The above rules address a specific denial of service attack in | which a bogus advertisement could contain prefixes with very | small Valid Lifetimes. Without the above rules, a single bogus | advertisement containing Prefix Information options with short | Lifetimes could cause all of a node's addresses to expire | prematurely. The above rules insure that legitimate | advertisements (which are sent periodically) will "cancel" the | short lifetimes before they actually take effect. | 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 Dec 3 11:25:33 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA09780 for ipng-dist; Wed, 3 Dec 1997 11:22:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA09773 for ; Wed, 3 Dec 1997 11:22:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA26510 for ; Wed, 3 Dec 1997 11:22:05 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA15190 for ; Wed, 3 Dec 1997 11:22:13 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA26450; Wed, 3 Dec 1997 14:22:02 -0500 (EST) Message-Id: <199712031922.OAA26450@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5013) I-D ACTION:draft-ietf-ipngwg-discovery-v2-01.txt Date: Wed, 03 Dec 1997 14:22:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : W. Simpson, T. Narten, E. Nordmark Filename : draft-ietf-ipngwg-discovery-v2-01.txt Pages : 91 Date : 02-Dec-97 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-v2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-v2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-v2-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971202170715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-v2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971202170715.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 3 12:28:26 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA09935 for ipng-dist; Wed, 3 Dec 1997 12:25:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA09928 for ; Wed, 3 Dec 1997 12:24:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA15978 for ; Wed, 3 Dec 1997 12:24:08 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA18689 for ; Wed, 3 Dec 1997 12:24:15 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id UAA23199; Wed, 3 Dec 1997 20:18:33 GMT From: "Peter Curran" To: , "Thomas Narten" Subject: (IPng 5014) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-01.txt Date: Wed, 3 Dec 1997 20:32:20 -0000 Message-ID: <01bd002a$8e5a2220$0f0120c1@desktop.ticl.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0081_01BD002A.8E41B820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0081_01BD002A.8E41B820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Referring to section 5.3 of this I-D (addrconf-v2): A link-local address is formed by prepending the well-known link- local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the interface identifier. If the interface identifier has a length of N | bits, the interface identifier replaces the right-most N zero bits of | the link-local prefix. If the interface identifier is more than 118 | bits in length, autoconfiguration fails and manual configuration is required. Could you explain why this new syntax has been introduced. According to addrarch-v2, a link local address is formed by appending a 64-bit interface ID to the prefix fe80::/64. It specifically states that the interface ID is 64 bits. In the snip above it suggests that the interface ID may be up to 118 bits long. I find this confusing, because: 1. There is a conflict between the two documents that are both at the same 'revision' level. 2. The same interface ID is used to generate the other unicast addresses, and here it is definately going to be 64 bits long because of the location of the SLA/Subnet ID field. 3. We are told later in the addrconf-v2 document that the interface ID is presumed unique once DAD has been performed against the link-local address. Surely this can only apply to a 64-bit interface ID. Am I missing something here? Regards Peter Curran TICL ------=_NextPart_000_0081_01BD002A.8E41B820 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0TCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoXDTk5MDYyNzIz NTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYD VQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOOLPhvltcunXZLEbE2jVfJw/0c xrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5912dFEObbpdFmIFH0S3L3bty10w/ cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+qQIDAQABozMwMTAPBgNVHRMECDAGAQH/ AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3 AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6VmQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+ lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0ilZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs 6SxQv6b5DduwpkowggQQMIIDeaADAgECAhApF9yEa2f1I6vNhJOMYHGgMA0GCSqGSIb3DQEBBAUA MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMr VmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzExMjEwMDAw MDBaFw05ODAxMjAyMzU5NTlaMIIBDTERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4g YnkgUmVmLixMSUFCLkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNy b3NvZnQxFTATBgNVBAMTDFBldGVyIEN1cnJhbjEhMB8GCSqGSIb3DQEJARYScGN1cnJhbkB0aWNs LmNvLnVrMFswDQYJKoZIhvcNAQEBBQADSgAwRwJAbGS4S0SN7NX2OODlfiOves53hbLKytcxawKy ipnvwVqlHCtugU+GznF/cq3jvMQeehvX+9+lxts1Q7BXxw9QuQIDAQABo4IBXTCCAVkwCQYDVR0T BAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVy aVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2 M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2Rh NWMxZTMxNDFiZWFkYjJiZDI5YWZhMTJiZDY4OTFhMTExNDk5OGExYmE0M2Y0ZTY5MTY1NDEwDQYJ KoZIhvcNAQEEBQADgYEAUXbKrrDI9DdxdSL9W4pMtNBTZpFV9yMkBkiKdSOwdjmSh3/qPl11P/HM KDT9CtIXpeT0JcUlkZsXaGkLGZnVWHvsqjUyvqT6XOCy1Vm1VokROmbfFItKacbTwoQsArhISOYB DdUOwpZiD/HEdCTnTb4r6bC3MZ+6afsCn0zi//sxggE6MIIBNgIBATB2MGIxETAPBgNVBAcTCElu dGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQKRfchGtn9SOrzYSTjGBxoDAJBgUrDgMCGgUA oF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTcxMjAzMjAzMjIw WjAjBgkqhkiG9w0BCQQxFgQUPTu0ki1Zb5Nfx4W4mKfHCOu3hyAwDQYJKoZIhvcNAQEBBQAEQBGs 0soHKtZItBKYHQ/fz1ja5ic2Nsmy8Iht76QTgDTJSKuDQqB2f2lTEjIyKSYO7XgOM0wm/glnKQ0l rvXo8hgAAAAAAAA= ------=_NextPart_000_0081_01BD002A.8E41B820-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 3 19:30:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id TAA10794 for ipng-dist; Wed, 3 Dec 1997 19:25:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id TAA10787 for ; Wed, 3 Dec 1997 19:25:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA05338 for ; Wed, 3 Dec 1997 19:25:06 -0800 Received: from snoopy.lucentmmit.com (smtp.Lucentmmit.com [38.160.171.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id TAA03872 for ; Wed, 3 Dec 1997 19:25:15 -0800 (PST) Received: by SNOOPY with Internet Mail Service (5.0.1457.3) id ; Wed, 3 Dec 1997 20:32:35 -0500 Message-ID: From: "Conta, Alex" To: "'ion@nexen.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5015) FYI: two new ION-IPv6 drafts Date: Wed, 3 Dec 1997 20:32:33 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following new drafts: draft-conta-ion-ipv6-fr-00.txt (Transmission of IPv6 packets over FR networks, by A.Conta, A.Malis, M. Mueller) draft-conta-ion-ipv6-ind-00.txt (Extensions to IPv6 ND for Inverse Discovery, by A.Conta) were submitted for discussion to the ION/IPng WGs (they were announced on the IETF exploder) They obsolete two previous drafts: draft-conta-ipv6-trans-fr-00.txt draft-conta-ipv6-nd_ext_ind-00.txt Comments/suggestions are welcome. Thanks, Alex Conta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 4 06:21:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA11162 for ipng-dist; Thu, 4 Dec 1997 06:19:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA11155 for ; Thu, 4 Dec 1997 06:18:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA23767 for ; Thu, 4 Dec 1997 06:18:32 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA16044 for ; Thu, 4 Dec 1997 06:18:42 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id JAA17156; Thu, 4 Dec 1997 09:18:30 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA37360; Thu, 4 Dec 1997 09:18:32 -0500 Received: from ludwigia.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19876; Thu, 4 Dec 1997 09:18:29 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id HAA02858; Thu, 4 Dec 1997 07:05:16 -0500 Message-Id: <199712041205.HAA02858@hygro.raleigh.ibm.com> To: "Peter Curran" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5016) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-01.txt In-Reply-To: Your message of "Wed, 03 Dec 1997 20:32:20 GMT." <01bd002a$8e5a2220$0f0120c1@desktop.ticl.co.uk> Date: Thu, 04 Dec 1997 07:05:15 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, > Referring to section 5.3 of this I-D (addrconf-v2): > A link-local address is formed by prepending the well-known link- > local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the > interface identifier. If the interface identifier has a length of N | > bits, the interface identifier replaces the right-most N zero bits of | > the link-local prefix. If the interface identifier is more than 118 | > bits in length, autoconfiguration fails and manual configuration is > required. > Could you explain why this new syntax has been introduced. Actually, the above text isn't "new". It's is a hold over from what's in the RFC. > According to addrarch-v2, a link local address is formed by > appending a 64-bit interface ID to the prefix fe80::/64. It > specifically states that the interface ID is 64 bits. In the snip > above it suggests that the interface ID may be up to 118 bits long. Actually, addrarch-v2 states that format prefixes 001-111 are required to use the EUI-64 interface identifier format, but format prefix 000 is "reserved/unassigned" and does not have this requirement. If its usage is ever defined, it may well be that EUI-64 interface identifiers will be required. But I think the intent is to leave this open for now. There are also other places in the addressing document where the text describes interface identifiers as n-bit quantities without stating that they are 64 bits. While the current text may be confusing, I don't believe it is incorrect. Changing the text to use 64-bit interface identifiers would also necessitate adding caveates that this only applies to some of the format prefixes. I'd prefer to leave those sorts of details in the addressing architecture document. If there is disagreement with this, what specific wording changes would be suggested? 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 Dec 4 07:24:47 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA11186 for ipng-dist; Thu, 4 Dec 1997 07:22:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA11179 for ; Thu, 4 Dec 1997 07:21:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA11297 for ; Thu, 4 Dec 1997 07:21:47 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA14904 for ; Thu, 4 Dec 1997 07:21:54 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA17010; Thu, 4 Dec 1997 10:21:42 -0500 (EST) Message-Id: <199712041521.KAA17010@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5017) I-D ACTION:draft-ietf-ipngwg-tla-assignment-02.txt Date: Thu, 04 Dec 1997 10:21:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : TLA and NLA Assignment Rules Author(s) : B. Hinden Filename : draft-ietf-ipngwg-tla-assignment-02.txt Pages : 6 Date : 03-Dec-97 This document defines assignment rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tla-assignment-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-tla-assignment-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971203164141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tla-assignment-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203164141.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 4 08:15:39 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA11323 for ipng-dist; Thu, 4 Dec 1997 08:12:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA11316 for ; Thu, 4 Dec 1997 08:12:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28473 for ; Thu, 4 Dec 1997 08:12:35 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA10236 for ; Thu, 4 Dec 1997 08:12:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18878; Thu, 4 Dec 1997 11:12:23 -0500 (EST) Message-Id: <199712041612.LAA18878@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5018) I-D ACTION:draft-ietf-ipngwg-dns-reverse-lookup-00.txt Date: Thu, 04 Dec 1997 11:12:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Reverse Address lookup in DNS for IPng. Author(s) : O. Gudmundsson Filename : draft-ietf-ipngwg-dns-reverse-lookup-00.txt Pages : 10 Date : 03-Dec-97 This document proposes a new mechanism to represent inverse address mapping in the Domain Name System (DNS) for IP version 6 (IPv6). Documented in here are the changes needed for securing the binding and delegation of address ranges, to facilitate queries for the binding of address to host name. This document also defines a mechanism for dumb resolvers to query directly for the binding. The changes include a new resource record to delegate the address space in segments based on arbitrary bit boundaries. This proposal provides a mechanism that is self checking and can be traversed from both top and bottom. Additional processing requirements on IPv6 aware resolvers and servers are defined. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-dns-reverse-lookup-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-dns-reverse-lookup-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-dns-reverse-lookup-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971203171448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-reverse-lookup-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-reverse-lookup-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203171448.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 4 09:41:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA11383 for ipng-dist; Thu, 4 Dec 1997 09:36:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA11376 for ; Thu, 4 Dec 1997 09:36:47 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA23268 for ; Thu, 4 Dec 1997 09:36:43 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA27951 for ; Thu, 4 Dec 1997 09:36:34 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA00691; Thu, 4 Dec 1997 11:40:55 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA17250; Thu, 4 Dec 1997 11:40:09 -0500 Message-Id: <199712041640.AA17250@wasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: bmanning@ISI.EDU, mo@uu.net (Mike O'Dell), brian@hursley.ibm.com, sob@harvard.edu, bound@zk3.dec.com, Daniel.Karrenberg@ripe.net, davidc@apnic.net, deering@Cisco.COM, hinden@ipsilon.com, iesg@ns.ietf.org, ipng@sunroof.eng.sun.com, ipv6-wg@ripe.net, k13@nikhef.nl, kimh@internic.net, lir-wg@ripe.net, postel@ISI.EDU Subject: (IPng 5019) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Tue, 02 Dec 1997 10:28:16 EST." <971202102814.ZM3751@seawind.bellcore.com> Date: Thu, 04 Dec 1997 11:40:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In short, limiting the size of TLA to 13 bits looks like a reasonable cut, >today. I want to add that for the TLA and AAAA record discussion I see nothing wrong with having a stage 1 solution and then stage 2 and we create the backwards compatibility as implementors. I realize we need to provide the best solution for dynamic addressing and for ISPs. But right now real customers want IPv6 on "Intranets", or private enterprises. We will see several products this year and customers will be able to start deploying IPv6 from vendors. Many customers do not want to move to private addresses and a total v4 NAT solution who need addresses today. They want to move to IPv6 and have a plan to participate on the Internet even before the ISPs start supporting their needs for IPv6. I will also say that Europe and Asia appear to be moving much faster than the U.S. ISPs to be IPv6 ready. The point of this mail is that we implementors of IPv6 can absorb updates to the Address Architecture and AAAA records and we have changed the addr arch twice and once enough where we updated our code on the 6bone, and are using the new specs. The implementors will do the changes we develop and that should not be a fear of anyone IMO. The essential architecture of IPv6 is done and most of us have our code base prep'd to support the evolutionary IPv6 fine tuning by this working group. It is not difficult to move forward here with changes. One of the things that has always driven the IETF processes is the "market". There is now a market for IPv6 and they want it right now. We need to give it to them as vendors, and I hope we view that need in our deliberations. Also we have some new players at the UNH bake-off this week and one of them is Microsoft. This is really good. /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 Dec 4 15:10:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA11759 for ipng-dist; Thu, 4 Dec 1997 14:57:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA11752 for ; Thu, 4 Dec 1997 14:57:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA24727 for ; Thu, 4 Dec 1997 14:57:05 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA09728 for ; Thu, 4 Dec 1997 14:57:09 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA29812; Thu, 4 Dec 1997 16:55:44 -0600 Message-Id: <199712042255.QAA29812@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5020) Re: I-D ACTION:draft-ietf-ipngwg-dns-reverse-lookup-00.txt In-reply-to: Your message of Thu, 04 Dec 1997 11:12:23 EST. <199712041612.LAA18878@ns.ietf.org> Date: Thu, 04 Dec 1997 16:55:44 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It looks to me like an authoritative server that holds some DBIT records with a non-zero value in the "last bit" field will have to not only have its data changed (and re-signed) when renumbering occurs higher in the address tree, but the set of zones for which the server is authoritative will also change! This seems to be a step further from the ideal, at least in one dimension of the problem space. 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 Thu Dec 4 15:41:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA11782 for ipng-dist; Thu, 4 Dec 1997 15:14:53 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA11775 for ; Thu, 4 Dec 1997 15:14:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA00996 for ; Thu, 4 Dec 1997 15:14:39 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA19057 for ; Thu, 4 Dec 1997 15:14:47 -0800 (PST) Received: by INET-02-IMC with Internet Mail Service (5.5.1960.3) id ; Thu, 4 Dec 1997 15:14:36 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810D022DD@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'nordmark@sun.com'" Cc: "'IPng List'" Subject: (IPng 5021) draft-ietf-ipngwg-site-prefixes-01.txt Date: Thu, 4 Dec 1997 15:14:34 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft fleshes out purpose & mechanism for site-local addresses. Overall I like the idea. The draft seems to assume that nodes will assign site-local addresses to their interfaces. There's no requirement for this in the addressing architecture (see section 2.8 - required addresses). I suggest that a node assign a site-local address to an interface based on the prefix information option in RAs (hosts when receiving RAs, routers if they will be sending such RAs). Basically if a site prefix matches a global address assigned to the interface, then assign the site-local address to the interface. Note this means that some interfaces might not have a site-local address assigned. In particular, some installations might choose not to use this mechanism or site-local addresses at all. Some links will belong to a site and some links will not belong to a site. A link can not belong to more than one site. I don't like the provision in 7.1 that global addresses be removed from the list of addresses returned from the name server. I think the addresses should be ordered, with site-local before global. Naive applications will probably just use the first address in the list. More sophisticated applications might go down the list until they get one that works; if for some reason there's a problem with the site-local address they should have the opportunity to try a global address. However I don't know much about how real applications respond when a name lookup returns multiple addresses. In section 6, should the prefix lengths be validated, ie ignore prefix if Site PLength > Prefix Length? This seems like a good precaution. There needs to be something about on-link determination for site-local addresses. When a node (assume single-homed for the moment) sends to a site-local address, does it use ND, send the packet to a router, or what? For example, suppose that a node has received the following prefixes: site prefixes: 2837:a:b::/48 and 2000:1:2::/48 on-link prefixes: 2837:a:b:c::/64 and 2000:1:2:c::/64 The node looks up the global address 2837:a:b:c:W:X:Y:Z and ends up sending to fec0:0:0:c:W:X:Y:Z. This site-local address is on-link. But there are cases where inconsistent prefix information leads to bad situations - where a site-local address will look to be on-link, but the original global address would not be on-link. For example: site prefixes: 2837:a:b::/48 and 2000:1:2::/48 on-link prefixes: 2837:a:b:c::/64 and 2000:1:2:3::/64 Global address 2837:a:b:3:W:X:Y:Z is not on-link. It is converted to site-local address fec0:0:0:3:W:X:Y:Z, which is on-link. An implementation can detect when this is a risk - so a diagnostic could be issued, or conversion to site-local addresses could be disabled. Or we could ignore this issue, if a network admin screws up so be it. Section 8 (nodes that are multihomed to multiple sites) needs more thought for me. For one thing, the remark about placing site boundaries between nodes is too cryptic. Thinking through this... It seems like the most important case to consider here is a node N with one interface I1 in a site and another interface I2 that is not in a site and does not have a site-local address assigned. For example a border router. I think this case will work just fine. When such a node N does name lookups for a node D with global address DAg, if DAg is within the site the name lookup will return site-local address DAs and global address DAg. The application will try to send to DAs, that being the first address returned. The implementation on node N will need to pick an interface and source address. Looking at DAs, it can pick interface I1 and site-local address NAs, because I1 has a site-local address assigned and I2 doesn't. On the other hand, if DAg is external, it does not match a prefix in the Site Prefix List. Then the application will try to send to DAg and the routing module should pick interface I2 (the one not in the site) and then pick a source address NAg assigned to interface I2. So I don't see any problems there. Now suppose that node N has interface I1 in one site and interface I2 in another site. This means that I1 has site prefix SP1 and I2 has site prefix SP2. When the node tries to send to a site-local address, there's no way to tell which interface to use (without explicit disambiguation by the application). So node N disables use of site-local addresses. Also OK. I think the algorithm in section 8.1 could be more clearly stated. I think you want the transitive closure of the "share at least one site prefix" relation. 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 Thu Dec 4 22:57:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id WAA12391 for ipng-dist; Thu, 4 Dec 1997 22:53:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id WAA12384 for ; Thu, 4 Dec 1997 22:53:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA27990 for ; Thu, 4 Dec 1997 22:53:49 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id WAA13882 for ; Thu, 4 Dec 1997 22:53:59 -0800 (PST) Received: from spruce.ipsilon.com ([205.226.22.76]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id WAA00289; Thu, 4 Dec 1997 22:53:48 -0800 Message-Id: <3.0.3.32.19971204225254.00b18220@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Dec 1997 22:52:54 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5022) Draft IPng Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the draft IPng agenda for next weeks IETF meeting. Please send corrections, changes, additions to me. Thanks, Bob ---------------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Status of moving base specs to Draft Standard / R. Hinden (5 min) TLA/NLA Assignment Rules Status / R. Hinden (15 min) Resolve Neighbor Discovery and Addr Conf issues / T. Narten (20 min) Interface Identifier Global Flag / S. Deering (10 min) IPv6/NBMA Status / G. Armitage (10 min) IPv6 over PVC ATM / K. Yamamoto (10 min) Socks64 work / Fujitsu (10 min) Mobile IPv6 Status / D. Johnson (10 min) THURSDAY, December 11, 1997, 0900-1130, (Empire Room) Router Renumbering / M. Crawford (20 min) DNS mappings / C. Huitema (20 min) Other DNS Presentations (20 min) Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound (10 min) Traceroute hop-by-hop option / A. Durand (10 min) ECN Bit Assignment / S. Floyd (20 min) Router Alert / C. Partridge (10 min) FRIDAY, December 12, 1997, 0900-1130, (Empire Room) IGMP for IPv6 / S. Deering (15 min) Neighbor Discovery over Tunnels / S. Deering (15 min) IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta (10 min) IPv6 Name Lookups Through ICMP / M. Crawford (15 min) Reverse Address lookup in DNS for IPng / O. Gudmundsson (15 min) Site prefixes in Neighbor Discovery / E. Nordmark (15 min) VRRP for IPv6 / R. Hinden (15 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 5 02:12:51 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id CAA12538 for ipng-dist; Fri, 5 Dec 1997 02:10:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id CAA12531 for ; Fri, 5 Dec 1997 02:09:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA21610 for ; Fri, 5 Dec 1997 02:09:57 -0800 Received: from scol.sco.com (scol.london.sco.COM [150.126.1.48]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id CAA15852 for ; Fri, 5 Dec 1997 02:10:06 -0800 (PST) Received: from nowhere.pd.london.sco.com by scol.sco.COM id aa05110; 5 Dec 97 9:47 GMT X-Uri: X-Face: "Ht#9&2KEo;v0Jn!m[7V}D}F5>{KUiNw cc: ipng@sunroof.eng.sun.com Subject: (IPng 5023) Re: comments on bsd-api-new-00 In-reply-to: Your message of "Fri, 21 Nov 1997 12:46:42 EST." <199711211746.AA02736@wasted.zk3.dec.com> Date: Fri, 05 Dec 1997 09:47:52 +0000 Message-ID: <7988.881315272@sco.COM> From: Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'd like to suggest a slightly different take on the default behavior of > gethostbyname3() (i.e. when flags == 0). The default (flags == 0) > behavior should be: > > - returns a pointer to a buffer of the same type as gethostbyname(), > be that static or per-thread static or whatever else today's > implementations might be doing; the caller must set a flag > e.g. AI_ALLOC to cause gethostbyname3() to return dynamically > allocated memory, and only then is the caller required to free > the pointer using freehostent() > - if the 'af' argument is AF_INET6, gethostbyname3() may return > IPv4-mapped IPv6 addresses and non-IPv4-mapped IPv6 addresses; > the choice of when to return a v4-mapped address or a non-v4-mapped > IPv6 address is left to the implementation; the caller must set a > flag e.g. AI_NOV4MAPPED to restrict the returned addresses to > non-v4-mapped IPv6 addresses > > This provides a simple port from gethostbyname to gethostbyname3 > for programs using AF_INET6 sockets: > > gethostbyname(host) -> gethostbyname3(host, AF_INET6, 0) Hmmm, there's something in this, even though it makes me gag. Would gethostbyname2() be more appropriate? How about AI_NOALLOC flag instead (use thread-safe static if supported, or static otherwise). These would be handy (because then everything could be written in terms of gethostbyname3()). Then the mapping would be; gethostbyname(host) -> gethostbyname3(host, AF_INET6, AI_NOALLOC|AI_V4MAPPED) > Perhaps AI_V6ADDRCONFIG should be the default behavior as well, > and require the caller to set a flag e.g. AI_IGNORE_ADDR_CONFIG that > says "I want the address(es) for this name regardless of the types > of addresses configured on the system". In any event such a flag > should not be limited to IPv6 addresses, one might also find an A > record for a node but have no IPv4 stack (or address) and therefore > not bother returning the IPv4 address. Again just add this to the mapping above. We want to make gethostbyname3() generic enough that it can do anything we'd like to do -- do we want to make it more complex just so it's slightly easier to port applications? > As for gethostbyaddr(), I don't think we should simply change the function > to return dynamically allocated memory by default. We must consider source > and binary compatibility for existing users of gethostbyaddr(). Yes, I don't like this one either. This would be a nightmare. Please please plase call the function gethostbyaddr3() -- that way you'd have symmetry on the names and functionality. --- Harvey Thompson harveyt@sco.com internet Engineering Group, SCO, London UK. +44 1923 813583 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 5 07:35:02 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA12769 for ipng-dist; Fri, 5 Dec 1997 07:31:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA12762 for ; Fri, 5 Dec 1997 07:30:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA07531 for ; Fri, 5 Dec 1997 07:30:55 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA09068 for ; Fri, 5 Dec 1997 07:30:57 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14247; Fri, 5 Dec 1997 10:30:42 -0500 (EST) Message-Id: <199712051530.KAA14247@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5024) I-D ACTION:draft-ietf-ipngwg-router-renum-02.txt Date: Fri, 05 Dec 1997 10:30:42 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Router Renumbering for IPv6 Author(s) : B. Hinden, M. Crawford Filename : draft-ietf-ipngwg-router-renum-02.txt Pages : 19 Date : 04-Dec-97 IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [SAA] conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering (''RR'') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-router-renum-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-router-renum-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971204110439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204110439.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 5 07:49:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA12808 for ipng-dist; Fri, 5 Dec 1997 07:46:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA12801 for ; Fri, 5 Dec 1997 07:46:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA12955 for ; Fri, 5 Dec 1997 07:46:34 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA17314 for ; Fri, 5 Dec 1997 07:46:36 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14823; Fri, 5 Dec 1997 10:46:21 -0500 (EST) Message-Id: <199712051546.KAA14823@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5025) I-D ACTION:draft-ietf-ipngwg-ipv6-spec-v2-01.txt Date: Fri, 05 Dec 1997 10:46:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-ipv6-spec-v2-01.txt Pages : 41 Date : 04-Dec-97 This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-spec-v2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971204135518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-spec-v2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204135518.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 5 09:36:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA13067 for ipng-dist; Fri, 5 Dec 1997 09:33:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA13060 for ; Fri, 5 Dec 1997 09:33:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA15701 for ; Fri, 5 Dec 1997 09:32:19 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA16375 for ; Fri, 5 Dec 1997 09:32:05 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA09531; Fri, 5 Dec 1997 11:59:07 -0500 (EST) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25620; Fri, 5 Dec 1997 11:59:02 -0500 Date: Fri, 5 Dec 1997 11:59:02 -0500 From: Jack McCann Message-Id: <199712051659.AA25620@wasted.zk3.dec.com> To: harveyt@sco.com Subject: (IPng 5026) Re: comments on bsd-api-new-00 Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From harveyt@sco.com Fri Dec 5 05:18:55 1997 >To: Jack McCann >Cc: ipng@sunroof.eng.sun.com >Subject: Re: (IPng 4943) comments on bsd-api-new-00 >Date: Fri, 05 Dec 1997 09:47:52 +0000 >From: Harvey Thompson > > >> I'd like to suggest a slightly different take on the default behavior of >> gethostbyname3() (i.e. when flags == 0). The default (flags == 0) >> behavior should be: >> >> - returns a pointer to a buffer of the same type as gethostbyname(), >> be that static or per-thread static or whatever else today's >> implementations might be doing; the caller must set a flag >> e.g. AI_ALLOC to cause gethostbyname3() to return dynamically >> allocated memory, and only then is the caller required to free >> the pointer using freehostent() > >> - if the 'af' argument is AF_INET6, gethostbyname3() may return >> IPv4-mapped IPv6 addresses and non-IPv4-mapped IPv6 addresses; >> the choice of when to return a v4-mapped address or a non-v4-mapped >> IPv6 address is left to the implementation; the caller must set a >> flag e.g. AI_NOV4MAPPED to restrict the returned addresses to >> non-v4-mapped IPv6 addresses >> >> This provides a simple port from gethostbyname to gethostbyname3 >> for programs using AF_INET6 sockets: >> >> gethostbyname(host) -> gethostbyname3(host, AF_INET6, 0) > >Hmmm, there's something in this, even though it makes me gag. What makes you gag? I could use a good gag right about now. :-) >Would gethostbyname2() be more appropriate? gethostbyname2() won't look for both A and AAAA records, it does either A or AAAA but not both. > How about AI_NOALLOC flag instead >(use thread-safe static if supported, or static otherwise). > >These would be handy (because then everything could be written in terms >of gethostbyname3()). > >Then the mapping would be; > >gethostbyname(host) -> gethostbyname3(host, AF_INET6, AI_NOALLOC|AI_V4MAPPED) > Yes, this would achieve the same result, just invert the sense of the flags: AI_ALLOC instead of AI_NOALLOC because dynamic hostent allocation is a new feature, existing gethostbyname() users must deliberately select it and provide the corresponding freehostent() call. AI_NOV4MAPPED instead of AI_V4MAPPED because most users just want an address they can use for subsequent communication (e.g. connect or sendto). It's the advanced user that has some concept of v4-mapped addresses and knows they do not want them, so let that user set a flag to get the desired behavior. AI_IGNORE_ADDR_CONFIG instead of AI_V6ADDRCONFIG for similar reasons: most users want an address they can use for subsequent communication, it's the special case that wants to know the address regardless of whether it can be used for subsequent communications. >> Perhaps AI_V6ADDRCONFIG should be the default behavior as well, >> and require the caller to set a flag e.g. AI_IGNORE_ADDR_CONFIG that >> says "I want the address(es) for this name regardless of the types >> of addresses configured on the system". In any event such a flag >> should not be limited to IPv6 addresses, one might also find an A >> record for a node but have no IPv4 stack (or address) and therefore >> not bother returning the IPv4 address. > >Again just add this to the mapping above. We want to make gethostbyname3() >generic enough that it can do anything we'd like to do -- do we want >to make it more complex just so it's slightly easier to port applications? It's just inverting the sense of the flags. Instead of: if (flags & AI_V4MAPPED) { /* handle v4-mapped case */ } else { /* handle no v4-mapped case */ } you have: if (flags & AI_NOV4MAPPED) { /* handle no v4-mapped case */ } else { /* handle v4-mapped case */ } Help me out here, I may be missing something, where do you see extra complexity? Thanks, - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 5 10:08:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA13212 for ipng-dist; Fri, 5 Dec 1997 10:05:11 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id KAA13205 for ; Fri, 5 Dec 1997 10:05:00 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id KAA28135; Fri, 5 Dec 1997 10:04:58 -0800 (PST) Date: Fri, 5 Dec 1997 10:04:58 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5027) Re: draft-ietf-ipngwg-site-prefixes-01.txt To: Richard Draves Cc: "'nordmark@sun.com'" , "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D810D022DD@red-msg-50.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The draft fleshes out purpose & mechanism for site-local addresses. Overall > I like the idea. > > The draft seems to assume that nodes will assign site-local addresses to > their interfaces. There's no requirement for this in the addressing > architecture (see section 2.8 - required addresses). Correct. The assumption (which might be unstated in the draft) is that when a site chooses to use this mechanism all the routers in the site would be configured to advertise site-local address prefixes in the router advertisements so that every host in the site will be automatically assigned a site-local address. > I suggest that a node assign a site-local address to an interface based on > the prefix information option in RAs (hosts when receiving RAs, routers if > they will be sending such RAs). Basically if a site prefix matches a global > address assigned to the interface, then assign the site-local address to the > interface. Just to make sure I understand: You are saying that we can avoid manually configuring the router to advertise a site-local prefix on a link by having the router look at the global address prefixes and the site prefixes it is advertising. Sounds like an excellent idea. > Note this means that some interfaces might not have a site-local address > assigned. In particular, some installations might choose not to use this > mechanism or site-local addresses at all. Yes, as long as all the interfaces which have addresses faslling under the site prefixes always have the corresponding site local address. I realize that this isn't very flexible. One could envision a quite different but more flexible approach where the site prefixes are used to filter site local addresses retrieved from the DNS instead of creating them. The quick outline of such a scheme would be: Site local addresses retrieved from the DNS are normally ignored. However, if the RRset has global addresses which match one of the site prefixes received from the router then the site local addresses are not ignored but instead placed in the front of the list returned to the application. The difficult part of such a scheme it to get all the implementation to start ignoring all site local addresses retrieved from the DNS since it is required as a starting point. But now back to the proposal in the draft ... > Some links will belong to a site and some links will not belong to a site. A > link can not belong to more than one site. > > I don't like the provision in 7.1 that global addresses be removed from the > list of addresses returned from the name server. I think the addresses > should be ordered, with site-local before global. Naive applications will > probably just use the first address in the list. More sophisticated > applications might go down the list until they get one that works; if for > some reason there's a problem with the site-local address they should have > the opportunity to try a global address. However I don't know much about how > real applications respond when a name lookup returns multiple addresses. The robust applications today go down the list until the find an address that works. The problem with not removing the global addresses by default is that such applications, due to a temporary network outage, might accidentally pick a global address if the outage goes away while the application is trying all addresses in the list. If this happens then we can not guarantee that all the communication local to the site uses site locals hence the communication might be disrupted by renumbering the site. Thus there is a tradeoff between avoiding failures during renumbering and making the applications robust against the case when the site local address doesn't work. > In section 6, should the prefix lengths be validated, ie ignore prefix if > Site PLength > Prefix Length? This seems like a good precaution. Do you propose ignoring all aspects of the prefix or just the site local aspect? > There needs to be something about on-link determination for site-local > addresses. When a node (assume single-homed for the moment) sends to a > site-local address, does it use ND, send the packet to a router, or what? Site local addresses are no different than global addresses in this respect. The routers will (based on policy etc) advertise the on-link site-local subnet prefix. > For example, suppose that a node has received the following prefixes: > site prefixes: 2837:a:b::/48 and 2000:1:2::/48 > on-link prefixes: 2837:a:b:c::/64 and 2000:1:2:c::/64 Then it would also (based on policy etc) receive an on-link prefix of fec0:0:0:c::0/64. (That prefix would also trigger addrconf which will assign a site local address to the node itself.) > The node looks up the global address 2837:a:b:c:W:X:Y:Z and ends up sending > to fec0:0:0:c:W:X:Y:Z. This site-local address is on-link. > > But there are cases where inconsistent prefix information leads to bad > situations - where a site-local address will look to be on-link, but the > original global address would not be on-link. For example: > site prefixes: 2837:a:b::/48 and 2000:1:2::/48 > on-link prefixes: 2837:a:b:c::/64 and 2000:1:2:3::/64 > > Global address 2837:a:b:3:W:X:Y:Z is not on-link. It is converted to > site-local address fec0:0:0:3:W:X:Y:Z, which is on-link. The stated assumption is that the subnet number (is it called the SLA nowadays?) should be the same for the global address allocation(s) and the site-local allocation. Thus the above subnet number allocation isn't supposed to work since unless both subnet '3' and 'c' are assigned to the same link. > An implementation can detect when this is a risk - so a diagnostic could be > issued, or conversion to site-local addresses could be disabled. Or we could > ignore this issue, if a network admin screws up so be it. I agree it would make sense to try to detect misconfiguration like the above one. > Section 8 (nodes that are multihomed to multiple sites) needs more thought > for me. For one thing, the remark about placing site boundaries between > nodes is too cryptic. Thinking through this... I agree it is unclear. It just tries to punt by requiring that the a node can not be in multiple site but can only be in one site plus have zero or more interfaces which are not part of any site. > It seems like the most important case to consider here is a node N with one > interface I1 in a site and another interface I2 that is not in a site and > does not have a site-local address assigned. For example a border router. I > think this case will work just fine. > > When such a node N does name lookups for a node D with global address DAg, > if DAg is within the site the name lookup will return site-local address DAs > and global address DAg. The application will try to send to DAs, that being > the first address returned. The implementation on node N will need to pick > an interface and source address. Looking at DAs, it can pick interface I1 > and site-local address NAs, because I1 has a site-local address assigned and > I2 doesn't. > > On the other hand, if DAg is external, it does not match a prefix in the > Site Prefix List. Then the application will try to send to DAg and the > routing module should pick interface I2 (the one not in the site) and then > pick a source address NAg assigned to interface I2. > > So I don't see any problems there. > > Now suppose that node N has interface I1 in one site and interface I2 in > another site. This means that I1 has site prefix SP1 and I2 has site prefix > SP2. When the node tries to send to a site-local address, there's no way to > tell which interface to use (without explicit disambiguation by the > application). So node N disables use of site-local addresses. Also OK. > > I think the algorithm in section 8.1 could be more clearly stated. I think > you want the transitive closure of the "share at least one site prefix" > relation. I intended to write "transitive closure" - I must have goofed. 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 Fri Dec 5 11:03:31 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA13277 for ipng-dist; Fri, 5 Dec 1997 11:00:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA13270 for ; Fri, 5 Dec 1997 11:00:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA15964 for ; Fri, 5 Dec 1997 10:59:56 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA06163 for ; Fri, 5 Dec 1997 11:00:03 -0800 (PST) Received: by INET-02-IMC with Internet Mail Service (5.5.1960.3) id ; Fri, 5 Dec 1997 10:59:54 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810D022EB@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Erik Nordmark'" Cc: "'IPng List'" Subject: (IPng 5028) RE: draft-ietf-ipngwg-site-prefixes-01.txt Date: Fri, 5 Dec 1997 10:59:43 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Correct. The assumption (which might be unstated in the draft) is that > when > a site chooses to use this mechanism all the routers in the site would > be configured to advertise site-local address prefixes in the router > advertisements so that every host in the site will be automatically > assigned a site-local address. > [Richard Draves] Aha, I didn't get that. I was assuming that the hosts would infer the need to assign a site-local address and infer on-link site-local prefixes, based on the site prefixes received in RAs and the interface's global addresses. An example to make this clear: suppose a host receives an RA with just one prefix information option, with the L, A, and S bits all set. The prefix is 2000:1:2:653a::/64 and Site PLength is 48. Then the host would assign a global address 2000:1:2:653a:W:X:Y:Z and site-local address fec0:0:0:653a:W:X:Y:Z. Destination addresses with prefixes 2000:1:2:653a::/64 and fec0:0:0:653a::/64 would be asssumed to be on-link. If I understand correctly, you were assuming that the host would receive an RA with *two* prefix information options. The first would be as above: L, A, and S bits all set, prefix 2000:1:2:653a::/64 and Site PLength 48. The second would have only the L and A bits set, prefix fec0:0:0:653a::/64. Then host would behave as above, assigning a global address and a site-local address and using corresponding on-link prefixes. > Just to make sure I understand: You are saying that we can avoid manually > configuring the router to advertise a site-local prefix on a link > by having the router look at the global address prefixes and the site > prefixes > it is advertising. Sounds like an excellent idea. > [Richard Draves] Yes. The question is whether the site-local prefix should be explicitly advertised at all, or should the receiving hosts also do the calculation. > Thus there is a tradeoff between avoiding failures during renumbering > and making the applications robust against the case when the site local > address doesn't work. > [Richard Draves] Agreed, it's a tradeoff. Here's another scenario: suppose an application on node A looks up an address for node B and then sends the address to node C. I think many distributed applications (distributed file systems etc) might do this. If node A and node B are in the same site and node C is in a different site, this will not work. Shouldn't applications have *some* access to the global addresses? If not putting them at the end of the list, then having a flag asking that they be returned? > > In section 6, should the prefix lengths be validated, ie ignore prefix > if > > Site PLength > Prefix Length? This seems like a good precaution. > > Do you propose ignoring all aspects of the prefix or just the site local > aspect? > [Richard Draves] Ignore all aspects of the prefix, same as if the Site PLength were zero. 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 Dec 5 11:24:10 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA13300 for ipng-dist; Fri, 5 Dec 1997 11:20:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA13293 for ; Fri, 5 Dec 1997 11:20:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA21893 for ; Fri, 5 Dec 1997 11:20:01 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA17212 for ; Fri, 5 Dec 1997 11:20:06 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id LAA20674; Fri, 5 Dec 1997 11:19:54 -0800 Message-Id: <3.0.3.32.19971205111916.008dce60@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 05 Dec 1997 11:19:16 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5029) Revised IPng Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the revised IPng agenda for next weeks IETF meeting. Change was to move all DNS related discussion to Thrusday and move Router Alert to Friday. Please send corrections, changes, additions to me. Thanks, Bob ---------------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Status of moving base specs to Draft Standard / R. Hinden (5 min) TLA/NLA Assignment Rules Status / R. Hinden (15 min) Resolve Neighbor Discovery and Addr Conf issues / T. Narten (20 min) Interface Identifier Global Flag / S. Deering (10 min) IPv6/NBMA Status / G. Armitage (10 min) IPv6 over PVC ATM / K. Yamamoto (10 min) Socks64 work / Fujitsu (10 min) Mobile IPv6 Status / D. Johnson (10 min) THURSDAY, December 11, 1997, 0900-1130, (Empire Room) Router Renumbering / M. Crawford (20 min) DNS mappings / C. Huitema (20 min) IPv6 Name Lookups Through ICMP / M. Crawford (15 min) Reverse Address lookup in DNS for IPng / O. Gudmundsson (15 min) Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound (10 min) Traceroute hop-by-hop option / A. Durand (10 min) ECN Bit Assignment / S. Floyd (20 min) FRIDAY, December 12, 1997, 0900-1130, (Empire Room) IGMP for IPv6 / S. Deering (15 min) Neighbor Discovery over Tunnels / S. Deering (20 min) IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta (10 min) Site prefixes in Neighbor Discovery / E. Nordmark (20 min) Router Alert / C. Partridge (10 min) VRRP for IPv6 / R. Hinden (15 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 5 14:50:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA13794 for ipng-dist; Fri, 5 Dec 1997 14:45:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA13787 for ; Fri, 5 Dec 1997 14:45:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA22462 for ; Fri, 5 Dec 1997 14:45:29 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA04468 for ; Fri, 5 Dec 1997 14:45:25 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA02583; Fri, 5 Dec 1997 16:43:52 -0600 Message-Id: <199712052243.QAA02583@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5030) multicast assignments Date: Fri, 05 Dec 1997 16:43:52 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maybe it would be a good idea to insert a line reserving FF0X:0:0:0:0:0:FFXX:XXXX at all scopes, so that ND is "protected" against multicast MAC address collisions, modulo infelicitous hash functions? 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 Sat Dec 6 04:20:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id EAA14674 for ipng-dist; Sat, 6 Dec 1997 04:18:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id EAA14667 for ; Sat, 6 Dec 1997 04:18:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA03620 for ; Sat, 6 Dec 1997 04:18:09 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA15239 for ; Sat, 6 Dec 1997 04:18:18 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id MAA28279; Sat, 6 Dec 1997 12:12:37 GMT From: "Peter Curran" To: "Thomas Narten" Cc: "IPNG WG List" Subject: (IPng 5031) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-01.txt Date: Sat, 6 Dec 1997 12:26:26 -0000 Message-ID: <01bd0242$2c71e240$0f0120c1@desktop.ticl.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_00A5_01BD0242.2C26F690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01BD0242.2C26F690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thomas Thanks for your response. >> Referring to section 5.3 of this I-D (addrconf-v2): > >> A link-local address is formed by prepending the well-known link- >> local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the >> interface identifier. If the interface identifier has a length of N | >> bits, the interface identifier replaces the right-most N zero bits of | >> the link-local prefix. If the interface identifier is more than 118 | >> bits in length, autoconfiguration fails and manual configuration is >> required. > >> Could you explain why this new syntax has been introduced. > >Actually, the above text isn't "new". It's is a hold over from what's >in the RFC. > Sorry - I assumed that it was new because it had sidebars. > ... stuff deleted .... >Actually, addrarch-v2 states that format prefixes 001-111 are required >to use the EUI-64 interface identifier format, but format prefix 000 >is "reserved/unassigned" and does not have this requirement. If its >usage is ever defined, it may well be that EUI-64 interface >identifiers will be required. But I think the intent is to leave this >open for now. There are also other places in the addressing document >where the text describes interface identifiers as n-bit quantities >without stating that they are 64 bits. > I agree that addrarch-v2 leaves the addresses starting with FP=000 as reserved/unassigned. However, the address we are talking about is link-local (FP=1111 1110 10). The following snip from addrarch-v2 illustrates my problem... Notes: (1) The "unspecified address" (see section 2.5.2), the loopback address (see section 2.5.3), and the IPv6 Addresses with Embedded IPv4 Addresses (see section 2.5.4), are assigned out of the 0000 0000 format prefix space. (2) The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format. See section 2.5.1 for definitions. Unless I am totally misreading this then it says that link-local addresses are required to have 64-bit interface IDs. The text in addrarch-v2 is potentially ambiguous - it is not clear whether the 001 thru 111 applies only to the 8 possible combinations of those 3 bits, or all addresses starting with those combinations. However, the qualifier concerning multicast addresses confirms that the latter interpretation should be used. IE, it applies to all unicast addresses. So, back to my original question. Why does section 5.3 use the syntax given above, which implies that an interface ID other than 64 bits in length can be used for a link-local address, when the 'higher-level' document says that it must be 64-bits? >While the current text may be confusing, I don't believe it is >incorrect. Changing the text to use 64-bit interface identifiers would >also necessitate adding caveates that this only applies to some of the >format prefixes. I'd prefer to leave those sorts of details in the >addressing architecture document. > I think it is not only confusing, but also incorrect. Aaaah - I SEE the problem. As I type this in, I can now see that you have interpreted the notes in the addrarch-v2 text the opposite way to me. OK - this is easy to resolve. Can we have clarification from Bob or Steve as to what the correct interpretation is? Have a nice time at the IETF next week, if you are going. My travel plans got blown out this time... Cheers Peter Curran TICL ------=_NextPart_000_00A5_01BD0242.2C26F690 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0TCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoXDTk5MDYyNzIz NTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYD VQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOOLPhvltcunXZLEbE2jVfJw/0c xrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5912dFEObbpdFmIFH0S3L3bty10w/ cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+qQIDAQABozMwMTAPBgNVHRMECDAGAQH/ AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3 AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6VmQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+ lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0ilZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs 6SxQv6b5DduwpkowggQQMIIDeaADAgECAhApF9yEa2f1I6vNhJOMYHGgMA0GCSqGSIb3DQEBBAUA MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMr VmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzExMjEwMDAw MDBaFw05ODAxMjAyMzU5NTlaMIIBDTERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4g YnkgUmVmLixMSUFCLkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNy b3NvZnQxFTATBgNVBAMTDFBldGVyIEN1cnJhbjEhMB8GCSqGSIb3DQEJARYScGN1cnJhbkB0aWNs LmNvLnVrMFswDQYJKoZIhvcNAQEBBQADSgAwRwJAbGS4S0SN7NX2OODlfiOves53hbLKytcxawKy ipnvwVqlHCtugU+GznF/cq3jvMQeehvX+9+lxts1Q7BXxw9QuQIDAQABo4IBXTCCAVkwCQYDVR0T BAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVy aVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2 M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2Rh NWMxZTMxNDFiZWFkYjJiZDI5YWZhMTJiZDY4OTFhMTExNDk5OGExYmE0M2Y0ZTY5MTY1NDEwDQYJ KoZIhvcNAQEEBQADgYEAUXbKrrDI9DdxdSL9W4pMtNBTZpFV9yMkBkiKdSOwdjmSh3/qPl11P/HM KDT9CtIXpeT0JcUlkZsXaGkLGZnVWHvsqjUyvqT6XOCy1Vm1VokROmbfFItKacbTwoQsArhISOYB DdUOwpZiD/HEdCTnTb4r6bC3MZ+6afsCn0zi//sxggE6MIIBNgIBATB2MGIxETAPBgNVBAcTCElu dGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQKRfchGtn9SOrzYSTjGBxoDAJBgUrDgMCGgUA oF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTcxMjA2MTIyNjI2 WjAjBgkqhkiG9w0BCQQxFgQUGX+yaX43opeIKlpPRLlwTqnbClkwDQYJKoZIhvcNAQEBBQAEQFaO /YNmOOYLKANJbGbf9kQtKfjlme1Myl7OlyN1v6YGg5WGi2LJI9d4ffb6i3gy+yA0uGraAZyHeyPs rQ928eYAAAAAAAA= ------=_NextPart_000_00A5_01BD0242.2C26F690-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 6 09:22:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA14790 for ipng-dist; Sat, 6 Dec 1997 09:19:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA14783 for ; Sat, 6 Dec 1997 09:19:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA01853; Sat, 6 Dec 1997 09:19:38 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA11102; Sat, 6 Dec 1997 09:19:48 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id MAA17223; Sat, 6 Dec 1997 12:19:35 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id MAA03973; Sat, 6 Dec 1997 12:19:34 -0500 (EST) Date: Sat, 6 Dec 1997 12:19:34 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971206121934.ZM3971@seawind.bellcore.com> In-Reply-To: Richard Draves "(IPng 5028) RE: draft-ietf-ipngwg-site-prefixes-01.txt" (Dec 5, 10:59am) References: <4D0A23B3F74DD111ACCD00805F31D810D022EB@red-msg-50.dns.microsoft.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Richard Draves , "'Erik Nordmark'" Subject: (IPng 5032) Re: draft-ietf-ipngwg-site-prefixes-01.txt Cc: "'IPng List'" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In fact, I think we should seriously downgrade the usage of Site Local prefixes, and to reserve it to the case of non connected sites -- just like net 10. The scenario would then be: 1) set up the site. Assign numbers to local links, have routers advertize site-local prefixes. 2) connect the site to a first provider. Use router renumbering, replace the site local prefix by the first provider prefix, or prefixes. 3) connect to a second provider. Use router renumbering to "add" a prefix, so that all routers now advertize two prefixes. Use the 'prefered' information to trigger preferential usage of the "best" provider, if that makes sense... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 6 10:24:01 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA14923 for ipng-dist; Sat, 6 Dec 1997 10:21:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA14916 for ; Sat, 6 Dec 1997 10:21:15 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA05472 for ; Sat, 6 Dec 1997 10:21:12 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA23748 for ; Sat, 6 Dec 1997 10:21:22 -0800 (PST) Date: Sat, 6 Dec 1997 10:21:22 -0800 (PST) From: Margaret Wasserman To: huitema@bellcore.com CC: richdr@microsoft.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com Message-ID: <9712061321.aa22991@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: <971206121934.ZM3971@seawind.bellcore.com> (message from Christian Huitema on Sat, 6 Dec 1997 12:19:34 -0500 (EST)) Subject: Re: (IPng 5032) Re: draft-ietf-ipngwg-site-prefixes-01.txt Date: Sat, 6 Dec 97 13:21:02 -0500 >In fact, I think we should seriously downgrade the usage of Site Local >prefixes, and to reserve it to the case of non connected sites -- just >like net 10. I don't strongly disagree with adding this restriction, but I would like to point out that this will reduce one potential utility of site-local addresses. Specifically, a potential advantage of using site local addresses for in-site TCP connections (or other stateful communication) is that the connections will survive renumbering by the ISP, since the in-site addresses (subnets) would not change. I am not certain that this advantage outweighs the added overhead of implementing special handling for site local addresses, though, particularly in multi-interface hosts or routers. The advantage will only exist if care is taken to use a site-local address for in-site communciation, and I have seen no good proposal for how hosts will decide to use a site-local address when initiating an in-site communication. However, this could have serious advantages if the mechanisms could be hammered out. Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Epilogue Technology Corp. FAX: (617) 245-8122 333 North Ave, 4th Floor http://www.epilogue.com Wakefield, MA 01880, USA Sales: info@epilogue.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 6 11:00:30 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA14959 for ipng-dist; Sat, 6 Dec 1997 10:57:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA14952 for ; Sat, 6 Dec 1997 10:57:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA07838 for ; Sat, 6 Dec 1997 10:57:43 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA01362 for ; Sat, 6 Dec 1997 10:57:53 -0800 (PST) Received: by INET-02-IMC with Internet Mail Service (5.5.1960.3) id ; Sat, 6 Dec 1997 10:57:44 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810D02300@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'huitema@bellcore.com'" , "'Erik Nordmark'" Cc: "'IPng List'" Subject: (IPng 5033) Re: draft-ietf-ipngwg-site-prefixes-01.txt Date: Sat, 6 Dec 1997 10:56:43 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In fact, I think we should seriously downgrade the usage of Site Local > prefixes, and to reserve it to the case of non connected sites -- just > like net 10. > [Richard Draves] As the draft points out and Margaret reiterated, using site-local addresses inside connected sites makes site renumbering much more palatable. If we can figure out a way to do it, I think we should. (Margaret, you say you haven't seen a good proposal - what don't you like about Erik's draft?) To wax philosophical for a moment, I perceive that good renumbering support is an important goal for IPv6. The question is how to do it with minimal impact on applications and users. I think there will be inevitably be some impact, but with the right engineering trade-offs we can make renumbering very acceptable. Some pieces of this are router renumbering and preferred/deprecated addresses. I think users & programmers expect glitchy behavior in the wide area, so for example if renumbering occasionally causes a long-lived long-distance TCP connection to break, it won't be any worse that what people experience today. Robust wide-area applications should code around this already. (This is not to say that we shouldn't work towards changes in TCP etc to eventually eliminate these glitches.) On the other hand, I think users & programmers generally expect reliable behavior within sites or intranets, and it's much more important for renumbering not to affect intranet applications. If we can set things up so that intranet applications use site-local addresses, I think renumbering will be much more successful. One price to pay for this is that a distributed system that spans site boundaries and passes around addresses internally will need to be cognizant of site-local vs global addresses; this will complicate the port to v6 of some codes. Another price to pay for renumbering is that very long-lived applications (eg servers) will need to be careful about caching name->address translations internally. This may also complicate the port to v6 of some codes. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 6 13:02:01 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA15259 for ipng-dist; Sat, 6 Dec 1997 12:58:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA15252; Sat, 6 Dec 1997 12:58:14 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16781; Sat, 6 Dec 1997 12:58:09 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA26529; Sat, 6 Dec 1997 12:58:17 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA26684; Sat, 6 Dec 1997 15:52:01 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA11660; Sat, 6 Dec 1997 15:52:00 -0500 Message-Id: <199712062052.AA11660@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, dhcp-v6@bucknell.edu Subject: (IPng 5034) Excellent draft Paper IPv6 Business and Technical Case Date: Sat, 06 Dec 1997 15:52:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you did not see this come by it is superb. It clearly articulates why folks are telling me they want to get started with IPv6 now. The authors have done a really good job. I am doing an IPng talk at the Re-Engineering the Internet conference in London the week of 1/26/98 and this paper is exactly what the audience needs to have as one point of reference. draft-ietf-iab-case-for-ipv6-00.txt /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 Dec 6 17:12:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id RAA15572 for ipng-dist; Sat, 6 Dec 1997 17:09:53 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id RAA15565 for ; Sat, 6 Dec 1997 17:09:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA01994 for ; Sat, 6 Dec 1997 17:09:39 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id RAA16623 for ; Sat, 6 Dec 1997 17:09:50 -0800 (PST) Date: Sat, 6 Dec 1997 17:09:50 -0800 (PST) From: Margaret Wasserman To: richdr@microsoft.com CC: huitema@bellcore.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com Message-ID: <9712062009.aa24716@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: <4D0A23B3F74DD111ACCD00805F31D810D02300@red-msg-50.dns.microsoft.com> (message from Richard Draves on Sat, 6 Dec 1997 10:56:43 -0800) Subject: Re: (IPng 5033) Re: draft-ietf-ipngwg-site-prefixes-01.txt Date: Sat, 6 Dec 97 20:09:28 -0500 >(Margaret, you say you haven't seen a good proposal - what don't you like >about Erik's draft?) I'm still busy catching up on my reading, so I must admit that I haven't read Erik's draft. I certainly think that a good mechanism for doing this is possible, I just haven't liked the earlier approaches I've seen. >From a quick reading of the beginning of Erik's draft (after reading your message), it does look promising. I'll withhold further comment until after I have a chance to read the entire work. Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Epilogue Technology Corp. FAX: (617) 245-8122 333 North Ave, 4th Floor http://www.epilogue.com Wakefield, MA 01880, USA Sales: info@epilogue.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 6 23:56:12 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id XAA15922 for ipng-dist; Sat, 6 Dec 1997 23:53:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id XAA15915 for ; Sat, 6 Dec 1997 23:53:28 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA24549; Sat, 6 Dec 1997 23:53:26 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA02097; Sat, 6 Dec 1997 23:53:38 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id CAA27912; Sun, 7 Dec 1997 02:48:08 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25950; Sun, 7 Dec 1997 02:48:05 -0500 Message-Id: <199712070748.AA25950@wasted.zk3.dec.com> To: Richard Draves Cc: "'huitema@bellcore.com'" , "'Erik Nordmark'" , "'IPng List'" Subject: (IPng 5037) Re: draft-ietf-ipngwg-site-prefixes-01.txt In-Reply-To: Your message of "Sat, 06 Dec 1997 10:56:43 PST." <4D0A23B3F74DD111ACCD00805F31D810D02300@red-msg-50.dns.microsoft.com> Date: Sun, 07 Dec 1997 02:48:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I want to hear Eriks open issues discussed at the meeting he listed in his draft. > I think users & programmers expect glitchy behavior in the wide >area, so for example if renumbering occasionally causes a long-lived >long-distance TCP connection to break, it won't be any worse that what >people experience today. Robust wide-area applications should code around >this already. (This is not to say that we shouldn't work towards changes in >TCP etc to eventually eliminate these glitches.) I am not sure we can head down this path. THough I agree I often find the IETF wants to build for the Internet case and assume the Intranet case will get solved defacto. This may be a case where that can be relaxed. But I don't think this draft or momentum should permit us to think we don't have to solve renumbering for Intranets too. That would be wrong. > On the other hand, I think users & programmers generally expect >reliable behavior within sites or intranets, and it's much more important >for renumbering not to affect intranet applications. THis is not the long term case. They will want their www connections worldwide to stay up and with great reliability and "scalability". Does this proposal scale is what I am asking myself? > If we can set things up so that intranet applications use site-local >addresses, I think renumbering will be much more successful. I agree. > One price to pay for this is that a distributed system that spans >site boundaries and passes around addresses internally will need to be >cognizant of site-local vs global addresses; this will complicate the port >to v6 of some codes. I don't see it? If we do it right the code will only exist in the DNS client and the kernel. Also it has to be transparent to applications by ISVs or its a broken idea. I think that can be done. > Another price to pay for renumbering is that very long-lived >applications (eg servers) will need to be careful about caching >name->address translations internally. This may also complicate the port to >v6 of some codes. I am really beginning to think we should update the hostent structure to have the TTL for the DNS address record for v4 and v6. But again I don't see a big porting issue. Also most everyone has ported to IPv6 and its not like we are just starting except for a few. My issue is all this worth adding to the existing v6 code base? Can it be done in an efficient manner? /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 Dec 7 06:24:14 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA16119 for ipng-dist; Sun, 7 Dec 1997 06:21:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA16112 for ; Sun, 7 Dec 1997 06:21:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA08999 for ; Sun, 7 Dec 1997 06:21:29 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA07236 for ; Sun, 7 Dec 1997 06:21:41 -0800 (PST) Date: Sun, 7 Dec 1997 06:21:41 -0800 (PST) From: Margaret Wasserman To: ipng@sunroof.eng.sun.com Message-ID: <9712070921.aa27758@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: <199712070748.AA25950@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: (IPng 5037) Re: draft-ietf-ipngwg-site-prefixes-01.txt Date: Sun, 7 Dec 97 09:21:29 -0500 >> On the other hand, I think users & programmers generally expect >>reliable behavior within sites or intranets, and it's much more important >>for renumbering not to affect intranet applications. > >THis is not the long term case. They will want their www connections >worldwide to stay up and with great reliability and "scalability". >Does this proposal scale is what I am asking myself? Using valid and preferred addresses, it should be possible to keep existing connections up for a finite time, anyway. If this time were long enough (hours), it should allow most connections that an end-user has established (www connections, ftp connections, etc.) to resolve cleanly. The more difficult case is when an application is trying to keep a connection up constantly (usually without a user driving it on an on-going basis). It is not my experience that any well-written application will rely upon a TCP connection (in- or out-of-site) staying up forever. The real possibility of hardware failures or human errors make this an unreasonable assumption, so applications which need long-term connectivity already have mechanisms for reestablishing connectivity after an outage. The issue would be whether these applications can survive IP address changes. For example, do they do a new DNS lookup before trying to reestablish connectivity, or are they simply trying to reconnect to the same IP address. If the former, then renumbering should not catastrophically affect the applications, whether the connection is in-site or out-of-site. This is how well-written IPv6 applications should be written, and I am sure that most of the applications that we (as commercial vendors) have ported to IPv6 would have this property. But, many customers have their own applications which they might not modify promptly/completely/correctly for IPv6, and some of these applications may fall into the second group (use the same IP address to reestablish a connection when it dies). In this case, a mechanism which allows automatic use of a site-local address for in-site communication would allow these applications to continue to function properly across renumbering by the ISP. In fact, the connection would not drop at all during renumbering. >> One price to pay for this is that a distributed system that spans >>site boundaries and passes around addresses internally will need to be >>cognizant of site-local vs global addresses; this will complicate the port >>to v6 of some codes. > >I don't see it? If we do it right the code will only exist in the DNS >client and the kernel. By kernel, do you mean the TCP/IP stack? As far as I have been able to determine, the main price for site-local addressing is increased complexity in IP (particularly in the source address selection and packet acceptance rules). The additional complexity is minor for singly-homed hosts, but is much greater for multi-interface hosts or routers as these systems have to deal with the possibility that their interfaces may be in separate sites. I agree that the choice whether to use site-local or global addressing can (and should) be made by the IP stack, not by an individual application (where an applications is anything over IP -- TCP, UDP, OSPF, a customer app). However, there are some details with this that I haven't nailed down in my own mind. For example, an application will call DNS to get the IP address(es) for the hostname it wants to reach. I think it would be a mistake to require DNS to know whether a particular connection would/wouldn't be site-local, as this seems pretty far outside the purview of DNS. So, the DNS should probably return only global addresses at this point. I do realize that there is still some outstanding disagreement on this point, though. But, let's go forward based on my assumption... So, now we have a list of global addresses. Currently, in some APIs, the applications picks one of these addresses to use as the remote address. I think this is rather broken, as applications seldom have any criteria on which to make this choice, but I believe that this is the existing mechanism for remote address selection in most IPv4 systems. After choosing a remote address, the application will "route" the packet to determine the local address to use, and both addresses will be used to compute the checksum (including the IP-pseudo-header). After this point, the addresses cannot be changed by the IP stack. So, the IP stack cannot, after this point, decide to use a site-local remote address (and corresponding site-local local address). One possible answer to this would be to have the DNS resolver add site local addresses to the list of proferred addresses when appropriate. Probably this information would be obtained via a call into IP with the list of global addresses? But, use of a site-local address may be dependent upon using a particular outbound interface, so IP would have to "route" the packet to determine what interface would be used (because, for example, the default route could be through an interface in a different site) before suggesting a site-local address. Since I assume that we wouldn't want to maintain state for this connection in IP, the packet would be "routed" again to determine the source address before the pseudo-header checksum is calculated -- or the DNS resolver would also need to pass up the source address. So, this plan seems less than ideal. I may be missing something here, though, since I am not a DNS expert. Perhaps the answer is to pass the entire list of DNS-returned addresses into the IP stack during the "routing" stage and have both the local and remote IP addresses returned at that time? If this were the case, it would be possible for the IP stack to pick a site-local address if one of the DNS-returned global addresses was in-site on (one of) the host's interface(s). However, this would require at least some changes to current applications. On some systems, this would in fact require changes to the application-layer applications, as they currently make the destination address selection from the list proferred by DNS. >But again I don't see a big porting issue. Also most everyone has >ported to IPv6 and its not like we are just starting except for a few. It depends who "everyone" is. There are a _huge_ number of people who write/use/sell sockets-based (or other) IP-based products. Most stack vendors have probably implemented IPv6 (or will use the port of someone who has), but I believe that most applications-vendors (including people with in-house applications) have not. >My issue is all this worth adding to the existing v6 code base? > >Can it be done in an efficient manner? These are both important questions. I am not certain whether the benefits of site-local addressing outweigh the costs. But, that is a hard determination to make given that we have yet to develop a full set of mechanisms that would provide the benefits. Until we know how the benefits would be achieved, it is impossible to measure the costs. Assuming that the benefits cannot be satisfactorily achieved or that the benefits would be outweighed by the costs, I believe we should revert to using site-local addressing only for non-internet connected sites (as previously suggested by Rich(?)). Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Epilogue Technology Corp. FAX: (617) 245-8122 333 North Ave, 4th Floor http://www.epilogue.com Wakefield, MA 01880, USA Sales: info@epilogue.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 Dec 7 23:36:11 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id XAA16558 for ipng-dist; Sun, 7 Dec 1997 23:33:36 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id XAA16551 for ; Sun, 7 Dec 1997 23:33:25 -0800 (PST) Received: from lillen (hobo139 [129.146.31.139]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id XAA16444; Sun, 7 Dec 1997 23:33:22 -0800 (PST) Date: Sun, 7 Dec 1997 23:30:26 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5038) Re: draft-ietf-ipngwg-site-prefixes-01.txt To: Christian Huitema Cc: Richard Draves , "'Erik Nordmark'" , "'IPng List'" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In fact, I think we should seriously downgrade the usage of Site Local > prefixes, and to reserve it to the case of non connected sites -- just > like net 10. I (and presumably others on the ipng list) would be interested in hearing your arguments for the above thought. I have a hard time having a constructive discussion without any motivation for your statement. Is it just that you think site local addresses add too much complexity with little gain? Or is it something completely different? 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 Sun Dec 7 23:43:50 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id XAA16610 for ipng-dist; Sun, 7 Dec 1997 23:40:32 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id XAA16603 for ; Sun, 7 Dec 1997 23:40:21 -0800 (PST) Received: from lillen (hobo139 [129.146.31.139]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id XAA17010; Sun, 7 Dec 1997 23:40:18 -0800 (PST) Date: Sun, 7 Dec 1997 23:40:15 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5039) Re: draft-ietf-ipngwg-site-prefixes-01.txt To: Richard Draves Cc: "'Erik Nordmark'" , "'IPng List'" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If I understand correctly, you were assuming that the host would > receive an RA with *two* prefix information options. The first would be as > above: L, A, and S bits all set, prefix 2000:1:2:653a::/64 and Site PLength > 48. The second would have only the L and A bits set, prefix > fec0:0:0:653a::/64. Then host would behave as above, assigning a global > address and a site-local address and using corresponding on-link prefixes. Yes, that is the intent of the current draft. But now I see that one could extend the semantics of Site PLength to affect the addrconf and on-link prefixes - I just can tell yet if such a change would make things simpler or more complex. > Here's another scenario: suppose an application on node A looks up > an address for node B and then sends the address to node C. I think many > distributed applications (distributed file systems etc) might do this. If > node A and node B are in the same site and node C is in a different site, > this will not work. Shouldn't applications have *some* access to the global > addresses? If not putting them at the end of the list, then having a flag > asking that they be returned? I think 3rd party ftp (to the extent it is in use) is an example of such a case where the PORT command sends the addresses around. But in general, such an application would have to also pass around the DNS ttl to avoid holding on to an address for too long when something gets renumbered. Thus one could argue that such an application would be better off passing around a stable identifier (a domain name) instead of IP addresses. But I have no problem having knobs in the gethostbyname family of APIs to allow the application to choose which sets of addresses are returned. > > Do you propose ignoring all aspects of the prefix or just the site local > > aspect? > > > [Richard Draves] Ignore all aspects of the prefix, same as if the > Site PLength were zero. If Site PLength is zero the prefix is still handled as normal by ND and addrconf. If Site PLength is bogus (less that Prefix Length) to you still want ND and addrconf to process the prefix? 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 Dec 8 00:10:50 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id AAA16687 for ipng-dist; Mon, 8 Dec 1997 00:07:44 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id AAA16676 for ; Mon, 8 Dec 1997 00:07:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA04206 for ; Mon, 8 Dec 1997 00:07:31 -0800 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA09194 for ; Mon, 8 Dec 1997 00:07:42 -0800 (PST) Received: from rhine.sm.sony.co.jp (onoe@duplo.sm.sony.co.jp [133.138.10.221]) by onoe2.sm.sony.co.jp (8.8.5/Sony6.1MX) with ESMTP id RAA05617 for ; Mon, 8 Dec 1997 17:07:22 +0900 (JST) Received: from localhost (onoe@localhost [127.0.0.1]) by rhine.sm.sony.co.jp (8.8.7/8.8.5) with ESMTP id QAA09595 for ; Mon, 8 Dec 1997 16:43:43 +0900 (JST) Message-Id: <199712080743.QAA09595@rhine.sm.sony.co.jp> To: ipng@sunroof.eng.sun.com Subject: (IPng 5040) Re: I-D ACTION:draft-ietf-ipngwg-site-prefixes-01.txt In-Reply-To: Your message of "Tue, 25 Nov 1997 10:35:31 -0500" References: <199711251535.KAA10346@ns.ietf.org> X-Mailer: Mew version 1.52 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 08 Dec 1997 16:43:43 +0900 From: Atsushi Onoe Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First, Site PLength value of the Prefix Option in RA MUST be in the range between 48 and Prefix Length. Because the site-local prefix length is defined as 48, Site Plength value less than 48 is invalid. Greater than Prefix length is obviously invalid. Receiver MUST check the value is in the range. Furthermore, site-local prefix length is sticked at the 48bit in [AGGR]. Therefore, only the meaningful value of Site Plength seems to be 48, otherwise invalid. If it is true, Site Plength field would not be necessary, 'S' (Site Prefix Flag) bit is enough, though I'm not clear about this assumption. At least, we should consider the updated announce with same Prefix and different Site Plength field value. Atsushi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 8 00:10:59 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id AAA16696 for ipng-dist; Mon, 8 Dec 1997 00:08:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id AAA16689 for ; Mon, 8 Dec 1997 00:07:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA04229 for ; Mon, 8 Dec 1997 00:07:50 -0800 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA09243 for ; Mon, 8 Dec 1997 00:08:00 -0800 (PST) Received: from rhine.sm.sony.co.jp (onoe@duplo.sm.sony.co.jp [133.138.10.221]) by onoe2.sm.sony.co.jp (8.8.5/Sony6.1MX) with ESMTP id RAA05620; Mon, 8 Dec 1997 17:07:26 +0900 (JST) Received: from localhost (onoe@localhost [127.0.0.1]) by rhine.sm.sony.co.jp (8.8.7/8.8.5) with ESMTP id QAA09613; Mon, 8 Dec 1997 16:57:34 +0900 (JST) Message-Id: <199712080757.QAA09613@rhine.sm.sony.co.jp> To: kre@munnari.oz.au Cc: roque@cisco.com, huitema@bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 5041) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: Your message of "Fri, 21 Nov 1997 08:15:29 +1100" References: <21666.880060529@munnari.OZ.AU> X-Mailer: Mew version 1.52 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 08 Dec 1997 16:57:34 +0900 From: Atsushi Onoe Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If the signing to the RRs is the primary concern in this proposal, dividing DNS RRs to ONLY TWO part, say, subnet number and interface identifier within a domain would be simpler and more acceptable for me. e.g. inverse query for 4321:0:1:7:3:4:567:89ab will be divide two lookups. 1st: 7.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int IN PTR subnet3.foo.bar 2nd: b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.net.foo.bar IN PTR host.subnet3.foo.bar Our experiences in MX RRs said that using the wildcard RRs would be a problem in the near future. Atsushi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 8 08:05:06 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA16935 for ipng-dist; Mon, 8 Dec 1997 08:02:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA16928 for ; Mon, 8 Dec 1997 08:02:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA05615 for ; Mon, 8 Dec 1997 08:01:58 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA29539 for ; Mon, 8 Dec 1997 08:01:54 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA05667; Mon, 8 Dec 1997 10:00:02 -0600 Message-Id: <199712081600.KAA05667@gungnir.fnal.gov> To: Atsushi Onoe Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5043) Re: I-D ACTION:draft-ietf-ipngwg-site-prefixes-01.txt In-reply-to: Your message of Mon, 08 Dec 1997 16:43:43 +0900. <199712080743.QAA09595@rhine.sm.sony.co.jp> Date: Mon, 08 Dec 1997 10:00:01 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Furthermore, site-local prefix length is sticked at the 48bit in > [AGGR]. Therefore, only the meaningful value of Site Plength seems to > be 48, otherwise invalid. If it is true, Site Plength field would not > be necessary, 'S' (Site Prefix Flag) bit is enough, though I'm not clear > about this assumption. I went down this same thought-road, but I could imagine cases where an organization chooses to split a /48 global prefix among different sites, and so in the model of the current draft the "Site PLength" would be greater than 48. On the other hand, I think I favor putting Site Prefix information in a separate prefix information option, so the existing length field could be used to hold the Site PLength. Or ... the S-flag could be defined to indicate the common case: the accompanying prefix is a Site Prefix with PLength=48. Uncommon cases would have to be specified in a separate prefix information option. ___________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP2 0x566F63C5 - D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A PGP5 0xC175B1C3 - 74AC 501A 450B F479 C2AF 03B0 7BA5 F5B1 1D6E 65C1 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 8 09:33:28 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA17035 for ipng-dist; Mon, 8 Dec 1997 09:30:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA17028 for ; Mon, 8 Dec 1997 09:30:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA27516 for ; Mon, 8 Dec 1997 09:30:24 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA21174 for ; Mon, 8 Dec 1997 09:30:20 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Mon, 8 Dec 1997 09:30:13 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810D0230C@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Erik Nordmark'" Cc: "'IPng List'" Subject: (IPng 5044) Re: draft-ietf-ipngwg-site-prefixes-01.txt Date: Mon, 8 Dec 1997 08:56:14 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Do you propose ignoring all aspects of the prefix or just the site > local > > > aspect? > > > > > [Richard Draves] Ignore all aspects of the prefix, same as if the > > Site PLength were zero. > > If Site PLength is zero the prefix is still handled as normal by ND and > addrconf. If Site PLength is bogus (less that Prefix Length) to you still > want ND and addrconf to process the prefix? > [Richard Draves] I think all forms of bogosity (Site PLength zero, Site PLength greater than Prefix Length, whatever) should be treated the same. I read the receiving rules in section 6 (eg "If the Site PLength is zero ignore the prefix.") to mean that the Prefix Information Option was to be totally ignored. If you mean that ND and addrconf should still process the prefix but the S flag should be ignored, then I think you need different wording. 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 Mon Dec 8 09:53:03 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA17118 for ipng-dist; Mon, 8 Dec 1997 09:50:17 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id JAA17111 for ; Mon, 8 Dec 1997 09:50:12 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA18618 for ; Mon, 8 Dec 1997 09:50:12 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28914; Mon, 8 Dec 1997 09:49:50 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA15391 for ; Sat, 6 Dec 1997 13:40:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA19386 for ; Sat, 6 Dec 1997 13:40:20 -0800 Received: from doorstep.unety.net (ns.unety.net [207.32.128.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA05699 for ; Sat, 6 Dec 1997 13:40:31 -0800 (PST) Received: from pc.unir.net (dial5.p0.unety.net [207.32.159.5]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id PAA09741; Sat, 6 Dec 1997 15:40:17 -0600 Received: by pc.unir.net with Microsoft Mail id <01BD025D.3E3F6CC0@pc.unir.net>; Sat, 6 Dec 1997 15:40:13 -0600 Message-ID: <01BD025D.3E3F6CC0@pc.unir.net> From: Jim Fleming To: "ipng@sunroof.Eng.Sun.COM" Cc: "'rsc@ah.net'" Subject: (IPng 5045) IPv8 Address Mapping for IPv6 Date: Sat, 6 Dec 1997 15:40:12 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Saturday, December 06, 1997 2:52 PM, bound@zk3.dec.com wrote: @If you did not see this come by it is superb. It clearly articulates @why folks are telling me they want to get started with IPv6 now. The @authors have done a really good job. I am doing an IPng talk at the @Re-Engineering the Internet conference in London the week of 1/26/98 @and this paper is exactly what the audience needs to have as one point @of reference. @ @draft-ietf-iab-case-for-ipv6-00.txt @ @/jim @ @ Since everyone will be moving to IPv6...can you make sure that there is a clean mapping of the 43 bit IPv8 addresses in the IPv6 empire ? (If you are not familiar with the format, it is 3+8+32) Also, it would be nice if there was also a recommended mapping for the 75 bit IPv4/8 format. That is a 32+3+8+32 organization. The leftmost 32 bits are mostly the 32 bit IPv4 core transport address bits but can also be treated as a 16+ASN quantity for local stargate routing. In each case, the 11 bit 3+8 (G+S) quantity identifies an Internet TLD authority. I am sure that people will be happy to start managing and charging for addresses as soon as the IPv6 world transport is ready. The RSCs can help to make sure that the IPv8 addresses used in the IPv6 fields are organized and well-managed. Without that, the IPv6 address space could end up looking being a mess, like the IPv4 address space. I hope that does not happen... Jim Fleming Unir Corporation IBC, Tortola, BVI -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 8 11:26:27 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA17472 for ipng-dist; Mon, 8 Dec 1997 11:20:34 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id LAA17465 for ; Mon, 8 Dec 1997 11:20:24 -0800 (PST) Received: from lillen (hobo132 [129.146.31.132]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id LAA23907; Mon, 8 Dec 1997 11:20:19 -0800 (PST) Date: Mon, 8 Dec 1997 11:20:14 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5046) Re: comments on bsd-api-new-00 To: Jack McCann Cc: 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 > As for gethostbyaddr(), I don't think we should simply change the function > to return dynamically allocated memory by default. We must consider source > and binary compatibility for existing users of gethostbyaddr(). We should > either define a new function (ow! I feel a flags argument coming on :-) > or define a compile time option that forces the new behavior. I'm not > fond of either but gethostbyaddrwithflags() sounds better at the moment. > Or dare I say just use getnameinfo() if you want thread safety? I agree we can't change the behavior of gethostbyaddr. How about naming the new thread safe variant getdynhostbyaddr? (We could then use getdynhostbyname and freedynhostent as more consistent names than gethostbyname3 and freehostent). > I'd like to suggest a slightly different take on the default behavior of > gethostbyname3() (i.e. when flags == 0). The default (flags == 0) > behavior should be: Some of your concerns can be handled by defining an AI_DEFAULT thus 99% of the applications use flags = AI_DEFAULT instead of zero as you propose. > - returns a pointer to a buffer of the same type as gethostbyname(), > be that static or per-thread static or whatever else today's > implementations might be doing; the caller must set a flag > e.g. AI_ALLOC to cause gethostbyname3() to return dynamically > allocated memory, and only then is the caller required to free > the pointer using freehostent() I don't like this at all. Either the function should return dynamically allocated memory or not. Thus we just need to pick one. I think using dynamically allocated memory all the time is fine. Having the applications add a free(dyn)hostent call as part of porting shouldn't add that much difficulty. And the easy porting of the one-shot application is just to skip the free function. (How many applications really free all the memory they malloc?) > - if the 'af' argument is AF_INET6, gethostbyname3() may return > IPv4-mapped IPv6 addresses and non-IPv4-mapped IPv6 addresses; > the choice of when to return a v4-mapped address or a non-v4-mapped > IPv6 address is left to the implementation; the caller must set a > flag e.g. AI_NOV4MAPPED to restrict the returned addresses to > non-v4-mapped IPv6 addresses Defining AI_DEFAULT to include AI_V4MAPPED can solve this as well. > Perhaps AI_V6ADDRCONFIG should be the default behavior as well, I agree. Thus AI_DEFAULT would be AI_V4MAPPED|AI_V6ADDRCONFIG. Also, it sems like getaddrinfo should be specified to support the new AI_ flags. Having getaddrinfo be less powerful than gethostbyname3 sounds like a bad ide 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 Dec 8 18:23:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA18051 for ipng-dist; Mon, 8 Dec 1997 18:20:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA18044 for ; Mon, 8 Dec 1997 18:20:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA28540 for ; Mon, 8 Dec 1997 18:20:31 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA28354 for ; Mon, 8 Dec 1997 18:20:43 -0800 (PST) From: Margaret Wasserman To: ipng@sunroof.eng.sun.com Subject: (IPng 5047) Feedback on "Site Prefixes" draft by Erik Nordmark Date: Mon, 8 Dec 97 21:20:31 -0500 Message-ID: <9712082120.aa08362@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have read Erik Nordmark's "Site prefixes in Neighbor Discovery" draft, and I have some comments. The mechanism in the draft for passing around site prefix information looks reasonable to me. I like the way that the information has been encoded into the current prefix option without increasing the option length. However, I have some concerns about having the DNS resolver make the determination about whether site-local addressing should be used to forward messages to a given destination. Replacing the global addresses with site-local addresses for the destination address will only solve 1/2 of the problem of establishing site-local communication between site-local addresses. We also need to make sure that the source address is also site-local. Some applications choose their own source addresses, and if the application supplies a global address, it would be impossible to establish any two-way communication (site-local or global) with another host using a site-local destination. So, it is only safe to force site-local addressing when it is know that the application will choose an appropriate source address or allow an appropriate source address to be chosen by IP. So, the mechanism supplied in this draft would require some extension in order to avoid mandating a site-local address when the application has chosen a global source address. Perhaps passing the chosen source address, if any, into the DNS resolver? There are also several problems in the case of multi-interface hosts (non-routers). I realize that the draft does not attempt to address these cases completely, and that seems reasonable given that the full ND draft does not address multi-interface hosts, at all. However, I believe that we must address these issues eventually. IPv4 did not address the idea of a non-router, multi-interface hosts very well, but these hosts have sprung up, anyway (full of hacks, warts and strange little annoyances). I expect the need for these types of hosts to grow as security becomes a bigger issue and parts of businesses are intentionally fire-walled from eachother, etc. I also believe that the current number of these sorts of hosts is high enough that they should not be ignored. It seems to me that IPv6 should be designed with these hosts in mind, and that we should stop promoting drafts and specs which defer these issues. I've been very concerned lately by the vocal minority who believe that IPv6 is already too widely deployed to change -- as this view becomes stronger, there will be more resistance to changing current specs. To integrate multi-interface hosts cleanly into IPv6 will require changes to some of the base specs, and I'd hate to see the deferral of these issues leave us between a rock and a hard-place (highly advanced specs and a strong resistance to changing them warring against the need for well-integrated multi-interface hosts). I believe, for example, that some changes to this draft could make it work for multi-interface hosts whether or not their interfaces are in different sites. These changes could also alleviate the source address selection issue discussed above and the problems with mobile hosts described in the draft. Let's consider the simplest case of a multi-site, multi-interface host: +-------------+ |(H2/S3) | +------------+ | | | | | Site A | | Site B | | | | | | S1 --H-- S2 (H3/S3)| +-------------+ +------------+ In the above picture, the host (H) has two interfaces, one in Site A, and the other in Site B. Interface #1 (I1) of H is in Site A on Subnet #1 (S1), and interface #2 (I2) of H is in Site B on Subnet #2 (S2). Certainly, the mechanism for detecting site multihoming described in this draft could detect that this host is in two different sites, and could prevent the use of site local addresses for communication. Is it desireable, though, to prevent their use? Wouldn't it still be desireable for H to communicate to other hosts in Site A using site-local addressing? Unfortunately, the mechanisms in this draft would not be "safe" to use on a multi-interface, multi-site host because the global addresses would be replaced by site-local addresses by the DNS resolver, and the IP send code would never receive the global destination address. In that case, it would be impossible for the IP engine to distinguish between Subnet #3 in Site A and Subnet #3 in Site B, and the packet could not be forwarded to the correct subnet with any assurance. Also, two hosts (H2 and H3) using the same address token, both on Subnet #3 in their respective sites could not be distinguished without further information (the interface over which communication with them could be established, which would not be known when sending a single packet outbound). So, how could this problem be resolved? I believe that it would be possible to resolve these situation by making the determination about whether to use a site-local address later in the processing of the packet. The DNS resolver would continue to return only global IP addresses. If desired, the application could continue to pick one of these addresses to attempt to establish communication. In the stacks I have worked with, there is a point before the checksum is calculated, when the IP "application" (UDP, TCP, etc.) will ask IP to return an appropriate source address to use for sending this packet (if one has not already been provided by an upper-layer application). This code also usually determines the outbound interface and next-hop destination information for the particular packet and stores that state in a way that can be used when the packet is finally sent. Do Berkeley stacks have a step like this? This is the point at which I believe we should be making the final selections of both the source and destination IP addresses. If the upper-layer application has mandated a particular source address, interface, etc., those choices can be taken into account at this time. I do realize that this would mean changing the API in use on most stacks (including my own) to handle this situation, but I believe it will solve a number of problems. If nothing is mandated by the upper-layers, the IP code could do the checks described in this draft to determine if the specified (global) destination address is actually site-local. This code would also know which interface(s) the address is site-local for, and could check that no other interface was specified by the upper-layers. It could also check (if necessary) how packets to the particular site-local address would be routed. If there were no route to that subnet, and a default route would send the packet out a non-site-local interface, a global address could be used instead. Since the IP code would have the actual global address when it was determining how the packet would be sent, there would be no ambiguity between site-local destinations in different sites. But, the communication between the hosts would all be site-local, reaping the benefits of site-local communication. Because the final source and destination addresses are chosen at the same time, an appropriate choice would be made based upon the source address (if any) mandated by the upper-layer application. I believe that asking the DNS resolver code to determine both the source and destination addresses and the interface that will be used for forwarding would be odd. And, it is important that all of these items be selected consistently in order to properly establish site-local communication. I also believe that this mechanism could "solve" the case of mobile hosts. Since the IP code of a host presumably knows if it has been configured as a potentially mobile host, mobile hosts could always use global addressing. I realize that this idea has not been completely specified in this message, but I would be interested to know if others see any obvious problems with this concept. As a separate comment -- in trying to write this message (and previous messages), I have been frustrated by a lack of common terminology to discuss the different portions of an IPv6 system. Although I have extensive experience with TCP/IP code, I have never worked with a Berkeley-based stack (or any stack which used sockets as its native interface). As a result, I often have some difficulty parsing others' discussions of how particular features could be implemented, and they sometimes appear to have trouble understanding my comments. I am certainly open to being educated in this area, and would welcome comments from the Berkeley-literate. I also thank you for your patience and forebearance. But, I believe that this problem, and others, could be resolved by writing an overall architecture specification for IPv6 which could define the basic components of an IPv6 system and define common terminology for discussing those units and their interfaces. Are there others who feel that such a document would be useful? Or has this idea already been discussed and rejected for some reason? Has anyone even read this far in this message :-). Margaret Margaret Wasserman mrf@epilogue.com Director of Internet Protocol Development (617) 245-0804 Epilogue Technology Corp. FAX: (617) 245-8122 333 North Ave, 4th Floor http://www.epilogue.com Wakefield, MA 01880, USA Sales: info@epilogue.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 Dec 8 21:23:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id VAA18153 for ipng-dist; Mon, 8 Dec 1997 21:20:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id VAA18146 for ; Mon, 8 Dec 1997 21:20:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA24050 for ; Mon, 8 Dec 1997 21:20:24 -0800 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id VAA03492 for ; Mon, 8 Dec 1997 21:20:35 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Mon, 8 Dec 1997 21:23:15 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810D0231F@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Margaret Wasserman'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5048) RE: Feedback on "Site Prefixes" draft by Erik Nordmar k Date: Mon, 8 Dec 1997 21:20:13 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Replacing the global addresses with site-local addresses for the > destination address will only solve 1/2 of the problem of establishing > site-local communication between site-local addresses. We also need > to make sure that the source address is also site-local. Some > applications choose their own source addresses, and if the application > supplies a global address, it would be impossible to establish any > two-way communication (site-local or global) with another host using a > site-local destination. So, it is only safe to force site-local > addressing when it is know that the application will choose an > appropriate source address or allow an appropriate source address to > be chosen by IP. So, the mechanism supplied in this draft would > require some extension in order to avoid mandating a site-local > address when the application has chosen a global source address. > Perhaps passing the chosen source address, if any, into the DNS > resolver? > This is a good issue. If the destination address is site-local and the application does not specify a source addess, then source address selection should pick a site-local source address in normal cases. If the application specifies a global source address, then communication will work, but the advantage of using site-local addresses will be lost. It's not ideal but I think it's best to modify these applications as they are ported to v6. Doing source address selection by hand is trickier for v6, there are more choices. Why do v4 applications sometimes specify a source address when initiating a connection? Maybe we supply better mechanisms for the common case. > There are also several problems in the case of multi-interface hosts > (non-routers). I realize that the draft does not attempt to address > these cases completely, and that seems reasonable given that the full > ND draft does not address multi-interface hosts, at all. However, I > believe that we must address these issues eventually. > I agree! It's actually pretty easy to support multi-interface hosts based on the ND draft. Off hand the only provision in the ND draft that causes problems is a provision that says if an address can not be ascertained to be on-link, and there are no default routers, then the address should be treated as on-link. For a multi-interface host, this doesn't work - on-link for what interface? Another issue with multi-interface hosts is sending to link-local destination addresses. The outgoing interface needs to be specified. The easy way to do this is specify a link-local source address, but that might not uniquely identify the interface in some situations. (See my earlier email today to ngtrans about link-local addresses for tunnels.) Source address selection is no harder, I believe - once you've identified the outgoing interface, just choose from the addresses assigned to it. (Note I prefer "strong model".) > I believe that it would be possible to resolve these situation by > making the determination about whether to use a site-local address > later in the processing of the packet. The DNS resolver would > continue to return only global IP addresses. If desired, the > application could continue to pick one of these addresses to attempt > to establish communication. > > In the stacks I have worked with, there is a point before the > checksum is calculated, when the IP "application" (UDP, TCP, etc.) > will ask IP to return an appropriate source address to use for > sending this packet (if one has not already been provided by an > upper-layer application). This code also usually determines the > outbound interface and next-hop destination information for the > particular packet and stores that state in a way that can be used > when the packet is finally sent. Do Berkeley stacks have a step like > this? > > This is the point at which I believe we should be making the final > selections of both the source and destination IP addresses. > There are a couple things I don't like about this. First, it means the application is telling the IP layer to send to one address and then the IP layer decides it knows better and sends to another address. I'm much more comfortable with DWIM at the application level, especially if the application can use a resolver flag to override the behavior. Second, I don't see how it helps with the original motivation, which is making renumbering transparent for applications that are communicating within a site. If the applications still have global addresses in their variables, then they can be hosed when the site renumbers. > As a separate comment -- in trying to write this message (and previous > messages), I have been frustrated by a lack of common terminology to > discuss the different portions of an IPv6 system. Although I have > extensive experience with TCP/IP code, I have never worked with a > Berkeley-based stack (or any stack which used sockets as its native > interface). As a result, I often have some difficulty parsing others' > discussions of how particular features could be implemented, and they > sometimes appear to have trouble understanding my comments. I am > certainly open to being educated in this area, and would welcome > comments from the Berkeley-literate. I also thank you for your > patience and forebearance. > > But, I believe that this problem, and others, could be resolved by > writing an overall architecture specification for IPv6 which could > define the basic components of an IPv6 system and define common > terminology for discussing those units and their interfaces. > I think a non-BSD perspective will be valuable. I take the conceptual data structures in the ND draft as the overall conceptual architecture for an implementation. Are they not what you are looking for? 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 Mon Dec 8 21:27:42 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id VAA18175 for ipng-dist; Mon, 8 Dec 1997 21:25:30 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id VAA18168 for ; Mon, 8 Dec 1997 21:25:19 -0800 (PST) Received: from lillen (hobo118 [129.146.31.118]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id VAA16003; Mon, 8 Dec 1997 21:25:12 -0800 (PST) Date: Mon, 8 Dec 1997 21:25:08 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5049) Re: Feedback on "Site Prefixes" draft by Erik Nordmark To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9712082120.aa08362@khitomer.epilogue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Replacing the global addresses with site-local addresses for the > destination address will only solve 1/2 of the problem of establishing > site-local communication between site-local addresses. We also need > to make sure that the source address is also site-local. If the application specifically binds the source address to be a global address it should still be able to communicate with a site local destination. (Of course, such communicating is likely to break when the global address is renumbered.) If the application doesn't specify the source address the protocol stack will presumably (although there is no draft or rfc which says this) prefer a site local source address when using a site local destination address. > There are also several problems in the case of multi-interface hosts > (non-routers). I realize that the draft does not attempt to address > these cases completely, and that seems reasonable given that the full > ND draft does not address multi-interface hosts, at all. However, I > believe that we must address these issues eventually. Are you referring to a node which has multiple interfaces belonging to different sites? Or a host which has multiple interfaces all in the same site? While the draft protocol essentially disables the mechanism in the former case I don't know of any problems in the latter case. > Certainly, the mechanism for detecting site multihoming described in > this draft could detect that this host is in two different sites, and > could prevent the use of site local addresses for communication. Is > it desireable, though, to prevent their use? Wouldn't it still be > desireable for H to communicate to other hosts in Site A using > site-local addressing? It is certainly possible but if you have something similar to the gethostbyname* APIs you would have to modify all the applications to always associate a "site index" (akin to an interface index) with each IP address since any place an IP address is used the address could be a site local address. A site local address on a node connection to multiple sites would not by itself be sufficient to identify the site (i.e. the set of interfaces over which the packet could be transmitted). > Unfortunately, the mechanisms in this draft would not be "safe" to > use on a multi-interface, multi-site host because the global > addresses would be replaced by site-local addresses by the DNS > resolver, and the IP send code would never receive the global > destination address. In that case, it would be impossible for the IP > engine to distinguish between Subnet #3 in Site A and Subnet #3 in > Site B, and the packet could not be forwarded to the correct subnet > with any assurance. Also, two hosts (H2 and H3) using the same > address token, both on Subnet #3 in their respective sites could not > be distinguished without further information (the interface over > which communication with them could be established, which would not be > known when sending a single packet outbound). > > So, how could this problem be resolved? > > I believe that it would be possible to resolve these situation by > making the determination about whether to use a site-local address > later in the processing of the packet. The DNS resolver would > continue to return only global IP addresses. If desired, the > application could continue to pick one of these addresses to attempt > to establish communication. Such a scheme makes it harder to port applications which use IP addresses in the application protocol such as FTP. The application would connect to a global address and, unless special logic is added, would use that address for the LPRT port command even though the protocol stack decided to connect using a site local address. I don't know all the application protocols which include IP addresses thus I don't know how hard it would be to change those applications. But if we choose to go this way it would probably be best to just introduce a new connect API where the address is specified using a domain name instead of an IP address. > I also believe that this mechanism could "solve" the case of > mobile hosts. Since the IP code of a host presumably knows if > it has been configured as a potentially mobile host, mobile > hosts could always use global addressing. Unfortunately the goal of mobile IP is that every host is potentially a mobile host. Thus mobile IP is still an unsolved problem. > But, I believe that this problem, and others, could be resolved by > writing an overall architecture specification for IPv6 which could > define the basic components of an IPv6 system and define common > terminology for discussing those units and their interfaces. Some RFCs (e.g. the TCP one) specifies an abstract API with primitives like CONNECT and assuming some SEND primmitives from below. But I haven't seen any generic description of the steps which e.g. all IP transmit code goes through. > Are there others who feel that such a document would be useful? Or > has this idea already been discussed and rejected for some reason? > Has anyone even read this far in this message :-). Not me :-) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 9 00:13:48 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id AAA18524 for ipng-dist; Tue, 9 Dec 1997 00:11:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id AAA18517 for ; Tue, 9 Dec 1997 00:11:06 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA14944 for ; Tue, 9 Dec 1997 00:11:03 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA29118 for ; Tue, 9 Dec 1997 00:11:17 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id DAA13362; Tue, 9 Dec 1997 03:04:42 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA15315; Tue, 9 Dec 1997 03:04:40 -0500 Message-Id: <199712090804.AA15315@wasted.zk3.dec.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Sun, 07 Dec 1997 06:21:41 PST." <9712070921.aa27758@khitomer.epilogue.com> Date: Tue, 09 Dec 1997 03:04:40 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, Unfortuneately I have to leave Thurs eve and won't be able to attend the site local and other discussions of IPng on Friday. First time I have to leave an IETF because a fortune 100 customers wants to hear about IPv6 technically and I gotta go.... I will respond to your other mail and Richards response as input too as I am able from this very hectic and crowded IETF meeting this week. >>> On the other hand, I think users & programmers generally expect >>>reliable behavior within sites or intranets, and it's much more important >>>for renumbering not to affect intranet applications. >> >>THis is not the long term case. They will want their www connections >>worldwide to stay up and with great reliability and "scalability". >>Does this proposal scale is what I am asking myself? >Using valid and preferred addresses, it should be possible to >keep existing connections up for a finite time, anyway. If this >time were long enough (hours), it should allow most connections >that an end-user has established (www connections, ftp connections, >etc.) to resolve cleanly. What I was speaking of (not clearly in the mail) was that what we have to do is when we see an address whose SLA is a site prefix (at this point I won't get concerned about multihomed) and translate it to fe0c::.... Note I agree that DNS is not the place to do this at all. So lets say its done as a "shim" in the resolver library (which I don't consider doing it in DNS), but where its done will have the same cost. On a client its not an issue as they usually use one browser and access one page at a time as one example. On a server they need to respond to many clients but don't really need to do a lookup and respond to the clients peer address. FTP has some commands that could require accessing the name. So I don't think there is an applications scaling problem after some thought. But if these are not in the DNS what happens with netstat -in and other network utilities that look up the DNS name for addresses. They won't find them without first recreating the global address and then doing a DNS look up. This I am less clear will scale. But again needs more thought. >The more difficult case is when an application is trying to keep a >connection up constantly (usually without a user driving it on an >on-going basis). It is not my experience that any well-written >application will rely upon a TCP connection (in- or out-of-site) >staying up forever. The real possibility of hardware failures or >human errors make this an unreasonable assumption, so applications >which need long-term connectivity already have mechanisms for >reestablishing connectivity after an outage. I agree. >The issue would be whether these applications can survive IP address >changes. For example, do they do a new DNS lookup before trying to >reestablish connectivity, or are they simply trying to reconnect to >the same IP address. If the former, then renumbering should not >catastrophically affect the applications, whether the connection is >in-site or out-of-site. This is how well-written IPv6 applications >should be written, and I am sure that most of the applications that we >(as commercial vendors) have ported to IPv6 would have this property. I agree. >But, many customers have their own applications which they might not >modify promptly/completely/correctly for IPv6, and some of these >applications may fall into the second group (use the same IP address >to reestablish a connection when it dies). In this case, a mechanism >which allows automatic use of a site-local address for in-site >communication would allow these applications to continue to function >properly across renumbering by the ISP. In fact, the connection would >not drop at all during renumbering. I agree. >>> One price to pay for this is that a distributed system that spans >>>site boundaries and passes around addresses internally will need to be >>>cognizant of site-local vs global addresses; this will complicate the port >>>to v6 of some codes. >> >>I don't see it? If we do it right the code will only exist in the DNS >>client and the kernel. >By kernel, do you mean the TCP/IP stack? As far as I have been able >to determine, the main price for site-local addressing is increased >complexity in IP (particularly in the source address selection and >packet acceptance rules). The additional complexity is minor for >singly-homed hosts, but is much greater for multi-interface hosts or >routers as these systems have to deal with the possibility that their >interfaces may be in separate sites. By client above I should have said "resolver library". I would think we want consistency from the point of inception of the site-local address when the app does gethostbyname3 down the IP stack. By kernel yes I mean't the IP stack. And yes I was concerned about the multihome situation. But also SNMP MIBs, Statistics, and even the data structures used to support the IP stack. Here is why: If I only depend on a constant fe0c::SLA::eui-id then what is to prevent duplicates in the IP stack look ups etc? This will require work arounds and those work arounds could mean larger structures, bigger hash tables, etc. And how do we make sure they are not duplicated if the nodes are on different links? I will assume the SLAs for what we used to call subnets. But now the longest match is longer than before, but we can fix that if we know a priori that its site local. But I worked this out for my comfort this evening so that will work. >I agree that the choice whether to use site-local or global addressing >can (and should) be made by the IP stack, not by an individual >application (where an applications is anything over IP -- TCP, UDP, >OSPF, a customer app). However, there are some details with this that >I haven't nailed down in my own mind. I think its the resolver right now? That way its transparent to the stack except for the multihome case. >For example, an application will call DNS to get the IP address(es) >for the hostname it wants to reach. I think it would be a mistake to >require DNS to know whether a particular connection would/wouldn't be >site-local, as this seems pretty far outside the purview of DNS. So, >the DNS should probably return only global addresses at this point. >I do realize that there is still some outstanding disagreement on >this point, though. But, let's go forward based on my assumption... The DNS can return global addresses and the resolver can do the grunt work of translation. On the apps to. If the app lets the IP stack pick the src address then because the dst address is site-local the IP stack can assign a site-local address. But if the app picks the IP address like dec::1 then the IP stack has to make that a site local address. That will be a pain especially at the kernel socket layer (e.g. uipc_socketxxxxx). Because if its not done there then the IP stack and tcp/udp code paths have to deal with global addresses, which IMO is a bad thing. >So, now we have a list of global addresses. Currently, in some APIs, >the applications picks one of these addresses to use as the remote >address. I think this is rather broken, as applications seldom have >any criteria on which to make this choice, but I believe that this is >the existing mechanism for remote address selection in most IPv4 >systems. After choosing a remote address, the application will >"route" the packet to determine the local address to use, and both >addresses will be used to compute the checksum (including the >IP-pseudo-header). After this point, the addresses cannot be changed >by the IP stack. Well they could as I allude to at the virtual socket layer on BSD type systems anyway. I would think it would be even cleaner on a non-Host OS too? >So, the IP stack cannot, after this point, decide to use a site-local >remote address (and corresponding site-local local address). I would agree and even the transport virtual layer should not be dealing with this at all IMO. >One possible answer to this would be to have the DNS resolver add site >local addresses to the list of proferred addresses when appropriate. Same conclusion I came up with. But it don't work when the app selects the src address and we CANNOT outlaw that IMO (others have tried and failed this would be a rathole IMO to attempt). >Probably this information would be obtained via a call into IP with >the list of global addresses? But, use of a site-local address may be >dependent upon using a particular outbound interface, so IP would >have to "route" the packet to determine what interface would be used >(because, for example, the default route could be through an interface >in a different site) before suggesting a site-local address. Since I >assume that we wouldn't want to maintain state for this connection in IP, >the packet would be "routed" again to determine the source address before >the pseudo-header checksum is calculated -- or the DNS resolver would >also need to pass up the source address. So, this plan seems less than >ideal. I may be missing something here, though, since I am not a DNS >expert. The DNS resolver is out of the loop by the time its in IP. Also what I outlined above avoids the IP stack kernel problems but we still got the multihome problem. One way to fix the multihome problem is label our ipv6_ifnet (how ever folks unionized v4 ifnets or did dual or whatever) with the sla's which can contain the link prefix too. In the forward path the sla+linkprefix would be used to select the interface on a multihomed node. I am pretty pro on Eriks proposal. But the DNS lookups for tcpdump and such will be very messy and will have a cost for customers network utilities. /jim Perhaps the answer is to pass the entire list of DNS-returned addresses into the IP stack during the "routing" stage and have both the local and remote IP addresses returned at that time? If this were the case, it would be possible for the IP stack to pick a site-local address if one of the DNS-returned global addresses was in-site on (one of) the host's interface(s). However, this would require at least some changes to current applications. On some systems, this would in fact require changes to the application-layer applications, as they currently make the destination address selection from the list proferred by DNS. >But again I don't see a big porting issue. Also most everyone has >ported to IPv6 and its not like we are just starting except for a few. It depends who "everyone" is. There are a _huge_ number of people who write/use/sell sockets-based (or other) IP-based products. Most stack vendors have probably implemented IPv6 (or will use the port of someone who has), but I believe that most applications-vendors (including people with in-house applications) have not. >My issue is all this worth adding to the existing v6 code base? > >Can it be done in an efficient manner? These are both important questions. I am not certain whether the benefits of site-local addressing outweigh the costs. But, that is a hard determination to make given that we have yet to develop a full set of mechanisms that would provide the benefits. Until we know how the benefits would be achieved, it is impossible to measure the costs. Assuming that the benefits cannot be satisfactorily achieved or that the benefits would be outweighed by the costs, I believe we should revert to using site-local addressing only for non-internet connected sites (as previously suggested by Rich(?)). Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Epilogue Technology Corp. FAX: (617) 245-8122 333 North Ave, 4th Floor http://www.epilogue.com Wakefield, MA 01880, USA Sales: info@epilogue.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 Dec 9 06:46:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA18697 for ipng-dist; Tue, 9 Dec 1997 06:41:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA18690 for ; Tue, 9 Dec 1997 06:41:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA26255 for ; Tue, 9 Dec 1997 06:41:10 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA17853 for ; Tue, 9 Dec 1997 06:41:19 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA07148; Tue, 9 Dec 1997 08:39:42 -0600 Message-Id: <199712091439.IAA07148@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5051) Re: Feedback on "Site Prefixes" draft by Erik Nordmark In-reply-to: Your message of Mon, 08 Dec 1997 21:20:31 EST. <9712082120.aa08362@khitomer.epilogue.com> Date: Tue, 09 Dec 1997 08:39:41 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Deleting the global addresses from the list returned is a bad idea. If a node has gone mobile, sending to its site-local or link-local address will get you an "Address Unreachable". Presumably, that's your cue to try another destination address. Put the globals last, but keep them. 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 Tue Dec 9 07:05:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA18727 for ipng-dist; Tue, 9 Dec 1997 07:01:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA18720 for ; Tue, 9 Dec 1997 07:01:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA03140 for ; Tue, 9 Dec 1997 07:01:43 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA27966 for ; Tue, 9 Dec 1997 07:01:35 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id KAA25357; Tue, 9 Dec 1997 10:01:21 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id KAA05551; Tue, 9 Dec 1997 10:01:20 -0500 (EST) Date: Tue, 9 Dec 1997 10:01:20 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971209100120.ZM5549@seawind.bellcore.com> In-Reply-To: Margaret Wasserman "(IPng 5047) Feedback on "Site Prefixes" draft by Erik Nordmark" (Dec 8, 9:20pm) References: <9712082120.aa08362@khitomer.epilogue.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: (IPng 5052) Re: Feedback on "Site Prefixes" draft by Erik Nordmark MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Your discussion of "multi-sited hosts" is at the heart of my questioning of site local addresses. The catch phrase is that, as specified now, site local addresses have all the "properties" of IPv4 net 10 addresses. Failure occur when: * a host is multi-sited (which of the N sites receives the site address) * a mobile host moves off-site but keeps a tunnel to its home. * sites are merged * sites are split These problems occur because site local addresses don't include a unique prefix that identifies the site. Adding this prefix would not be very difficult, for example as: | 10 bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+-------------------------+ |1111111011| site-id | subnet ID | interface ID | +----------+-------------+-----------+-------------------------+ The 38 bits prefix could actually be organized to indicate the type of assignment, for example a 6 bit prefix identifying the registry, with values such as 0 meaningless 1 random number 2 IANA assigned followed by a 32 bit number which can be either random (the site manager throws a coin 32 times) or assigned by the IANA, probably through a system of registries, but maybe through some automatic process (2**32 is a big number, much larger than the number of networks registered in the DNS). This would not make the site local addresses routable, but it would help enforce site boundaries and site selection. And the site local addresses could even be stored in the DNS, because you could easily instruct the agents to ignore addresses that are not part of "your site." -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 9 07:40:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA18786 for ipng-dist; Tue, 9 Dec 1997 07:36:46 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id HAA18779 for ; Tue, 9 Dec 1997 07:36:13 -0800 (PST) Received: from lillen (hobo139 [129.146.31.139]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id HAA20712; Tue, 9 Dec 1997 07:36:00 -0800 (PST) Date: Tue, 9 Dec 1997 07:35:55 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5053) Re: Feedback on "Site Prefixes" draft by Erik Nordmark To: Christian Huitema Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <971209100120.ZM5549@seawind.bellcore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | 10 bits | 38 bits | 16 bits | 64 bits | > +----------+-------------+-----------+-------------------------+ > |1111111011| site-id | subnet ID | interface ID | > +----------+-------------+-----------+-------------------------+ Adding a site-id is worth exploring. If we reserve the all-zero value we can maintain compatibility with today's format. Do you think that the site-id can help solve the mobile moving outside its home site? > This would not make the site local addresses routable, but it would help > enforce site boundaries and site selection. And the site local addresses > could even be stored in the DNS, because you could easily instruct > the agents to ignore addresses that are not part of "your site." If we want to use random site ids there might be collisions if you put the site locals in the DNS. Thus the check for "your site" should probably verify that the RRset contained one or more global addresses which match the global prefixes assigned to the site (in addition to verifying that the site-id belong to the site). If we are seriously considering putting site local addresses in the DNS (and ignoring them if they are not in the same site) it would be a good idea to immediately state that site local addresses (fec0::0/10) retrieved from the DNS should be ignored (until the mechanism for verifying that the sender is in the same 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 Dec 9 08:36:24 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA18943 for ipng-dist; Tue, 9 Dec 1997 08:33:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA18936 for ; Tue, 9 Dec 1997 08:33:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA02551 for ; Tue, 9 Dec 1997 08:33:06 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA20071 for ; Tue, 9 Dec 1997 08:32:12 -0800 (PST) From: Margaret Wasserman To: richdr@microsoft.com CC: ipng@sunroof.eng.sun.com In-reply-to: <4D0A23B3F74DD111ACCD00805F31D810D0231F@red-msg-50.dns.microsoft.com> (message from Richard Draves on Mon, 8 Dec 1997 21:20:13 -0800) Subject: (IPng 5054) Re: Feedback on "Site Prefixes" draft by Erik Nordmar k Date: Tue, 9 Dec 97 11:31:36 -0500 Message-ID: <9712091131.aa12596@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >[Rich Draves:] >If the >application specifies a global source address, then communication will work, >but the advantage of using site-local addresses will be lost. The communication will always work in this direction (site local destination, global source). But there could be cases where the responses would not be returned (site local source, global destination) if the routing path to the global address traverses any links that are not within the site. In general, it is probably desireable to avoid sending packets from a site local address to a global address. I agree that this is probably best fixed by suggesting that IPv6 applications not choose a source address or interface themselves (unless they really know what they're doing?). Probably the most common case in which hosts specify a source address is when the are sending a response to a particular message. If the application works over UDP, for example, it could be necessary to specify the source in order to make sure that the response is properly associated with the request. However, in this case things will work properly if we make sure that the mechanisms for selecting the source and destination addresses for a new communication make a consistent choice of addresses. They would then be used (in reverse) for the response, and all would be well. > I agree! > > It's actually pretty easy to support multi-interface hosts based on >the ND draft... Then, let's do it! I am not completely certain of all of the details that would need to be changed for multi-interface, multi-site hosts to work, but your list looks like a good place to start. > There are a couple things I don't like about this. > > First, it means the application is telling the IP layer to send to >one address and then the IP layer decides it knows better and sends to >another address. I'm much more comfortable with DWIM at the application >level, especially if the application can use a resolver flag to override the >behaviour. DWIM? I guess I've never really understood why the application gets involved again between the DNS resolver and the call into the IP layer to send the packet. I have never really worked with an application that did more than hand the first resolved address into IP, anyway. But, I agree that having the resolver change the addresses is more consistent with the existing IPv4 architecture. Which probably makes it preferrable. > Second, I don't see how it helps with the original motivation, which >is making renumbering transparent for applications that are communicating >within a site. If the applications still have the global addresses in their >variables, then they can be hosed when the site renumbers. Actually, I hadn't pictured the applications keeping the global addresses in their variables on an ongoing basis. I had thought that an application could hand a global destination address into IP and be handed back both a source and destination address to use for that communication. Ideally, I'd just like to see a DNS name passed in and a full set of addresses returned, but the division between DNS and IP in the current application calling sequence makes this clumsy, as well. The important thing in my mind (and the thing that makes it possible to do site-local communication from a multi-site host) is that the source address, destination address, interface and next-hop address all need to be picked consistently by an entity that knows the global destination address, the site prefix(es) for each interface, which interface will be used to send to a given destination (site-local or global) AND what parameters (source address, interface, etc.) the application has mandated. I believe that all of this information is needed to make a proper selection of the source and destination addresses. Unfortunately, there is no good fit for a part of IP that would have all of this information and be in a position to communicate to the application the information that the application would need to compute the IPv6 pseudo-header checksum and send the packet... > I take the conceptual data structures in the ND draft as the overall >conceptual architecture for an implementation. Are they not what you are >looking for? There are certainly a big step in the right direction. However, they seem to confine themselves to the routing/addressing related datastructures (which is probably good for the ND spec). There are other pieces to this puzzle that would be helpful, though, such as the conceptual "modules" (for lack of a better word) that comprise an IP system, how IP communicates with other parts of the stack (i.e. DNS, etc.). There are an enormous number of assumptions we make because of our experiences with v4 stacks, but there doesn't seem to be any write-up of the basic architectural model of an IP stack (either v4 or v6). Therefore, it is hard to discuss the changes to that model that would make multi-interface hosts work better. The base reaction seems to be that we can't change to existing IPv4 architecture. But, is there a single existing IPv4 architecture, or are there several? I can accept that, for most important issues, the current IPv4 stacks have quite a bit in common, and we can probably refer to the "IPv4 architecture" without *too* much room for different interpretations (although different terminology does creep in). However, we are changing the IPv4 architecture by adding the concept of sites and site-local addressing, link-local addressing, etc. In fact, the entire ND spec which moves address resolution in IP is a pretty major architectural change. Also, I believe that some changes to the IPv4 architecture would be necessary to support multi-interface hosts more cleanly in IPv6 than they were supported in IPv4. However it is difficult to unambigously discuss changes in an architecture which is more a matter of shared experience than any actual specification. But, specifying an abstract architecture for all of IPv6 would be a large amount of work, and I am certainly willing to accept a consensus opinion that the return would not be worth the effort. It is my opinion that the return would justify the effort, though, particularly in the long term. Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Epilogue Technology Corp. FAX: (617) 245-8122 333 North Ave, 4th Floor http://www.epilogue.com Wakefield, MA 01880, USA Sales: info@epilogue.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 Dec 9 08:56:58 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA18966 for ipng-dist; Tue, 9 Dec 1997 08:53:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA18959 for ; Tue, 9 Dec 1997 08:53:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA07569 for ; Tue, 9 Dec 1997 08:53:30 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA01657 for ; Tue, 9 Dec 1997 08:52:11 -0800 (PST) From: Margaret Wasserman To: Erik.Nordmark@Eng CC: ipng@sunroof.eng.sun.com In-reply-to: (message from Erik Nordmark on Mon, 8 Dec 1997 21:25:08 -0800 (PST)) Subject: (IPng 5055) Re: Feedback on "Site Prefixes" draft by Erik Nordmark Date: Tue, 9 Dec 97 11:50:43 -0500 Message-ID: <9712091150.aa12793@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >[Erik Nordmark:] >Are you referring to a node which has multiple interfaces belonging >to different sites? Or a host which has multiple interfaces all >in the same site. Sorry, I should have been more specific. The problems with this draft only exist in the former case -- the case in which this draft disables its mechanisms. I also think that it is reasonable, given that fact that several other drafts punt the concept of mutli-interface hosts altogether, specifically the ND draft, for this draft to handle multi-site hosts by disabling the mechanism. I'd just like to see a mechanism that would work for multi-site hosts. Some parts of this draft are hard to evaluate because the concept of a "site" is poorly defined. As such, it is not really possible to make a determination about whether the check for a multi-site hosts will/will not work reliably. For example, are sites allowed to overlap? Can one site be a subset of another site? Can a single site have multiple site prefixes? If a site prefix is only valid on a subset of the hosts interfaces, for any reason, I don't think that it would be "safe" to convert the global address matching that address to a site-local address in the resolver, since the resolver cannot control which interface will be used for sending the packet. >Such a scheme makes it harder to port applications which >use IP addresses in the application protocol such as FTP. >The application would connect to a global address and, unless special... Obviously I was unclear on this point, since both you and Rich reached the same conclusion. I expected the application to receive the addresses from IP (during the address-selection step I described) and use both of the addresses obtained in this manner for the full communication. The application couldn't assume that the first address returned by DNS is the "final" destination address (as many do). It would need to wait until after this additional step to know the destination address (at the same time that it would currently find out the source address). >Unfortunately the goal of mobile IP is that every host is potentially >a mobile host. Thus mobile IP is still an unsolved problem. Somehow I keep having trouble with this concept. I realized after I sent my previous mail, that my approach wouldn't solve the situation for mobile IP, anyway. Even if mobile hosts could know that they are potentially mobile, there would be no way for other hosts establishing communication with those hosts to know... So, it remains an unresolved issue. >Some RFCs (e.g. the TCP one) specifies an abstract API with primitives >like CONNECT and assuming some SEND primmitives from below. >But I haven't seen any generic description of the steps which e.g. >all IP transmit code goes through. This is what I had in mind. I think it would be very useful if we could come to agreement on such a conceptual model for IPv6 and could understand well whatever changes we had made from a similar (understood, but not specified) conceptual model for IPv4. We could then understand the various implications of any architectural changes we make and evaluate their worth, etc. Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Epilogue Technology Corp. FAX: (617) 245-8122 333 North Ave, 4th Floor http://www.epilogue.com Wakefield, MA 01880, USA Sales: info@epilogue.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 Dec 9 09:36:00 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA19045 for ipng-dist; Tue, 9 Dec 1997 09:33:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA19038 for ; Tue, 9 Dec 1997 09:32:53 -0800 (PST) From: bound@zk3.dec.com Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA18982 for ; Tue, 9 Dec 1997 09:32:46 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA15943 for ; Tue, 9 Dec 1997 09:32:42 -0800 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA11065; Tue, 9 Dec 1997 11:28:26 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00479; Tue, 9 Dec 1997 11:28:22 -0500 Message-Id: <199712091628.AA00479@wasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: (IPng 5056) Re: Feedback on "Site Prefixes" draft by Erik Nordmark In-Reply-To: Your message of "Tue, 09 Dec 1997 10:01:20 EST." <971209100120.ZM5549@seawind.bellcore.com> Date: Tue, 09 Dec 1997 11:28:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good points christian....I am going to stop responding until I see mail to these points. could be a set of showstoppers you have presented us that must be discussed... /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 Dec 9 12:43:59 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA19244 for ipng-dist; Tue, 9 Dec 1997 12:40:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA19237 for ; Tue, 9 Dec 1997 12:40:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA24785 for ; Tue, 9 Dec 1997 12:40:31 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA14832 for ; Tue, 9 Dec 1997 12:40:13 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA07819; Tue, 9 Dec 1997 14:38:32 -0600 Message-Id: <199712092038.OAA07819@gungnir.fnal.gov> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5057) Re: Feedback on "Site Prefixes" draft by Erik Nordmark In-reply-to: Your message of Tue, 09 Dec 1997 10:01:20 EST. <971209100120.ZM5549@seawind.bellcore.com> Date: Tue, 09 Dec 1997 14:38:32 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > type of assignment, for example a 6 bit prefix identifying the > registry, with values such as > 0 meaningless > 1 random number > 2 IANA assigned > followed by a 32 bit number which can be either random (the site > manager throws a coin 32 times) or assigned by the IANA, probably > through a system of registries, but maybe through some automatic > process (2**32 is a big number, much larger than the number of > networks registered in the DNS). Happy birthday (problem) to you. In other words, the probability of duplication occuring among M random selections from N values becomes large when M ~ sqrt(N). 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 Tue Dec 9 20:04:52 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id UAA19535 for ipng-dist; Tue, 9 Dec 1997 20:02:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id UAA19528 for ; Tue, 9 Dec 1997 20:01:59 -0800 (PST) Received: from lillen (hobo124 [129.146.31.124]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id UAA18060; Tue, 9 Dec 1997 20:01:54 -0800 (PST) Date: Tue, 9 Dec 1997 20:01:50 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5058) Re: Feedback on "Site Prefixes" draft by Erik Nordmark To: Matt Crawford Cc: Christian Huitema , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199712092038.OAA07819@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Happy birthday (problem) to you. > > In other words, the probability of duplication occuring among M > random selections from N values becomes large when M ~ sqrt(N). I don't know Christian's intent but if the primary problem is the node that is multihomed to multiple sites then M is likele to be a rather small number (say less than 10). Thus while 38 bits might not be enough for global uniqueness it should be plenty in the local case. We can still put such link locals in the DNS if we are careful enough when they are used (only when the RRset also includes a global address which falls in one of the site prefixes advertised by the router). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 10 19:20:51 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id TAA20625 for ipng-dist; Wed, 10 Dec 1997 19:13:03 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id TAA20610 for ; Wed, 10 Dec 1997 19:12:45 -0800 (PST) Received: from lillen (hobo161 [129.146.31.161]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id TAA17001; Wed, 10 Dec 1997 19:12:13 -0800 (PST) Date: Wed, 10 Dec 1997 13:11:54 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5062) Site prefix and mobile IP To: ipng@sunroof.eng.sun.com Cc: mobile-ip@smallworks.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 Re: draft-ietf-ipngwg-site-prefixes-01.txt Please reply to just the ipng alias. The site prefix draft has an open issue when it comes to multicast. This is an attempt to resolve that issue by defining that the site extends to the mobile node that has moved outside its home site. It is possible to tunnel site local addresses to and from a mobile node which has moved outside its home site as long as the mobile node ignores all the site prefixes associated with the visited link/site. Thus I believe the only issue is an architectural one: When a mobile node moves outside its home site (and has a tunnel to its home agent) do we still consider it being part of the home site? Assume we take the view that the mobile node away from home has a tunnel interface which is part of the home site (i.e. it has a site local address and global addresses) and has one (or more) interfaces in the visited site which do not have any site local addresses. Then the MN can be considered to be part of the home site while also having one or more interfaces which are not considered to be part of any site. In such a case the HA can safely tunnel site local packets to and from the MN without any confusion - in the MN a site local address would always be part of the home site and would always apply to the tunnel interface. Thus the MN must tunnel any packets with a site local source *or* destination to the HA (the same way it MUST tunnel multicast packet that have a home address as a source). Comments? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 10 19:52:59 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id TAA20683 for ipng-dist; Wed, 10 Dec 1997 19:48:28 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id TAA20676 for ; Wed, 10 Dec 1997 19:48:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA19503; Wed, 10 Dec 1997 19:48:13 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id TAA17257; Wed, 10 Dec 1997 19:48:26 -0800 (PST) From: Masataka Ohta Message-Id: <199712110341.MAA07994@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA07994; Thu, 11 Dec 1997 12:41:43 +0900 Subject: (IPng 5063) Re: Site prefix and mobile IP To: Erik.Nordmark@Eng Date: Thu, 11 Dec 97 12:41:42 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: ; from "Erik Nordmark" at Dec 10, 97 1:11 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Re: draft-ietf-ipngwg-site-prefixes-01.txt > > Please reply to just the ipng alias. > > > The site prefix draft has an open issue when it comes to > multicast. This is an attempt to resolve that issue by defining > that the site extends to the mobile node that has moved outside > its home site. I'm afraid you misunderstand what "multicast" means (which means CBT with a single core, PIM with a single RVP and BGMP are all broken). As multicast is location independent, you don't have to worry about the locality of multicast. With IPv6 address space, it is just OK to delegate unicast addresses to end users and says that the users are delegated multicast addresses with some higher bit reversed from the delegated unicast address. Of course, it is a lot better to further separate unicast addressing structure into 8+8 that address to name mapping can be performed only looking at the lower 8 bytes of the IPv6 address, which make lower part of unicast address location independent, which then means multicast address should be only 8 byte long (the remaining 8 bytes can be used to avoid tunneling) the neccesity of which I think takes one or two more years to be recognized by many. But, that's life. As you might know, it took more than a year to make IPv6 address 8+8, after I prophetted that it absolutely necessary to let IPv6 support all the people in the world. > Thus I believe the only issue is an architectural one: > When a mobile node moves outside its home site > (and has a tunnel to its home agent) do we still consider > it being part of the home site? As the current mobility protocol support only a single home, it is highly location dependent and is no good for multicast. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 10 19:58:54 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id TAA20709 for ipng-dist; Wed, 10 Dec 1997 19:55:51 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id TAA20702 for ; Wed, 10 Dec 1997 19:55:41 -0800 (PST) Received: from lillen (hobo161 [129.146.31.161]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id TAA19751; Wed, 10 Dec 1997 19:55:38 -0800 (PST) Date: Wed, 10 Dec 1997 19:55:34 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5064) Re: Site prefix and mobile IP To: ipng@sunroof.eng.sun.com, mobile-ip@smallworks.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 > The site prefix draft has an open issue when it comes to > multicast. In case it isn't obvious "multicast" should be "mobile IP". 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 Dec 15 16:54:42 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA24201 for ipng-dist; Mon, 15 Dec 1997 16:50:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA24194 for ; Mon, 15 Dec 1997 16:50:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA14158 for ; Mon, 15 Dec 1997 16:50:19 -0800 Received: from desolation.CS.Berkeley.EDU (desolation.CS.Berkeley.EDU [128.32.33.142]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA22809 for ; Mon, 15 Dec 1997 16:50:32 -0800 (PST) Received: from desolation.CS.Berkeley.EDU (padmanab@localhost) by desolation.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id QAA06863 for ; Mon, 15 Dec 1997 16:46:52 -0800 (PST) Message-Id: <199712160046.QAA06863@desolation.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 Reply-To: Venkat Padmanabhan From: Venkat Padmanabhan To: ipng@sunroof.eng.sun.com Subject: (IPng 5069) support for priority drop in IPv6 X-Face: 8oz'i+bl`|5PbRnbf:lhb^%e[KkX6s2O+~WXUjjyZy3Ew*s3R1@]D {~a]r4V]),Mlwru>UYa+!f7aeLD3),v{_U3S*(e/Os}3N7*+U+#;5\W0!-U+zs&>c/Gb2FH/|KZ*Li eMcCH0X~${-18~JhYDf3Dc}H1,F; Wed, 17 Dec 1997 12:06:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA11361 for ; Wed, 17 Dec 1997 12:06:31 -0800 Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA17450 for ; Wed, 17 Dec 1997 12:06:38 -0800 (PST) Received: (from richier@localhost) by horus.imag.fr (8.8.5/8.8.5) id VAA17548 for ipng@sunroof.Eng.Sun.COM; Wed, 17 Dec 1997 21:06:19 +0100 (MET) Date: Wed, 17 Dec 1997 21:06:19 +0100 (MET) From: Jean-Luc Richier Message-Id: <199712172006.VAA17548@horus.imag.fr> Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 5070) How do I declare ::1 in the reverse DNS ? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am trying to port some commands and libraries to IPv6, and I have a problem with codes using a combinaison of gethostbyname and gethostbyaddr to control that an address is ``correct''. I need to declare ::1 in the reverse DNS (in the same way than everybody declare 1.0.0.127.in-addr.arpa). But where do I declare it: - Is it an IPv4 compatible address, and I have to declare 1.0.0.0.in-addr.arpa - or is it not, and I declare int the .....int domain. The first case is how the gethostbyaddr code do it now, but I am not sure it is correct: ::1 is a ordinary IPv6 address, not a mark for a tunnel to the machine with IPv4 0.0.0.1 address. For ``correctness'' controls done with gethostname(gethostaddr(x)) == x, if x is IPv4 mapped or compatible, I have to use AF_INET DNS calls, otherwise I do AF_INET6 tests. But it seems erroneous to declare that the IPv4 address of gethostbyaddr(::1) (that is localhost.ipv6....) is 0.0.0.1 So what is the exact definition of a IPv4 compatible address - Any address in the prefix ::/96 - Or only the addresses in the prefix ::/96 which correspond to legal IPv4 addresses (for exemple the prefix ::/96 MINUS the prefix ::/104) PS: The problem is similar for the unspecified address :: In that case, it can be seen as corresponding to IPv4 unspecified address 0.0.0.0, but what interest for a IPv4 compatible unspecified address ? But ther problem is less important for nobody expect DNS checks on unspecified address ... Sincerly -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : (33) 4 76 82 72 32 Fax : (33) 4 76 82 72 87 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 21 08:07:17 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA28718 for ipng-dist; Sun, 21 Dec 1997 08:03:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA28711 for ; Sun, 21 Dec 1997 08:03:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA12384 for ; Sun, 21 Dec 1997 08:03:20 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA02371 for ; Sun, 21 Dec 1997 08:03:39 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA24041; Sun, 21 Dec 1997 16:03:13 GMT Received: from brianh.hursley.ibm.com (brianh.hursley.ibm.com [9.20.43.84]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with SMTP id QAA30522; Sun, 21 Dec 1997 16:03:10 GMT Message-Id: <349D1B60.5472@hursley.ibm.com> Date: Sun, 21 Dec 1997 13:36:32 +0000 From: Brian E Carpenter Reply-To: brian@hursley.ibm.com Organization: IBM Internet Division X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: Venkat Padmanabhan Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5074) Re: support for priority drop in IPv6 References: <199712160046.QAA06863@desolation.CS.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Venkat, There's a new IETF effort growing out of the integrated services WG to define the IPv6 traffic class byte and the IPv4 type of service byte compatibly so as to cover this and other functions needed for differentiated services. Nothing is decided yet. Brian Carpenter >-- Venkat Padmanabhan wrote: > > Is there a proposal to use one or more bits in the traffic class field > to support priority drop of packets (akin to cell loss priority in > ATM)? If there is, is the proposal to make such a priority mechanism > applicable to packets across multiple sources? > > I joined this list very recently and haven't been able to find this > information in the archive of mails from recent months, so I would > really appreciate relevant pointers. > > Thanks. > > -Venkat > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Dec 22 10:34:07 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA29435 for ipng-dist; Mon, 22 Dec 1997 10:29:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA29428 for ; Mon, 22 Dec 1997 10:29:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA27478 for ; Mon, 22 Dec 1997 10:29:46 -0800 Received: from digi-data.com (odin.digi-data.com [196.32.33.17]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA01376 for ; Mon, 22 Dec 1997 10:30:05 -0800 (PST) Received: by odin.digi-data.com id <19585>; Mon, 22 Dec 1997 14:28:36 -0400 Date: Mon, 22 Dec 1997 18:28:25 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems, Limited X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: IPng Mailing List Subject: (IPng 5076) Followup to Analysis on GSE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <97Dec22.142836gmt-0400.19585@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings, Can anyone point me to an RFC or Internet Draft that was produced as a followup to the Internet Draft titled "IPng Analysis of the GSE Proposal" if anything like that exists? -- Yours sincerely, Robert Honore robert@digi-data.com > Take care of what IS. The APPEARANCES will take care of themselves. > Money can't buy happiness, but the LACK of money can't buy ANYthing. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 22 10:59:43 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA29482 for ipng-dist; Mon, 22 Dec 1997 10:54:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA29475 for ; Mon, 22 Dec 1997 10:54:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA04495 for ; Mon, 22 Dec 1997 10:54:26 -0800 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA14148 for ; Mon, 22 Dec 1997 10:54:47 -0800 (PST) Received: from abfab.juniper.net (abfab.juniper.net [208.197.169.86]) by red.juniper.net (8.8.5/8.8.5) with SMTP id KAA22937; Mon, 22 Dec 1997 10:53:57 -0800 (PST) Message-Id: <3.0.1.32.19971222105320.006beda4@pobox.juniper.net> X-Sender: jstewart@pobox.juniper.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 22 Dec 1997 10:53:20 -0800 To: robert@digi-data.com, IPng Mailing List From: John W Stewart III Subject: (IPng 5077) Re: Followup to Analysis on GSE In-Reply-To: <97Dec22.142836gmt-0400.19585@odin.digi-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the authors of that document will be publishing an update soon so that it can be published as an informational rfc /jws At 06:28 PM 12/22/97 -0400, Robert Honore wrote: > >Greetings, >Can anyone point me to an RFC or Internet Draft that was produced as a >followup to the Internet Draft titled "IPng Analysis of the GSE >Proposal" if anything like that exists? > >-- > >Yours sincerely, > >Robert Honore > >robert@digi-data.com > >> Take care of what IS. The APPEARANCES will take care of themselves. >> Money can't buy happiness, but the LACK of money can't buy ANYthing. >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Dec 24 12:50:58 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA00781 for ipng-dist; Wed, 24 Dec 1997 12:43:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA00774 for ; Wed, 24 Dec 1997 12:43:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA17679 for ; Wed, 24 Dec 1997 12:43:34 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA08531 for ; Wed, 24 Dec 1997 12:43:56 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id MAA01917; Wed, 24 Dec 1997 12:43:32 -0800 Message-Id: <3.0.3.32.19971224124709.0083d830@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 24 Dec 1997 12:47:09 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5079) Draft December IPng W.G. Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached are the draft minutes from the IPng sessions at the Washington, DC IETF. Comments/changes to me. I will do an update early next week. Thanks and Happy Holidays! Bob -------------------- IPng Meeting Washington, DC IETF December 8-12, 1997 ---------------------- Chaired by Steve Deering (Cisco) and Robert Hinden (Ipsilon). Minutes taken and prepared by Robert Hinden. Agenda ------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Status of moving base specs to Draft Standard / R. Hinden (5 min) TLA/NLA Assignment Rules Status / R. Hinden (15 min) Resolve Neighbor Discovery and Addr Conf issues / T. Narten (20 min) Interface Identifier Global Flag / S. Deering (10 min) Mobile IPv6 Status / D. Johnson (10 min) THURSDAY, December 11, 1997, 0900-1130, (Empire Room) IPv6/NBMA Status / G. Armitage (10 min) IPv6 over PVC ATM / K. Yamamoto (10 min) Router Renumbering / M. Crawford (20 min) DNS mappings / C. Huitema (20 min) IPv6 Name Lookups Through ICMP / M. Crawford (15 min) Reverse Address lookup in DNS for IPng / O. Gudmundsson (15 min) Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound (10 min) Traceroute hop-by-hop option / A. Durand (10 min) ECN Bit Assignment / S. Floyd (20 min) FRIDAY, December 12, 1997, 0900-1130, (Empire Room) IGMP for IPv6 / S. Deering (15 min) Neighbor Discovery over Tunnels / S. Deering (20 min) IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta (10 min) Site prefixes in Neighbor Discovery / E. Nordmark (20 min) Router Alert / C. Partridge (10 min) VRRP for IPv6 / R. Hinden (15 min) DHCP vs. M & O Bits / Narten (10 min) IPv6 Addresses in URL's / Deering, Carpenter (10 min) Non-Corrosive Multi-Homing Idea / Matt Crawford --------------------------------------------------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) --------------------------------------------------- Introduction / S. Deering Review Agenda / S. Deering -------------------------- Steve Deering introduced the meeting and reviewed the agenda. UNH Testing Report / Bill Lenharth ----------------------------------- Interoperability test session last week at UNH. First purely interoperability test session at UNH. First time to put routers into the test network. There were 10 hosts and 6 routers tested. 90% of the host implementations worked well as did 70% of host implementations. After work on site most of the problems discovered were "addressed". Both BGP4+ and RIPng routing protocols including route redistribution worked. Three long days of testing. Next test period is with Sun Connectathon in March. Both conformance and routing testing will be done. No IPSEC testing was done. Document Status / R. Hinden --------------------------- IETF Last Call completed for Proposed Standard - Generic Packet Tunneling in IPv6 Specification / Dec 96 (IESG Comments received 11/25/97, waiting for new ID) AD reported that this should resolved soon. - Transmission of IPv6 Packets over Ethernet Networks / Nov 97 (IESG: Resolve Global/Local bit setting issue) - Transmission of IPv6 Packets over FDDI Networks / Nov 97 (G/L) - IP Version 6 Addressing Architecture / Nov 97 (G/L) - An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments from Registries) IETF Last Call completed for Experimental - IPv6 Testing Address Allocation / Nov 97 IETF Last Call completed for Informational - IPv6 Multicast Address Assignments / Nov 97 Submitted to IESG for Proposed Standard - IPv6 Router Alert Option (IESG returned, need new ID) - MIB for IPv6: ICMPv6 Group / Jun 97 - MIB for IPv6: TCP / Jun 97 - MIB for IPv6: Textual Conventions & General Group / Jun 97 - MIB for IPv6: UDP / Jun 97 - Transmission of IPv6 Packets over Token Ring Networks / Nov 97 (G/L) - IPv6 over PPP / Nov 97 (G/L) - IP Header Compression / Nov 97 Submitted to IESG for Informational - Advanced Sockets API for IPv6 / Jul 97 Submitted to IESG for BCP - TLA and NLA Assignment Rules / Nov 97 Status of moving base specs to Draft Standard / R. Hinden --------------------------------------------------------- BASE SPECS TO DRAFT - IPv6 Specification o MTU Issue Resolved (1280 octets) o New Draft Issued o Starting to Collect Implementation Info - ICMP o New Draft issued w/out IGMP messages o Starting to Collect Implementation Info - Path MTU Discovery o Starting to Collect Implementation Info Will be sending questionnaire about implementation info to the ipngwg list in next day or two. [Editors Note: Bill Lenharth of UNH, volunteered after to the session to help with this based on the testing being done at UNH. He will be contacting implementers.] TLA/NLA Assignment Rules Status / R. Hinden ------------------------------------------- TLA/NLA ASSIGNMENT RULES STATUS - Updated Draft based on IANA Comments o Added Established Provider Criteria, Registration Fee, and Auction for New Organizations - Submitted to IESG for BCP 11/11/97 - Considerable Controversy!!! - Waiting for IESG Direction on how to proceed Met with registry folks this morning about their concerns about TLA doc. Progress made, but nothing concrete to report yet. Will report again at Friday session. Resolve Neighbor Discovery and Addr Conf issues / T. Narten ----------------------------------------------------------- Talk about remaining issues with ND and Addr conf doc. Zero Lifetime denial of service attack - Bad guy sends out a single bogus Router Advertisement (RA) - RA contain prefix info option with Valid lifetime of zero - Host interprets RA to mean address is now invalid, stop using it immediately. - Upper layer protocols may stop working (e.g., all TCP connections break) This is not a hard requirement in spec but some implementations may do this] Not like other Denial of Service attacks - No comparable "hit and run" packet in IPv4 (or IPv6) as dangerous - Once upper layer have aborted open connections, no recovery is possible. - Problem must be fixed in IPv6 is to be no more vulnerable than IPv4 Proposal 1 - If received with Valid Lifetime > 2 hours or greater than lifetime in cache, process as before - Attempts to reduce the valid lifetime to value less than 2 hours and less than lifetime of cached entry require special processing. [pseudo code for algorithm] This proposal limits removing prefix to 2 hours units. Can't remove one in shorter time. Proposal 2 [from Erik Nordmark] - Avoid defining special mechanism to handle this one specific denial of service attack. - Rely on robustness of transport protocol to limit impact of zero lifetime denial of service attack. - Already have many denial of service attacks (both IPv4 and IPv6) that cause packets to be blackholed. - Transports (e.g., TCP) are robust in such cases by continuing to retransmit (e.g., not allowing ICMP destination unreachable to terminate connection) - IP layer continues processing zero lifetime as specified inRFC1971, but transport layer is not required to terminate connections using addresses that become invalid. - IP layer on host would blackhole packets form invalid source address (i.e., no violation of existing spec). Comments that this proposal, is just focused on TCP. Problem is worse, it affects all other transports, SNMP, etc. Everyone that the machine uses addresses. Attack is much worse than just TCP. Suggestion that we should do both. They are not really in conflict. Could also use authenticated router advertisements. Comment that this is not normal behavior for TCP. Should kill all state with TCP and other transports. R. Hinden suggested that lifetimes less than two hours should be accepted only if packet was authenticated. This allows for finer grained control (e.g., less that two hours) in environments that need it and two hour everywhere else. Suggestion was made for Proposal 1 unless packet was authenticated. If authenticated, then accept lifetime less than 2 hours. Strong consensus to adopt this proposal. DHCP-specific bits in Router Advertisement - "M" bit indicates DHCP should be used to obtain addressing information. - "O" bit indicates DHCP should be used to obtain other (i.e., non-addressing) information. Proposal - Do away with "O" bit - Single bit would say "do" or "don't" use DHCP Rational - Separate bits complicates protocol - Having "O" bit raises issue of what to do if DHCP server returns DHCP option that "O" bit says shouldn't be obtained - Benefit unclear. Behavior of the two bits can be obtained by having DHCP server decide what information it wants to give out. J. Bound thinks we only need one bit. All that stateless is for is addresses and link parameters. Critical parts of IPv6 is to make renumbering work. Important part of this is dynamic DNS. Thinks that the router should only control the address allocation. Rest of configuration is independent of what router can supply. DHCP w.g. does not have a strong feeling either way. Matt C. suggested that these bits tell the host when it is completely configured. If both bits are zero it is done. Otherwise it needs to go to DHCP to get additional information. It should not come up until it has all information. Narten suggest wait to come to closure on this topic until after discussed by DHCP w.g. IPng will continue this in the Friday session. Default value for valid lifetime in Prefix information options: - RFC1970 says default preferred lifetime is 7 days - RFC 1970 says default valid lifetime is infinity - Value of infinity problematic: o Suppose system administrator decides to timeout prefix o Subsequent Router advertisements advertise small lifetimes, eventually going to zero. o Lifetime of zero must be advertised forever, to be sure nodes that are disconnected from the link receive updated value on reconnection. o Danger that any prefix advertised with infinite Lifetime will be hard to completely purge from network. - Propose setting default value to 30 days o System administrator is free to change this value; 30 days is the default value in the absence of input from system administrator o Having an address without properly functioning router is of limited benefit; if router is functioning properly, it will be sending out proper Prefix Advertisement options. Consensus to adopt this proposal. Summary of Open Issues - Protection from zero life denial of service attacks. - If Proposal 1, is 2 hours the right time? No objections to 2 hours. [Editor's note: Remaining issue to be resolved at Thursday w.g. session before moving this to draft standard] Mobile IPv6 Status / D. Johnson ------------------------------- High-level overview of operation: - Care-of addresses from IPv6 address autoconfiguration - Mobile node sends its own Binding Updates - Used for correspondent nodes and home registration - Nodes cache bindings in a Binding Cache - Correspondents route own packets directly to mobile node Current spec is draft-ietf-mobileip-ipv6-04.txt One implementation done so far (CMU). Other implementations in progress? Editorial Changes: - Added a statement of some non-goals of the protocol in Section 1. - Added definition for home link and home subnet prefix, replacing the old term home subnet. - The new terms foreign link and foreign subnet prefix likewise replace the old term foreign subnet. - Moved the Comparison with Mobile IP for IPv4 section to earlier in the document (now Section 2) - Added specific in Section 4 listing the fields conceptually present in each Binding Cache entry and in each Binding Update List entry. - Added Section 12 on IANA Considerations. - Replaced the description of specification language keywords, MUST, MAY, SHOULD, etc., with the new standard reference to RFC 2119. - Updated the References to point to the most recent version of each cited RFC or Internet-Draft. Binding Update Option Changes: - Increased the Lifetime field from 16 bits to 32 bits, to allow consistency with other lifetime values used in IPv6. - Replaced the Home Link-Local Address Present (L) bit and the Home Link-Local Address field with a new mechanism implemented by the ID Length field: o Home agent becomes home agent for all on-link home addresses with this interface ID o Proxies for mobile node in Neighbor Discovery with this ID o If ID Length is 0, only use single specific home address o Mobile node may send separate Binding Updates for each ID if different - Change sending of Binding Update to a mobile node's previous default router from SHOULD to MAY. - Clarified handling for packets addressed to a mobile node's link-local address or site-local address: o Data packets are not forwarded to the mobile node while away from home. o Home agent returns ICMP Destination Unreachable, Code 3, for any received. o Home agent continues to defend for Neighbor Discovery. o As the use of link-local addresses or site-local addresses evolves over time in IPv6, this disposition of such packets may need to change, however. Binding Update Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|C| Reserved| ID Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | (only present if C bit set) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Acknowledgment Option Changes: - Changed the Option Type value to now ignore rather than returning an ICMP error if not recognized. - Increased the Lifetime field from 16 bits to 32 bits. - Increased the Refresh field from 16 bits to 32 bits. Binding Acknowledgment Option Format: +-+-+-+-+-+-+-+-+ | Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Status | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Request Option Changes: - Changed the Option Type value to now ignore rather than returning an ICMP error if not recognized. - Added a discussion of sending Binding Requests in Section 7.6. - Added a discussion of receiving Binding Requests in Section 9.11. Binding Request Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Address Option Changes: - Added details of how and when Home Address option is added to a packet when sending: o TCP/UDP/etc. generates packet as normal. o In IP (Mobile IP), if the Source Address is not home address, just send packet normally. o Otherwise, insert a Home Address option: + Copy Home Address field from Source Address + Change the Source Address to care-of address + Must be performed before outgoing IPsec processing, if any - Added details for inbound IPsec processing: o Must be performed before any packet modifications for Home Address option processing. Home Address Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Comments, Please: - We need feedback/agreement from IPng Working Group - Please send e-mail comments to Mobile IP mailing list: mobile-ip@SmallWorks.COM - Comments can also be sent to: o Dave Johnson, dbj@cs.cmu.edu o Charlie Perkins, cperkins@eng.sun.com Wants processing of home address option on the receive side to be required by all receivers. Not just the ones that implement Mobile-IPv6. Need Home agents anycast address, and option code for bridging xxx, yyy, zzzz options. IPng chairs will figure out how to do these allocations. Need to reserve a group of interface identifiers to be used as anycast addresses. Chairs promised to resolve issue this week. Interface Identifier Global Flag / S. Deering --------------------------------------------- [Figure showing how EUI-64 based interface identifiers are created from IEEE 48bit MAC addresses] Current algorithm for doing this fabrication inverts the state of the "Global/Local" bit. Becomes "1" if global, "0" if local. Reason for inversion is to make it easier on links that do not have hardware tokens, such as dialup links, tunnels, etc. in order to make it easier to set this bit correctly. Comment on mailing list that this is complex and the bit should not be inverted. IESG sent it back to the working group to review earlier decision. Matt Crawford: Arguments in favor of inverting the bit. Makes it easier to recognize vendor type code when looking at wire. We are corrupting the use of EUI64 format. Would be better to not change bit. KRE: Matt's comment is correct, but he came to the wrong conclusion. Packet trace will still have real MAC addresses at front of frame. Thinks a better way to do this would be to Xor with different value to make it look very different. M. Wasserman: Thinks we should have a fixed prefix for manually assigned interface identifiers. Brian C: Thinks current approach will make things harder for maintenance technications. C. Huitema: Thinks the problem is reversed. Real problem is that managers will assign bit's incorrectly. Computers will not have a problem. KRE: Also disagrees with Brian C. Thinks we should leave the way it is. A. Durant: In the ten implementations he has seen nine out of ten do it correctly, and would like to keep it as it is. Deering took poll. 1) Keep it as is, 2) eliminate inversion, 3) KRE proposal Rough consensus to keep things the way they are now. Document editor will report w.g. consensus to area director. [Editor Note: done as of 12/15/97] ------------------------------------------------------------ THURSDAY, December 11, 1997, 0900-1130, (Empire Room) ------------------------------------------------------------ IPv6/NBMA Status / G. Armitage ------------------------------ ION w.g. summary relevant for IPng Since last meeting - In Munich, much confusion - Action items o Generalize the architecture - ATM Split document into two o draft-ietf-ion-ipv6-oo.txt o draft-ietf-ion-ipv6-atm-00.txt - Other IPv6 related drafts o draft-conta-ion-ipv6-fr-00.txt o draft-conta-ion-ipv6-ind-00.txt General Architecture - Assume general NBMA "cloud" o Capable of p-p links, pt-mpt links, may/may not native multicast - MBMA could be ATM, Frame Relay, IPv4, ... - MARS? NHRP? Major New Item / Shortcut suppression - Request in Munich for host controlled shortcut suppression - How to convey this indication in-band? - Original default, discover shortcut whenever a "flow" is detected - Need indication of "flows" that should not have this default action applied - Proposal for broad interpretation of flow label field Interpretation of Flow Label - Flow label == 0 o Apply default IPv6/NBMA flow-detection and short cut discovery - Flow label != 0 o Do not apply IPv6/NBMA flow-detection and shortcut discovery by default - Support whatever other packet forwarding, queuing, and/or scheduling rules may have been negotiated with each router along the path - Perform best effort in absence of negotiated service - No additional semantic restrictions Discussion how this would interact with other usage of flow label. C. Huitema pointed out that it is backwards. Flowlabel indicates that it is a long lived flow. That is the case when extra overhead to shortcut flow is worthwhile. No flow label probably indicates that flow will be short lived. Long discussion about merits/cons of this proposal. draft-ietf-ion-ipv6-atm-00.txt - Media specific companion document to draft-ion-ipv6-00.txt PVC rules - Standard LLC/SNAP encaps, with IPv6 PID (null encapsulation allowed/negotiable) Document currently in ION working group last call. If doesn't go through quickly, ATM Point-to-Point link text will be moved to a separate document. Router Renumbering / M. Crawford -------------------------------- RR Goals - One step changes to the set of prefixes in use site-wide o Including ND timers and flags - Spectrum of finer-grained operations, down to a single interface of a single router - Reliability - Security RR Basics - Carried in ICMPv6, type = TBD - two codes: Command & Result - Built-in authentication and & replay protection, or use IPSEC - "Dry-run" mode to simulate a Command - "site-conscious" can apply command to subset of multi-sited router RR Command Structure [Using ABNF of RFC2234] - CmdPkt = Header *PCO AuthData - PCO = Op MatchPrefix *UsePrefixPart - UsePrefixPart = cut & paste info to combine old & new bits Mask & Flags to set ND PIO flags ND RA timers New Prefix bits RR Result Structure - ResPkt = Header *MatchReport AuthData - MatchReport identifies a match by Which PCO in the corresponding Command packet Interface Prefix - The new prefixes, if any, can be inferred Lacking in current draft - Examples! - Asymmetric keys?? - Is message processing section sufficiently rigorous - Other error contradictions? Comments: Doesn't deal with result implosion. Author agrees, needs to be added. Is there any way to have routers tell what prefixes you have now without changing anything. Answer: could ask for zero prefix match and look at replies. Also use SNMP. Deering suggested to use similar mechanisms that IGMP uses to space out replies to multicast query. Would like to see ICMP code assigned, then folks build implementations. Need to resolve open issues. DNS mappings / C. Huitema ------------------------- Revising the AAAA record New AAAA Record? - One proposal: draft...-aaaa-00.txt - Main feature: indirection AAAA = prefix length + suffix + name of prefix - Three questions: o Do we need this? o Shall we use the same record number? o Shall we maintain upward compatibility? Needs, Let's take an example +--------+ +--------+ | | | | | TLA-1 | +--+ TLA-2 | | | / | | +---+----+ / +----+---+ | / | | / | +---+----+ / +----+---+ | +-+ | | | ISP-A | | ISP-B | | | | | +----+---+ +---+----+ \ / +--+--------------+--+ | Site | +--------------------+ | Host - We will Consider o Change provider, o Network multi-homing o Provider renumbering, o Provider multihoming What we have today will not scale - For each host, 3 records TLA1/A/SiteA/LinkID TLA2/A/SiteA/LinkID TLA2/B/SiteA/LinkID - Change provider Change all records - Network multihoming Duplicate record Provider renumbering Phone call to site - Provider multihoming Duplicate prefixes Local copies Using the new format solves the problem - For each host, one record Link/ID + net.site.com - For the site NLA-A + net.ips-a.net - Change provider update net.site.com/AAAA - Network multihoming Two AAAA records for net.site.com - Provider renumbering - Provider multihoming Update provider AAAA record Question 2 - Resource Record Number - Using new RR type o Allows parallel deployment, o But resolvers will never look for two records - Use same RR type (AAAA) o Will break old software o Forces transition to new structure Question 3 - Format compatibility +---+--------+-------------+ | L | Suffix | Domain Name | +---+--------+-------------+ +-----------------+---+-------------+ | 128 bit address | L | Domain Name | +-----------------+---+-------------+ +-----------------+---+-------------+ | 128 bit address | 0 | ...... | +-----------------+---+-------------+ - If compatible, two phase deployment - Longer records per host (128 bits v.s. 80) - Sill wins over current AAAA record (multihoming) A decision on AAAA record? - Shall we o Leave RFC1886 alone, or o Modify & recycle to Proposed Standard? - If we modify: o Shall we keep the AAAA record? - If we modify the AAA record Shall we adopt the new format (draft) ? or shall we maintain compatibility ? Question about impact on gethostbyname. Would not change gethostbyname interface in host. Could this be hidden from hosts? Answer: Doesn't work, caching problems, some parts short lived, some long lived. Won't work. Authors conclusion is that we want to modify RFC1886. Recycle at PS. How does this relate to dynamic updates? Group wants to adopt this proposal. Then do a working group last call. This will replace RFC1886 IPv6 Name Lookups Through ICMP / M. Crawford -------------------------------------------- Who-Are-You? ------------ Format +-----------+-----------+-----------+-----------+ | Type | Code | Checksum | +-----------+-----------+-----------+-----------+ | ID | unused | +-----------------------+-----------------------+ | | + Nonce + | | +-----------------------------------------------+ | Time-to-Live | +-----------+-----------------------------------+ | NameLen | | +-----------+ + | | + FQDN.... + | | +-----------------------------------------------+ Review of Motivation - IN-ADDR.ARPA poorly maintained, will IPv6.INT be better? - Maintenance of delegations will be more difficult in the expected frequent renumbering environment of The Future. - For access control, or even logging, IP6.INT provides nothing but a hint anyway. Features - PLUS: Routing system takes the place of IP6.INT delegations o Always current - PLUS: A meaningful TTL is usually available from Auto config or DHCP - MINUS: Target must be up and reachable to do a lookup o But is it meaningful to say a certain FQDN is associated with an address, when it isn't up? Status of -01 - Query & Response processing: done - Rules for TTL field: done - Added terminology section; guidelines & discussion; security considerations, IANA considerations. - Open issues: o Possible change to DNS client view o Negative caching - Authentication: new issue DNS Delegation and Renumbering ------------------------------ Two General Modifications to DNS Problems - aaaa-00 DBIT records o Rely on wildcard records which produce intermediate data of no later use - dns-reverse-lookup-00 DBIT records o Require lower zones to be renamed on renumbering * Even DynDNS can't pull off that trick New Proposal - Previous proposal involved only new RR types and new resolver/additional section processing rules - I propose two extension to DNS which have uses unrelated to IPv6 Non-Terminal CNAMEs - ... or whatever you want to call them - Translate a suffix of the queried domain. - Query to be repeated with same initial part of translated suffix - Examples 225.131.in-addr.arpa ZNAME in-addr.final.gov. foo.com ZNAME foo-division.bar.com Counted Bit-Strings - Length-of-Label counts bits, not octets. o Pad data to octet, of course - To be considered: as a sequence of 1-bit labels (at an almost 16x space saving) - Consider it a form of compression +------+------------------+------------------------+ | 01xy | bit count | bit string | +------+------------------+------------------------+ What they can do for IPv6 - Simplify and shrink synthesized AAAA records - Enable reverse zones which are nearly hands-free maintainable across "renumbering events." o Non-terminal ZNAME > delegation o Counted bit strings > N x (single purpose RR) Discussion. Conclusions: Make ICMP approach experimental. With multiple names? With warnings for scope? Keep ICMP for link-local. Could also add local name to address lookups as well for dentist office operation. Reverse Address lookup in DNS for IPng / O. Gudmundsson ------------------------------------------------------- IPng reverse DNS address lookup - Storing all reverse records under name like 0102030405060708090a0b0c0d0e0f10 o Is impossible to maintain o Is impossible to secure - Addresses consist of fields that reflect the delegation authorities, reverse lookup should maintain this information. - It is impossible to know the size of the next delegation unless it is fixed or it is explicitly stated. DBIT (delegated BITs) record - RBATA contains last bit delegated, DNS name of the authority assignment has been delegated to - Name on DBIT record encodes prior delegations o First byte is length of bit field o Subsequent bytes is the bit field o Names are stored as binary values - Examples: (in hex) o 08aa.ip6.ing IN DBIT 20 ripe.net - Last bit delegated == 128 delegates all remaining bits and corresponding DBIT record is expected in the domain delegated to - Last bit delegated == 0 is a EID/host DBIT record DBIT Example - Query for address aa2f:34:1::3fff:1234 - Server needs to query for the following DBIT records o IP6.INT DBIT 8 iana.org. o 08aa.IP6.INT DBIT 20 ripe.org. o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example. o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example - 2000010000.0c0034.0c02f0.08aa.IP6.INT. DBIT 128 thorshofn.ismennt.is.example. - 40000000003fff1234.thorshofn.ismennt.is.example. DBIT 0 sia.thorshofn.ismennt.is.example Example 1: Query for address - Ask server ipv6.int for DBIT record ofip6.int o IN.INT DBIT 8 iana.org o + NS records for iana.org + glue - Now ask iana.org for 08aa.IP6.INT DBIT record o 08aa.IP6.INT DBIT 20 ripe.org o + NS records for rip.net + glue - Now ask one of the ripe.net servers for 0c02f0.08aa.IP6.INT DBIT o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example o 20000020000.0c0034.0c02f0.08aa.IP6.INT DBIT 128 thorshofn.ismennt.is.example DBIT Example (2) - At this point all remaining bits are delegated now asks server thorshofn.ismennt.is.example. for 40000000003fff1234.thorshofn.isment.is.example o 40000000003fff1234.thorshofn.isment.is.example DBIT 0 sia.thorshofn.ismennt.is.example. for - Now server has all the DBIT records in and can generate an answer that looks like: o 80aa2f003400010000000000003fff1234.IP6.INT DBIT 0 sia.thorshofn.ismennt.is.example. - The last answer is not signed but the server can return to the resolve all DBIT records used to allow signature verification. DNS Impact of DBIT records - DBIT ignorant servers and resolvers will ask for 80aa2f003400010000000000003fff1234.IP6.INT - DBIT aware server needs to break address requested into the different fields o Servers SHOULD be able to longest prefix match on DBIT records in cache o Servers need to issue multiple queries to generate correct answers o Servers need to be able to merge multiple DBIT records into one answer. - DBIT preprocessing is similar to KEY chain verification in DNSSEC. Advantages of DBIT records - Allows delegations to take place on any bit boundary - Explicitly state the delegations and size of delegations o Allows full verification of the bindings - Fits well with caching name servers - End sites do not have to resign any DBIT records when renumbering Discussion. Contrasted with other proposals. CH: Suggests leaving 1886 alone (existing practice), wait until the newer stuff is ready to bring forward when we have all of the tools. Suspect that 1886 and new ZNAME will be OK to pursue. Chairs will discuss how to move these drafts forward and report back to the working group. J. Bound reports that this will slip deployment by 6 months. Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound -------------------------------------------------------- RFC1233 Update - flags now - Freehostent MUST always be called! - Flags Default (continues ....) 7. Agreement on change by hostbyaddr() 8. Suggest we use AI.Default as a system default. Also suggested to author off-line -> xxxxx 10. Name change suggestions: getdynhostbyname() Freedynhostent() getdynhostbyaddr() Suggestion to use "node" instead of "host" 11. Add new AI_Flags to getaddrinfo() Warning - TOG/XNET owns this spec ???? Thanks to Bob, Sue, Jim, & Rich [Jim Bound will send slides by email] Traceroute hop-by-hop option / A. Durand ---------------------------------------- Round trip Traceroute Traceroute Problem - Route for the direct patch - No information about the reverse path - Source-routing is not a solution - Many (most?) routes are asymmetrical (difficult to debug) - Can go through firewalls... Proposed Solution - Based on RFC1394 for IPv4 & IPv4 Record Route option - Define an hop-by-hop option processed by routers on the direct and the reverse path. - Define a new ICMP traceroute message - 4 different strategies can be used Traceroute hop-by-hop option 0 3 0 1 +-----------+-----------+ | Value=TBD | Length | +-----------+-----------+-----------+-----------+ | ID | Ptr | Flags | Boundary | +-----------+-----------+-----------+-----------+ | | | space to record information | . . . | | +-----------------------------------------------+ Router Information 0 3 0 1 +-----------+-----------+-----------+-----------+ | Type | HL | Medium | Reserved | +-----------+-----------+-----------+-----------+ | MBZ | AS | +-----------------------+-----------------------+ | | | Address | | | | | +-----------------------------------------------+ ICMP Traceroute message 0 3 0 1 +-----------+-----------+-----------+-----------+ | TBD | MBZ | Checksum | +-----------+-----------+-----------+-----------+ | ID | HL | Medium | Reserved | +-----------------------+-----------------------+ | MBZ | AS | +-----------------------+-----------------------+ | Reserved | +-----------------------------------------------+ | Address | | | | | +-----------------------------------------------+ Strategy #1 Two Packet traceroute - Originator send ICMP echo request to target with traceroute hop-by-hop - Routers store information within the option - Target send ICMP echo reply with traceroute hop-by-hop option initialized with data from the received packet. - How many routers can be recorded? o min MTU 576 => up to 21 o min MTU 1200 => up to 47 - OK for small networks, not enough in the general case [figure of two packet traceroute] Strategy #2 Limited Traceroute - Originator specifies to record the direct path or the reverse path. - Originator includes a boundary indication - Packet is sent with Hop Count set to 255 - Routers should record information iff current Hop Count <= Boundary [figure of limited traceroute] Strategy #3 Debug Mode - Originator set a "debug flag" in the hop-by-hop option - Routers send their information in a new ICMP traceroute message back to the originator. [figure of debug traceroute] Comments: Have looked at multicast route traceroute draft? Deering very nervous about debug mode because it generates so much traffic. Suggest modeling this like multicast traceroute and remove debug mode. CH: Two problems with approach. Real reason IPv4 traceroute not uses was that it was a stupid idea. Debug mode is a great tool for denial of service attack. This is very bad. M. Wasserman: Thinks proposal needs some more work. Likes the goal for what this does, but isn't sure this is the right mechanism. Overall conclusion that work should continue. DHCP vs. M & O Bits / Narten ---------------------------- M bit to control how if DHCP should be used to get addresses O bit to get other info from DHCP. Discussed in DHCP w.g. Agreed on clarification to language in spec. Issue is if different advertisements have different M & O bit values also resolved. Once use DHCP keep using it. Ignore changes in bits. Text will also be clarified. Bound suggested alternative. Bits not needed. If administrator has policy, then they control ND advertisements or turn on DHCP. Discussion and clarifications. Comment bit is important, because otherwise you have to wait for a timeout before continuing. Suggesting that we should keep bits and clarify usage. Bits are advisory. Hint to use DHCP or not. Working group consensus to leave keep bits and clarify text as to usage. ------------------------------------------------------------ FRIDAY, December 12, 1997, 0900-1130, (Empire Room) ------------------------------------------------------------ Document Status (continues) / R. Hinden --------------------------------------- Neighbor Discovery & Address Auto-Conf - Document editor will do wg last call for advancement to Draft as soon as updated drafts are out. Unicast Aggregation Formats draft - Author will add motivations section based on last call discussions. [Editor's note: Following additional discussions, author will change format to add a 8 bit reserved field between TLA and NLA field (reduces NLA to 24 bits). This resolves issue of allowing additional TLA's if routing system evolves to handle more top level routes but keeps initial limit at ~8K for initial allocations.] TLA/NLA Assignment Rules draft - After discussions with lots of IESG folks and other interested parties this week, decision is to form operations area WG to progress rules document. Allison Mankin and Erik Huizer will co-chair working group. ECN Bit Assignment / S. Floyd ----------------------------- A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP Internet Draft ECN Web page: http://www-nrg.ee.lbl.gov/floyd/ecn.html What is needed from IPv6 - An ECN-capable bit set by the origin transport protocol (for incremental deployment) - An ECN bit set by the router (instead of dropping the packet) (When the buffer has not overflowed, and the ECN-capable bit is set, and the router would otherwise drop the packet because of the RED algorithm, base don the average queue size. Where would the bits come from? - The IPv4 TOS byte and/or the IPv6 traffic class byte - Our original proposal was only in terms of IPv6 - IPv4: The current draft of draft-ellesson-tos-00.txt includes the CE and ECT (ECN-capable transport) bits - What would be the time scale of making this decision? - Where? Intserv/diff-serv? or IPng? Planning an ECN BOF at next IETF. Could make a formal request to IESG for two bits in IPv4 Why two bits instead of one? - The One-bit approach: The single bit would have two values: "ECN-Capable", and "either not-ECN-Capable, or Congestion Notification". - The ECN-Capable functionality is needed to allow a viable incentive for incremental deployment of ECN-aware hosts. - Robustness issues for one bit approach: o Default setting MUST be "either non ECN capable, or Congestion Notification" - The receiver has to know in advance that the sender is sending all packet with the bit set as "ECN-Capable". Why not Source Quench? - The delay difference (between RTT and part of an RTT) is not a critical issue for most environments - The ECN bit is applicable for multicast as well as for unicast applications. - With Source Quench, care must be taken not to add significant extra traffic in times of congestion. How would the router decide whether to drop the packet or set the ECN bit? - For ECN-capable packets, the router would set the ECN bit when it is in the regime of using RED to "mark" packets probabilistically. When the average queue size exceeds the maximum queue threshold, the router would drop arriving packets. - For most routers today, the packet drop rate is less than 10%. If these routers deploy RED, they are therefore generally in the regime of probabilistic marking. Does ECN make it easy for evil applications to ignore congestion control? - Already easy for "evil" applications to ignore congestion control. Just use UDP, and add a little FEC to counteract the packet drop rate. Or "turn off" congestion control for TCP. - In the absence of congestion control in the end-nodes, a moderate (less than 10%) packet drop rate is not, in and of itself, an effective mechanism of congestion control, or an effective deterrent to any application that wishes to "turn off" end-to-end congestion control. - ECN does add another way that applications could ignore congestion control, but setting the "ECN-capable" bit but ignoring the ECN bit in received packets. What applications would benefit from ECN - Reliable multicast - Real time flows with (fixed or adaptive) playback times - Very short web transfers - Low-bandwidth telnet connections ECN Simulations and Experiments - Simulations: the ns-1 and ns-2 simulators [floyd1994] - Experiments: UCLA (Chris Chen, Hariharam Krishnan, Steve Leung, Nelson Tang) has an ECN implementation in IPv6 FreeBSD. Using RED implementation from ALTQ. - The bits to use in the IPv6 header for experimental purposes? IGMP for IPv6 / S. Deering -------------------------- Based on IGMPv2 for IPv4 Spec (recently approved as proposed standard) Changes of terminology from IPv4 version - Host/Router/Node, Network/Link, etc. - "multcast listener discover" Uses ICMPv6 message types, not protocol ID #2 Uses Link-local source address for messages - Link-Scope all-nodes multicast destination address for queries Didn't get new draft out prior to ID deadline. Will get it a week or two after IETF. Packet Format +--------+-------+-----------------| | Type | Code | checksum | +--------+-------+-----------------| | Max resp delay | reserved | +----------------+-----------------+ | | | Multicast | | | | Address | | | +----------------------------------+ Types: Query 130 Report 131 Done 132 Code: 0 Max resp delay: in milliseconds (Router alert also present) Suggestion: Reserve these type codes in ICMP spec. Also the ND type codes. Also reference to other docs. IPng Document editor will reissue ICMP draft with type codes. Question about Multicast routing protocols: PIM and MOSPF currently support OSPF. DVMRP will not. Neighbor Discovery over Tunnels / S. Deering -------------------------------------------- Should we run ND over tunnels and p-p links? Suggestion that we need additional specification about how to run ND on point-to-point links. Bi-directional links only. Probably should not run it over uni-directional links. When a pair of routers are at ends of link, ND is also not needed. Routing protocols have needed functionality. In some ways ND is the routing protocol for Host-Host and Host-Router. NUD may be used between routers. Required for other cases. Should we consider ND on or off, or should we allow it's individual components to be used individually? Questions: Should we use ND between hosts and router on bi-directional p-p link? Deering would like this to be the case. Parts can be turned off as appropriate. Issue may be mostly focused on address resolution. Deering wants resolution of should we do this so, if so, we can write a document that defines operation. Discussion. Define p-p link as one that there can only be two nodes. Given that property, we can leave out specific ND components. M. Wasserman will outline the issues on the mailing list. IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta --------------------------------------------------- Define - Tunnel minimum, maximum, and default MTU - Frame format for IPv6 over IPv6 and IPv4 tunnels - Interface ID for IPv6 tunnel interfaces - IPv6 link-local addresses for tunnel virtual links - Source/Target Link-Layer address option used in ND or IND over IPv6 and IPv4 tunnels. MTU - default tunnel MTU = ( physical underlying IPv6 interface MTU - tunnel headers size) o For Ethernet 1500-20=1480 - 1280 <= tunnel MTU < default tunnel MTU Tunnel Packet Format - IPv6 tunnel packets are encapsulated as: o IPv6 packets o IPv4 packets Interface ID (token) - The IPv6 tunnel pseudo-interface ID (token) o Unique on the virtual link represented by the tunnel - Method 1 o Use underlying physical interface identifier (e.g., EUI-64, EUI-48, etc.) - Method 2 o Based on random number - local, individual 7 6 5 4 3 2 1 0 (bit order +-----+-----+-----+-----+-----+-----+-----+-----+ 0 | Random Number | MBZ | + +-----+-----+ . . . . . . 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+ o Advantage: survives underlying physical interface NIC changes Comment: This might conflict with vendor assignments. If using this, why transform the interface ID. Could use it without change. Question are both end of links required to be on the same subnet. Answer: No we can have unnumbered links. Not prohibited either. Could also use link-local addresses. Comment: It is very important to keep the token the same when rebooting, rebooting, etc. Author will revise draft and republish. Site prefixes in Neighbor Discovery / E. Nordmark ----------------------------------------- Goals - Limit effect of renumbering in a site by ensuring that traffic local to the site use site local addresses. - Do this without requiring a two-faced DNS. Proposal - Advertise the global prefixes (w/ lifetimes) for the site in Neighbor Discovery messages. - The hosts use this information to maintain a list of the current site prefixes. - The host resolver (gethostbyname function) checks against list of prefixes after resolving the name. - When one of the addresses retrieved from the DNS matches one of the site prefixes (i.e., the first N bits match) then replace with the corresponding site local address. Open issue 1 - Mobile nodes moving off site and have been using site local addresses. - Clarify in architecture: mobile is part of home site, not part of visited site - Site local packets (src or dst) over bi-directional tunnel to mobile KRE: The problem is that we have not defined what is a site. Need to do this. Proposal: Node or link are never in more than one site. Some node/links are not in any site (used to connect sites). Question about if tunnel is bi-directional or uni-directional. Issue is more complex. Disagreement about KRE's definition of site. Alternative definition is that node can be in multiple sites and link can only be in one. Agreement on criteria that sites can never overlap. Open Issue 2 - Node multihomed to multiple sites - Disable algorithm (in draft), or - Christian H. proposal with random site ID in site local address +-------+-------------------+--------+--------------+ | xxxx | 0........0 | Subnet | Interface id | +-------+-------------------+--------+--------------+ put random # here Comment: Same issue as what we decided with link local addresses. Should not need random number. Just need to keep track of scope of these addresses. Additional discussion..... Open Issue 3 - Site local address in DNS - Flexibility - not all nodes in the site must have a site local address - Limits denial of service attack? - No need for two-faced DNS - Site local address is ignored unless in same site - If RRset contains global address matching a site prefix => Use site local RRset Open Issue 4 - Include or remove global addresses? - Site local should be tried first by application - Returning globals => accidentally using global when site local would have worked - No globals => site locals better work! - Admin applications need to see content of DNS Open Issue 5 - Encoding the exact semantics of advertisement: - Note: Separate prefix option advertisement to assign site local address - Should the site prefix be a separate prefix option (i.e., remove Site PLength? Open Issue 6 - Security considerations: - Any node on the link can cause a denial of service attack by advertising a bogus site prefix - This is not any worse than other on-link DoS attacks. Open Issue 7 - Assumes common SLA (subnet number): - 16 bits in site local - Must match in all global and the site local addressing plans - Relax if site locals in DNS Open Issue 8 - Are the benefits worth the added complexity? Discussion will be continued on mailing list. Router Alert / R. Hinden ------------------------ This draft has been returned from the IESG for several changes. C. Partridge will be submitting a new draft in the next few weeks that should resolve the problems. Comment: IPsec supposedly is requesting an additional code point in the router alert option for multicast key. VRRP for IPv6 / R. Hinden ------------------------- Virtual Router Redundancy Protocol (VRRP) developed initially for IPv4. VRRP Overview - VRRP allows one router to back up another router transparently to hosts o Goal is to keep TCP connections from breaking - Current Host OS's don't handle switching to a second router well or at all - Mechanisms such as Router Discover were not designed for this function and are not widely implemented. IETF - VRRP being developed in IETF o VRRP Working Group o Current draft is: - Provides functions similar to Proprietary Protocols o Cisco HSRP o Digital IP Standby Protocol - Work Includes o VRRP Protocol o VRRP MIB o VRRP for IPv6 [Figure showing basic operation of VRRP] VRRP Mechanisms - Virtual MAC Addresses o Mapping between Router IP Address and MAC Address o Host Default Gateway stays the same - VRRP Protocol and State Machine o Determines which router is Master o Sends Periodic Advertisements + Default is 1 second o Backup takes over if three Advertisements not heard Additional Detail - Priority Allows control over which router backs up another - Supports Loadsharing by setting Default Gateway in Hosts to different VRRP Routers - More sophisticated control can be done by dynamically changing priority based on status of other interfaces - Runs over Shared Media LAN's - Authentication choices include MD5 Status - Working Group Meet at this week's IETF - Group agreed to move to Proposed Standard with small changes - Work starting on o VRRP MIB o VRRP for IPv6 Issue for IPv6 is to either add VRRP features to neighbor discovery or to define a profile for current ND mechanisms that meet VRRP goals. Comments were mostly to just use ND (with some tuning if necessary). IPv6 Addresses in URL's / B. Carpenter -------------------------------------- Design team meet in the bar a few nights ago. Need numeric address in URL's for emergency operations (or robotic apps). Colons break URL parsers "hostname" syntax Proposals: http://--ABCD-EF12-192.100.1.2.ipv6:80/ http://[ABCD:EF12:192.100.1.2]:80/ Issue: Should IPng w.g. reopen the "colon" notation? Heated discussion. Most comments that this is stupid, we should not reopen IPv6 text notation. Long discussion. Issue seems to be that many parsers that take URL's are very limited. No one was in favor of changing current text representation. Extremely strong consensus! It was noted that the issue is probably only relevant for complete web browsers (e.g., Netscape, Microsoft, etc.), not all other applications that use URL's. If the complete web browsers can be changed it is very likely to be sufficient. Recommend that the primary preferred syntax for IPv6 addresses in URL's be: http://[ABCD.EF01::2345:6789]:80/ The IPv6 address should be enclosed in brackets. URL parsers that can not support this notation can either support the proposed alternative syntax: http://--ABCD-EF12-192.100.1.2.ipv6:80/ or not allow IPv6 addresses to be entered directly. Non-Corrosive Multi-Homing Idea / Matt Crawford ----------------------------------------------- Goal - Allow a multihomed site to use other links for existing sessions which have addresses derived from the provider on the failed link. - Do not inject long prefixes into global routing. - Do not tell ISP's how to run their busine$$es. Three Magic Words - Multicast - Security - Mobility [three diagrams showing basic topology of site connected to two providers and how mechanism works when a link to one of the providers fails.] Basic idea is for border router to send a renumbering message when link fails. New flag for prefix info. option - The "B" (for broken) flag o Valid/preferred lifetimes unchanged - Host action: o Do not select this prefix for new communication if there's a non-broken prefix available o For existing communication, use IPv6 mobility as if host has moved to A::S::HL Wants discussion on mailing list. ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 29 10:41:47 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA09649 for ipng-dist; Mon, 29 Dec 1997 10:36:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA09642 for ; Mon, 29 Dec 1997 10:36:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA22020 for ; Mon, 29 Dec 1997 10:36:41 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA29972 for ; Mon, 29 Dec 1997 10:37:07 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA10207; Mon, 29 Dec 1997 10:36:38 -0800 Message-Id: <3.0.3.32.19971229104019.008a8d60@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 29 Dec 1997 10:40:19 -0800 To: burgan@home.net From: Bob Hinden Subject: (IPng 5080) Interface Identifier Global Flag Cc: Thomas Narten , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, >> >The other news of importance is that the v6 over fddi and ethernet >> >docs weren't moved forward due to the universal/local bit flipping >> >issue that Matt raised. The IESG wants the WG to reconsider the issue >> >again and decide whether to stay with its original decision or do >> >something different. This is the only issue raised on these documents, >> >so once the WG makes a decision, approval should be straightforward. The working group discussed the interface identifier global flag at the Washington, DC IETF and concluded to keep the bits as they are currently defined. An excerpt from the minutes is attached. Regards, Bob Interface Identifier Global Flag / S. Deering --------------------------------------------- [Figure showing how EUI-64 based interface identifiers are created from IEEE 48bit MAC addresses] Current algorithm for doing this fabrication inverts the state of the "Global/Local" bit. Becomes "1" if global, "0" if local. Reason for inversion is to make it easier on links that do not have hardware tokens, such as dialup links, tunnels, etc.to set this bit correctly. Comment on mailing list that this is complex and the bit should not be inverted. IESG sent it back to the working group to review earlier decision. Matt Crawford: Arguments in favor of inverting the bit. Makes it easier to recognize vendor type code when looking at wire. We are corrupting the use of EUI64 format. Would be better to not change bit. KRE: Matt's comment is correct, but he came to the wrong conclusion. Packet trace will still have real MAC addresses at front of frame. Thinks a better way to do this would be to XOR with different value to make it look very different. M. Wasserman: Thinks we should have a fixed prefix for manually assigned interface identifiers. Brian C: Thinks current approach will make things harder for maintenance technicians. C. Huitema: Thinks the problem is reversed. Real problem is that managers will assign bit's incorrectly. Computers will not have a problem. KRE: Also disagrees with Brian C. Thinks we should leave the way it is. A. Durand: In the ten implementations he has seen nine out of ten do it correctly, and would like to keep it as it is. Deering took poll. 1) Keep it as is, 2) eliminate inversion, 3) KRE proposal Rough consensus to keep things the way they are now. Document editor will report w.g. consensus to area director. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 29 13:53:50 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA10004 for ipng-dist; Mon, 29 Dec 1997 13:50:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA09997 for ; Mon, 29 Dec 1997 13:49:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA08616 for ; Mon, 29 Dec 1997 13:49:49 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA09137 for ; Mon, 29 Dec 1997 13:50:14 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id QAA02193; Mon, 29 Dec 1997 16:49:48 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id QAA15839; Mon, 29 Dec 1997 16:49:47 -0500 (EST) Date: Mon, 29 Dec 1997 16:49:47 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971229164947.ZM15837@seawind.bellcore.com> In-Reply-To: Bob Hinden "(IPng 5079) Draft December IPng W.G. Minutes" (Dec 24, 12:47pm) References: <3.0.3.32.19971224124709.0083d830@mailhost.ipsilon.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 5081) Re: December minutes / Site addresses MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reading the minutes of the discussion on "site local" addresses, I note that the idea of inserting a unique site number was dismissed "because we already went through this discussion for link local addresses." Well, there is a lot of differences between links and sites. An interface, by definition, is connected to exactly one link. We could perhaps rule that a link always belong to exactly one site, but we can definitely not assume that all the links to which a station is interfaced belong to the same site. And even the first assumption is dubious -- think of a ring that connects several ASes... Inserting a unique identifier in the site local addresses would: * allow a mobile host to read mail from a site local "home address" and print it to the site local address of a "visited printer." * allow stations to read site local addresses in the DNS and immediately discard those that do not belong to the local site. * allow managers of merging network to renumber them without creating a panic mode. * allow routers beyond the immediate border to recognize and prune foreign site local packets. Is it worth the cost ? I think so. Obviously, many differ. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 29 15:18:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA10146 for ipng-dist; Mon, 29 Dec 1997 15:14:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA10139 for ; Mon, 29 Dec 1997 15:14:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA15221 for ; Mon, 29 Dec 1997 15:14:35 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA07731 for ; Mon, 29 Dec 1997 15:15:00 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id AAA05573; Tue, 30 Dec 1997 00:14:33 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id AAA19814; Tue, 30 Dec 1997 00:14:31 +0100 (MET) Message-Id: <199712292314.AAA19814@givry.inria.fr> From: Francis Dupont To: huitema@bellcore.com (Christian Huitema) cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 5082) Re: December minutes / Site addresses In-reply-to: Your message of Mon, 29 Dec 1997 16:49:47 EST. <971229164947.ZM15837@seawind.bellcore.com> Date: Tue, 30 Dec 1997 00:14:30 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Inserting a unique identifier in the site local addresses would: ... => more important, it makes the code for a multi-sited router easy to write. Without it a multi-sited router can be in an arbitrary complex situation, for instance two routers can be connected to two (same) sites and have a link between them (the link is of course shared between the two sites :-)... The other alternative is to use site local addresses only for isolated sites (I believe it is the solution but there is no agreement about this point). Is it worth the cost ? I think so. Obviously, many differ. => I agree, the real difference is the routing stuff (link local is only one hop => no routing consideration). Even multi-linked nodes are no so simple (I'd still like to see the kernel code unconnected UDP servers (kernel code => you can't modify the server code in order to use in6_pktinfo) for multi-linked node in *any* cases, someone said he knew how to do it but I still wait). In conclusion if we want to use site local addresses for not-isolated site I think we can't avoid the unique identifier (with a site scope, an issue with link IDs was there had a node scope). Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 29 15:56:30 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA10232 for ipng-dist; Mon, 29 Dec 1997 15:51:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA10221 for ; Mon, 29 Dec 1997 15:51:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA17938 for ; Mon, 29 Dec 1997 15:50:59 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA17628 for ; Mon, 29 Dec 1997 15:51:26 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA14187; Mon, 29 Dec 1997 17:50:59 -0600 Message-Id: <199712292350.RAA14187@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com Cc: huitema@bellcore.com (Christian Huitema) From: "Matt Crawford" Subject: (IPng 5083) Re: December minutes / Site addresses In-reply-to: Your message of Mon, 29 Dec 1997 16:49:47 EST. <971229164947.ZM15837@seawind.bellcore.com> Date: Mon, 29 Dec 1997 17:50:59 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is it worth the cost ? I think so. Obviously, many differ. You've listed some real values of globally-unique site-local addresses, but you have not addressed the cost. Here are some of the requirements ... * The site identifiers must never change -- otherwise most of the value of site-local addresses is destroyed. * The site identifiers should be unique. Recovery in the case of duplication will be essentially impossible. ("Recovery" might consist of an injunction for nodes from one site to never visit the site with the duplicate id, plus some jiggery-pokery to hide the site-local DNS entries with the duplicated prefix.) * Every node in a site must learn the site id automatically -- even in a serverless environment. + We must admit the possibility that the "advanced dentist's office" has communications which must not be distrupted when the office obtains its first global network connection. + But we can assume that a routerless office will be using link-local addresses, not site-local, for internal communication. The fact that at most 38 bits are available for a site id imposes a few constraints. Use of some MAC address or EUI64 as a site id is out, and using random bit-strings would make duplicates likely in O(1/2 million) sites. I suggest a more deliberate approach to the question. + Define "site." + Decide whether site boundaries may cut links, nodes, or both. + Study the details of a multi-sited router. + Decide whether multi-sited hosts need to be allowed. o If yes, would it suffice to support just 2-sited hosts, with one site on a physical link and one on a tunnel? The decision about identifying sites by a field in site-local addresses should fall out of this process somewhere. 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 Tue Dec 30 06:59:51 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA10844 for ipng-dist; Tue, 30 Dec 1997 06:56:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA10837 for ; Tue, 30 Dec 1997 06:56:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA07872 for ; Tue, 30 Dec 1997 06:56:12 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA19306 for ; Tue, 30 Dec 1997 06:56:39 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id JAA21372; Tue, 30 Dec 1997 09:56:03 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id JAA16433; Tue, 30 Dec 1997 09:56:02 -0500 (EST) Date: Tue, 30 Dec 1997 09:56:02 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971230095602.ZM16431@seawind.bellcore.com> In-Reply-To: "Matt Crawford" "(IPng 5083) Re: December minutes / Site addresses" (Dec 29, 5:50pm) References: <199712292350.RAA14187@gungnir.fnal.gov> X-Mailer: Z-Mail (5.0.0 30July97) To: "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: (IPng 5084) Re: December minutes / Site addresses Cc: huitema@bellcore.com (Christian Huitema) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Dec 29, 5:50pm, Matt Crawford wrote: > * The site identifiers must never change -- otherwise most of the > value of site-local addresses is destroyed. Never say never... Saying that would mean that the shape of sites, whatever that is, should never change. Obviously, if two sites merge, at least one of them will have to be renumbered. Unless we allow hosts to belong to very many sites. > * The site identifiers should be unique. Recovery in the case of > duplication will be essentially impossible. ("Recovery" might > consist of an injunction for nodes from one site to never visit the > site with the duplicate id, plus some jiggery-pokery to hide the > site-local DNS entries with the duplicated prefix.) Yes, that is probably a real requirement. > * Every node in a site must learn the site id automatically -- > even in a serverless environment. Serverless? I don't think so. Serverless => no router. No router => only one link => use link local addresses. (Also, don't expect to use the DNS). > The fact that at most 38 bits are available for a site id > imposes a few constraints. Use of some MAC address or EUI64 as > a site id is out, and using random bit-strings would make > duplicates likely in O(1/2 million) sites. You are basically right. I would suggest reserving a value 0 for sites that are truly unconnected, and using router renumbering + address configuration to replace "site=0" by "site=my-very-own" as soon as I get a number. Apart from that, we need to set up a distribution system that doles out unique numbers. We can imagine using web + CGI + a stupid database -- these numbers have no structure... > > I suggest a more deliberate approach to the question. > > + Define "site." I think we should be cautiously generic, as in "a connected set of links." From an operational point of view, the definition is "whatever is behind a firewall." From a routing point of view, a /48... > + Decide whether site boundaries may cut links, nodes, or both. He who draws borders lives to regret it... Remember how EGP fell prey to backdoor links and other alternative connections. Then ask how may extranets a host will belong to in 2005. If a site is strictly a routing conctruct (as in /48, or scope of renumbering), then nodes can definitely belong to very many sites, and links may. > + Study the details of a multi-sited router. Francis started doing that. > + Decide whether multi-sited hosts need to be allowed. Who are we to disallow them ? What forbids a host to set up as many tunnels as is requested by applications and management ? Multi-sited hosts are, or will be, a fact of life. The choice is between a correct architecture today or dirty hacks tomorrow. > o If yes, would it suffice to support just 2-sited hosts, > with one site on a physical link and one on a tunnel? You were kidding, right ? You know how creative the young guys are, don't you ? > The decision about identifying sites by a field in site-local > addresses should fall out of this process somewhere. Yes. Maybe we should summarize all this in a "use of site local addresses document. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 30 09:58:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA11266 for ipng-dist; Tue, 30 Dec 1997 09:52:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA11259 for ; Tue, 30 Dec 1997 09:52:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA01626 for ; Tue, 30 Dec 1997 09:52:22 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA18723 for ; Tue, 30 Dec 1997 09:52:47 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA09839; Tue, 30 Dec 1997 09:51:22 -0800 Message-Id: <3.0.3.32.19971230095459.0097d580@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 30 Dec 1997 09:54:59 -0800 To: minutes@ietf.org From: Bob Hinden Subject: (IPng 5085) IPng W.G. Minutes Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Meeting Washington, DC IETF December 8-12, 1997 ---------------------- Chaired by Steve Deering (Cisco) and Robert Hinden (Ipsilon). Minutes taken and prepared by Robert Hinden. Agenda ------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Status of moving base specs to Draft Standard / R. Hinden (5 min) TLA/NLA Assignment Rules Status / R. Hinden (15 min) Resolve Neighbor Discovery and Addr Conf issues / T. Narten (20 min) Interface Identifier Global Flag / S. Deering (10 min) Mobile IPv6 Status / D. Johnson (10 min) THURSDAY, December 11, 1997, 0900-1130, (Empire Room) IPv6/NBMA Status / G. Armitage (10 min) IPv6 over PVC ATM / K. Yamamoto (10 min) Router Renumbering / M. Crawford (20 min) DNS mappings / C. Huitema (20 min) IPv6 Name Lookups Through ICMP / M. Crawford (15 min) Reverse Address lookup in DNS for IPng / O. Gudmundsson (15 min) Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound (10 min) Traceroute hop-by-hop option / A. Durand (10 min) ECN Bit Assignment / S. Floyd (20 min) FRIDAY, December 12, 1997, 0900-1130, (Empire Room) IGMP for IPv6 / S. Deering (15 min) Neighbor Discovery over Tunnels / S. Deering (20 min) IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta (10 min) Site prefixes in Neighbor Discovery / E. Nordmark (20 min) Router Alert / C. Partridge (10 min) VRRP for IPv6 / R. Hinden (15 min) DHCP vs. M & O Bits / Narten (10 min) IPv6 Addresses in URL's / Deering, Carpenter (10 min) Non-Corrosive Multi-Homing Idea / Matt Crawford --------------------------------------------------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) --------------------------------------------------- Introduction / S. Deering Review Agenda / S. Deering -------------------------- Steve Deering introduced the meeting and reviewed the agenda. UNH Testing Report / Bill Lenharth ----------------------------------- Interoperability test session last week at UNH. First purely interoperability test session at UNH. First time to put routers into the test network. There were 10 hosts and 6 routers tested. 90% of the host implementations worked well as did 70% of router implementations. After work on site most of the problems discovered were "addressed". Both BGP4+ and RIPng routing protocols, including route redistribution, worked. Three long days of testing. Next test period is with Sun Connectathon in March. Both conformance and routing testing will be done. No IPSEC testing was done. Document Status / R. Hinden --------------------------- IETF Last Call completed for Proposed Standard - Generic Packet Tunneling in IPv6 Specification / Dec 96 (IESG Comments received 11/25/97, waiting for new ID) AD reported that this should resolved soon. - Transmission of IPv6 Packets over Ethernet Networks / Nov 97 (IESG: Resolve Global/Local bit setting issue) - Transmission of IPv6 Packets over FDDI Networks / Nov 97 (G/L) - IP Version 6 Addressing Architecture / Nov 97 (G/L) - An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments from Registries) IETF Last Call completed for Experimental - IPv6 Testing Address Allocation / Nov 97 IETF Last Call completed for Informational - IPv6 Multicast Address Assignments / Nov 97 Submitted to IESG for Proposed Standard - IPv6 Router Alert Option (IESG returned, need new ID) - MIB for IPv6: ICMPv6 Group / Jun 97 - MIB for IPv6: TCP / Jun 97 - MIB for IPv6: Textual Conventions & General Group / Jun 97 - MIB for IPv6: UDP / Jun 97 - Transmission of IPv6 Packets over Token Ring Networks / Nov 97 (G/L) - IPv6 over PPP / Nov 97 (G/L) - IP Header Compression / Nov 97 Submitted to IESG for Informational - Advanced Sockets API for IPv6 / Jul 97 Submitted to IESG for BCP - TLA and NLA Assignment Rules / Nov 97 Status of moving base specs to Draft Standard / R. Hinden --------------------------------------------------------- BASE SPECS TO DRAFT - IPv6 Specification o MTU Issue Resolved (1280 octets) o New Draft Issued o Starting to Collect Implementation Info - ICMP o New Draft issued w/out IGMP messages o Starting to Collect Implementation Info - Path MTU Discovery o Starting to Collect Implementation Info Will be sending questionnaire about implementation info to the ipngwg list in next day or two. [Editors Note: Bill Lenharth of UNH, volunteered after to the session to help with this based on the testing being done at UNH. He will be contacting implementers.] TLA/NLA Assignment Rules Status / R. Hinden ------------------------------------------- TLA/NLA ASSIGNMENT RULES STATUS - Updated Draft based on IANA Comments o Added Established Provider Criteria, Registration Fee, and Auction for New Organizations - Submitted to IESG for BCP 11/11/97 - Considerable Controversy!!! - Waiting for IESG Direction on how to proceed Met with registry folks this morning about their concerns about TLA doc. Progress made, but nothing concrete to report yet. Will report again at Friday session. Resolve Neighbor Discovery and Addr Conf issues / T. Narten ----------------------------------------------------------- Talk about remaining issues with ND and Addr conf doc. Zero Lifetime denial of service attack - Bad guy sends out a single bogus Router Advertisement (RA) - RA contain prefix info option with Valid lifetime of zero - Host interprets RA to mean address is now invalid, stop using it immediately. - Upper layer protocols may stop working (e.g., all TCP connections break) This is not a hard requirement in spec but some implementations may do this] Not like other Denial of Service attacks - No comparable "hit and run" packet in IPv4 (or IPv6) as dangerous - Once upper layer have aborted open connections, no recovery is possible. - Problem must be fixed in IPv6 is to be no more vulnerable than IPv4 Proposal 1 - If received with Valid Lifetime > 2 hours or greater than lifetime in cache, process as before - Attempts to reduce the valid lifetime to value less than 2 hours and less than lifetime of cached entry require special processing. [pseudo code for algorithm] This proposal limits removing prefix to 2 hours units. Can't remove one in shorter time. Proposal 2 [from Erik Nordmark] - Avoid defining special mechanism to handle this one specific denial of service attack. - Rely on robustness of transport protocol to limit impact of zero lifetime denial of service attack. - Already have many denial of service attacks (both IPv4 and IPv6) that cause packets to be blackholed. - Transports (e.g., TCP) are robust in such cases by continuing to retransmit (e.g., not allowing ICMP destination unreachable to terminate connection) - IP layer continues processing zero lifetime as specified inRFC1971, but transport layer is not required to terminate connections using addresses that become invalid. - IP layer on host would blackhole packets form invalid source address (i.e., no violation of existing spec). Comments that this proposal, is just focused on TCP. Problem is worse, it affects all other transports, SNMP, etc. Everyone that the machine uses addresses. Attack is much worse than just TCP. Suggestion that we should do both. They are not really in conflict. Could also use authenticated router advertisements. Comment that this is not normal behavior for TCP. Should kill all state with TCP and other transports. R. Hinden suggested that lifetimes less than two hours should be accepted only if packet was authenticated. This allows for finer grained control (e.g., less that two hours) in environments that need it and two hour everywhere else. Suggestion was made for Proposal 1 unless packet was authenticated. If authenticated, then accept lifetime less than 2 hours. Strong consensus to adopt this proposal. DHCP-specific bits in Router Advertisement - "M" bit indicates DHCP should be used to obtain addressing information. - "O" bit indicates DHCP should be used to obtain other (i.e., non-addressing) information. Proposal - Do away with "O" bit - Single bit would say "do" or "don't" use DHCP Rational - Separate bits complicates protocol - Having "O" bit raises issue of what to do if DHCP server returns DHCP option that "O" bit says shouldn't be obtained - Benefit unclear. Behavior of the two bits can be obtained by having DHCP server decide what information it wants to give out. J. Bound thinks we only need one bit. All that stateless is for is addresses and link parameters. Critical parts of IPv6 is to make renumbering work. Important part of this is dynamic DNS. Thinks that the router should only control the address allocation. Rest of configuration is independent of what router can supply. DHCP w.g. does not have a strong feeling either way. Matt C. suggested that these bits tell the host when it is completely configured. If both bits are zero it is done. Otherwise it needs to go to DHCP to get additional information. It should not come up until it has all information. Narten suggest wait to come to closure on this topic until after discussed by DHCP w.g. IPng will continue this in the Friday session. Default value for valid lifetime in Prefix information options: - RFC1970 says default preferred lifetime is 7 days - RFC 1970 says default valid lifetime is infinity - Value of infinity problematic: o Suppose system administrator decides to timeout prefix o Subsequent Router advertisements advertise small lifetimes, eventually going to zero. o Lifetime of zero must be advertised forever, to be sure nodes that are disconnected from the link receive updated value on reconnection. o Danger that any prefix advertised with infinite Lifetime will be hard to completely purge from network. - Propose setting default value to 30 days o System administrator is free to change this value; 30 days is the default value in the absence of input from system administrator o Having an address without properly functioning router is of limited benefit; if router is functioning properly, it will be sending out proper Prefix Advertisement options. Consensus to adopt this proposal. Summary of Open Issues - Protection from zero life denial of service attacks. - If Proposal 1, is 2 hours the right time? No objections to 2 hours. [Editor's note: Remaining issue to be resolved at Thursday w.g. session before moving this to draft standard] Mobile IPv6 Status / D. Johnson ------------------------------- High-level overview of operation: - Care-of addresses from IPv6 address autoconfiguration - Mobile node sends its own Binding Updates - Used for correspondent nodes and home registration - Nodes cache bindings in a Binding Cache - Correspondents route own packets directly to mobile node Current spec is draft-ietf-mobileip-ipv6-04.txt One implementation done so far (CMU). Other implementations in progress? Editorial Changes: - Added a statement of some non-goals of the protocol in Section 1. - Added definition for home link and home subnet prefix, replacing the old term home subnet. - The new terms foreign link and foreign subnet prefix likewise replace the old term foreign subnet. - Moved the Comparison with Mobile IP for IPv4 section to earlier in the document (now Section 2) - Added specific in Section 4 listing the fields conceptually present in each Binding Cache entry and in each Binding Update List entry. - Added Section 12 on IANA Considerations. - Replaced the description of specification language keywords, MUST, MAY, SHOULD, etc., with the new standard reference to RFC 2119. - Updated the References to point to the most recent version of each cited RFC or Internet-Draft. Binding Update Option Changes: - Increased the Lifetime field from 16 bits to 32 bits, to allow consistency with other lifetime values used in IPv6. - Replaced the Home Link-Local Address Present (L) bit and the Home Link-Local Address field with a new mechanism implemented by the ID Length field: o Home agent becomes home agent for all on-link home addresses with this interface ID o Proxies for mobile node in Neighbor Discovery with this ID o If ID Length is 0, only use single specific home address o Mobile node may send separate Binding Updates for each ID if different - Change sending of Binding Update to a mobile node's previous default router from SHOULD to MAY. - Clarified handling for packets addressed to a mobile node's link-local address or site-local address: o Data packets are not forwarded to the mobile node while away from home. o Home agent returns ICMP Destination Unreachable, Code 3, for any received. o Home agent continues to defend for Neighbor Discovery. o As the use of link-local addresses or site-local addresses evolves over time in IPv6, this disposition of such packets may need to change, however. Binding Update Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|C| Reserved| ID Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | (only present if C bit set) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Acknowledgment Option Changes: - Changed the Option Type value to now ignore rather than returning an ICMP error if not recognized. - Increased the Lifetime field from 16 bits to 32 bits. - Increased the Refresh field from 16 bits to 32 bits. Binding Acknowledgment Option Format: +-+-+-+-+-+-+-+-+ | Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Status | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Request Option Changes: - Changed the Option Type value to now ignore rather than returning an ICMP error if not recognized. - Added a discussion of sending Binding Requests in Section 7.6. - Added a discussion of receiving Binding Requests in Section 9.11. Binding Request Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Address Option Changes: - Added details of how and when Home Address option is added to a packet when sending: o TCP/UDP/etc. generates packet as normal. o In IP (Mobile IP), if the Source Address is not home address, just send packet normally. o Otherwise, insert a Home Address option: + Copy Home Address field from Source Address + Change the Source Address to care-of address + Must be performed before outgoing IPsec processing, if any - Added details for inbound IPsec processing: o Must be performed before any packet modifications for Home Address option processing. Home Address Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Comments, Please: - We need feedback/agreement from IPng Working Group - Please send e-mail comments to Mobile IP mailing list: mobile-ip@SmallWorks.COM - Comments can also be sent to: o Dave Johnson, dbj@cs.cmu.edu o Charlie Perkins, cperkins@eng.sun.com Wants processing of home address option on the receive side to be required by all receivers. Not just the ones that implement Mobile-IPv6. Need Home agents anycast address, and option code for bridging xxx, yyy, zzzz options. IPng chairs will figure out how to do these allocations. Need to reserve a group of interface identifiers to be used as anycast addresses. Chairs promised to resolve issue this week. Interface Identifier Global Flag / S. Deering --------------------------------------------- [Figure showing how EUI-64 based interface identifiers are created from IEEE 48bit MAC addresses] Current algorithm for doing this fabrication inverts the state of the "Global/Local" bit. Becomes "1" if global, "0" if local. Reason for inversion is to make it easier on links that do not have hardware tokens, such as dialup links, tunnels, etc.to set this bit correctly. Comment on mailing list that this is complex and the bit should not be inverted. IESG sent it back to the working group to review earlier decision. Matt Crawford: Arguments in favor of inverting the bit. Makes it easier to recognize vendor type code when looking at wire. We are corrupting the use of EUI64 format. Would be better to not change bit. KRE: Matt's comment is correct, but he came to the wrong conclusion. Packet trace will still have real MAC addresses at front of frame. Thinks a better way to do this would be to XOR with different value to make it look very different. M. Wasserman: Thinks we should have a fixed prefix for manually assigned interface identifiers. Brian C: Thinks current approach will make things harder for maintenance technicians. C. Huitema: Thinks the problem is reversed. Real problem is that managers will assign bit's incorrectly. Computers will not have a problem. KRE: Also disagrees with Brian C. Thinks we should leave the way it is. A. Durand: In the ten implementations he has seen nine out of ten do it correctly, and would like to keep it as it is. S. Deering took poll. 1) Keep it as is, 2) eliminate inversion, 3) KRE proposal Rough consensus to keep things the way they are now. Document editor will report w.g. consensus to area director. [Editor's note: done as of 12/29/97] ------------------------------------------------------------ THURSDAY, December 11, 1997, 0900-1130, (Empire Room) ------------------------------------------------------------ IPv6/NBMA Status / G. Armitage ------------------------------ ION w.g. summary relevant for IPng Since last meeting - In Munich, much confusion - Action items o Generalize the architecture - ATM Split document into two o draft-ietf-ion-ipv6-oo.txt o draft-ietf-ion-ipv6-atm-00.txt - Other IPv6 related drafts o draft-conta-ion-ipv6-fr-00.txt o draft-conta-ion-ipv6-ind-00.txt General Architecture - Assume general NBMA "cloud" o Capable of p-p links, pt-mpt links, may/may not native multicast - MBMA could be ATM, Frame Relay, IPv4, ... - MARS? NHRP? Major New Item / Shortcut suppression - Request in Munich for host controlled shortcut suppression - How to convey this indication in-band? - Original default, discover shortcut whenever a "flow" is detected - Need indication of "flows" that should not have this default action applied - Proposal for broad interpretation of flow label field Interpretation of Flow Label - Flow label == 0 o Apply default IPv6/NBMA flow-detection and short cut discovery - Flow label != 0 o Do not apply IPv6/NBMA flow-detection and shortcut discovery by default - Support whatever other packet forwarding, queuing, and/or scheduling rules may have been negotiated with each router along the path - Perform best effort in absence of negotiated service - No additional semantic restrictions Discussion how this would interact with other usage of flow label. C. Huitema pointed out that it is backwards. Flowlabel indicates that it is a long lived flow. That is the case when extra overhead to shortcut flow is worthwhile. No flow label probably indicates that flow will be short lived. Long discussion about merits/cons of this proposal. draft-ietf-ion-ipv6-atm-00.txt - Media specific companion document to draft-ion-ipv6-00.txt PVC rules - Standard LLC/SNAP encaps, with IPv6 PID (null encapsulation allowed/negotiable) Document currently in ION working group last call. If doesn't go through quickly, ATM Point-to-Point link text will be moved to a separate document. Status of "IPv6 Transmission over Frame Relay" and "Extensions to IPv6 Neighbor Discovery for Inverse Discovery" was also reviewed. They will become ION w.g. drafts and pursued there. Router Renumbering / M. Crawford -------------------------------- RR Goals - One step changes to the set of prefixes in use site-wide o Including ND timers and flags - Spectrum of finer-grained operations, down to a single interface of a single router - Reliability - Security RR Basics - Carried in ICMPv6, type = TBD - two codes: Command & Result - Built-in authentication and & replay protection, or use IPSEC - "Dry-run" mode to simulate a Command - "site-conscious" can apply command to subset of multi-sited router RR Command Structure [Using ABNF of RFC2234] - CmdPkt = Header *PCO AuthData - PCO = Op MatchPrefix *UsePrefixPart - UsePrefixPart = cut & paste info to combine old & new bits Mask & Flags to set ND PIO flags ND RA timers New Prefix bits RR Result Structure - ResPkt = Header *MatchReport AuthData - MatchReport identifies a match by Which PCO in the corresponding Command packet Interface Prefix - The new prefixes, if any, can be inferred Lacking in current draft - Examples! - Asymmetric keys?? - Is message processing section sufficiently rigorous - Other error contradictions? Comments: Doesn't deal with result implosion. Author agrees, needs to be added. Is there any way to have routers tell what prefixes you have now without changing anything. Answer: could ask for zero prefix match and look at replies. Also use SNMP. Deering suggested to use similar mechanisms that IGMP uses to space out replies to multicast query. Would like to see ICMP code assigned, then folks build implementations. Need to resolve open issues. DNS mappings / C. Huitema ------------------------- Revising the AAAA record New AAAA Record? - One proposal: draft...-aaaa-00.txt - Main feature: indirection AAAA = prefix length + suffix + name of prefix - Three questions: o Do we need this? o Shall we use the same record number? o Shall we maintain upward compatibility? Needs, Let's take an example +--------+ +--------+ | | | | | TLA-1 | +--+ TLA-2 | | | / | | +---+----+ / +----+---+ | / | | / | +---+----+ / +----+---+ | +-+ | | | ISP-A | | ISP-B | | | | | +----+---+ +---+----+ \ / +--+--------------+--+ | Site | +--------------------+ | Host - We will Consider o Change provider, o Network multi-homing o Provider renumbering, o Provider multihoming What we have today will not scale - For each host, 3 records TLA1/A/SiteA/LinkID TLA2/A/SiteA/LinkID TLA2/B/SiteA/LinkID - Change provider Change all records - Network multihoming Duplicate record Provider renumbering Phone call to site - Provider multihoming Duplicate prefixes Local copies Using the new format solves the problem - For each host, one record Link/ID + net.site.com - For the site NLA-A + net.ips-a.net - Change provider update net.site.com/AAAA - Network multihoming Two AAAA records for net.site.com - Provider renumbering - Provider multihoming Update provider AAAA record Question 2 - Resource Record Number - Using new RR type o Allows parallel deployment, o But resolvers will never look for two records - Use same RR type (AAAA) o Will break old software o Forces transition to new structure Question 3 - Format compatibility +---+--------+-------------+ | L | Suffix | Domain Name | +---+--------+-------------+ +-----------------+---+-------------+ | 128 bit address | L | Domain Name | +-----------------+---+-------------+ +-----------------+---+-------------+ | 128 bit address | 0 | ...... | +-----------------+---+-------------+ - If compatible, two phase deployment - Longer records per host (128 bits v.s. 80) - Sill wins over current AAAA record (multihoming) A decision on AAAA record? - Shall we o Leave RFC1886 alone, or o Modify & recycle to Proposed Standard? - If we modify: o Shall we keep the AAAA record? - If we modify the AAA record Shall we adopt the new format (draft) ? or shall we maintain compatibility ? Question about impact on gethostbyname. Would not change gethostbyname interface in host. Could this be hidden from hosts? Answer: Doesn't work, caching problems, some parts short lived, some long lived. Won't work. Authors conclusion is that we want to modify RFC1886. Recycle at PS. How does this relate to dynamic updates? Group wants to adopt this proposal. Then do a working group last call. This will replace RFC1886 IPv6 Name Lookups Through ICMP / M. Crawford -------------------------------------------- Who-Are-You? ------------ Format +-----------+-----------+-----------+-----------+ | Type | Code | Checksum | +-----------+-----------+-----------+-----------+ | ID | unused | +-----------------------+-----------------------+ | | + Nonce + | | +-----------------------------------------------+ | Time-to-Live | +-----------+-----------------------------------+ | NameLen | | +-----------+ + | | + FQDN.... + | | +-----------------------------------------------+ Review of Motivation - IN-ADDR.ARPA poorly maintained, will IPv6.INT be better? - Maintenance of delegations will be more difficult in the expected frequent renumbering environment of The Future. - For access control, or even logging, IP6.INT provides nothing but a hint anyway. Features - PLUS: Routing system takes the place of IP6.INT delegations o Always current - PLUS: A meaningful TTL is usually available from Auto config or DHCP - MINUS: Target must be up and reachable to do a lookup o But is it meaningful to say a certain FQDN is associated with an address, when it isn't up? Status of -01 - Query & Response processing: done - Rules for TTL field: done - Added terminology section; guidelines & discussion; security considerations, IANA considerations. - Open issues: o Possible change to DNS client view o Negative caching - Authentication: new issue DNS Delegation and Renumbering ------------------------------ Two General Modifications to DNS Problems - aaaa-00 DBIT records o Rely on wildcard records which produce intermediate data of no later use - dns-reverse-lookup-00 DBIT records o Require lower zones to be renamed on renumbering * Even DynDNS can't pull off that trick New Proposal - Previous proposal involved only new RR types and new resolver/additional section processing rules - I propose two extension to DNS which have uses unrelated to IPv6 Non-Terminal CNAMEs - ... or whatever you want to call them - Translate a suffix of the queried domain. - Query to be repeated with same initial part of translated suffix - Examples 225.131.in-addr.arpa ZNAME in-addr.final.gov. foo.com ZNAME foo-division.bar.com Counted Bit-Strings - Length-of-Label counts bits, not octets. o Pad data to octet, of course - To be considered: as a sequence of 1-bit labels (at an almost 16x space saving) - Consider it a form of compression +------+------------------+------------------------+ | 01xy | bit count | bit string | +------+------------------+------------------------+ What they can do for IPv6 - Simplify and shrink synthesized AAAA records - Enable reverse zones which are nearly hands-free maintainable across "renumbering events." o Non-terminal ZNAME > delegation o Counted bit strings > N x (single purpose RR) Discussion. Conclusions: Make ICMP approach experimental. With multiple names? With warnings for scope? Keep ICMP for link-local. Could also add local name to address lookups as well for dentist office operation. Reverse Address lookup in DNS for IPng / O. Gudmundsson ------------------------------------------------------- IPng reverse DNS address lookup - Storing all reverse records under name like 0102030405060708090a0b0c0d0e0f10 o Is impossible to maintain o Is impossible to secure - Addresses consist of fields that reflect the delegation authorities, reverse lookup should maintain this information. - It is impossible to know the size of the next delegation unless it is fixed or it is explicitly stated. DBIT (delegated BITs) record - RBATA contains last bit delegated, DNS name of the authority assignment has been delegated to - Name on DBIT record encodes prior delegations o First byte is length of bit field o Subsequent bytes is the bit field o Names are stored as binary values - Examples: (in hex) o 08aa.ip6.ing IN DBIT 20 ripe.net - Last bit delegated == 128 delegates all remaining bits and corresponding DBIT record is expected in the domain delegated to - Last bit delegated == 0 is a EID/host DBIT record DBIT Example - Query for address aa2f:34:1::3fff:1234 - Server needs to query for the following DBIT records o IP6.INT DBIT 8 iana.org. o 08aa.IP6.INT DBIT 20 ripe.org. o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example. o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example - 2000010000.0c0034.0c02f0.08aa.IP6.INT. DBIT 128 thorshofn.ismennt.is.example. - 40000000003fff1234.thorshofn.ismennt.is.example. DBIT 0 sia.thorshofn.ismennt.is.example Example 1: Query for address - Ask server ipv6.int for DBIT record ofip6.int o IN.INT DBIT 8 iana.org o + NS records for iana.org + glue - Now ask iana.org for 08aa.IP6.INT DBIT record o 08aa.IP6.INT DBIT 20 ripe.org o + NS records for rip.net + glue - Now ask one of the ripe.net servers for 0c02f0.08aa.IP6.INT DBIT o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example o 20000020000.0c0034.0c02f0.08aa.IP6.INT DBIT 128 thorshofn.ismennt.is.example DBIT Example (2) - At this point all remaining bits are delegated now asks server thorshofn.ismennt.is.example. for 40000000003fff1234.thorshofn.isment.is.example o 40000000003fff1234.thorshofn.isment.is.example DBIT 0 sia.thorshofn.ismennt.is.example. for - Now server has all the DBIT records in and can generate an answer that looks like: o 80aa2f003400010000000000003fff1234.IP6.INT DBIT 0 sia.thorshofn.ismennt.is.example. - The last answer is not signed but the server can return to the resolve all DBIT records used to allow signature verification. DNS Impact of DBIT records - DBIT ignorant servers and resolvers will ask for 80aa2f003400010000000000003fff1234.IP6.INT - DBIT aware server needs to break address requested into the different fields o Servers SHOULD be able to longest prefix match on DBIT records in cache o Servers need to issue multiple queries to generate correct answers o Servers need to be able to merge multiple DBIT records into one answer. - DBIT preprocessing is similar to KEY chain verification in DNSSEC. Advantages of DBIT records - Allows delegations to take place on any bit boundary - Explicitly state the delegations and size of delegations o Allows full verification of the bindings - Fits well with caching name servers - End sites do not have to resign any DBIT records when renumbering Discussion. Contrasted with other proposals. CH: Suggests leaving 1886 alone (existing practice), wait until the newer stuff is ready to bring forward when we have all of the tools. Suspect that 1886 and new ZNAME will be OK to pursue. Chairs will discuss how to move these drafts forward and report back to the working group. J. Bound reports that this will slip deployment by 6 months. Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound -------------------------------------------------------- RFC1233 Update - flags now - Freehostent MUST always be called! - Flags Default (continues ....) 7. Agreement on change by hostbyaddr() 8. Suggest we use AI.Default as a system default. Also suggested to author off-line -> xxxxx 10. Name change suggestions: getdynhostbyname() Freedynhostent() getdynhostbyaddr() Suggestion to use "node" instead of "host" 11. Add new AI_Flags to getaddrinfo() Warning - TOG/XNET owns this spec ???? Thanks to Bob, Sue, Jim, & Rich [Jim Bound will send slides by email] Traceroute hop-by-hop option / A. Durand ---------------------------------------- Round trip Traceroute Traceroute Problem - Route for the direct patch - No information about the reverse path - Source-routing is not a solution - Many (most?) routes are asymmetrical (difficult to debug) - Can go through firewalls... Proposed Solution - Based on RFC1394 for IPv4 & IPv4 Record Route option - Define an hop-by-hop option processed by routers on the direct and the reverse path. - Define a new ICMP traceroute message - 4 different strategies can be used Traceroute hop-by-hop option 0 3 0 1 +-----------+-----------+ | Value=TBD | Length | +-----------+-----------+-----------+-----------+ | ID | Ptr | Flags | Boundary | +-----------+-----------+-----------+-----------+ | | | space to record information | . . . | | +-----------------------------------------------+ Router Information 0 3 0 1 +-----------+-----------+-----------+-----------+ | Type | HL | Medium | Reserved | +-----------+-----------+-----------+-----------+ | MBZ | AS | +-----------------------+-----------------------+ | | | Address | | | | | +-----------------------------------------------+ ICMP Traceroute message 0 3 0 1 +-----------+-----------+-----------+-----------+ | TBD | MBZ | Checksum | +-----------+-----------+-----------+-----------+ | ID | HL | Medium | Reserved | +-----------------------+-----------------------+ | MBZ | AS | +-----------------------+-----------------------+ | Reserved | +-----------------------------------------------+ | Address | | | | | +-----------------------------------------------+ Strategy #1 Two Packet traceroute - Originator send ICMP echo request to target with traceroute hop-by-hop - Routers store information within the option - Target send ICMP echo reply with traceroute hop-by-hop option initialized with data from the received packet. - How many routers can be recorded? o min MTU 576 => up to 21 o min MTU 1200 => up to 47 - OK for small networks, not enough in the general case [figure of two packet traceroute] Strategy #2 Limited Traceroute - Originator specifies to record the direct path or the reverse path. - Originator includes a boundary indication - Packet is sent with Hop Count set to 255 - Routers should record information iff current Hop Count <= Boundary [figure of limited traceroute] Strategy #3 Debug Mode - Originator set a "debug flag" in the hop-by-hop option - Routers send their information in a new ICMP traceroute message back to the originator. [figure of debug traceroute] Comments: Have looked at multicast route traceroute draft? Deering very nervous about debug mode because it generates so much traffic. Suggest modeling this like multicast traceroute and remove debug mode. CH: Two problems with approach. Real reason IPv4 traceroute not uses was that it was a stupid idea. Debug mode is a great tool for denial of service attack. This is very bad. M. Wasserman: Thinks proposal needs some more work. Likes the goal for what this does, but isn't sure this is the right mechanism. Overall conclusion that work should continue. DHCP vs. M & O Bits / Narten ---------------------------- M bit to control how if DHCP should be used to get addresses O bit to get other info from DHCP. Discussed in DHCP w.g. Agreed on clarification to language in spec. Issue is if different advertisements have different M & O bit values also resolved. Once use DHCP keep using it. Ignore changes in bits. Text will also be clarified. Bound suggested alternative. Bits not needed. If administrator has policy, then they control ND advertisements or turn on DHCP. Discussion and clarifications. Comment bit is important, because otherwise you have to wait for a timeout before continuing. Suggesting that we should keep bits and clarify usage. Bits are advisory. Hint to use DHCP or not. Working group consensus to leave keep bits and clarify text as to usage. ------------------------------------------------------------ FRIDAY, December 12, 1997, 0900-1130, (Empire Room) ------------------------------------------------------------ Document Status (continues) / R. Hinden --------------------------------------- Neighbor Discovery & Address Auto-Conf - Document editor will do wg last call for advancement to Draft as soon as updated drafts are out. Unicast Aggregation Formats draft - Author will add motivations section based on last call discussions. [Editor's note: Following additional discussions, author will change format to add a 8 bit reserved field between TLA and NLA field (reduces NLA to 24 bits). This resolves issue of allowing additional TLA's if routing system evolves to handle more top level routes but keeps initial limit at ~8K for initial allocations.] TLA/NLA Assignment Rules draft - After discussions with lots of IESG folks and other interested parties this week, decision is to form operations area WG to progress rules document. Allison Mankin and Erik Huizer will co-chair working group. ECN Bit Assignment / S. Floyd ----------------------------- A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP Internet Draft ECN Web page: http://www-nrg.ee.lbl.gov/floyd/ecn.html What is needed from IPv6 - An ECN-capable bit set by the origin transport protocol (for incremental deployment) - An ECN bit set by the router (instead of dropping the packet) (When the buffer has not overflowed, and the ECN-capable bit is set, and the router would otherwise drop the packet because of the RED algorithm, base don the average queue size. Where would the bits come from? - The IPv4 TOS byte and/or the IPv6 traffic class byte - Our original proposal was only in terms of IPv6 - IPv4: The current draft of draft-ellesson-tos-00.txt includes the CE and ECT (ECN-capable transport) bits - What would be the time scale of making this decision? - Where? Intserv/diff-serv? or IPng? Planning an ECN BOF at next IETF. Could make a formal request to IESG for two bits in IPv4 Why two bits instead of one? - The One-bit approach: The single bit would have two values: "ECN-Capable", and "either not-ECN-Capable, or Congestion Notification". - The ECN-Capable functionality is needed to allow a viable incentive for incremental deployment of ECN-aware hosts. - Robustness issues for one bit approach: o Default setting MUST be "either non ECN capable, or Congestion Notification" - The receiver has to know in advance that the sender is sending all packet with the bit set as "ECN-Capable". Why not Source Quench? - The delay difference (between RTT and part of an RTT) is not a critical issue for most environments - The ECN bit is applicable for multicast as well as for unicast applications. - With Source Quench, care must be taken not to add significant extra traffic in times of congestion. How would the router decide whether to drop the packet or set the ECN bit? - For ECN-capable packets, the router would set the ECN bit when it is in the regime of using RED to "mark" packets probabilistically. When the average queue size exceeds the maximum queue threshold, the router would drop arriving packets. - For most routers today, the packet drop rate is less than 10%. If these routers deploy RED, they are therefore generally in the regime of probabilistic marking. Does ECN make it easy for evil applications to ignore congestion control? - Already easy for "evil" applications to ignore congestion control. Just use UDP, and add a little FEC to counteract the packet drop rate. Or "turn off" congestion control for TCP. - In the absence of congestion control in the end-nodes, a moderate (less than 10%) packet drop rate is not, in and of itself, an effective mechanism of congestion control, or an effective deterrent to any application that wishes to "turn off" end-to-end congestion control. - ECN does add another way that applications could ignore congestion control, but setting the "ECN-capable" bit but ignoring the ECN bit in received packets. What applications would benefit from ECN - Reliable multicast - Real time flows with (fixed or adaptive) playback times - Very short web transfers - Low-bandwidth telnet connections ECN Simulations and Experiments - Simulations: the ns-1 and ns-2 simulators [floyd1994] - Experiments: UCLA (Chris Chen, Hariharam Krishnan, Steve Leung, Nelson Tang) has an ECN implementation in IPv6 FreeBSD. Using RED implementation from ALTQ. - The bits to use in the IPv6 header for experimental purposes? IGMP for IPv6 / S. Deering -------------------------- Based on IGMPv2 for IPv4 Spec (recently approved as proposed standard) Changes of terminology from IPv4 version - Host/Router/Node, Network/Link, etc. - "multcast listener discover" Uses ICMPv6 message types, not protocol ID #2 Uses Link-local source address for messages - Link-Scope all-nodes multicast destination address for queries Didn't get new draft out prior to ID deadline. Will get it a week or two after IETF. Packet Format +--------+-------+-----------------| | Type | Code | checksum | +--------+-------+-----------------| | Max resp delay | reserved | +----------------+-----------------+ | | | Multicast | | | | Address | | | +----------------------------------+ Types: Query 130 Report 131 Done 132 Code: 0 Max resp delay: in milliseconds (Router alert also present) Suggestion: Reserve these type codes in ICMP spec. Also the ND type codes. Also reference to other docs. IPng Document editor will reissue ICMP draft with type codes. Question about Multicast routing protocols: PIM and MOSPF currently support OSPF. DVMRP will not. Neighbor Discovery over Tunnels / S. Deering -------------------------------------------- Should we run ND over tunnels and p-p links? Suggestion that we need additional specification about how to run ND on point-to-point links. Bi-directional links only. Probably should not run it over uni-directional links. When a pair of routers are at ends of link, ND is also not needed. Routing protocols have needed functionality. In some ways ND is the routing protocol for Host-Host and Host-Router. NUD may be used between routers. Required for other cases. Should we consider ND on or off, or should we allow it's individual components to be used individually? Questions: Should we use ND between hosts and router on bi-directional p-p link? Deering would like this to be the case. Parts can be turned off as appropriate. Issue may be mostly focused on address resolution. Deering wants resolution of should we do this so, if so, we can write a document that defines operation. Discussion. Define p-p link as one that there can only be two nodes. Given that property, we can leave out specific ND components. M. Wasserman will outline the issues on the mailing list. IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta --------------------------------------------------- Define - Tunnel minimum, maximum, and default MTU - Frame format for IPv6 over IPv6 and IPv4 tunnels - Interface ID for IPv6 tunnel interfaces - IPv6 link-local addresses for tunnel virtual links - Source/Target Link-Layer address option used in ND or IND over IPv6 and IPv4 tunnels. MTU - default tunnel MTU = ( physical underlying IPv6 interface MTU - tunnel headers size) o For Ethernet 1500-20=1480 - 1280 <= tunnel MTU < default tunnel MTU Tunnel Packet Format - IPv6 tunnel packets are encapsulated as: o IPv6 packets o IPv4 packets Interface ID (token) - The IPv6 tunnel pseudo-interface ID (token) o Unique on the virtual link represented by the tunnel - Method 1 o Use underlying physical interface identifier (e.g., EUI-64, EUI-48, etc.) - Method 2 o Based on random number - local, individual 7 6 5 4 3 2 1 0 (bit order +-----+-----+-----+-----+-----+-----+-----+-----+ 0 | Random Number | MBZ | + +-----+-----+ . . . . . . 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+ o Advantage: survives underlying physical interface NIC changes Comment: This might conflict with vendor assignments. If using this, why transform the interface ID. Could use it without change. Question are both end of links required to be on the same subnet. Answer: No we can have unnumbered links. Not prohibited either. Could also use link-local addresses. Comment: It is very important to keep the token the same when rebooting, rebooting, etc. Author will revise draft and republish. Site prefixes in Neighbor Discovery / E. Nordmark -------------------------------------------------- Goals - Limit effect of renumbering in a site by ensuring that traffic local to the site use site local addresses. - Do this without requiring a two-faced DNS. Proposal - Advertise the global prefixes (w/ lifetimes) for the site in Neighbor Discovery messages. - The hosts use this information to maintain a list of the current site prefixes. - The host resolver (gethostbyname function) checks against list of prefixes after resolving the name. - When one of the addresses retrieved from the DNS matches one of the site prefixes (i.e., the first N bits match) then replace with the corresponding site local address. Open issue 1 - Mobile nodes moving off site and have been using site local addresses. - Clarify in architecture: mobile is part of home site, not part of visited site - Site local packets (src or dst) over bi-directional tunnel to mobile KRE: The problem is that we have not defined what is a site. Need to do this. Proposal: Node or link are never in more than one site. Some node/links are not in any site (used to connect sites). Question about if tunnel is bi-directional or uni-directional. Issue is more complex. Disagreement about KRE's definition of site. Alternative definition is that node can be in multiple sites and link can only be in one. Agreement on criteria that sites can never overlap. Open Issue 2 - Node multihomed to multiple sites - Disable algorithm (in draft), or - Christian H. proposal with random site ID in site local address +-------+-------------------+--------+--------------+ | xxxx | 0........0 | Subnet | Interface id | +-------+-------------------+--------+--------------+ put random # here Comment: Same issue as what we decided with link local addresses. Should not need random number. Just need to keep track of scope of these addresses. Additional discussion..... Open Issue 3 - Site local address in DNS - Flexibility - not all nodes in the site must have a site local address - Limits denial of service attack? - No need for two-faced DNS - Site local address is ignored unless in same site - If RRset contains global address matching a site prefix => Use site local RRset Open Issue 4 - Include or remove global addresses? - Site local should be tried first by application - Returning globals => accidentally using global when site local would have worked - No globals => site locals better work! - Admin applications need to see content of DNS Open Issue 5 - Encoding the exact semantics of advertisement: - Note: Separate prefix option advertisement to assign site local address - Should the site prefix be a separate prefix option (i.e., remove Site PLength? Open Issue 6 - Security considerations: - Any node on the link can cause a denial of service attack by advertising a bogus site prefix - This is not any worse than other on-link DoS attacks. Open Issue 7 - Assumes common SLA (subnet number): - 16 bits in site local - Must match in all global and the site local addressing plans - Relax if site locals in DNS Open Issue 8 - Are the benefits worth the added complexity? Discussion will be continued on mailing list. Router Alert / R. Hinden ------------------------ This draft has been returned from the IESG for several changes. C. Partridge will be submitting a new draft in the next few weeks that should resolve the problems. Comment: IPsec supposedly is requesting an additional code point in the router alert option for multicast key. VRRP for IPv6 / R. Hinden ------------------------- Virtual Router Redundancy Protocol (VRRP) developed initially for IPv4. VRRP Overview - VRRP allows one router to back up another router transparently to hosts o Goal is to keep TCP connections from breaking - Current Host OS's don't handle switching to a second router well or at all - Mechanisms such as Router Discover were not designed for this function and are not widely implemented. IETF - VRRP being developed in IETF o VRRP Working Group o Current draft is: - Provides functions similar to Proprietary Protocols o Cisco HSRP o Digital IP Standby Protocol - Work Includes o VRRP Protocol o VRRP MIB o VRRP for IPv6 [Figure showing basic operation of VRRP] VRRP Mechanisms - Virtual MAC Addresses o Mapping between Router IP Address and MAC Address o Host Default Gateway stays the same - VRRP Protocol and State Machine o Determines which router is Master o Sends Periodic Advertisements + Default is 1 second o Backup takes over if three Advertisements not heard Additional Detail - Priority Allows control over which router backs up another - Supports Loadsharing by setting Default Gateway in Hosts to different VRRP Routers - More sophisticated control can be done by dynamically changing priority based on status of other interfaces - Runs over Shared Media LAN's - Authentication choices include MD5 Status - Working Group Meet at this week's IETF - Group agreed to move to Proposed Standard with small changes - Work starting on o VRRP MIB o VRRP for IPv6 Issue for IPv6 is to either add VRRP features to neighbor discovery or to define a profile for current ND mechanisms that meet VRRP goals. Comments were mostly to just use ND (with some tuning if necessary). IPv6 Addresses in URL's / B. Carpenter -------------------------------------- Design team meet in the bar a few nights ago. Need numeric address in URL's for emergency operations (or robotic apps). Colons break URL parsers "hostname" syntax Proposals: http://--ABCD-EF12-192.100.1.2.ipv6:80/ http://[ABCD:EF12:192.100.1.2]:80/ Issue: Should IPng w.g. reopen the "colon" notation? Heated discussion. Most comments that this is stupid, we should not reopen IPv6 text notation. Long discussion. Issue seems to be that many parsers that take URL's are very limited. No one was in favor of changing current text representation. Extremely strong consensus! It was noted that the issue is probably only relevant for complete web browsers (e.g., Netscape, Microsoft, etc.), not all other applications that use URL's. If the complete web browsers can be changed it is very likely to be sufficient. Recommend that the primary preferred syntax for IPv6 addresses in URL's be: http://[ABCD.EF01::2345:6789]:80/ The IPv6 address should be enclosed in brackets. URL parsers that can not support this notation can either support the proposed alternative syntax: http://--ABCD-EF12-192.100.1.2.ipv6:80/ or not allow IPv6 addresses to be entered directly. Non-Corrosive Multi-Homing Idea / Matt Crawford ----------------------------------------------- Goal - Allow a multihomed site to use other links for existing sessions which have addresses derived from the provider on the failed link. - Do not inject long prefixes into global routing. - Do not tell ISP's how to run their busine$$es. Three Magic Words - Multicast - Security - Mobility [three diagrams showing basic topology of site connected to two providers and how mechanism works when a link to one of the providers fails.] Basic idea is for border router to send a renumbering message when link fails. New flag for prefix info. option - The "B" (for broken) flag o Valid/preferred lifetimes unchanged - Host action: o Do not select this prefix for new communication if there's a non-broken prefix available o For existing communication, use IPv6 mobility as if host has moved to A::S::HL Wants discussion on mailing list. ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 30 14:58:03 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA11452 for ipng-dist; Tue, 30 Dec 1997 14:54:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA11445 for ; Tue, 30 Dec 1997 14:54:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA00020 for ; Tue, 30 Dec 1997 14:54:39 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA07094 for ; Tue, 30 Dec 1997 14:55:01 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA03807; Tue, 30 Dec 1997 19:18:06 +1100 (from kre@munnari.OZ.AU) To: huitema@bellcore.com (Christian Huitema) Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 5086) Re: December minutes / Site addresses In-Reply-To: A message of "Mon, 29 Dec 1997 16:49:47 -0500." References: <3.0.3.32.19971224124709.0083d830@mailhost.ipsilon.com> <971229164947.ZM15837@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Dec 1997 19:17:59 +1100 Message-Id: <28195.883469879@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 29 Dec 1997 16:49:47 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-ID: <971229164947.ZM15837@seawind.bellcore.com> | Reading the minutes of the discussion on "site local" addresses, I note | that the idea of inserting a unique site number was dismissed "because | we already went through this discussion for link local addresses." I think you misread the minutes. There was a comment along those lines, but there was also rather a lot of opposing comment, and I certainly don't think anything was dismissed (and I don't see in the minutes any suggestion that it was). That section of the minutes is most notable for the long list of open issues... I believe that Matt has a reasonable plan of where to go next, though I'm not sure I quite agree with all the requirements, but never mind. In any case, his first step was to define a "site", which I also agree is the first thing to do, and as I made a brief verbal proposal in Washington, I'll start... I suggest simplifying the concept as much as we reasonably can, while not precluding at some later time expanding the definition, once we have all of the basics understood, and as we find ways to extend things without breaking what is already in place (which is much the way the IPv4 address model has been transformed over time). To that end, I define a site as any set of connected nodes and links none of which is a member of any other site. That sounds a bit vague, but I think is adequate for our purposes. The most important part is that anything which would seem to be a member of two sites, becomes a member of neither. That is, links which connect two sites are in neither site (that is, DNZ type links). Alternatively, nodes which serve as exchange points would belong to none of the sites. Which interconnect between sites to use would be up to the sites concerned. For our purposes, being "in" a site means having assigned site local addresses that come from that site, a node that is in no site would have no assigned site local addresses (it would simply not configure any), a link that is in no site would have no site local prefixes advertised on that link. This also provides some idea of the answer to Matt's second question... + Decide whether site boundaries may cut links, nodes, or both. which I would answer as "neither", though whether that is correct depends a lot on what is implied by "cut". Since I allow nothing to be in two sites I see no boundaries, hence the "none". On the other hand, the sites and links that are in no site are effectively the boundary, and defined that way the answer would be "both". I'm not sure that this matters that much - the definition of site should make this more or less irrelevant (ie: this is just one part of that definition). 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 Dec 31 06:50:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA11813 for ipng-dist; Wed, 31 Dec 1997 06:42:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA11806 for ; Wed, 31 Dec 1997 06:41:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA23371 for ; Wed, 31 Dec 1997 06:41:55 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA04008 for ; Wed, 31 Dec 1997 06:42:22 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id JAA20896; Wed, 31 Dec 1997 09:41:54 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id JAA17310; Wed, 31 Dec 1997 09:41:53 -0500 (EST) Date: Wed, 31 Dec 1997 09:41:53 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971231094153.ZM17308@seawind.bellcore.com> In-Reply-To: Robert Elz "(IPng 5086) Re: December minutes / Site addresses" (Dec 30, 7:17pm) References: <3.0.3.32.19971224124709.0083d830@mailhost.ipsilon.com> <971229164947.ZM15837@seawind.bellcore.com> <28195.883469879@munnari.OZ.AU> X-Mailer: Z-Mail (5.0.0 30July97) To: Robert Elz , huitema@bellcore.com (Christian Huitema) Subject: (IPng 5087) Re: December minutes / Site addresses Cc: Bob Hinden , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk KRE, You propose to define a site as "a set of links and nodes that belong to no other site." I have three comments: 1) you forget an important qualifier, connectivity. 2) your definition precludes multi-sited nodes. This produces a consistent behavior, which is your goal, but cannot be enforced because network managers have very little control on what goes on inside a node. 3) your definition does not start from the purpose of a site, which is to define an addressing scope, as in multicast addressing. Defining that scope only makes sense if it relates to some form of real life entity, e.g. a campus. As soon as you build this relation, you realize that you cannot exclude multi-sited users. I would propose to amend your definition, to "a connected set of links that belong to no other site, and the nodes with interfaces to those links." -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 31 08:33:53 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA12012 for ipng-dist; Wed, 31 Dec 1997 08:30:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA12005 for ; Wed, 31 Dec 1997 08:30:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA13099 for ; Wed, 31 Dec 1997 08:30:21 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA10796 for ; Wed, 31 Dec 1997 08:30:48 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA29445; Wed, 31 Dec 1997 11:30:18 -0500 (EST) Message-Id: <199712311630.LAA29445@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5088) Last Call: IP Version 6 over PPP to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Wed, 31 Dec 1997 11:30:17 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider IP Version 6 over PPP as a Proposed Standard. This document will replace RFC2023 which will be reclassified as Historic. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 14, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-04.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 Wed Dec 31 08:53:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA12069 for ipng-dist; Wed, 31 Dec 1997 08:50:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA12062 for ; Wed, 31 Dec 1997 08:50:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA15213 for ; Wed, 31 Dec 1997 08:50:00 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA19101 for ; Wed, 31 Dec 1997 08:50:27 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA29888; Wed, 31 Dec 1997 11:49:56 -0500 (EST) Message-Id: <199712311649.LAA29888@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5089) Last Call: Transmission of IPv6 Packets over Token Ring Networks to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Wed, 31 Dec 1997 11:49:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Transmission of IPv6 Packets over Token Ring Networks as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 14, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-tokenring-04.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 Wed Dec 31 15:49:18 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA12502 for ipng-dist; Wed, 31 Dec 1997 15:43:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA12495 for ; Wed, 31 Dec 1997 15:43:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA21356 for ; Wed, 31 Dec 1997 15:43:15 -0800 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA10155 for ; Wed, 31 Dec 1997 15:43:42 -0800 (PST) Received: by INET-01-IMC with Internet Mail Service (5.5.1960.3) id ; Wed, 31 Dec 1997 15:43:17 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF11113E@red-msg-52.dns.microsoft.com> From: Brian Zill To: "'huitema@bellcore.com'" , Robert Elz Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 5090) Re: December minutes / Site addresses Date: Wed, 31 Dec 1997 15:43:13 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, Robert, et. al, KRE proposes that a site is "a set of links and nodes that belong to no other site." Christian proposes that a site is "a connected set of links that belong to no other site, and the nodes with interfaces to those links." Could someone explain to me this desire to define site address applicability in a fundamentally different way than IP address applicability has traditionally been defined? It seems obvious to me that since IP addresses denote interfaces (or a collection thereof), not nodes or links, that site addresses should do likewise. Thus a site would be "a set of interfaces". (Since it seems obvious to me, I must be missing something :-), could someone clue me in?) Whether or not to allow an interface to belong to more than one site at a time is a separate issue, but restricting an interface to a single site sounds like a rational simplification to me (the mobility folks might disagree, however). This would leave one with the definition of a site as "a set of interfaces that belong to no other site". Likewise, If you want to include connectivity, you'd have to define a site in such a way that stated the set of interfaces were connected somehow. Since I would hope that encapsulating tunnels would be allowed to connect otherwise disjoint parts of a "site", I don't think the terminology "a connected set of links" applies. Maybe a site should be "that set of interfaces which have only one site-local address and can communicate with each other via that site-local address". Note that defining a site this way allows for multi-sited nodes (such a border routers), which I consider to be a good thing. The boundaries of sites would always lie inside of multi-sited nodes. --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 Dec 31 16:07:36 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA12633 for ipng-dist; Wed, 31 Dec 1997 16:04:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA12626 for ; Wed, 31 Dec 1997 16:04:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA23031 for ; Wed, 31 Dec 1997 16:03:58 -0800 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA16919 for ; Wed, 31 Dec 1997 16:04:25 -0800 (PST) Received: by mail5.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Wed, 31 Dec 1997 16:04:02 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81002398D9C@red-msg-50.dns.microsoft.com> From: Richard Draves To: Brian Zill , "'huitema@bellcore.com'" , Robert Elz Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 5091) Re: December minutes / Site addresses Date: Wed, 31 Dec 1997 16:03:56 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Whether or not to allow an interface to belong to more than one site at a > time is a separate issue, but restricting an interface to a single site > sounds like a rational simplification to me (the mobility folks might > disagree, however). This would leave one with the definition of a site as > "a set of interfaces that belong to no other site". > > Likewise, If you want to include connectivity, you'd have to define a site > in such a way that stated the set of interfaces were connected somehow. > Since I would hope that encapsulating tunnels would be allowed to connect > otherwise disjoint parts of a "site", I don't think the terminology "a > connected set of links" applies. Maybe a site should be "that set of > interfaces which have only one site-local address and can communicate with > each other via that site-local address". > [Richard Draves] I agree, it seems clearer to talk about interfaces instead of nodes, since addresses are assigned to interfaces. The simpler forms of tunnelling (point-to-point bidirectional, 6-over-4) are defined to be virtual links, so I think the "connected set of links" part of the definition is OK. 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 Dec 31 23:01:31 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id WAA12915 for ipng-dist; Wed, 31 Dec 1997 22:57:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id WAA12908 for ; Wed, 31 Dec 1997 22:57:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA12103 for ; Wed, 31 Dec 1997 22:57:45 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id WAA17849 for ; Wed, 31 Dec 1997 22:58:10 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA07507; Thu, 1 Jan 1998 17:57:33 +1100 (from kre@munnari.OZ.AU) To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5092) Re: December minutes / Site addresses In-Reply-To: A message of "Wed, 31 Dec 1997 09:41:53 -0500." References: <3.0.3.32.19971224124709.0083d830@mailhost.ipsilon.com> <971229164947.ZM15837@seawind.bellcore.com> <28195.883469879@munnari.OZ.AU> <971231094153.ZM17308@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Jan 1998 17:57:31 +1100 Message-Id: <8653.883637851@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 31 Dec 1997 09:41:53 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-ID: <971231094153.ZM17308@seawind.bellcore.com> | 1) you forget an important qualifier, connectivity. I didn't, but that doesn't matter, we both agree that's important. | 2) your definition precludes multi-sited nodes. This produces a | consistent behavior, which is your goal, Yes. | but cannot be enforced | because network managers have very little control on what | goes on inside a node. I actually had (somewhere in my tiny brain) an idea that the sitedness of a node would be automatically determined by the software, a node which say "site N" advertised on one link, and "site M" advertised on another would simply refuse to configure any site local addressing (the software would not allow it to happen) and would automatically be a member of neither site. Similarly, on a link where a node saw adverts for two different sites, it would ignore all of those, and treat the link as if no site addresses were available on it (including for the purpose of the previous test). So in a sense, yes, it could be enforced. But in another sense, no, and I don't want to either - by leaving the flexibility there for nodes (or links perhaps) to belong to multiple sites we can allow the definition to expand over time. What I really want the simple definition for is to crystalize our thinking on how we operate on site local addresses - to give us a basis from which we can build uses and find out how they're useful, and exactly what we can do with them, and what problems attempting to use addresses that aren't global (and in a scope where global addresses are available) actually causes. (Using site local addressing in an isolated island comprising one site isn't an interesting case, though the addresses are obviously valuable there). | 3) your definition does not start from the purpose of a site, Actually, it did, though I didn't state it. | which | is to define an addressing scope, as in multicast addressing. Yes. | Defining that scope only makes sense if it relates to some form | of real life entity, e.g. a campus. Yes. | As soon as you build this | relation, you realize that you cannot exclude multi-sited users. I don't come to that conclusion. My building belongs to only one campus, and other than sub-units of the campus (essentially sub-nets in the IP addressing world) I see nothing that is simultaneously a member of multiple different campuses. So, your real life entity example to me re-inforces my definition, rather than contradicts it. On the other hand, I have no doubt that there will be hard cases, where I would initially at least define that the node belongs to no site, and is simply a global entity. This does have the effect that it would not be possible to trivially derive a site's site local address from its global address (by replacement of the upper bits), at the very least before doing that nodes would need to determine if the target node had any other global addresses that would not be part of the site, which would imply that the node might be potentially a part of multiple sites, and as such, a membe rof none of them. | I would propose to amend your definition, to "a connected set of links | that belong to no other site, and the nodes with interfaces to those | links." That's certainly another possibility - though one that creates more complexity. It is perhaps what I might expect that my definition might migrate into over time. Brian Zill said: | It seems obvious to me | that since IP addresses denote interfaces (or a collection thereof), | not nodes or links, that site addresses should do likewise. That's basically Christian's definition, just stated in a different way. The reason I avoided that (though in practice it amounts to the same thing in my definition, when one extra restriction is added) is because I would like to start making site local addresses work without having to initially figure out how a node decides which particular site local addresses it can use to communicate with various other sets of nodes. Further, I'd like site local addressing to be transitive, if node A can use site local addressing to talk to nodes B and C, I'd like (initially anyway) for nodes B anc C to automatically be able to use site local addresses to communicate with each other. This avoids all kinds of hairy issues that would tend to preclude nodes from using site local addresses in a natural way, and in particular would make it a lot harder to simply have the DNS API insert site local addressing into the returned address set (whether it comes from the DNS server, or is calculated by the interface routines doesn't matter here). Eg: if the DNS API simply returns site local addresses (as well as global) whenever the destination is in the same site as I am a member of (which is a very nice way to keep communications within a site using site local addresses essentially always) then there are problems if the addressing isn't transitive, and I happen to be node A arranging a 3 way conversation of some kind with nodes B and C. My application (perhaps it is ftp, perhaps something different) will need to explicitly look at the addresses returned form the API, see that site local addresses are involved, then know how to extract the site identifier (assuming they carry such a thing) and compare those to determine if the same site is involved, and then not use the site local addresses if it isn't. That's pretty messy. Now it is certainly true that the app is still (even with my definition) going to have to determine that site local addresses are in use in such a case, and avoid using site local to talk to one node and global to talk to another, if it is hoping to use the addresses to establish three way communications - but that's a much simpler test than the other (what is a site local address is very well defined already). | Whether or not to allow an interface to belong to more than one site | at a time is a separate issue, but restricting an interface to a | single site sounds like a rational simplification to me (the mobility | folks might disagree, however). I don't know why they'd disagree, though there did seem to be some people in Washington who had the idea that a link should be able to be in multiple sites, just as there are some (including Christian) who believe that a node should. | Likewise, If you want to include connectivity, That's essential. Without it two nodes in nominally the same site wouldn't be able to use site local addresses to communicate. That effectively makes them useless for the intended purpose - they'd be for all practical purposes two different sites, with only global connectivity between them. | you'd have to define a | site in such a way that stated the set of interfaces were connected | somehow. Yes. | Since I would hope that encapsulating tunnels would be | allowed to connect otherwise disjoint parts of a "site", I don't think | the terminology "a connected set of links" applies. Yes. But I view a tunnel as simply another link. Point to point usually though that isn't absolutely required (it may be to be called a tunnel, but that doesn't bother me right now). I view (conceptually) a tunnel as having an interface at each end (or all ends). That the tunnel just happens to be implemented over an IP substructure is irrelevant to me, as it is that the same physical piece of hardware is used to transmit and receive it as is used for some other link (or perhaps even that the physical hardware used by the tunnel shifts around over time). That's all just as irrelevant as that the physical interface used for an ISDN link can have 2 (or 30) different links all connected through it. That the addressing of the underlying layer looks pretty similar to the addressing of the link layered over it is just one of those co-incidences. Viewing tunnels as some kind of magic, rather than as just another link, causes way too much complexity, and I never do that. So, I do think the terminology applies, the tunnel is just one of the connected links. 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 --------------------------------------------------------------------