From owner-ipng@sunroof.eng.sun.com Mon Mar 1 13:53:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA17648 for ipng-dist; Mon, 1 Mar 1999 13:44:27 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17641 for ; Mon, 1 Mar 1999 13:43:45 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id NAA02169 for ; Mon, 1 Mar 1999 13:43:42 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA09136 for ; Mon, 1 Mar 1999 13:43:27 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA01041; Mon, 1 Mar 1999 15:42:46 -0600 (CST) Message-Id: <199903012142.PAA01041@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com Cc: brian@hursley.ibm.com, cmj@3Com.com From: "Matt Crawford" Subject: (IPng 7246) A 6over4 isomorphism Date: Mon, 01 Mar 1999 15:42:46 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv4 multicast on ethernet IPv6 multicast on 6over4 ================================ ================================ An IPv4 multicast address. An IPv6 multicast address. Many-to-one mapping to subset of Many-to-one mapping to subset of IPv4 IEEE group addresses. multicast addresses. Driver instructs NIC to receive a Host instructs router to send an IPv4 group address, possibly pulling in multicast address, possibly pulling traffic to several IPv4 addresses. in traffic to several IPv6 addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 15:49:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA17833 for ipng-dist; Mon, 1 Mar 1999 15:42:40 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17826 for ; Mon, 1 Mar 1999 15:42:29 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id PAA26220 for ; Mon, 1 Mar 1999 15:42:29 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA02519 for ; Mon, 1 Mar 1999 15:42:27 -0800 (PST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA29568; Mon, 1 Mar 1999 15:42:17 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id PAA06700; Mon, 1 Mar 1999 15:42:17 -0800 (PST) Received: from tdc97-cyndi.tdc.3com.com (tdc30pc.tdc.3com.com [139.87.12.117]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id PAA08240; Mon, 1 Mar 1999 15:42:17 -0800 (PST) Message-Id: <3.0.32.19990301153922.0129c5ac@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 01 Mar 1999 15:39:22 -0800 To: "Matt Crawford" , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: (IPng 7247) Re: A 6over4 isomorphism Cc: brian@hursley.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And your point? Cyndi At 03:42 PM 3/1/99 -0600, Matt Crawford wrote: >IPv4 multicast on ethernet IPv6 multicast on 6over4 >================================ ================================ > >An IPv4 multicast address. An IPv6 multicast address. > >Many-to-one mapping to subset of Many-to-one mapping to subset of IPv4 >IEEE group addresses. multicast addresses. > >Driver instructs NIC to receive a Host instructs router to send an IPv4 >group address, possibly pulling in multicast address, possibly pulling >traffic to several IPv4 addresses. in traffic to several IPv6 addresses. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 16:08:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA17867 for ipng-dist; Mon, 1 Mar 1999 15:59:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17860 for ; Mon, 1 Mar 1999 15:59:33 -0800 (PST) From: crawdad@fnal.gov Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id PAA12701 for ; Mon, 1 Mar 1999 15:59:30 -0800 (PST) Received: from praseodumium (praseodumium.btinternet.com [194.73.73.82]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA12704 for ; Mon, 1 Mar 1999 15:59:31 -0800 (PST) Received: from [195.99.43.202] (helo=thss-barney.THSS-BARNEY) by praseodumium with esmtp (Exim 2.05 #1) id 10HcZj-0007nd-00 for ipng@sunroof.Eng.Sun.COM; Mon, 1 Mar 1999 23:58:15 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id F3AG9N1M; Tue, 2 Mar 1999 00:00:11 -0000 Message-Id: Date: Mon, 1 Mar 1999 23:58:15 +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.Eng.Sun.COM Mon Mar 01 22:04:36 1999 Received: from [193.113.210.238] (helo=mail2.) by tantalum with smtp (Exim 2.05 #1) id 10Hane-0002yc-00 for nbc@btinternet.com; Mon, 1 Mar 1999 22:04:30 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id WAA24242; Mon, 1 Mar 1999 22:05:23 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP); Mon, 1 Mar 1999 22:05:21 +0000 Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA04204; Mon, 1 Mar 1999 14:02:51 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id OAA05730; Mon, 1 Mar 1999 14:02:33 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA17648 for ipng-dist; Mon, 1 Mar 1999 13:44:27 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17641 for ; Mon, 1 Mar 1999 13:43:45 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id NAA02169 for ; Mon, 1 Mar 1999 13:43:42 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA09136 for ; Mon, 1 Mar 1999 13:43:27 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA01041; Mon, 1 Mar 1999 15:42:46 -0600 (CST) Message-Id: <199903012142.PAA01041@gungnir.fnal.gov> To: ipng@sunroof.Eng.Sun.COM Cc: brian@hursley.ibm.com, cmj@3Com.com From: "Matt Crawford" Subject: (IPng 7246) A 6over4 isomorphism Date: Mon, 01 Mar 1999 15:42:46 -0600 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk IPv4 multicast on ethernet IPv6 multicast on 6over4 ================================ ================================ An IPv4 multicast address. An IPv6 multicast address. Many-to-one mapping to subset of Many-to-one mapping to subset of IPv4 IEEE group addresses. multicast addresses. Driver instructs NIC to receive a Host instructs router to send an IPv4 group address, possibly pulling in multicast address, possibly pulling traffic to several IPv4 addresses. in traffic to several IPv6 addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 18:04:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA18114 for ipng-dist; Mon, 1 Mar 1999 17:51:10 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18106 for ; Mon, 1 Mar 1999 17:51:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id RAA15011 for ; Mon, 1 Mar 1999 17:50:55 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA20895 for ; Mon, 1 Mar 1999 17:50:07 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id MAA12872; Tue, 2 Mar 1999 12:50:05 +1100 (EST) (envelope-from pete@trumpet.com.au) To: From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 7248) loose end... Date: Tue, 2 Mar 1999 12:50:00 +1100 cc: deployment@ipv6.org Message-ID: <3c481mc$1fs@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This has been thrashed out before I bet, but I'm concerned over a particular issue relating to IPv6 headers. In the implementation of my stack, I came across an issue as to how to recognize and deal with undefined headers. say stack A implements the standard IPv6 headers. Stack B also implements the same options and the two stacks communicate without a problem. Customer X is utilizing a protocol outside the mainstream, it could be listed in the assigned numbers, but not necessarily so. Some time later, IPv6 is updated and new headers are implemented in stack B. This new header however is indistiguishable from the protocol that customer X has. Stack A cannot be updated easily for any number of reasons. The issue is two fold. Firstly how is an IPv6 option distinguishable from a regular IP protocol. Secondly if it is unknown, how do we not know that there are known protocols further along the chain. The RFC says that seeing an unknown header options implies that the packet be dropped and a parameter problem message be sent back to the originating host, but I personally think that is unacceptable. Firstly, the unrecognized header may actually be recognizable as a valid IP payload. Secondly, it may result in well known IP payloads not getting through simply because the originating host threw a new header in. Indeed a router may insert a header too, or is that forbidden. The issue manifests itself in my stack as a clash between two data structures/algorithms, the first being the header demultiplexor and the second the protocol demultiplexor. The issue I believe is resolvable if there is a sure fire way of distinguishing between header options and between payloads. As it stands, the know values for IPv6 headers are quite assorted and follow no pattern as far as I can see. While some may see the issue as purely academic as it might be suggested that there will be no more IPv6 header classes in the foreseeable future, I believe that the issue may eventually bite us in the bottom. It also cuts right across the grain of the Internet protocols being rugged in nature. IPv4 was different in this regard in that options are always recognizable and can be parsed out simply. Have got it plain wrong? or have I missed something that is obvious. Please feel free to correct me if necessary. If I haven't got it wrong, I believe it to be a flaw in the protocol and we need to do something to control the issue. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 18:42:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA18161 for ipng-dist; Mon, 1 Mar 1999 18:28:55 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18152 for ; Mon, 1 Mar 1999 18:28:15 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id SAA28522 for ; Mon, 1 Mar 1999 18:28:15 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA10089 for ; Mon, 1 Mar 1999 18:28:16 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Mon, 1 Mar 1999 18:28:14 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF07222A97@RED-MSG-52> From: Brian Zill To: "'pete@trumpet.com.au'" , ipng@sunroof.eng.sun.com Cc: deployment@ipv6.org Subject: (IPng 7249) RE: loose end... Date: Mon, 1 Mar 1999 18:28:11 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Could you be more specific about what you perceive to be the problem? You seem to be using the terms "headers" and "options" interchangeably, when they are very different things in IPv6. I believe you always mean "headers", but it's not completely clear. Packets with unrecognized headers must be dropped because there is no way to skip over them. Options, however, have a bit specifying whether they should be dropped or skipped over if the receiving host does not recognize them. Obviously, new headers are not expected to be created lightly. The fact that they will not work with stacks that don't understand them will serve to restrict their development. This is no different than it was for creating new IPv4 protocols. I don't see the problem. In our stack, what you call the "header demultiplexor" and the "protocol demultiplexor" are the same thing. They're all headers, there is no reason to treat "protocols" as different things. --Brian > -----Original Message----- > From: pete@trumpet.com.au [mailto:pete@trumpet.com.au] > Sent: Monday, March 01, 1999 17:50 > To: ipng@sunroof.Eng.Sun.COM > Cc: deployment@ipv6.org > Subject: (IPng 7248) loose end... > > > This has been thrashed out before I bet, but I'm concerned > over a particular > issue relating to IPv6 headers. > > In the implementation of my stack, I came across an issue as > to how to > recognize and deal with undefined headers. > > say stack A implements the standard IPv6 headers. Stack B > also implements > the same options and the two stacks communicate without a > problem. Customer X > is utilizing a protocol outside the mainstream, it could be > listed in the > assigned numbers, but not necessarily so. > > Some time later, IPv6 is updated and new headers are implemented in > stack B. This new header however is indistiguishable from > the protocol > that customer X has. Stack A cannot be updated easily for > any number of > reasons. > > The issue is two fold. Firstly how is an IPv6 option > distinguishable from a > regular IP protocol. Secondly if it is unknown, how do we > not know that there > are known protocols further along the chain. > > The RFC says that seeing an unknown header options implies > that the packet be > dropped and a parameter problem message be sent back to the > originating host, > but I personally think that is unacceptable. Firstly, the > unrecognized header > may actually be recognizable as a valid IP payload. > Secondly, it may result > in well known IP payloads not getting through simply because > the originating > host threw a new header in. Indeed a router may insert a > header too, or is > that forbidden. > > The issue manifests itself in my stack as a clash between two data > structures/algorithms, the first being the header > demultiplexor and the second > the protocol demultiplexor. > > The issue I believe is resolvable if there is a sure fire way of > distinguishing between header options and between payloads. > As it stands, the > know values for IPv6 headers are quite assorted and follow no > pattern as far > as I can see. > > While some may see the issue as purely academic as it might > be suggested that > there will be no more IPv6 header classes in the foreseeable > future, I believe > that the issue may eventually bite us in the bottom. It also > cuts right > across the grain of the Internet protocols being rugged in > nature. IPv4 was > different in this regard in that options are always > recognizable and can be > parsed out simply. > > Have got it plain wrong? or have I missed something that is > obvious. Please > feel free to correct me if necessary. > > If I haven't got it wrong, I believe it to be a flaw in the > protocol and we > need to do something to control the issue. > > Peter > > -- > Peter R. Tattam - Managing Director > Trumpet Software International Pty Ltd. > Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 19:10:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA18251 for ipng-dist; Mon, 1 Mar 1999 19:05:28 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18244 for ; Mon, 1 Mar 1999 19:05:15 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id TAA02864 for ; Mon, 1 Mar 1999 19:05:14 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA25593 for ; Mon, 1 Mar 1999 19:05:09 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id OAA17239; Tue, 2 Mar 1999 14:04:52 +1100 (EST) (envelope-from pete@trumpet.com.au) To: Brian Zill From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 7250) Re: loose end... Date: Tue, 2 Mar 1999 14:04:47 +1100 cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com Message-ID: <3c8gvfk$1ft@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <4FD6422BE942D111908D00805F3158DF07222A97@RED-MSG-52> Brian Zill writes: >From: Brian Zill >To: "'pete@trumpet.com.au'" , ipng@sunroof.Eng.Sun.COM >Cc: deployment@ipv6.org >Subject: RE: (IPng 7248) loose end... >Date: Mon, 1 Mar 1999 18:28:11 -0800 >Peter, >Could you be more specific about what you perceive to be the problem? You >seem to be using the terms "headers" and "options" interchangeably, when >they are very different things in IPv6. I believe you always mean >"headers", but it's not completely clear. I do indeed mean headers. I thought I had removed all references to the word "options" as I was aware of the confusion but obviously not :) >Packets with unrecognized headers must be dropped because there is no way to >skip over them. Options, however, have a bit specifying whether they should >be dropped or skipped over if the receiving host does not recognize them. I have observed that the current header structure follows some kind of pattern and have utilized that to my advantage. Given that headers adhere to the pattern, I could arbitrarily skip unknown headers if I could distinguish a header from a >Obviously, new headers are not expected to be created lightly. The fact >that they will not work with stacks that don't understand them will serve to >restrict their development. This is no different than it was for creating >new IPv4 protocols. I don't see the problem. There is a subtle difference between a header and a protocol in that requires slightly different processing i.e. the packet must be reprocessed. If a protocol is missing, it can be implemented via a raw socket in my stack. The model is fairly clean for unimplemented protocols, but not so for unimplemented headers. >In our stack, what you call the "header demultiplexor" and the "protocol >demultiplexor" are the same thing. They're all headers, there is no reason >to treat "protocols" as different things. I guess I could have processed headers as generic protocols using raw sockets, but I believe that most stacks will tend to optimize these frequent operations (especially fragmentation) through the use of specific header recognition at the IP packet processing layer, which is in fact what I do in my stack. I brief look at the ICMPV6 RFC indicates that there is no distinction between protocols and headers since it only refers to an invalid next header field when sending a parameter problem message. With that in mind, perhaps it needs to be stated more clearly that it is deliberate that the distinction between protocols and headers is supposed to be blurry, and that stacks should be designed with that concept in mind. If I had known this at the time, my implementation could indeed have been simplified - indeed the modification needed is basic and I may implement it if I can get a definite answer on the issue of whether there needs to be any distinction between headers and payloads. >--Brian Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 19:10:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA18238 for ipng-dist; Mon, 1 Mar 1999 19:00:19 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18231 for ; Mon, 1 Mar 1999 19:00:09 -0800 (PST) From: pete@trumpet.com.au Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id TAA27908 for ; Mon, 1 Mar 1999 19:00:04 -0800 (PST) Received: from tungsten (tungsten.btinternet.com [194.73.73.81]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA23436 for ; Mon, 1 Mar 1999 19:00:02 -0800 (PST) Received: from [195.99.43.180] (helo=thss-barney.THSS-BARNEY) by tungsten with esmtp (Exim 2.05 #1) id 10HfPK-0001zz-00 for ipng@sunroof.Eng.Sun.COM; Tue, 2 Mar 1999 02:59:42 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id F3AG9NGC; Tue, 2 Mar 1999 03:00:45 -0000 Message-Id: Date: Tue, 2 Mar 1999 02:59:42 +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.Eng.Sun.COM Tue Mar 02 02:16:13 1999 Received: from [193.113.211.246] (helo=mailhub.btwebworld.com) by rhenium with smtp (Exim 2.05 #1) id 10HejD-0000Fi-00 for nbc@btinternet.com; Tue, 2 Mar 1999 02:16:11 +0000 Received: from mail.btwebworld.com by mailhub.btwebworld.com (SMI-8.6/SMI-SVR4) id CAA08818; Tue, 2 Mar 1999 02:16:31 GMT Received: by mail.btwebworld.com (SMI-8.6/SMI-SVR4) id CAA29940; Tue, 2 Mar 1999 02:15:51 GMT Received: from mercury.Sun.COM by mail.btwebworld.com with SMTP (XT-PP); Tue, 2 Mar 1999 02:15:43 +0000 Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA13571; Mon, 1 Mar 1999 18:15:40 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id SAA02559; Mon, 1 Mar 1999 18:15:29 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA18114 for ipng-dist; Mon, 1 Mar 1999 17:51:10 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18106 for ; Mon, 1 Mar 1999 17:51:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id RAA15011 for ; Mon, 1 Mar 1999 17:50:55 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA20895 for ; Mon, 1 Mar 1999 17:50:07 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id MAA12872; Tue, 2 Mar 1999 12:50:05 +1100 (EST) (envelope-from pete@trumpet.com.au) To: From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 7248) loose end... Date: Tue, 2 Mar 1999 12:50:00 +1100 cc: deployment@ipv6.org Message-ID: <3c481mc$1fs@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This has been thrashed out before I bet, but I'm concerned over a particular issue relating to IPv6 headers. In the implementation of my stack, I came across an issue as to how to recognize and deal with undefined headers. say stack A implements the standard IPv6 headers. Stack B also implements the same options and the two stacks communicate without a problem. Customer X is utilizing a protocol outside the mainstream, it could be listed in the assigned numbers, but not necessarily so. Some time later, IPv6 is updated and new headers are implemented in stack B. This new header however is indistiguishable from the protocol that customer X has. Stack A cannot be updated easily for any number of reasons. The issue is two fold. Firstly how is an IPv6 option distinguishable from a regular IP protocol. Secondly if it is unknown, how do we not know that there are known protocols further along the chain. The RFC says that seeing an unknown header options implies that the packet be dropped and a parameter problem message be sent back to the originating host, but I personally think that is unacceptable. Firstly, the unrecognized header may actually be recognizable as a valid IP payload. Secondly, it may result in well known IP payloads not getting through simply because the originating host threw a new header in. Indeed a router may insert a header too, or is that forbidden. The issue manifests itself in my stack as a clash between two data structures/algorithms, the first being the header demultiplexor and the second the protocol demultiplexor. The issue I believe is resolvable if there is a sure fire way of distinguishing between header options and between payloads. As it stands, the know values for IPv6 headers are quite assorted and follow no pattern as far as I can see. While some may see the issue as purely academic as it might be suggested that there will be no more IPv6 header classes in the foreseeable future, I believe that the issue may eventually bite us in the bottom. It also cuts right across the grain of the Internet protocols being rugged in nature. IPv4 was different in this regard in that options are always recognizable and can be parsed out simply. Have got it plain wrong? or have I missed something that is obvious. Please feel free to correct me if necessary. If I haven't got it wrong, I believe it to be a flaw in the protocol and we need to do something to control the issue. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 19:42:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA18300 for ipng-dist; Mon, 1 Mar 1999 19:31:33 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18293 for ; Mon, 1 Mar 1999 19:31:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id TAA00546 for ; Mon, 1 Mar 1999 19:31:23 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA05261 for ; Mon, 1 Mar 1999 19:31:18 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id OAA18753; Tue, 2 Mar 1999 14:31:08 +1100 (EST) (envelope-from pete@trumpet.com.au) To: pete@trumpet.com.au (Peter R. Tattam) From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 7251) Re: loose end... Date: Tue, 2 Mar 1999 14:31:03 +1100 cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com Message-ID: <3ca13di$1fu@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <3c8gvfk$1ft@jimmy.trumpet.com.au> pete@trumpet.com.au (Peter R. Tattam) writes: >To: Brian Zill >From: pete@trumpet.com.au (Peter R. Tattam) >Subject: (IPng 7250) Re: loose end... >Date: Tue, 2 Mar 1999 14:04:47 +1100 >cc: deployment@ipv6.org, ipng@sunroof.Eng.Sun.COM >In article <4FD6422BE942D111908D00805F3158DF07222A97@RED-MSG-52> Brian Zill > writes: >>From: Brian Zill >>To: "'pete@trumpet.com.au'" , ipng@sunroof.Eng.Sun.COM >>Cc: deployment@ipv6.org >>Subject: RE: (IPng 7248) loose end... >>Date: Mon, 1 Mar 1999 18:28:11 -0800 >>Peter, >>Could you be more specific about what you perceive to be the problem? You >>seem to be using the terms "headers" and "options" interchangeably, when >>they are very different things in IPv6. I believe you always mean >>"headers", but it's not completely clear. >I do indeed mean headers. I thought I had removed all references to the word >"options" as I was aware of the confusion but obviously not :) >>Packets with unrecognized headers must be dropped because there is no way to >>skip over them. Options, however, have a bit specifying whether they should >>be dropped or skipped over if the receiving host does not recognize them. >I have observed that the current header structure follows some kind of pattern >and have utilized that to my advantage. Given that headers adhere to the >pattern, I could arbitrarily skip unknown headers if I could distinguish a >header from a Oops... Read "header from a payload." >>Obviously, new headers are not expected to be created lightly. The fact >>that they will not work with stacks that don't understand them will serve to >>restrict their development. This is no different than it was for creating >>new IPv4 protocols. I don't see the problem. >There is a subtle difference between a header and a protocol in that requires >slightly different processing i.e. the packet must be reprocessed. If a >protocol is missing, it can be implemented via a raw socket in my stack. The >model is fairly clean for unimplemented protocols, but not so for >unimplemented headers. >>In our stack, what you call the "header demultiplexor" and the "protocol >>demultiplexor" are the same thing. They're all headers, there is no reason >>to treat "protocols" as different things. >I guess I could have processed headers as generic protocols using raw sockets, >but I believe that most stacks will tend to optimize these frequent operations >(especially fragmentation) through the use of specific header recognition at >the IP packet processing layer, which is in fact what I do in my stack. >I brief look at the ICMPV6 RFC indicates that there is no distinction between >protocols and headers since it only refers to an invalid next header field >when sending a parameter problem message. >With that in mind, perhaps it needs to be stated more clearly that it is >deliberate that the distinction between protocols and headers is supposed to >be blurry, and that stacks should be designed with that concept in mind. If I >had known this at the time, my implementation could indeed have been >simplified - indeed the modification needed is basic and I may implement it if >I can get a definite answer on the issue of whether there needs to be any >distinction between headers and payloads. >>--Brian >Peter >-- >Peter R. Tattam - Managing Director >Trumpet Software International Pty Ltd. >Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 20:21:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA18353 for ipng-dist; Mon, 1 Mar 1999 20:13:54 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18346 for ; Mon, 1 Mar 1999 20:13:44 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA08281 for ; Mon, 1 Mar 1999 20:13:43 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id UAA23007 for ; Mon, 1 Mar 1999 20:13:37 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id EA25575; Tue, 2 Mar 1999 15:13:02 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: pete@trumpet.com.au (Peter R. Tattam) Cc: Brian Zill , deployment@ipv6.org, ipng@sunroof.eng.sun.com Subject: (IPng 7252) Re: loose end... In-Reply-To: Your message of "Tue, 02 Mar 1999 14:04:47 +1100." <3c8gvfk$1ft@jimmy.trumpet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Mar 1999 15:13:01 +1100 Message-Id: <17794.920347981@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 2 Mar 1999 14:04:47 +1100 From: pete@trumpet.com.au (Peter R. Tattam) Message-ID: <3c8gvfk$1ft@jimmy.trumpet.com.au> | I have observed that the current header structure follows some kind | of pattern and have utilized that to my advantage. As I recall, the routing header is different from the others, and when the draft for the payload header was around, it also was quite different. There's no guarantee at all that a header that you don't recognise can be parsed according to any rules that you think you can infer from the headers that you can recognise. | There is a subtle difference between a header and a protocol in that | requires slightly different processing I can't imagine what that difference is. The (now defunct) payload header carried (one or more instances of) TCP, UDP (or anything else) in its body. The only oddity is that we have a set of legacy headers that are required to come last in the packet processing, as they carry no "next header" field. | If a protocol is missing, it can be implemented via a raw socket So could processing of a missing header. | I guess I could have processed headers as generic protocols using raw | sockets, but I believe that most stacks will tend to optimize these | frequent operations yes, they will, just as most stacks optimise UDP TCP and (most) ICMP by including their processing in the kernel. It seems unlikely that a not-yet-invented header will be a frequent operation - or not within the timeframe before general deployment of stacks that support it well. Implementors might want to make sure they have a mechanism that allows a packet that has been passed out for raw processing of an unknown header to be dropped back into the kernel for processing of later headers though. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 1 21:01:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA18409 for ipng-dist; Mon, 1 Mar 1999 20:52:09 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18402 for ; Mon, 1 Mar 1999 20:52:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA16094 for ; Mon, 1 Mar 1999 20:52:02 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA06704 for ; Mon, 1 Mar 1999 20:52:01 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Mon, 1 Mar 1999 20:52:01 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81E28@RED-MSG-50> From: Richard Draves To: "'Mobile IP'" , "'IPsec'" , "'IPng List'" Subject: (IPng 7253) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 1 Mar 1999 20:52:00 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Steve Kent and I have talked this over off-line and come to > agreement. (Actually, I think we were already in agreement, > we just weren't communicating effectively via email.) We > agree on the following two points: > > 1. A node will only process an ESP or AH header if it is > participating in the relevant security association. In > particular, a node processing a routing header will not > "snoop" into ESP & AH headers that are not associated with the node. > > 2. In any case, an IPsec-enabled node that is processing a > routing header (with segs left != 0) and hence forwarding a > packet must perform inbound and outbound security policy > checks. The IPsec processing in this situation is the same as > the IPsec processing performed by a security gateway that is > forwarding a packet not destined for itself. Well, it seems we have consensus on the above points. On to something more interesting & perhaps more controversial: what IPsec processing should a correspondent node perform when sending to a mobile node? My first email on this subject suggested that a correspondent node should perform outbound IPsec processing twice: first looking up a security policy using the home address as the destination address selector and applying the resulting security associations, and then doing another security policy database lookup using the care-of address as the destination address selector and applying the additional security associations. However after thinking about more scenarios, it's clear that's too simplistic. I still think two outbound SPD lookups are necessary, using the home address and the care-of address as the destination address selectors, but the results of the two lookups must be *spliced* instead of just concatenated. An assumption here: I believe that it's impractical for a correspondent node to update its security policy database to handle the movement of mobile nodes. The way this works without IPsec: a correspondent node CN is sending to a mobile node with a home address HA. CN looks in its Binding Cache and discovers a care-of address CA associated with the home address. CN sends the packet with a routing header: IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA Transport hdr So let's consider two scenarios with IPsec. In the first scenario, the correspondent node has a transport-mode AH association with the home address. The correpondent node sends packets that look like IPv6 hdr - src CN, dst HA AH hdr - transport-mode SA CN -> HA Transport hdr Then the correspondent node learns that the mobile node has moved. The SPD in the correspondent says that the care-of address is behind a security gateway SG. A tunnel-mode ESP association with SG is required to reach the care-of address. Now the correspondent node sends packets that look like IPv6 hdr - src CN, dst SG ESP hdr - tunnel-mode SA CN -> SG IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA AH hdr - transport-mode SA CN -> HA Transport hdr Note that the correspondent node must do two outbound SPD lookups - one using HA as the destination address selector, and another using CA as the destination address selector - to discover both of the security associations. In the second scenario, the mobile node's home address is behind a security gateway SG1. The correspondent node uses a tunnel-mode ESP association with SG1 to reach the home address. So the correspondent node sends packets that look like IPv6 hdr - src CN, dst SG1 ESP hdr - tunnel-mode SA CN -> SG1 IPv6 hdr - src CN, dst HA Transport hdr Then the correspondent node learns that the mobile node has moved. The SPD in the correspondent says that the care-of address is behind a different security gateway SG2. The correspondent node must use a tunnel-mode ESP association with SG2 to reach the care-of address. So the correspondent node sends packets that look like IPv6 hdr - src CN, dst SG2 ESP hdr - tunnel-mode SA CN -> SG2 IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA Transport hdr In this scenario, the security policy used with the home address is not used when sending to the care-of address, while in the first scenario it is. What's the difference? The difference is that in the first scenario, the correspondent node has a security association directly with the home address, while in this second scenario the association is with a security gateway. I think the correspondent node must do two outbound SPD lookups, using both the home address (lookup #1) and care-of address (lookup #2) as destination address selectors. Then the results of the two lookups are combined. Associations directly with the home address (might be transport-mode or tunnel-mode) are taken from the first lookup, and associations with intermediate security gateways (always tunnel-mode) are taken from the second lookup. Then the headers from the security associations are combined with a routing header as follows: IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA Transport hdr How does this sound? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 2 07:22:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA18834 for ipng-dist; Tue, 2 Mar 1999 07:17:14 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18827 for ; Tue, 2 Mar 1999 07:17:02 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id HAA13276 for ; Tue, 2 Mar 1999 07:17:01 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA05181 for ; Tue, 2 Mar 1999 07:17:01 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA04656; Tue, 2 Mar 1999 09:16:49 -0600 (CST) Message-Id: <199903021516.JAA04656@gungnir.fnal.gov> To: pete@trumpet.com.au (Peter R. Tattam) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 7254) Re: loose end... In-reply-to: Your message of Tue, 02 Mar 1999 14:04:47 +1100. <3c8gvfk$1ft@jimmy.trumpet.com.au> Date: Tue, 02 Mar 1999 09:16:49 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, the key to the answer is this paragraph from RFC 2460: Next Header 8-bit selector. Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.]. The 8-bit field that identifies IPv6 extension headers is drawn from the same space that identifies "higher-level protocols" such as TCP, IP-in-IP, ESP, and so on. So if you customer X got an assigned number, he's safe. If he pulled an unassigned number out of thin air, he's not safe, but he wouldn't have been safe anyway since his number could have been given to a new thing-that-you're-calling-a- protocol. And Brian, remember that we do still have options in v6, but they're wrapped in specific extension headers: the hob-by-hop and destination options headers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 2 15:19:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA19755 for ipng-dist; Tue, 2 Mar 1999 15:13:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19748 for ; Tue, 2 Mar 1999 15:12:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id PAA12723 for ; Tue, 2 Mar 1999 15:12:47 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA29933 for ; Tue, 2 Mar 1999 15:12:47 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16019; Tue, 2 Mar 1999 18:12:42 -0500 (EST) Message-Id: <199903022312.SAA16019@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7256) I-D ACTION:draft-ietf-ipngwg-jumbograms-00.txt Date: Tue, 02 Mar 1999 18:12: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 : IPv6 Jumbograms Author(s) : D. Borman, S. Deering, B. Hinden Filename : draft-ietf-ipngwg-jumbograms-00.txt Pages : 8 Date : 01-Mar-99 A 'jumbogram' is an IPv6 packet containing a payload longer than 65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-jumbograms-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990301131510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-jumbograms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990301131510.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 2 15:19:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA19743 for ipng-dist; Tue, 2 Mar 1999 15:11:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19735 for ; Tue, 2 Mar 1999 15:11:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id PAA12467 for ; Tue, 2 Mar 1999 15:10:57 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA28549 for ; Tue, 2 Mar 1999 15:10:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15873; Tue, 2 Mar 1999 18:10:53 -0500 (EST) Message-Id: <199903022310.SAA15873@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7255) I-D ACTION:draft-ietf-ipngwg-router-renum-08.txt Date: Tue, 02 Mar 1999 18:10:52 -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. Note: This revision reflects comments received during the last call period. Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-08.txt Pages : 30 Date : 01-Mar-99 IPv6 Neighbor Discovery and Address Autoconfiguration 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-router-renum-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990301124654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990301124654.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 2 15:21:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA19778 for ipng-dist; Tue, 2 Mar 1999 15:20:14 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19767 for ; Tue, 2 Mar 1999 15:19:47 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id PAA18787 for ; Tue, 2 Mar 1999 15:19:23 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA04001 for ; Tue, 2 Mar 1999 15:19:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16589; Tue, 2 Mar 1999 18:19:13 -0500 (EST) Message-Id: <199903022319.SAA16589@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7257) I-D ACTION:draft-ietf-ipngwg-mld-01.txt Date: Tue, 02 Mar 1999 18:19:13 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Multicast Listener Discovery (MLD) for IPv6 Author(s) : S. Deering, B. Fenner, B. Haberman Filename : draft-ietf-ipngwg-mld-01.txt Pages : 20 Date : 01-Mar-99 This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990301151656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990301151656.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 2 21:37:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA20258 for ipng-dist; Tue, 2 Mar 1999 21:30:17 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20251 for ; Tue, 2 Mar 1999 21:30:05 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id VAA00834 for ; Tue, 2 Mar 1999 21:30:04 -0800 (PST) Received: from delcluster1.vsnl.net.in (delcluster1.vsnl.net.in [202.54.96.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA07789 for ; Tue, 2 Mar 1999 21:30:02 -0800 (PST) Received: from mailserver ([202.54.106.237]) by delcluster1.vsnl.net.in (8.9.2/8.9.2) with SMTP id LAA09546 for ; Wed, 3 Mar 1999 11:00:03 -0500 (GMT) Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for at Wed, 3 Mar 99 10:50:45 +0530 Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id UAA24438 for ; Tue, 2 Mar 1999 20:25:18 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy2.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id UAA05210; Tue, 2 Mar 1999 20:23:51 -0800 (PST) Received: by ietf.org (8.9.1a/8.9.1a) id XAA06716 for ietf-123-outbound.02@ietf.org; Tue, 2 Mar 1999 23:15:08 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16589; Tue, 2 Mar 1999 18:19:13 -0500 (EST) Message-Id: <199903022319.SAA16589@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@bisquare.com; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7260) I-D ACTION:draft-ietf-ipngwg-mld-01.txt Date: Tue, 02 Mar 1999 18:19:13 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: eab9829b92e17e59f150cd068dd73a11 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 : Multicast Listener Discovery (MLD) for IPv6 Author(s) : S. Deering, B. Fenner, B. Haberman Filename : draft-ietf-ipngwg-mld-01.txt Pages : 20 Date : 01-Mar-99 This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990301151656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990301151656.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 2 21:37:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA20249 for ipng-dist; Tue, 2 Mar 1999 21:27:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20242 for ; Tue, 2 Mar 1999 21:27:13 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id VAA14286 for ; Tue, 2 Mar 1999 21:27:12 -0800 (PST) Received: from delcluster1.vsnl.net.in (del3.vsnl.net.in [202.54.96.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA06510 for ; Tue, 2 Mar 1999 21:27:00 -0800 (PST) Received: from mailserver ([202.54.106.237]) by delcluster1.vsnl.net.in (8.9.2/8.9.2) with SMTP id KAA22624 for ; Wed, 3 Mar 1999 10:56:56 -0500 (GMT) Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for at Wed, 3 Mar 99 10:45:12 +0530 Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id RAA29719 for ; Tue, 2 Mar 1999 17:38:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id RAA00243; Tue, 2 Mar 1999 17:32:20 -0800 (PST) Received: by ietf.org (8.9.1a/8.9.1a) id UAA24071 for ietf-123-outbound.02@ietf.org; Tue, 2 Mar 1999 20:25:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16019; Tue, 2 Mar 1999 18:12:42 -0500 (EST) Message-Id: <199903022312.SAA16019@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7259) I-D ACTION:draft-ietf-ipngwg-jumbograms-00.txt Date: Tue, 02 Mar 1999 18:12:41 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: eec920e777675ca4b9b7962050666477 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 Jumbograms Author(s) : D. Borman, S. Deering, B. Hinden Filename : draft-ietf-ipngwg-jumbograms-00.txt Pages : 8 Date : 01-Mar-99 A 'jumbogram' is an IPv6 packet containing a payload longer than 65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-jumbograms-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990301131510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-jumbograms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990301131510.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 2 21:37:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA20236 for ipng-dist; Tue, 2 Mar 1999 21:26:42 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20229 for ; Tue, 2 Mar 1999 21:26:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id VAA00553 for ; Tue, 2 Mar 1999 21:26:30 -0800 (PST) Received: from delcluster1.vsnl.net.in (del3.vsnl.net.in [202.54.96.4]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA06258 for ; Tue, 2 Mar 1999 21:26:27 -0800 (PST) Received: from mailserver ([202.54.106.237]) by delcluster1.vsnl.net.in (8.9.2/8.9.2) with SMTP id KAA19862 for ; Wed, 3 Mar 1999 10:56:26 -0500 (GMT) Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for at Wed, 3 Mar 99 10:44:56 +0530 Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id RAA24175 for ; Tue, 2 Mar 1999 17:03:11 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id RAA14777; Tue, 2 Mar 1999 17:00:33 -0800 (PST) Received: by ietf.org (8.9.1a/8.9.1a) id TAA22075 for ietf-123-outbound.02@ietf.org; Tue, 2 Mar 1999 19:55:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15873; Tue, 2 Mar 1999 18:10:53 -0500 (EST) Message-Id: <199903022310.SAA15873@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@bisquare.com; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7258) I-D ACTION:draft-ietf-ipngwg-router-renum-08.txt Date: Tue, 02 Mar 1999 18:10:52 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: d551d02f93d022928e11fc4bdbb4e982 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. Note: This revision reflects comments received during the last call period. Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-08.txt Pages : 30 Date : 01-Mar-99 IPv6 Neighbor Discovery and Address Autoconfiguration 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-router-renum-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990301124654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990301124654.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 Mar 3 04:17:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA20610 for ipng-dist; Wed, 3 Mar 1999 04:10:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20603 for ; Wed, 3 Mar 1999 04:09:57 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id EAA16873 for ; Wed, 3 Mar 1999 04:09:54 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA02188 for ; Wed, 3 Mar 1999 04:09:55 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id VAA14561; Wed, 3 Mar 1999 21:04:23 +0900 (JST) Date: Wed, 03 Mar 1999 21:09:50 +0900 Message-ID: <14045.9870.431608.65113P@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7261) lifetime in router renumbering messages User-Agent: Wanderlust/0.9.6 (Dirty Diana) Emacs/20.3 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.2 - "Mikawa") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We are now implementing router renumbering in the KAME project and have a question about how to use lifetime fields in router renumbering messages. There are two lifetime fields in a use-prefix part; Valid Lifetime and Preferred Lifetime. For these fields, the specification says as follows. Additional information for each Use-Prefix is included in the Prefix Control Operation: the valid and preferred lifetimes to be included in Router Advertisement Prefix Information Options [ND], and either the L and A flags for the same option, or an indication that they are to be copied from the prefix that matched the Match-Prefix. It seems that the specification only says that how these fields are used in corresponding Router Advertisements, but do the lifetimes have an effect on a router which receives router renumbering messages? For example, should a router decrement the lifetime and delete the corresponding prefix when the lifetime expired? Or should the router just copy the lifetime to the corresponding field of succeeding router advertisement messages (and should not apply the lifetimes to its own prefixes)? Or is the semantics completely implementation dependent? IMO, the specification does not intend that a router use the lifetimes for its own prefixes and addresses. However, it may be convenient since we can omit RR messages that cause explicit deletion. We would like to know whether it is allowed or not. Thanks in advance, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 3 09:20:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA20978 for ipng-dist; Wed, 3 Mar 1999 09:10:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20971 for ; Wed, 3 Mar 1999 09:10:27 -0800 (PST) Received: from saturn2.Sun.COM (saturn2.EBay.Sun.COM [129.150.69.18]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id JAA00433; Wed, 3 Mar 1999 09:10:25 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn2.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02178 for ; Wed, 3 Mar 1999 09:10:23 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id MAA19503 for ; Wed, 3 Mar 1999 12:10:19 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000016769; Wed, 3 Mar 1999 12:10:17 -0500 (EST) From: Jim Bound Message-Id: <199903031710.MAA0000016769@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 7262) Updates to DHCPv6 fyi Date: Wed, 03 Mar 1999 12:10:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If any can get Charlie and I a review on this to wrap this up to get to PS it would be appreciated. thanks /jim ------- Forwarded Message Return-Path: dhcp-v6@bucknell.edu Received: from rock.zk3.dec.com by mailhub1.zk3.dec.com (5.65v4.0/1.1.10.5/24Sep96-0323PM) id AA26720; Tue, 2 Mar 1999 16:58:56 -0500 Received: from mail11.digital.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000016483; Tue, 2 Mar 1999 16:58:53 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by mail11.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id QAA08967; Tue, 2 Mar 1999 16:59:15 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id QAA31581; Tue, 2 Mar 1999 16:48:50 -0500 (EST) Date: Tue, 2 Mar 1999 16:48:50 -0500 (EST) Message-Id: <199903021954.OAA0000008086@quarry.zk3.dec.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Jim Bound To: Multiple recipients of list Subject: DHCPv6/Extsv6 Resolution Status of Last Call Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. The new specs are on the IETF ID dir. draft-ietf-dhc-dhcpv6-14.txt draft-ietf-dhc-v6exts-11.txt Here are the resolutions to the Last Call comments previously sent out to the list. Some as noted we can discuss at Minneapolis or on the mail list. Please send comments to this list even if only to say these are fine and should move forward to IETF last call. We need acks on the list. thanks /jim >* Use of exponential backoff in retransmission Fixed. See section 8 REPLY_MSG_TIMEOUT. >* Replace "S", "L" and "D" bits with the "R" bit for "relayed > packet" to distinguish the cases where a transaction went through a > relay agent vs. direct communication Authors did not change these mail was sent to the working group explaining why. See dhcpv6 mail entitled in the archives. Bits set where Relay is Noted "S", "L", and "D" >* Use of arbitrary source port versus use of ports 546-547 as source ports Authors left the source port arbitrary as to not do so has no benefit or pain to the protocol, and hence a restriction should not be done. See dhcpv6 mail entitled in the archives. Use of arbitrary source port versus use of ports 546-547 as source port >* Numbering of status/error codes Authors left status/errors as is to permit grouping. >* Uniqueness of link-local address and applicability as key value for client > identification Fixed. See sections 4.1, 5.1, 5.2, 6.0 >* Specification of MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY to constrain >random delay in backoff mechanism The authors did not change these and we feel they are important to delay the nodes sending solicitations. >* Requirement that RELEASE message go to the original server, with the > implication that the client retain information about the source of > configuration information Fixed. See 5.1, 5.6. We state the client needs to recall the original server in essence but do not mandate it. May need more discussion. >* Semantics of RECONFIGURE message - is the RECONFIGURE message a trigger for > the client to recontact the server, or does the RECONFIGURE message carry > information that the client can ACK to the server? >* Specifics of RECONFIGURE retransmission - does the client respond to every > retransmitted RECONFIGURE or just the first transmission? >* Specifics of RECONFIGURE processing in client - does the client copy the > transaction-ID from the RECONFIGURE message or choose a new transaction-ID > in its response to the server? Fixed and expounded on for clarity and added fix for multicast. See 4.6, 5.4, 5.7, 6.5, 8.0. >* Requirement that servers include random delay in sending DHCP Advertise > messages Authors did not change this and kept the requirement as to not second guess the market as to the number of servers used within a site. >* Should the spec include definition of equivalent for T1/T2 from DHCPv4 or > base renewal timing on IPv6 addrconf timers? We state the client SHOULD request and address before it is deprectated. See 3.1.1. At this time we leave how that is done up to the client. >* Dynamic DNS and DHCPv6 - does the 'A' bit imply an FQDN extension; is the > 'P' bit necessary or is the PTR record always the responsibility of the > server? Fixed. Added words in extv6 spec that the default should be client updates AAAA records and server updates PTR records. See section 3. >* Description of "prefix-size" field in header Fixed. See section 3. >* Should the server wait for DNS updates before replying to the client? The server should do this based on the period that is normal for waiting but if the DNS server does not respond we have stated the DHCPv6 server should REJECT the clients Request. See 3.2.3. We cannot mandate what is the threshold for the DNS subsystem in DHCPv6. >* Should the client adjust address lifetimes from the server to account for > transmission delays? This was deleted per the request in 3.1.1. >* Potential denial of service attack through receipt of address with zero > lifetime Discussion. We want to discuss with the WG further. We believe we should not permit this DOS but want to discuss it. In section 3.1.3 text replacement could be as follows: *** Upon reception of a new IP address with a lifetime, the client MUST perform Duplicate Address Detection (DAD) [23]; however, if the renewing the lifetime of the address, the client does not have to perform DAD each time. If the client receives an IP address with zero valid lifetime, the client MUST immediately discontinue using that IP address. *** === Upon reception of a new IP address with a lifetime, the client MUST perform Duplicate Address Detection (DAD) [23]; however, if the renewing the lifetime of the address, the client does not have to perform DAD each time. Processing of address and liftimes MUST be done as defined in Statless Address Configuration for IPv6 [23]. How and if a client differentiates DHCPv6 addresses from Stateless Addresses is implementation defined. === >* Definition of SPI values - same as in IPSec? We now reference the assigned numbers and believe using what IPsec uses is valid. But this may need some more clarification. Changes for dhcpv6 - Fixed grammatical and clarity problems. - Added saved agent-address field to the solicit message and altered and enhanced references to the C bit use. - Removed all references of agent-address prefix as it is implied by the agent-address and can be used as such by implementors. - Verified all binding dependencies use the link-local address and agent-address. - Added clients in what cases SHOULD retain specific addresses when the client is not stationary. - Updated DHCP terminology section and re-ordered. - Put RFC 2119 terms in lower case, in section 3.1. - Changed definition of transaction-ID and specified ranges for client and server use. - Added and fixed text to clarify use of Reconfigure message for clients in all relevant sections. - Added words in spec to differentiate format section from processing section. - Added retransmission algorithm for Reconfigure multicast messages and new configuration parameter. - Differentiated processing for requests by clients when received from Reconfigure message. - Added more words when binding cache is used for XID timeout. - Added exponential backoff to client retransmissions. - Updated the references section. Changes for extv6. - Made clarity and grammatical fixes. - Removed statements in client section and moved to server section. - Added prefix description to IP address extension. - Changed dhcpv6 msg size for pmtu from 1500 to 1280. - Added default processing for dynamic updates to DNS. - Removed requirement for random delay of the network. - Added new reconfigure multicast parameter. ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 3 20:47:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA21536 for ipng-dist; Wed, 3 Mar 1999 20:35:25 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21529 for ; Wed, 3 Mar 1999 20:35:12 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA26282; Wed, 3 Mar 1999 20:35:09 -0800 (PST) Date: Wed, 3 Mar 1999 20:33:41 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7263) Re: (mobile-ip) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard To: Richard Draves Cc: "'Mobile IP'" , "'IPsec'" , "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81E28@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My first email on this subject suggested that a correspondent node should > perform outbound IPsec processing twice: first looking up a security policy > using the home address as the destination address selector and applying the > resulting security associations, and then doing another security policy > database lookup using the care-of address as the destination address > selector and applying the additional security associations. Let me try to add some more complexity to the brew: When two mobile nodes communicate there are actually 4 IP addresses in use since each of them have a care-of-address and a home address. Does that mean you need to do 4 SPD lookups for the 4 combinations of source and destination? Source home address -> Destination home address Source home address -> Destination COA Source COA -> Destination home address Source COA -> Destination COA What about the case when the correspondent doesn't have a binding cache entries - perhaps due to transient behavior (the first few packets) or perhaps due to the mobile wanting location privacy. Does the policy have to be coordinated between the correspondent host and the home agent that will tunnel the packet in those cases? What about when the CH and the HA are part of different admin domains? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 4 01:01:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA21913 for ipng-dist; Thu, 4 Mar 1999 00:50:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21906 for ; Thu, 4 Mar 1999 00:50:47 -0800 (PST) From: bound@zk3.dec.com Received: from saturn2.Sun.COM (saturn2.EBay.Sun.COM [129.150.69.18]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id AAA10295 for ; Thu, 4 Mar 1999 00:50:46 -0800 (PST) Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by saturn2.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10417 for ; Thu, 4 Mar 1999 00:50:45 -0800 (PST) Received: from [195.99.53.91] (helo=thss-barney.THSS-BARNEY) by tantalum with esmtp (Exim 2.05 #1) id 10ITq5-0001gN-00 for ipng@sunroof.Eng.Sun.COM; Thu, 4 Mar 1999 08:50:41 +0000 Received: from THSS-1-SUP-1 by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id F3AG93BG; Thu, 4 Mar 1999 08:51:20 -0000 Message-Id: Date: Thu, 4 Mar 1999 08:50:41 +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.Eng.Sun.COM Thu Mar 04 03:10:50 1999 Received: from [193.113.210.238] (helo=mail2.) by carbon with smtp (Exim 2.05 #1) id 10IOX9-0005Td-00 for nbc@btinternet.com; Thu, 4 Mar 1999 03:10:47 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id RAA08776; Wed, 3 Mar 1999 17:30:39 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP); Wed, 3 Mar 1999 17:30:37 +0000 Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA06508; Wed, 3 Mar 1999 09:27:53 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id JAA07518; Wed, 3 Mar 1999 09:27:42 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA20978 for ipng-dist; Wed, 3 Mar 1999 09:10:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20971 for ; Wed, 3 Mar 1999 09:10:27 -0800 (PST) Received: from saturn2.Sun.COM (saturn2.EBay.Sun.COM [129.150.69.18]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id JAA00433; Wed, 3 Mar 1999 09:10:25 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn2.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02178 for ; Wed, 3 Mar 1999 09:10:23 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id MAA19503 for ; Wed, 3 Mar 1999 12:10:19 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000016769; Wed, 3 Mar 1999 12:10:17 -0500 (EST) From: Jim Bound Message-Id: <199903031710.MAA0000016769@quarry.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 7262) Updates to DHCPv6 fyi Date: Wed, 03 Mar 1999 12:10:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk If any can get Charlie and I a review on this to wrap this up to get to PS it would be appreciated. thanks /jim ------- Forwarded Message Return-Path: dhcp-v6@bucknell.edu Received: from rock.zk3.dec.com by mailhub1.zk3.dec.com (5.65v4.0/1.1.10.5/24Sep96-0323PM) id AA26720; Tue, 2 Mar 1999 16:58:56 -0500 Received: from mail11.digital.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000016483; Tue, 2 Mar 1999 16:58:53 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by mail11.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id QAA08967; Tue, 2 Mar 1999 16:59:15 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.2/8.9.2) with SMTP id QAA31581; Tue, 2 Mar 1999 16:48:50 -0500 (EST) Date: Tue, 2 Mar 1999 16:48:50 -0500 (EST) Message-Id: <199903021954.OAA0000008086@quarry.zk3.dec.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Jim Bound To: Multiple recipients of list Subject: DHCPv6/Extsv6 Resolution Status of Last Call Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. The new specs are on the IETF ID dir. draft-ietf-dhc-dhcpv6-14.txt draft-ietf-dhc-v6exts-11.txt Here are the resolutions to the Last Call comments previously sent out to the list. Some as noted we can discuss at Minneapolis or on the mail list. Please send comments to this list even if only to say these are fine and should move forward to IETF last call. We need acks on the list. thanks /jim >* Use of exponential backoff in retransmission Fixed. See section 8 REPLY_MSG_TIMEOUT. >* Replace "S", "L" and "D" bits with the "R" bit for "relayed > packet" to distinguish the cases where a transaction went through a > relay agent vs. direct communication Authors did not change these mail was sent to the working group explaining why. See dhcpv6 mail entitled in the archives. Bits set where Relay is Noted "S", "L", and "D" >* Use of arbitrary source port versus use of ports 546-547 as source ports Authors left the source port arbitrary as to not do so has no benefit or pain to the protocol, and hence a restriction should not be done. See dhcpv6 mail entitled in the archives. Use of arbitrary source port versus use of ports 546-547 as source port >* Numbering of status/error codes Authors left status/errors as is to permit grouping. >* Uniqueness of link-local address and applicability as key value for client > identification Fixed. See sections 4.1, 5.1, 5.2, 6.0 >* Specification of MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY to constrain >random delay in backoff mechanism The authors did not change these and we feel they are important to delay the nodes sending solicitations. >* Requirement that RELEASE message go to the original server, with the > implication that the client retain information about the source of > configuration information Fixed. See 5.1, 5.6. We state the client needs to recall the original server in essence but do not mandate it. May need more discussion. >* Semantics of RECONFIGURE message - is the RECONFIGURE message a trigger for > the client to recontact the server, or does the RECONFIGURE message carry > information that the client can ACK to the server? >* Specifics of RECONFIGURE retransmission - does the client respond to every > retransmitted RECONFIGURE or just the first transmission? >* Specifics of RECONFIGURE processing in client - does the client copy the > transaction-ID from the RECONFIGURE message or choose a new transaction-ID > in its response to the server? Fixed and expounded on for clarity and added fix for multicast. See 4.6, 5.4, 5.7, 6.5, 8.0. >* Requirement that servers include random delay in sending DHCP Advertise > messages Authors did not change this and kept the requirement as to not second guess the market as to the number of servers used within a site. >* Should the spec include definition of equivalent for T1/T2 from DHCPv4 or > base renewal timing on IPv6 addrconf timers? We state the client SHOULD request and address before it is deprectated. See 3.1.1. At this time we leave how that is done up to the client. >* Dynamic DNS and DHCPv6 - does the 'A' bit imply an FQDN extension; is the > 'P' bit necessary or is the PTR record always the responsibility of the > server? Fixed. Added words in extv6 spec that the default should be client updates AAAA records and server updates PTR records. See section 3. >* Description of "prefix-size" field in header Fixed. See section 3. >* Should the server wait for DNS updates before replying to the client? The server should do this based on the period that is normal for waiting but if the DNS server does not respond we have stated the DHCPv6 server should REJECT the clients Request. See 3.2.3. We cannot mandate what is the threshold for the DNS subsystem in DHCPv6. >* Should the client adjust address lifetimes from the server to account for > transmission delays? This was deleted per the request in 3.1.1. >* Potential denial of service attack through receipt of address with zero > lifetime Discussion. We want to discuss with the WG further. We believe we should not permit this DOS but want to discuss it. In section 3.1.3 text replacement could be as follows: *** Upon reception of a new IP address with a lifetime, the client MUST perform Duplicate Address Detection (DAD) [23]; however, if the renewing the lifetime of the address, the client does not have to perform DAD each time. If the client receives an IP address with zero valid lifetime, the client MUST immediately discontinue using that IP address. *** === Upon reception of a new IP address with a lifetime, the client MUST perform Duplicate Address Detection (DAD) [23]; however, if the renewing the lifetime of the address, the client does not have to perform DAD each time. Processing of address and liftimes MUST be done as defined in Statless Address Configuration for IPv6 [23]. How and if a client differentiates DHCPv6 addresses from Stateless Addresses is implementation defined. === >* Definition of SPI values - same as in IPSec? We now reference the assigned numbers and believe using what IPsec uses is valid. But this may need some more clarification. Changes for dhcpv6 - Fixed grammatical and clarity problems. - Added saved agent-address field to the solicit message and altered and enhanced references to the C bit use. - Removed all references of agent-address prefix as it is implied by the agent-address and can be used as such by implementors. - Verified all binding dependencies use the link-local address and agent-address. - Added clients in what cases SHOULD retain specific addresses when the client is not stationary. - Updated DHCP terminology section and re-ordered. - Put RFC 2119 terms in lower case, in section 3.1. - Changed definition of transaction-ID and specified ranges for client and server use. - Added and fixed text to clarify use of Reconfigure message for clients in all relevant sections. - Added words in spec to differentiate format section from processing section. - Added retransmission algorithm for Reconfigure multicast messages and new configuration parameter. - Differentiated processing for requests by clients when received from Reconfigure message. - Added more words when binding cache is used for XID timeout. - Added exponential backoff to client retransmissions. - Updated the references section. Changes for extv6. - Made clarity and grammatical fixes. - Removed statements in client section and moved to server section. - Added prefix description to IP address extension. - Changed dhcpv6 msg size for pmtu from 1500 to 1280. - Added default processing for dynamic updates to DNS. - Removed requirement for random delay of the network. - Added new reconfigure multicast parameter. ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 4 11:51:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA22391 for ipng-dist; Thu, 4 Mar 1999 11:44:38 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22384 for ; Thu, 4 Mar 1999 11:44:30 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id LAA11191 for ; Thu, 4 Mar 1999 11:44:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA05574 for ; Thu, 4 Mar 1999 11:44:28 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA05714; Thu, 4 Mar 1999 11:44:18 -0800 (PST) Message-Id: <3.0.5.32.19990304114347.038d64f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Mar 1999 11:43:47 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7264) Request for Agenda Items Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng working group will meet for two sessions at the Minneapolis IETF. The current sessions are: MONDAY, March 15, 1999 0930-1130 IPng WG 1st session 1930-2200 IPng WG 2nd session Please send Steve Deering and myself proposed agenda items including topic description and length of time required. Thanks, Bob Hinden / Steve Deering IPng Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 4 18:00:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA22744 for ipng-dist; Thu, 4 Mar 1999 17:44:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22737 for ; Thu, 4 Mar 1999 17:44:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id RAA00475 for ; Thu, 4 Mar 1999 17:44:37 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id RAA09165 for ; Thu, 4 Mar 1999 17:44:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21213; Thu, 4 Mar 1999 20:44:32 -0500 (EST) Message-Id: <199903050144.UAA21213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7267) I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-03.txt Date: Thu, 04 Mar 1999 20:44:27 -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 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-03.txt Pages : 6 Date : 03-Mar-99 This document describes an experimental protocol for asking an IPv6 node to supply certain network information, such as its fully- qualified domain name. IPv6 implementation experience has shown that direct queries for FQDN are useful, and a direct query mechanism for other information has been requested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990303124215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990303124215.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 4 21:08:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA22956 for ipng-dist; Thu, 4 Mar 1999 20:58:30 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22949 for ; Thu, 4 Mar 1999 20:58:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA10696 for ; Thu, 4 Mar 1999 20:58:19 -0800 (PST) Received: from delcluster1.vsnl.net.in (del3.vsnl.net.in [202.54.96.3]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id UAA22753 for ; Thu, 4 Mar 1999 20:58:08 -0800 (PST) Received: from mailserver ([202.54.106.196]) by delcluster1.vsnl.net.in (8.9.2/8.9.2) with SMTP id KAA12070 for ; Fri, 5 Mar 1999 10:28:06 -0500 (GMT) Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for at Fri, 5 Mar 99 10:01:09 +0570 Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id TAA28804 for ; Thu, 4 Mar 1999 19:54:58 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id TAA12728; Thu, 4 Mar 1999 19:53:09 -0800 (PST) Received: by ietf.org (8.9.1a/8.9.1a) id WAA01205 for ietf-123-outbound.02@ietf.org; Thu, 4 Mar 1999 22:45:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21213; Thu, 4 Mar 1999 20:44:32 -0500 (EST) Message-Id: <199903050144.UAA21213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@bisquare.com; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7268) I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-03.txt Date: Thu, 04 Mar 1999 20:44:27 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: b005561133395112adb516dc53d086c0 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 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-03.txt Pages : 6 Date : 03-Mar-99 This document describes an experimental protocol for asking an IPv6 node to supply certain network information, such as its fully- qualified domain name. IPv6 implementation experience has shown that direct queries for FQDN are useful, and a direct query mechanism for other information has been requested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990303124215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990303124215.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 00:17:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA23204 for ipng-dist; Fri, 5 Mar 1999 00:04:11 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23197 for ; Fri, 5 Mar 1999 00:03:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id AAA02012 for ; Fri, 5 Mar 1999 00:03:58 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id AAA19096; Fri, 5 Mar 1999 00:03:57 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.1W/3.7W) with ESMTP id RAA11802; Fri, 5 Mar 1999 17:03:20 +0900 (JST) To: narten@raleigh.ibm.com, nordmark@sun.com, Bill.Simpson@um.cc.umich.edu cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 7270) multicast NS without no source lladdr From: Jun-ichiro itojun Hagino Date: Fri, 05 Mar 1999 17:03:20 +0900 Message-ID: <11798.920621000@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The NDP spec (RFC2461) says that the sender of multicast NS MUST attach source link-layer address option to the NS packet. However, the NS validation rule on the receiver side does not reject such packet. I would like to understand the reason for the difference: - What is the reason for the difference? (1) Just an inconsistency (2) "be strict on what you send, be liberal on what you receive" - Which is the expected behavior for the receiver side, when it receives multicast NS packet *without* souce link-layer address option? A. reject the packet (more strict than spec) B. accept the packet, try sending new NS to the sender to get link-layer address (DoS attack possible by sending tons of multicast NS?) Thanks, itojun@kame.net --- sender side ======================================================================== 4.3. Neighbor Solicitation Message Format Source link-layer address The link-layer address for the sender. MUST NOT be included when the source IP address is the unspecified address. Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations. ======================================================================== receiver side ======================================================================== 7.1.1. Validation of Neighbor Solicitations A node MUST silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks: - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. - If the message includes an IP Authentication Header, the message authenticates correctly. - ICMP Checksum is valid. - ICMP Code is 0. - ICMP length (derived from the IP length) is 24 or more octets. - Target Address is not a multicast address. - All included options have a length that is greater than zero. - If the IP source address is the unspecified address, the IP destination address is a solicited-node multicast address. - If the IP source address is the unspecified address, there is no source link-layer address option in the message. ======================================================================== -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 01:25:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA23263 for ipng-dist; Fri, 5 Mar 1999 01:15:32 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23256 for ; Fri, 5 Mar 1999 01:15:19 -0800 (PST) From: hinden@iprg.nokia.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id BAA28112 for ; Fri, 5 Mar 1999 01:15:19 -0800 (PST) Received: from praseodumium (praseodumium.btinternet.com [194.73.73.82]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id BAA16625 for ; Fri, 5 Mar 1999 01:15:18 -0800 (PST) Received: from [195.99.43.224] (helo=thss-barney.THSS-BARNEY) by praseodumium with esmtp (Exim 2.05 #1) id 10Iqg5-0000I0-00 for ipng@sunroof.Eng.Sun.COM; Fri, 5 Mar 1999 09:13:54 +0000 Received: from THSS-1-SUP-1 by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id F3AG932X; Fri, 5 Mar 1999 09:15:45 -0000 Message-Id: Date: Fri, 5 Mar 1999 09:13:54 +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.Eng.Sun.COM Fri Mar 05 03:43:20 1999 Received: from [193.113.211.246] (helo=mailhub.btwebworld.com) by neodymium with smtp (Exim 2.05 #1) id 10IlWB-0001H6-00 for nbc@btinternet.com; Fri, 5 Mar 1999 03:43:19 +0000 Received: from mail.btwebworld.com by mailhub.btwebworld.com (SMI-8.6/SMI-SVR4) id TAA25405; Thu, 4 Mar 1999 19:56:04 GMT Received: by mail.btwebworld.com (SMI-8.6/SMI-SVR4) id TAA29035; Thu, 4 Mar 1999 19:55:23 GMT Received: from mercury.Sun.COM by mail.btwebworld.com with SMTP (XT-PP); Thu, 4 Mar 1999 19:55:21 +0000 Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA05621; Thu, 4 Mar 1999 11:55:41 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id LAA14632; Thu, 4 Mar 1999 11:55:34 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA22391 for ipng-dist; Thu, 4 Mar 1999 11:44:38 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22384 for ; Thu, 4 Mar 1999 11:44:30 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id LAA11191 for ; Thu, 4 Mar 1999 11:44:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA05574 for ; Thu, 4 Mar 1999 11:44:28 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA05714; Thu, 4 Mar 1999 11:44:18 -0800 (PST) Message-Id: <3.0.5.32.19990304114347.038d64f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Mar 1999 11:43:47 -0800 To: ipng@sunroof.Eng.Sun.COM From: Bob Hinden Subject: (IPng 7264) Request for Agenda Items Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IPng working group will meet for two sessions at the Minneapolis IETF. The current sessions are: MONDAY, March 15, 1999 0930-1130 IPng WG 1st session 1930-2200 IPng WG 2nd session Please send Steve Deering and myself proposed agenda items including topic description and length of time required. Thanks, Bob Hinden / Steve Deering IPng Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 02:27:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA23322 for ipng-dist; Fri, 5 Mar 1999 02:19:07 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23315 for ; Fri, 5 Mar 1999 02:18:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA04535 for ; Fri, 5 Mar 1999 02:18:57 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id CAA06319 for ; Fri, 5 Mar 1999 02:18:54 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id KA01362; Fri, 5 Mar 1999 21:18:40 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7271) draft-ietf-ipngwg-icmp-name-lookups-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Mar 1999 21:18:40 +1100 Message-Id: <4183.920629120@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few nits ... In section 4 .. If the Queried Address was anycast, the source adderss for the Reply should be one belonging to the interface on which the Query was received. Is it not possible for a request to be sent to an anycast address and arrive via an interface which has no address of its own (or have we deprecated addressless interfaces in IPv6 and I just failed to notice) ? In section 5.3 .. FQDN The fully-qualified domain name of the Responder which corresponds to the Queried Address, as a sequence of NameLen US-ASCII octets, with periods between the labels, and no period after the last label. That's inadequate. First, there is a (very slow, perhaps almost comatose) gradual motion towards UTF-8 being allowed for names. US-ASCII is a retrograde step here (further, there doesn't seem to be any real reason for that). Second, whether the name is restricted to ascii or not, using periods as separators limits the names more than the DNS does. There are three conceivable solutions to this one ... limit the names even more, by prohibiting '.' as a character in a label (the DNS does not do that), add an escaping mechanism (the way the DNS does in text files) to allow the '.' to appear (and the escape character itself as well of course) as a literal, rather than as a separator (or escape). Doing that would mean that an 8 bit length field would be inadequate though, at least 8 bits would be required to cope with the worst case. Or, simply encode the name the way the DNS encodes names (ignoring DNS name compression), as a series of length counted labels (with count bytes replacing the dots, more or less). I prefer the third, it is by far the cleanest way. I am not sure I quite believe that the TTL field in the FQDN query is quite being used the right way. The TTL of an address->name binding doesn't necessarily have much at all to do with the TTL of the associated name->address binding, much less the TTL on a lease granting that address to a particlar need. (Sure, in some, perhaps even many, cases they're related, but not by necessity). At the very least I'd like to see some kind of justification for the TTL definition being the way it is. Last in 5.3.1.1 (which I would guess was really intended to be 5.4) .. T Defined in a Reply only, indicates that the set of addresses is inclomplete for space reasons. Is there to be any hint as to what "space reasons" might be sanely applied here? That is, is returning no addresses, and setting the T bit instead acceptable? Or is it intended that the T bit be set only when the reply would be greater than the max payload (65536 since I don't think we permit jumbogram ICMP messages)? Or perhaps it can/should be set if the reply would otherwise need to be fragmented? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 02:48:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA23345 for ipng-dist; Fri, 5 Mar 1999 02:38:53 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23338 for ; Fri, 5 Mar 1999 02:38:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id CAA01946 for ; Fri, 5 Mar 1999 02:38:44 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id CAA13232 for ; Fri, 5 Mar 1999 02:38:40 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id KA01193; Fri, 5 Mar 1999 21:38:29 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7272) Re: draft-ietf-ipngwg-icmp-name-lookups-03.txt In-Reply-To: Your message of "Fri, 05 Mar 1999 21:18:40 +1100." <4183.920629120@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Mar 1999 21:38:28 +1100 Message-Id: <4258.920630308@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A couple of typos in my message... | as a literal, rather than as a separator (or escape). Doing that would | mean that an 8 bit length field would be inadequate though, at least 8 | bits would be required to cope with the worst case. Which should read, of course ... as a literal, rather than as a separator (or escape). Doing that would mean that an 8 bit length field would be inadequate though, at least 9 bits would be required to cope with the worst case. And ... | The TTL of an address->name binding doesn't necessarily have much at | all to do with the TTL of the associated name->address binding, much | less the TTL on a lease granting that address to a particlar need. "to a particular node"... (sigh). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 02:48:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA23363 for ipng-dist; Fri, 5 Mar 1999 02:46:13 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23347; Fri, 5 Mar 1999 02:45:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA06112; Fri, 5 Mar 1999 02:45:52 -0800 (PST) Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id CAA16122; Fri, 5 Mar 1999 02:45:51 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA15754; Fri, 5 Mar 1999 10:46:58 GMT Received: from slip139-92-190-229.wak.uk.ibm.net [139.92.190.229] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Fri Mar 05 10:46 GMT 1999 Message-Id: <3.0.3.32.19990305102021.00805990@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 05 Mar 1999 10:20:21 +0000 To: xnet@opengroup.org From: Chris Harding Subject: (IPng 7273) Ipv6 Migration Cc: ipng@sunroof.eng.sun.com, deployment@ipv6.org, ngtrans@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - I had a thought about the API that may be "off the wall" but that could enable existing applications to work with IPv6 with no change whatsoever. The advantages of this for v6 deployment would be enormous. It does not affect the IPv6 extensions to sockets, or the recommendation that new applications should use them in order to make use of IPv6 features. It is simply a change of behavior of the core API in the presense of IPv6. This is how it would operate. 1. Application calls gethostbyname() to look up a host address. 2. gethostbyname() invokes DNS and finds an IPv6 address. 3. gethostbyname() allocates an IPv4 address from a pool kept for this purpose, sets up a mapping between the v4 address and the v6 address obtained from DNS, and returns the v4 address to the application. 4. Application does its stuff, making sockets calls from time to time. 5. Sockets calls recognise the v4 address as being from the pool, and communicate via IPv6 to the v6 address to which the v4 address is mapped, instead of using v4. 6. When an application binds to a v4 address from the pool, subsequent sockets calls do a similar v4-v6 translation. This doesn't actually require standardization. An individual vendor who obtained a block of IPv4 addresses could do it without consulting anyone else. But there could be advantages in allocating a single block of IPv4 addresses for everyone to use in this way. The questions are: Will this work? Should it be required behavior for conforming UNIX implementations? Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 03:07:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA23410 for ipng-dist; Fri, 5 Mar 1999 03:00:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23384; Fri, 5 Mar 1999 02:57:04 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA10930; Fri, 5 Mar 1999 02:57:02 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id CAA20610; Fri, 5 Mar 1999 02:57:02 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.1W/3.7W/smtpfeed 0.93) with ESMTP id TAA14055; Fri, 5 Mar 1999 19:56:52 +0900 (JST) To: Chris Harding cc: xnet@opengroup.org, ipng@sunroof.eng.sun.com, deployment@ipv6.org, ngtrans@sunroof.eng.sun.com In-reply-to: c.harding's message of Fri, 05 Mar 1999 10:20:21 GMT. <3.0.3.32.19990305102021.00805990@mailhome.rdg.opengroup.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 7274) Re: Ipv6 Migration From: Jun-ichiro itojun Hagino Date: Fri, 05 Mar 1999 19:56:51 +0900 Message-ID: <14051.920631411@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I had a thought about the API that may be "off the wall" but that could >enable existing applications to work with IPv6 with no change whatsoever. >The advantages of this for v6 deployment would be enormous. (snip) >It does not affect the IPv6 extensions to sockets, or the recommendation >that new applications should use them in order to make use of IPv6 >features. It is simply a change of behavior of the core API in the presense >of IPv6. I believe someone can implement fake libc to implement your idea. Also I would like to note that the approach is similar to draft-tsuchiya-ipv4-ipv6-translator-00. (worth a look) >The questions are: > Will this work? > Should it be required behavior for conforming UNIX implementations? I believe this will work, but I think we do not need to/want to mandate this. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 06:15:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA23671 for ipng-dist; Fri, 5 Mar 1999 06:04:17 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23655; Fri, 5 Mar 1999 06:03:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id GAA24714; Fri, 5 Mar 1999 06:03:54 -0800 (PST) Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id GAA18157; Fri, 5 Mar 1999 06:03:52 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA00641; Fri, 5 Mar 1999 14:04:56 GMT Received: from slip139-92-21-78.lo.uk.ibm.net [139.92.21.78] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Fri Mar 05 14:04 GMT 1999 Message-Id: <3.0.3.32.19990305135158.0088e300@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 05 Mar 1999 13:51:58 +0000 To: itojun@iijlab.net From: Chris Harding Subject: (IPng 7275) Re: Ipv6 Migration Cc: ipng@sunroof.eng.sun.com, deployment@ipv6.org, ngtrans@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Itojun, > >>I had a thought about the API that may be "off the wall" but that could >>enable existing applications to work with IPv6 with no change whatsoever. >>The advantages of this for v6 deployment would be enormous. >(snip) >>It does not affect the IPv6 extensions to sockets, or the recommendation >>that new applications should use them in order to make use of IPv6 >>features. It is simply a change of behavior of the core API in the presense >>of IPv6. > > I believe someone can implement fake libc to implement your idea. > > Also I would like to note that the approach is similar to > draft-tsuchiya-ipv4-ipv6-translator-00. (worth a look) > Yes there is similarity - thanks for the pointer! The big difference is that this approach is implemented in the host, not in a gateway or router. The host is an IPv6 host, so we are talking about IPv4 applications in an IPv6 host, not about an IPv4 host in an IPv6 ocean. The address mapper and translator functions needed in the host would be similar to the ones described in draft-tsuchiya-ipv4-ipv6-translator-00. Other points are that - there is no impact on DNS - since this is all done in the host, IPSEC can still work. >>The questions are: >> Will this work? >> Should it be required behavior for conforming UNIX implementations? > > I believe this will work, but I think we do not need to/want to > mandate this. > The benefit of making it a requirement is that users who buy a UNIX-branded system will know that their existing applications are guaranteed to work with IPv6. Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 06:15:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA23681 for ipng-dist; Fri, 5 Mar 1999 06:14:04 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23674; Fri, 5 Mar 1999 06:13:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id GAA12837; Fri, 5 Mar 1999 06:13:53 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id GAA22006; Fri, 5 Mar 1999 06:13:51 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id JAA32101; Fri, 5 Mar 1999 09:13:50 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000031969; Fri, 5 Mar 1999 09:13:49 -0500 (EST) From: Jim Bound Message-Id: <199903051413.JAA0000031969@quarry.zk3.dec.com> To: Chris Harding cc: xnet@opengroup.org, ipng@sunroof.eng.sun.com, deployment@ipv6.org, ngtrans@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 7276) Re: Ipv6 Migration In-reply-to: Your message of "Fri, 05 Mar 1999 10:20:21 GMT." <3.0.3.32.19990305102021.00805990@mailhome.rdg.opengroup.org> Date: Fri, 05 Mar 1999 09:13:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Chris, I am responding to all lists. But we should pick one list. I suggest as its brainstorming about implementation it can be done on deployment list. Then if something happens we then should run logic check by the implementors list. Then if it is still moving forward go to IETF list or in this case maybe the XNET list. As a suggestion for future stuff from anyone. But if we all use all these lists all the time and for the folks on every list it creates a mail storm. Sorry for contributing to this mail storm but the idea has been put out and I got something to say about it. >I had a thought about the API that may be "off the wall" but that could >enable existing applications to work with IPv6 with no change whatsoever. Many of us have thought about this and several of the ngtrans proposals assume such an API as Itojun already responded for one of them. I think??? In your thought your assuming the platform has an IPv6 stack on it though. That should be stated otherwise it gets very intense and IPv4 needs magic cookies and such and I don't think that will ever work IMO and perform. >The advantages of this for v6 deployment would be enormous. It depends on the costs and performance hit. One thing customers have made loud and clear to me is "DO NOT AFFECT THE PERFORMANCE OF MY IPV4 STACK with your IPV6 STACK APPROACH". I don't know about other vendors but Compaq is working real hard to make IPv6 transparent to IPv4 ONLY applications. When one adds extra conditions, 16 bytes to data structures, extra code path for IPv6, etc... you can negatively impact the IPv4 environment by what we call the death of a thousand cuts. So we need to keep a heads up when we discuss such thoughts as your proposing. And probably why this cannot be mandated; as Itojun as replied and I agree with him. I will point out that transition has some of the same issues and properties and why standardizing transition tools will be tricky and the term "implementation defined" will have to be maintained in many of those specs and if going to standards track the IESG will have to live with implementation defined statements in ALL transition specs at this time. >It does not affect the IPv6 extensions to sockets, or the recommendation >that new applications should use them in order to make use of IPv6 >features. It is simply a change of behavior of the core API in the presense >of IPv6. When you say the core API what do you mean? I think in this case the resolver set of libraries. I don't know if you looked at BIND lately as one example but in that code base is not what I would call a core API but a set of access methods and routines to do DNS processing on a client type platform. We are trying to get some things standard working with ISC now via a group of us vendors with bindworkers as a logic check but I don't think there is a core API below gethostbyname which is really nothing more than a lib call into BIND. Also for Microsoft and other vendors that don't use BIND I assume have the same issue to support DNS lookups? >This is how it would operate. >1. Application calls gethostbyname() to look up a host address. > >2. gethostbyname() invokes DNS and finds an IPv6 address. gethostbyname has no present code base behind it (from the discussion above) to handle getting IPv6 addresses back into the struct hostent data structure. This is why we did the base API initially 4-5 years ago as one sticky for its incarnation. So your statement above implies a lot of work that is not stated and I would claim is overlaying gethostbyname to really become getipnodebyname in the implementation. That is overhead for IPv4 apps if IPv6 is not being used in that instance. But I realize your just presenting a taxonomy at this point. >3. gethostbyname() allocates an IPv4 address from a pool kept for this >purpose, sets up a mapping between the v4 address and the v6 address >obtained from DNS, and returns the v4 address to the application. Now we are adding lots of new state to gethostbyname and it will cost and a translation table in the resolver for client DNS for IPv4 that will cost too. Also why wouldn't an application just want to use IPv6 that is the whole point? And other cases need to be defined. >4. Application does its stuff, making sockets calls from time to time. This is just to vague for me to comment on or parse. I am all for implementation defined statements but I need to know at least what the end result is to be. >5. Sockets calls recognise the v4 address as being from the pool, and >communicate via IPv6 to the v6 address to which the v4 address is mapped, >instead of using v4. Given that this mapping can work and I am not sure it can without a significant performance hit. This has to be done in most implementations kernel now and the resolver so you have left the application space and now in kernel space. So the pool is now in the kernel too really (its duplicated in the resolver and the kernel) and before the TCP/IP processing starts the code uses v6 addresses out the stack and on incoming converts them to v4. This is exactly what has been proposed in serveral ngtrans specs and I suggest you read all those specs. But this is a performance hit and I don't believe anyway to get aggreement to standardize it. We will face this in ngtrans for those specs I predict once they are scrutinized to that level of detail. >6. When an application binds to a v4 address from the pool, subsequent >sockets calls do a similar v4-v6 translation. Exactly as I said before. Now we are putting translation in our kernels and why I don't think this is a good idea in the "normative" case and why I am not real hot on the ngtrans specs that do this either and very suspect they can be standardized in a meaningful way. The IETF did not tell me how to implement IP, TCP, etc. and I am sure they are not going to tell me how to implement a transition tool, which is what I think your suggesting. >This doesn't actually require standardization. An individual vendor who >obtained a block of IPv4 addresses could do it without consulting anyone >else. I agree we don't need a standard to do neat and tricky things to make our platforms work well in the storm of transition. But I doubt any of us vendors will ship a stack that reduces the performance of IPv4 in any way. It took a lot of work to get 16bytes to not burn us and it is suspect to add more to the barrel of engineering we all must do to get IPv6 out the door and be able to state it is "production" quality. >But there could be advantages in allocating a single block of IPv4 >addresses for everyone to use in this way. I disagree. With the depletion of IPv4 addresses this is not going to fly with any formal address registrys or with customers. I faced this in AIIH trans mechanism and why I provide all addresses to nodes in the transition scenario dynamically. >The questions are: > Will this work? Heck Chris many of us on these lists could make anything work as engineers and programmers the question I think that should be asked is (and for many of the transition specs): Will this work at a reasonable performance cost and scale for large servers and distributed node sets (e.g. clusters, Large MP machines) [Routers too but I don't think Routers are concerend about the case Chris is presenting]. That I can answer. NO. IPv4 performance will be reduced and IPv6 performance will not reach its optimum level. THEN: But do you want to do it anyway if the above answer is NO. It depends and a vendor could add it as a layered product with all the health warnings on performance, if a customer wanted it. I also don't think this needs to be interoperable or portable if it was done. Which leads me to believe it may be work for the deployment and implementors list to parse and not a standards body. > Should it be required behavior for conforming UNIX implementations? Absolutely NOT NOT NOT NOT. For all the reasons I stated above. And besides IPv6 cannot be a UNIX only thing for anything we work on IMO. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 06:32:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA23744 for ipng-dist; Fri, 5 Mar 1999 06:22:32 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23737; Fri, 5 Mar 1999 06:22:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id GAA13779; Fri, 5 Mar 1999 06:22:23 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id GAA26031; Fri, 5 Mar 1999 06:22:19 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id JAA10230; Fri, 5 Mar 1999 09:23:15 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000001028; Fri, 5 Mar 1999 09:22:16 -0500 (EST) From: Jim Bound Message-Id: <199903051422.JAA0000001028@quarry.zk3.dec.com> To: Chris Harding cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com, deployment@ipv6.org, ngtrans@sunroof.eng.sun.com Subject: (IPng 7277) Re: Ipv6 Migration In-reply-to: Your message of "Fri, 05 Mar 1999 13:51:58 GMT." <3.0.3.32.19990305135158.0088e300@mailhome.rdg.opengroup.org> Date: Fri, 05 Mar 1999 09:22:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Forget this UNIX branded stuff. I don't want to get into it but there is a lot more potential IPv6 users using something other than UNIX. And UNIX is becoming extinct on the desk top. Linux might prevail though. Are you trying to find more work for TOG or something? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 07:30:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23863 for ipng-dist; Fri, 5 Mar 1999 07:22:29 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23856 for ; Fri, 5 Mar 1999 07:22:20 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id HAA18567 for ; Fri, 5 Mar 1999 07:22:20 -0800 (PST) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA01754 for ; Fri, 5 Mar 1999 07:22:16 -0800 (PST) Received: (qmail 16044 invoked from network); 5 Mar 1999 15:22:12 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 5 Mar 1999 15:22:12 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA00562; Fri, 5 Mar 1999 10:22:11 -0500 (EST) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.0/8.9.0) with SMTP id KAA01696; Fri, 5 Mar 1999 10:22:09 -0500 (EST) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Fri, 5 Mar 1999 10:22:08 -0500 (EST) From: Shane Kerr X-Sender: kerr@sunshine Reply-To: Shane Kerr To: Jim Bound cc: Chris Harding , ipng@sunroof.eng.sun.com, deployment@ipv6.org Subject: (IPng 7278) Re: Ipv6 Migration In-Reply-To: <199903051413.JAA0000031969@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 5 Mar 1999, Jim Bound wrote: > I am responding to all lists. But we should pick one list. I suggest > as its brainstorming about implementation it can be done on deployment list. I've reduced the set to deployment and IETF (since I'm only on the IETF list). > >The advantages of this for v6 deployment would be enormous. > > It depends on the costs and performance hit. One thing customers have > made loud and clear to me is "DO NOT AFFECT THE PERFORMANCE OF MY IPV4 > STACK with your IPV6 STACK APPROACH". I don't know about other vendors > but Compaq is working real hard to make IPv6 transparent to IPv4 ONLY > applications. When one adds extra conditions, 16 bytes to data > structures, extra code path for IPv6, etc... you can negatively impact > the IPv4 environment by what we call the death of a thousand cuts. So > we need to keep a heads up when we discuss such thoughts as your proposing. > And probably why this cannot be mandated; as Itojun as replied and I agree > with him. I think you overestimate the cost of performace to the IPv4 stack. It seems to me that what Mr. Harding proposed would only affect a small set of the socket API calls, and those that are performace critical almost not at all. Basically we're talking about adding a translation layer between any functions that return an address to the application, such as gethost...(), accept(), and recvmsg(), and functions that require an address from the application, such as bind(), connect(), sendmsg(). For the vast majority of applications, this is going to mean a few cycles (certainly less than 100 microseconds) of extra processing time assuming worst case (meaning translation required). For most applications (those that use TCP, like HTTP, FTP, telnet, mail, etc.), this is going to occur only at connection setup and breakdown. The read() and write() calls don't need to be translated! For performance critical (mostly server-side) applications, I would recommend linking with seperate IPv4 and IPv6 interfaces, as is done today. Where performance IS going to hit the application is if it is connectionless, as in a UDP-based application. This would affect things like NTP and some high-performance cluster software (MPI, PVM, etc.). Having to do a translation on every send or receive would certainly be meaningful for large numbers of packets. Another potential problem set is embedded applications, who really can't afford the extra 2 Kbyte or so for a table. In either of these cases, rewrite the code or live without IPv6 - Mr. Harding has proposed what I think is a neat-o keen alternative, which eases integration, not complicates it! > And besides IPv6 cannot be a UNIX only thing for anything we work on > IMO. One problem that I see with this methodology is that it requires either every application to be re-linked with a library that supports the mapping, or that the operating system support it and perform the translation before it hits the applications. Not an impassable hurdle, but there it is, and it will almost certainly mean that it will happen on Unix systems before other platforms, simply because Unix folks are used to compiling their programs before installing them. -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 08:00:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24032 for ipng-dist; Fri, 5 Mar 1999 07:51:17 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24025 for ; Fri, 5 Mar 1999 07:51:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id HAA07161 for ; Fri, 5 Mar 1999 07:51:00 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id HAA12238 for ; Fri, 5 Mar 1999 07:49:55 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id KAA24366; Fri, 5 Mar 1999 10:49:40 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000021799; Fri, 5 Mar 1999 10:49:40 -0500 (EST) From: Jim Bound Message-Id: <199903051549.KAA0000021799@quarry.zk3.dec.com> To: Shane Kerr cc: Jim Bound , Chris Harding , ipng@sunroof.eng.sun.com, deployment@ipv6.org Subject: (IPng 7279) Re: Ipv6 Migration In-reply-to: Your message of "Fri, 05 Mar 1999 10:22:08 EST." Date: Fri, 05 Mar 1999 10:49:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> It depends on the costs and performance hit. One thing customers have >> made loud and clear to me is "DO NOT AFFECT THE PERFORMANCE OF MY IPV4 >> STACK with your IPV6 STACK APPROACH". I don't know about other vendors >> but Compaq is working real hard to make IPv6 transparent to IPv4 ONLY >> applications. When one adds extra conditions, 16 bytes to data >> structures, extra code path for IPv6, etc... you can negatively impact >> the IPv4 environment by what we call the death of a thousand cuts. So >> we need to keep a heads up when we discuss such thoughts as your proposing. >> And probably why this cannot be mandated; as Itojun as replied and I agree >> with him. >I think you overestimate the cost of performace to the IPv4 stack. It >seems to me that what Mr. Harding proposed would only affect a small set >of the socket API calls, and those that are performace critical almost not >at all. Basically we're talking about adding a translation layer between >any functions that return an address to the application, such as >gethost...(), accept(), and recvmsg(), and functions that require an >address from the application, such as bind(), connect(), sendmsg(). >For the vast majority of applications, this is going to mean a few cycles >(certainly less than 100 microseconds) of extra processing time assuming >worst case (meaning translation required). For most applications (those >that use TCP, like HTTP, FTP, telnet, mail, etc.), this is going to occur >only at connection setup and breakdown. The read() and write() calls >don't need to be translated! For performance critical (mostly >server-side) applications, I would recommend linking with seperate IPv4 >and IPv6 interfaces, as is done today. The performance hit is in two places. In the libraries where gethostxxx access the DNS resolver code path. DNS resolver has to parse all this and that is some code for sure. And any perf hit in this code path needs serious justification. In the kernel processing the socket layer for the apps and socket set calls you speak of above. Likewise on the justification. What do you mean by "would recommend linking with seperate IPv4 >and IPv6 interfaces, as is done today" above? I could take that to mean several things can you expound just on that statement? It is a cost I will not speculate on the xxxseconds variable because I did that when I thought 16bytes would not do much to protocol control block look ups and a bigger IP header would not affect things and I was wrong. Lets just agree now it is a performance hit. We can then go from there. >Where performance IS going to hit the application is if it is >connectionless, as in a UDP-based application. This would affect things >like NTP and some high-performance cluster software (MPI, PVM, etc.). >Having to do a translation on every send or receive would certainly be >meaningful for large numbers of packets. Another potential problem set is >embedded applications, who really can't afford the extra 2 Kbyte or so for >a table. In either of these cases, rewrite the code or live without IPv6 >- Mr. Harding has proposed what I think is a neat-o keen alternative, >which eases integration, not complicates it! The connection case will require translation for the lookup once it is found. >> And besides IPv6 cannot be a UNIX only thing for anything we work on >> IMO. >One problem that I see with this methodology is that it requires either >every application to be re-linked with a library that supports the >mapping, or that the operating system support it and perform the >translation before it hits the applications. Not an impassable hurdle, >but there it is, and it will almost certainly mean that it will happen on >Unix systems before other platforms, simply because Unix folks are used to >compiling their programs before installing them. Another could point we all need to think about for these implementation defined thingees anywhere in IPv6. If we add anything that breaks std interfaces on platforms that takes longer to get in a product. Users are not happy about having to recompile things all the time including most of my UNIX customers. So I am not sure I agree with your premise about UNIX. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 08:44:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA24132 for ipng-dist; Fri, 5 Mar 1999 08:37:21 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24125 for ; Fri, 5 Mar 1999 08:37:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id IAA28874 for ; Fri, 5 Mar 1999 08:37:11 -0800 (PST) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id IAA08519 for ; Fri, 5 Mar 1999 08:36:30 -0800 (PST) Received: (qmail 26473 invoked from network); 5 Mar 1999 16:36:21 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 5 Mar 1999 16:36:21 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA05742; Fri, 5 Mar 1999 11:36:21 -0500 (EST) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.0/8.9.0) with SMTP id LAA01779; Fri, 5 Mar 1999 11:36:19 -0500 (EST) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Fri, 5 Mar 1999 11:36:18 -0500 (EST) From: Shane Kerr X-Sender: kerr@sunshine Reply-To: Shane Kerr To: Jim Bound cc: Chris Harding , ipng@sunroof.eng.sun.com, deployment@ipv6.org Subject: (IPng 7280) Re: Ipv6 Migration In-Reply-To: <199903051549.KAA0000021799@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 5 Mar 1999, Jim Bound wrote: > The performance hit is in two places. > > In the libraries where gethostxxx access the DNS resolver code path. > DNS resolver has to parse all this and that is some code for sure. > And any perf hit in this code path needs serious justification. Again, this is really not that much code. For any IPv4 addresses found, a simple truncation to 32-bits is all you need to do. This is going to be only a few addresses per lookup in any case (maximum of 35 addresses on Solaris 2.6, the machine I'm using now). Compare this to the overhead of sending IP packets through the network device and the overhead dwindles to the point where I think you're going to have a hard time even measuring it! > In the kernel processing the socket layer for the apps and socket set > calls you speak of above. Likewise on the justification. > What do you mean by "would recommend linking with seperate IPv4 > >and IPv6 interfaces, as is done today" above? I could take that to > mean several things can you expound just on that statement? Well, if I want to connect to an IPv6 address, I need to create a socket with the PF_INET6 flag, and pack sockaddr_in6 structures to define addresses. If I want an application that connects to both IPv4 and IPv6 platforms, there's going to be seperate code paths, with one using PF_INET and sockaddr_in rather than the IPv6 definitions. Really, building in a translation layer is merely hiding the details of the operation inside of an API. There IS going to be more translation overhead, but not too much. > It is a cost I will not speculate on the xxxseconds variable because I > did that when I thought 16bytes would not do much to protocol control > block look ups and a bigger IP header would not affect things and I was > wrong. > > Lets just agree now it is a performance hit. We can then go from there. I apologize. I was thinking of modern (i.e. 80486-class or faster) processors running well-written C code. This is a mistake, considering how slow older or embedded CPU's are. Or Java, for that matter. :) > >Where performance IS going to hit the application is if it is > >connectionless, as in a UDP-based application. This would affect things > >like NTP and some high-performance cluster software (MPI, PVM, etc.). > >Having to do a translation on every send or receive would certainly be > >meaningful for large numbers of packets. Another potential problem set is > >embedded applications, who really can't afford the extra 2 Kbyte or so for > >a table. In either of these cases, rewrite the code or live without IPv6 > >- Mr. Harding has proposed what I think is a neat-o keen alternative, > >which eases integration, not complicates it! > > The connection case will require translation for the lookup once it is > found. No, because when I connect, the API can return a file descriptor. The application doesn't have to know that it is "really" an IPv6 connection. All it has to have is a number to pass to the kernel for read() and write() calls. I don't know if [gs]etsockopt() and ioctl() calls work the same on IPv4 and IPv6 sockets, so these calls may have to be translated as well. These should be relatively rare, however. > Another could point we all need to think about for these implementation > defined thingees anywhere in IPv6. > > If we add anything that breaks std interfaces on platforms that takes > longer to get in a product. Users are not happy about having to > recompile things all the time including most of my UNIX customers. So I > am not sure I agree with your premise about UNIX. Ack! I'm not happy about NOT being able to recompile things. :) I mean, I guess I'm not really sure where your performance concerns lie. If I found empirically (by writing and and performing timings) that code that did what Mr. Harding proposed slowed gethostbyname() calls on a 100 Mbit LAN (using a fast network will increase the relative performance loss of translation) by 1%, connect() calls by 0.1%, and read() and write() calls by 0%, slowing a real-world heavy network-usage client application by 0.001% would that be too much? If you say that "any performace loss is too much, all of our CPU cycles are priceless", then I guess you're right. But I think that a lot of consumers don't really understand the real effects of performace loss. When I've been forced by customers to explain the full algorithms involved in (say) phone call setup, they can't believe that it's fast enough. Computers are really fast. -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 09:32:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA24178 for ipng-dist; Fri, 5 Mar 1999 09:26:02 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24171 for ; Fri, 5 Mar 1999 09:25:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id JAA07723 for ; Fri, 5 Mar 1999 09:25:49 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id JAA05001 for ; Fri, 5 Mar 1999 09:23:52 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id LAA03972; Fri, 5 Mar 1999 11:23:47 -0600 (CST) Date: Fri, 5 Mar 1999 11:23:47 -0600 (CST) From: David Borman Message-Id: <199903051723.LAA03972@frantic.bsdi.com> To: kerr@arin.net Subject: (IPng 7281) Re: Ipv6 Migration Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Fri, 5 Mar 1999 11:36:18 -0500 (EST) > From: Shane Kerr > Subject: (IPng 7280) Re: Ipv6 Migration > ... > Well, if I want to connect to an IPv6 address, I need to create a socket > with the PF_INET6 flag, and pack sockaddr_in6 structures to define > addresses. If I want an application that connects to both IPv4 and IPv6 > platforms, there's going to be seperate code paths, with one using > PF_INET and sockaddr_in rather than the IPv6 definitions. Really, > building in a translation layer is merely hiding the details of the > operation inside of an API. If you properly rewrite the host lookup to use getaddrinfo(), then your application can work with both IPv4 and IPv6 addresses, without having to have seperate code paths for each. That's one of the main features of it, it returns all the data needed to do socket()/connect() or socket()/bind()/accept() without having to worry about whether the returned address is IPv4 or IPv6. Of course, if the application itself is aware of IP addresses (like the FTP protocol), it needs other changes as well. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 09:33:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA24212 for ipng-dist; Fri, 5 Mar 1999 09:31:26 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24197 for ; Fri, 5 Mar 1999 09:31:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id JAA13194 for ; Fri, 5 Mar 1999 09:31:11 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id JAA07458 for ; Fri, 5 Mar 1999 09:29:25 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id MAA19870; Fri, 5 Mar 1999 12:29:04 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000012708; Fri, 5 Mar 1999 12:28:05 -0500 (EST) From: Jim Bound Message-Id: <199903051728.MAA0000012708@quarry.zk3.dec.com> To: Shane Kerr cc: ipng@sunroof.eng.sun.com Subject: (IPng 7282) Re: Ipv6 Migration In-reply-to: Your message of "Fri, 05 Mar 1999 11:36:18 EST." Date: Fri, 05 Mar 1999 12:28:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Most of the discussion is happeing on the deployment list now. I will respond to Shanes last message there and cc Shane so he can participate. I did not cc deployment list for this msg. 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 Fri Mar 5 09:59:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA24269 for ipng-dist; Fri, 5 Mar 1999 09:46:49 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24258 for ; Fri, 5 Mar 1999 09:46:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id JAA28483 for ; Fri, 5 Mar 1999 09:46:02 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id JAA16200 for ; Fri, 5 Mar 1999 09:45:52 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id JAA13818; Fri, 5 Mar 1999 09:43:34 -0800 (PST) Received: from feller.mentat.com by leo.mentat.com (SMI-8.6/SMI-4.1) id JAA16857; Fri, 5 Mar 1999 09:43:34 -0800 Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id JAA05937; Fri, 5 Mar 1999 09:47:57 -0800 Date: Fri, 5 Mar 1999 09:47:57 -0800 From: tim@mentat.com (Tim Hartrick) Message-Id: <199903051747.JAA05937@feller.mentat.com> To: c.harding@opengroup.org Subject: (IPng 7283) Re: Ipv6 Migration Cc: ipng@sunroof.eng.sun.com, deployment@ipv6.org, xnet@opengroup.org X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chris, > > This is how it would operate. > > 1. Application calls gethostbyname() to look up a host address. > > 2. gethostbyname() invokes DNS and finds an IPv6 address. > > 3. gethostbyname() allocates an IPv4 address from a pool kept for this > purpose, sets up a mapping between the v4 address and the v6 address > obtained from DNS, and returns the v4 address to the application. > > 4. Application does its stuff, making sockets calls from time to time. > > 5. Sockets calls recognise the v4 address as being from the pool, and > communicate via IPv6 to the v6 address to which the v4 address is mapped, > instead of using v4. > > 6. When an application binds to a v4 address from the pool, subsequent > sockets calls do a similar v4-v6 translation. > > This doesn't actually require standardization. An individual vendor who > obtained a block of IPv4 addresses could do it without consulting anyone > else. But there could be advantages in allocating a single block of IPv4 > addresses for everyone to use in this way. > > The questions are: > > Will this work? > > Should it be required behavior for conforming UNIX implementations? > The answer to the first question is certainly yes with the performance and NAT caveats that Jim and Brian have noted. We actually implemented a very simple version of this three years or so ago. It allowed us to use regular IPv4 only Netscape, ftp and telnet on MacOS and Windows NT and communicate using IPv6 to a IPv4 only servers that were using the same mapping technique. The KAME folks have done a Windows 9[5?|8] "bump in the stack" implementation which basically does the same thing. The problem is that this is not free. It really ends up being NAT in a host because for applications like ftp which embed addresses in their data stream you need to look at every piece of data sent by the application so you can convert the PORT command on the fly to the IPv6 equivalent of your choice. It is simpler than NAT implemented in a router since you don't need to monkey with the TCP sequence numbers to fix up the embedded addresses but it is still a performance hit. The resolver parts have similar issues both in performance and NATlyness. The technique definitely could be used in circumstances where you abolutely can't get the applications updated. For example on Windows 9[5|8] it may be the only game in town. I am not sure that it is a technique that one would want to mandate however since it comes at significant cost. That is at least my answer to the second question. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 10:31:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA24394 for ipng-dist; Fri, 5 Mar 1999 10:30:16 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24387 for ; Fri, 5 Mar 1999 10:30:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id KAA09113 for ; Fri, 5 Mar 1999 10:29:22 -0800 (PST) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id KAA07041 for ; Fri, 5 Mar 1999 10:24:41 -0800 (PST) Received: (qmail 10185 invoked from network); 5 Mar 1999 18:24:38 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 5 Mar 1999 18:24:38 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA17145; Fri, 5 Mar 1999 13:24:38 -0500 (EST) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.0/8.9.0) with SMTP id NAA01983; Fri, 5 Mar 1999 13:24:34 -0500 (EST) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Fri, 5 Mar 1999 13:24:33 -0500 (EST) From: Shane Kerr X-Sender: kerr@sunshine Reply-To: Shane Kerr To: David Borman cc: ipng@sunroof.eng.sun.com Subject: (IPng 7285) Re: Ipv6 Migration In-Reply-To: <199903051723.LAA03972@frantic.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 5 Mar 1999, David Borman wrote: > If you properly rewrite the host lookup to use getaddrinfo(), then > your application can work with both IPv4 and IPv6 addresses, without > having to have seperate code paths for each. That's one of the main > features of it, it returns all the data needed to do socket()/connect() > or socket()/bind()/accept() without having to worry about whether the > returned address is IPv4 or IPv6. > > Of course, if the application itself is aware of IP addresses (like > the FTP protocol), it needs other changes as well. Well, isn't my face red!?!? I guess I should read the IPv6 socket API spec one of these days. :) This is cool, and makes for convient IPv6 programming. Although the translation idea still has merit for applications, since they can just be re-linked - no recompile necessary. Neither the Solaris 2.6 nor the RedHat Linux system I have easy access to here has the getaddrinfo() function, so it is unlikely any existing programs support it. Not to keep harping on performance or anything, but also note that the getaddrinfo() function is going to have to do significant processing to handle its arguments and return the data properly, far greater than any processing required to handle a simple address translation lookup. Just a thought. :P -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 10:31:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA24381 for ipng-dist; Fri, 5 Mar 1999 10:28:38 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24374 for ; Fri, 5 Mar 1999 10:28:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id KAA21118 for ; Fri, 5 Mar 1999 10:28:29 -0800 (PST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id KAA07694 for ; Fri, 5 Mar 1999 10:26:00 -0800 (PST) Received: from hyper (dhcp60-08.merit.edu [198.108.60.208]) by home.merit.edu (8.8.8/merit-2.0) with SMTP id NAA07571; Fri, 5 Mar 1999 13:25:58 -0500 (EST) Message-Id: <3.0.6.32.19990305133637.009b9200@home.merit.edu> X-Sender: wfs@home.merit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 05 Mar 1999 13:36:37 To: ipng@sunroof.eng.sun.com From: William Siadak Subject: (IPng 7284) Gated on IPv6 Cc: skh@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, the Gated team is porting Gated to run with IPv6. We currently are testing the KAME and INRIA stacks on FreeBSD and NetBSD with future plans for supporting Digital, SUN, IBM, and others as they come online. We would like to periodically post as an FYI our progress to either this list or some other one. Is this something we should post here, or if not can someone point us to an appropriate list. TIA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 11:38:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA24486 for ipng-dist; Fri, 5 Mar 1999 11:32:15 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24479 for ; Fri, 5 Mar 1999 11:32:05 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id LAA06278 for ; Fri, 5 Mar 1999 11:32:05 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA14019 for ; Fri, 5 Mar 1999 11:32:03 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id OAA24538; Fri, 5 Mar 1999 14:32:55 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000008608; Fri, 5 Mar 1999 14:31:56 -0500 (EST) From: Jim Bound Message-Id: <199903051931.OAA0000008608@quarry.zk3.dec.com> To: William Siadak cc: ipng@sunroof.eng.sun.com, skh@merit.edu Subject: (IPng 7286) Re: Gated on IPv6 In-reply-to: Your message of "Fri, 05 Mar 1999 13:36:37." <3.0.6.32.19990305133637.009b9200@home.merit.edu> Date: Fri, 05 Mar 1999 14:31:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please post this to deployment@ipv6.org too. In fact we now have a web page www.ipv6.org we can cross post your updates to. also Digital is now Compaq :-)...thanks 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 Fri Mar 5 11:38:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA24495 for ipng-dist; Fri, 5 Mar 1999 11:34:15 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24488 for ; Fri, 5 Mar 1999 11:34:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id LAA06866 for ; Fri, 5 Mar 1999 11:34:02 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA15551 for ; Fri, 5 Mar 1999 11:34:02 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id OAA24546; Fri, 5 Mar 1999 14:34:51 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000009156; Fri, 5 Mar 1999 14:33:52 -0500 (EST) From: Jim Bound Message-Id: <199903051933.OAA0000009156@quarry.zk3.dec.com> To: Shane Kerr cc: David Borman , ipng@sunroof.eng.sun.com Subject: (IPng 7287) Re: Ipv6 Migration In-reply-to: Your message of "Fri, 05 Mar 1999 13:24:33 EST." Date: Fri, 05 Mar 1999 14:33:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk shane, I hate getaddrinfo ... so I did not mention it or want it proliferated. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 14:00:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA24656 for ipng-dist; Fri, 5 Mar 1999 13:11:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24649 for ; Fri, 5 Mar 1999 13:11:35 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id NAA20012 for ; Fri, 5 Mar 1999 13:11:32 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA24271 for ; Fri, 5 Mar 1999 13:11:34 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id QAA16508; Fri, 5 Mar 1999 16:11:33 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000032266; Fri, 5 Mar 1999 16:11:32 -0500 (EST) From: Jim Bound Message-Id: <199903052111.QAA0000032266@quarry.zk3.dec.com> To: David Borman cc: ipng@sunroof.eng.sun.com Subject: (IPng 7289) Re: Ipv6 Migration In-reply-to: Your message of "Fri, 05 Mar 1999 14:53:21 CST." <199903052053.OAA05827@frantic.bsdi.com> Date: Fri, 05 Mar 1999 16:11:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David, Forgot to put my :-) face on the statement. And we support getaddrinfo too it is required. But I don't care about any address family but AF_INET and AF_NET6. if another one is invented I won't work on it, and that means IPv6 failed. If that happens I probably will go fishing. I don't care if folks use getaddrinfo. I won't though. 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 Fri Mar 5 14:00:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA24642 for ipng-dist; Fri, 5 Mar 1999 12:56:52 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24635 for ; Fri, 5 Mar 1999 12:56:05 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id MAA21992 for ; Fri, 5 Mar 1999 12:56:04 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA14423 for ; Fri, 5 Mar 1999 12:56:02 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id OAA05827; Fri, 5 Mar 1999 14:53:21 -0600 (CST) Date: Fri, 5 Mar 1999 14:53:21 -0600 (CST) From: David Borman Message-Id: <199903052053.OAA05827@frantic.bsdi.com> To: bound@zk3.dec.com, kerr@arin.net Subject: (IPng 7288) Re: Ipv6 Migration Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From bound@zk3.dec.com Fri Mar 5 13:34:09 1999 > From: Jim Bound > Date: Fri, 05 Mar 1999 14:33:52 -0500 > ... > I hate getaddrinfo ... so I did not mention it or want it proliferated. And that's really too bad. The getaddrinfo() function is a very useful function that allows you to do protocol independent address lookups. If (heaven forbid...) a new address family is added, applications that have been modified to use getaddrinfo() will not need any changes to support the new address family (assuming, of course, that the application itself doesn't care about the addresses). I don't have any objections to getipnodebyname(), because it does serve a useful purpose. But it is not the ultimate solution, since it cannot return a mixed bag of IPv4 and IPv6 addresses (in both sockaddr_in and sockaddr_in6 structures). I don't have any problem if others wish to limit their applications to using getipnodebyname(), as long as those providing the library function also include getaddrinfo(). The getaddrinfo() function is part of the API spec, and thus will proliferate to the same extent as getipnodbyname() or any other function in the spec. And getipnodebyname() *is* limited, because it is not protocol independent. Yes, you can ask for different types of addresses, but in the end you will only get *one* type of address back. The only reason it works for both IPv4 and IPv6 addresses is that you can return IPv4 addresses as IPv4-mapped IPv6 addresses. But you are still only dealing with one sockaddr form. If your application is to work with IPv6 addresses, you have to use sockaddr_in6, which means it will not work on kernels that don't have IPv6 built into them. Or else you need to have code that makes two getipnodebyname() calls, for both IPv6/IPv4 and IPv4-only. That makes the ability to have IPv4-mapped addresses returned or the successive call for AF_INET addresses redundant. Using getaddrinfo(), you make one call and then loop down the list of returned addresses, trying each. A staight forward loop, and the application doesn't even have to know about the different sockaddr formats. The bottom line for me is that I want applications that are not filled with "ifdef INET6" or have lots of redundant/duplicated code, and once compiled will run on both IPv6 aware and IPv4-only kernels. I can do that a whole lot more cleanly using getaddrinfo() than getipnodbyname(), because using the latter I have to have two calls to getipnodebyname(), one for each address family format. I do not object to anyone using getipnodebyname(), but I don't appreciate attempts to stifle it (and I *WILL* scream loudly if any attempts are made remove getaddrinfo(), (which has not happened, and I don't expect it to happen)). Both functions are useful, as they provide different capabilities. I happen to think that getaddrinfo() provides a cleaner coding solution to the problem of supporting multiple protocol families. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 14:04:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA24681 for ipng-dist; Fri, 5 Mar 1999 13:29:19 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24671 for ; Fri, 5 Mar 1999 13:28:46 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id NAA27206 for ; Fri, 5 Mar 1999 13:28:21 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA06284 for ; Fri, 5 Mar 1999 13:28:19 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id PAA05878; Fri, 5 Mar 1999 15:25:06 -0600 (CST) Date: Fri, 5 Mar 1999 15:25:06 -0600 (CST) From: David Borman Message-Id: <199903052125.PAA05878@frantic.bsdi.com> To: bound@zk3.dec.com Subject: (IPng 7291) Re: Ipv6 Migration Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > From: Jim Bound > Date: Fri, 05 Mar 1999 16:11:32 -0500 > ... > Forgot to put my :-) face on the statement. > > And we support getaddrinfo too it is required. That's fine, I've known for some time that you weren't fond of getaddrinfo(). I guess I saw your statement as an oppertunity to remind everyone that though most of the changes to the API have had to do with the creation of getipnodebyname(), there is still the getaddrinfo() function that can provide a cleaner solution to some problems. > But I don't care about any address family but AF_INET and AF_NET6. > > if another one is invented I won't work on it, and that means IPv6 > failed. If that happens I probably will go fishing. *If* another one is invented, then *when* it is invented will indicate whether IPv6 was a success or not. And if there does become need for one, I hope that by that time I'll also be spending my time fishing (or golfing, or working in my woodshop or darkroom) :-) And I appreciate all that you have done on getting the new API out. Thanks for all your hard work. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 14:04:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA24714 for ipng-dist; Fri, 5 Mar 1999 14:01:08 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24693 for ; Fri, 5 Mar 1999 14:00:47 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id OAA02097 for ; Fri, 5 Mar 1999 14:00:46 -0800 (PST) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA00814 for ; Fri, 5 Mar 1999 14:00:37 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 07B34181; Fri, 5 Mar 1999 17:00:34 -0500 (EST) To: William Siadak Cc: ipng@sunroof.eng.sun.com, skh@merit.edu Subject: (IPng 7292) Re: Gated on IPv6 References: <3.0.6.32.19990305133637.009b9200@home.merit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 05 Mar 1999 17:00:33 -0500 In-Reply-To: William Siadak's message of "Fri, 05 Mar 1999 13:36:37" Message-ID: <873e3jha0u.fsf@jekyll.piermont.com> Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk William Siadak writes: > Hello, the Gated team is porting Gated to run with IPv6. We currently are > testing the KAME and INRIA stacks on FreeBSD and NetBSD with future plans > for supporting Digital, SUN, IBM, and others as they come online. > > We would like to periodically post as an FYI our progress to either this > list or some other one. Is this something we should post here, or if not > can someone point us to an appropriate list. This is a reasonable place, as is users@ipv6.org. Also, if you get in touch with webmaster@ipv6.org, we can list your software on www.ipv6.org. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 15:04:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA24840 for ipng-dist; Fri, 5 Mar 1999 15:01:16 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24833 for ; Fri, 5 Mar 1999 15:01:05 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id PAA17030 for ; Fri, 5 Mar 1999 15:00:49 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA12219 for ; Fri, 5 Mar 1999 15:00:48 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id SAA23132; Fri, 5 Mar 1999 18:00:47 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id SAA0000027690; Fri, 5 Mar 1999 18:00:47 -0500 (EST) From: Jim Bound Message-Id: <199903052300.SAA0000027690@quarry.zk3.dec.com> To: David Borman cc: ipng@sunroof.eng.sun.com Subject: (IPng 7293) Re: Ipv6 Migration In-reply-to: Your message of "Fri, 05 Mar 1999 15:25:06 CST." <199903052125.PAA05878@frantic.bsdi.com> Date: Fri, 05 Mar 1999 18:00:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David, ACK... and on the golf too....... thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 5 19:03:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA24947 for ipng-dist; Fri, 5 Mar 1999 19:00:03 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24940 for ; Fri, 5 Mar 1999 18:59:50 -0800 (PST) From: wfs@merit.edu Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id SAA23341 for ; Fri, 5 Mar 1999 18:59:51 -0800 (PST) Received: from rhenium (rhenium.btinternet.com [194.73.73.93]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA16926 for ; Fri, 5 Mar 1999 18:59:50 -0800 (PST) Received: from [195.99.52.215] (helo=thss-barney.THSS-BARNEY) by rhenium with esmtp (Exim 2.05 #1) id 10J7JG-0002Jk-00 for ipng@sunroof.Eng.Sun.COM; Sat, 6 Mar 1999 02:59:26 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id F3AG93SA; Sat, 6 Mar 1999 03:00:29 -0000 Message-Id: Date: Sat, 6 Mar 1999 02:59:26 +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.Eng.Sun.COM Sat Mar 06 02:10:25 1999 Received: from [193.113.210.238] (helo=mail2.) by tantalum with smtp (Exim 2.05 #1) id 10J6Xn-0001dq-00 for nbc@btinternet.com; Sat, 6 Mar 1999 02:10:23 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id UAA23367; Fri, 5 Mar 1999 20:51:21 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP) with ESMTP; Fri, 5 Mar 1999 20:51:20 +0000 Received: from Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03174; Fri, 5 Mar 1999 12:50:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id MAA16655; Fri, 5 Mar 1999 12:47:17 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA24381 for ipng-dist; Fri, 5 Mar 1999 10:28:38 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24374 for ; Fri, 5 Mar 1999 10:28:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id KAA21118 for ; Fri, 5 Mar 1999 10:28:29 -0800 (PST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id KAA07694 for ; Fri, 5 Mar 1999 10:26:00 -0800 (PST) Received: from hyper (dhcp60-08.merit.edu [198.108.60.208]) by home.merit.edu (8.8.8/merit-2.0) with SMTP id NAA07571; Fri, 5 Mar 1999 13:25:58 -0500 (EST) Message-Id: <3.0.6.32.19990305133637.009b9200@home.merit.edu> X-Sender: wfs@home.merit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 05 Mar 1999 13:36:37 To: ipng@sunroof.Eng.Sun.COM From: William Siadak Subject: (IPng 7284) Gated on IPv6 Cc: skh@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hello, the Gated team is porting Gated to run with IPv6. We currently are testing the KAME and INRIA stacks on FreeBSD and NetBSD with future plans for supporting Digital, SUN, IBM, and others as they come online. We would like to periodically post as an FYI our progress to either this list or some other one. Is this something we should post here, or if not can someone point us to an appropriate list. TIA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 6 00:44:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA25151 for ipng-dist; Sat, 6 Mar 1999 00:39:02 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25144 for ; Sat, 6 Mar 1999 00:38:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id AAA29098 for ; Sat, 6 Mar 1999 00:38:51 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA27246 for ; Sat, 6 Mar 1999 00:38:52 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Sat, 6 Mar 1999 00:38:53 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81EA5@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: "'Mobile IP'" , "'IPsec'" , "'IPng List'" Subject: (IPng 7294) RE: (mobile-ip) Re: Last Call: Mobility Support i n IPv6 to Propos ed Standard Date: Sat, 6 Mar 1999 00:38:51 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik asked about more cases where mobility and IPsec interact: > What about the case when the correspondent doesn't have a > binding cache > entries - perhaps due to transient behavior (the first few packets) or > perhaps due to the mobile wanting location privacy. > Does the policy have to be coordinated between the correspondent host > and the home agent that will tunnel the packet in those cases? > What about when the CH and the HA are part of different admin domains? If the correspondent node doesn't have a binding cache entry for the mobile - ie it doesn't know the mobile is mobile - I think the correspondent when sending just needs to do IPsec processing as usual with the mobile's home address as the destination address selector. No policy coordination between the correspondent and the home agent is required. This assumes that there is no security gateway between the mobile and its home agent, so that when the home agent intercepts the packet destined for the mobile, the only security associations remaining in the packet are those directly with the mobile's home address. For example, suppose the correspondent has a transport-mode AH association with the mobile's home address. The correspondent sends packets like IPv6 hdr - src CN, dst HA AH hdr - transport-mode SA CN -> HA Transport hdr The home agent intercepts these and sends them to the care-of address. Suppose the care-of address is behind a security gateway. The home agent sets up a tunnel-mode ESP assocation with the security gateway and sends packets like IPv6 hdr - src Agent, dst SG ESP hdr - tunnel-mode SA Agent -> SG IPv6 hdr - src Agent, dst CA IPv6 hdr - src CN, dst HA AH hdr - transport-mode SA CN -> HA Transport hdr In this situation the mobile will do a first inbound SPD check when it hits the 3rd IPv6 header. The first policy check will use as selectors source Agent and destination CA. (It will verify that no association exists between the Agent and the care-of address.) It will do a second inbound SPD check when it hits the transport header. The second policy check will use as selectors source CN and destination HA. (It will verify the transport-mode AH association between the correspondent and the home address.) > When two mobile nodes communicate there are actually 4 IP addresses > in use since each of them have a care-of-address and a home address. > Does that mean you need to do 4 SPD lookups for the 4 combinations of > source and destination? > Source home address -> Destination home address > Source home address -> Destination COA > Source COA -> Destination home address > Source COA -> Destination COA > I think when two mobile nodes are communicating, you still only want two SPD lookups. The two SPD lookups are first using the two home addresses as destination and source selectors, and then second using the two care-of addresses as destination and source selectors. The results of the two lookups are spliced together. Associations directly with the destination home address (might be transport-mode or tunnel-mode) are taken from the first lookup, and associations with intermediate security gateways (always tunnel-mode) are taken from the second lookup. Then the headers from the security associations are combined with a routing header and destination options header as follows: IPv6 hdr - src care-of address, dst care-of address Routing hdr - segs left = 1, dst home address Destination options hdr - Home Address option, src home address Transport hdr Looking at what I just wrote, I'm unclear on two things: 1. The desired placement of the Home Address option. Should it be immediately before the transport header, or immediately after the Routing header? (The draft tries to specify this in section 10.1, but I'm not sure which alternative it means or which is correct.) 2. The processing of this packet when it gets to the destination mobile node. Does the routing header processing require inbound and outbound security policy checks before it is looped-back internally? This is the consensus that we already reached for generic routing header processing - it's like forwarding. But in this case the new destination address is reached via loopback, not forwarding outside the node. 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 Sun Mar 7 00:32:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA25693 for ipng-dist; Sun, 7 Mar 1999 00:28:02 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25686; Sun, 7 Mar 1999 00:27:53 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id AAA13499; Sun, 7 Mar 1999 00:27:51 -0800 (PST) Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA12255; Sun, 7 Mar 1999 00:27:52 -0800 (PST) Received: from bear.ebina.hitachi.co.jp by hitiij.hitachi.co.jp (8.9.1a/3.7W-hitiij) id RAA27124; Sun, 7 Mar 1999 17:27:16 +0900 (JST) Received: from gordon.ebina.hitachi.co.jp by bear.ebina.hitachi.co.jp (8.8.5/3.4W-EBINA) id TAA02071; Sun, 7 Mar 1999 19:19:27 +0900 (JST) Message-Id: <199903071019.TAA02071@bear.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Sun, 07 Mar 1999 17:28:25 +0900 To: Chris Harding From: Kazuaki Tsuchiya Subject: (IPng 7296) Re: Ipv6 Migration Cc: ipng@sunroof.eng.sun.com, deployment@ipv6.org, ngtrans@sunroof.eng.sun.com In-Reply-To: <3.0.3.32.19990305135158.0088e300@mailhome.rdg.opengroup.or g> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Chris, At 13:51 99/03/05 +0000, Chris Harding wrote: > > Also I would like to note that the approach is similar to > > draft-tsuchiya-ipv4-ipv6-translator-00. (worth a look) > > > Yes there is similarity - thanks for the pointer! > > The big difference is that this approach is implemented in the host, not in a > gateway or router. The host is an IPv6 host, so we are talking about IPv4 > applications in an IPv6 host, not about an IPv4 host in an IPv6 ocean. The > address mapper and translator functions needed in the host would be similar > to the ones described in draft-tsuchiya-ipv4-ipv6-translator-00. > Please see also draft-ietf-ngtrans-dual-stack-hosts-00 in addition to draft-tsuchiya-ipv4-ipv6-translator-00. There will be what you want, I believe. > Other points are that > > - there is no impact on DNS > Right! > - since this is all done in the host, IPSEC can still work. > At this point hosts' implementation surpasses routers' one, I think. ------ Additional info ------- We have 2 implementations. One is routers' implementation, and the other is hosts'. Both of them have already worked well. Please see the following URL. (1)Hosts' implementation http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm # You can get the free evaluation kit for Windows PCs here. (2)Routers' implementation http://www.hitachi.co.jp/Prod/comp/network/nr60e.htm > >>The questions are: > >> Will this work? > >> Should it be required behavior for conforming UNIX implementations? > > > > I believe this will work, but I think we do not need to/want to > > mandate this. > > > The benefit of making it a requirement is that users who buy a UNIX-branded > system will know that their existing applications are guaranteed to work > with IPv6. > That's just exactly what I want to say. Best regards. -- Kazuaki Tsuchiya. -------------------------------------------------------- Kazuaki Tsuchiya (E-mail:tsuchi@ebina.hitachi.co.jp) Hitachi, Ltd. Server & Network Development Division Phone:+81-462-32-2111(ex.2458) Fax:+81-462-35-8324 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 7 01:24:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA25747 for ipng-dist; Sun, 7 Mar 1999 01:18:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25740; Sun, 7 Mar 1999 01:18:28 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id BAA21991; Sun, 7 Mar 1999 01:18:27 -0800 (PST) Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA17684; Sun, 7 Mar 1999 01:18:27 -0800 (PST) Received: from bear.ebina.hitachi.co.jp by hitiij.hitachi.co.jp (8.9.1a/3.7W-hitiij) id SAA28940; Sun, 7 Mar 1999 18:18:25 +0900 (JST) Received: from gordon.ebina.hitachi.co.jp by bear.ebina.hitachi.co.jp (8.8.5/3.4W-EBINA) id UAA03599; Sun, 7 Mar 1999 20:10:37 +0900 (JST) Message-Id: <199903071110.UAA03599@bear.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Sun, 07 Mar 1999 18:19:34 +0900 To: Chris Harding From: Kazuaki Tsuchiya Subject: (IPng 7297) Re: Ipv6 Migration Cc: ipng@sunroof.eng.sun.com, deployment@ipv6.org, ngtrans@sunroof.eng.sun.com In-Reply-To: <199903071019.TAA02071@bear.ebina.hitachi.co.jp> References: <3.0.3.32.19990305135158.0088e300@mailhome.rdg.opengroup.or g> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Chris and IPv6 folks, At 17:28 99/03/07 +0900, Kazuaki Tsuchiya wrote: > > >>The questions are: > > >> Will this work? > > >> Should it be required behavior for conforming UNIX implementations? > > > > > > I believe this will work, but I think we do not need to/want to > > > mandate this. > > > > > The benefit of making it a requirement is that users who buy a UNIX-branded > > system will know that their existing applications are guaranteed to work > > with IPv6. > > > > That's just exactly what I want to say. > Sorry. I made a mistake. What I wanted to say is the following. We do not need to make this mandatory. But this is one of useful migration ways for end-users. There is a meaning in having many people know this. Best regards. -- Kazuaki Tsuchiya. -------------------------------------------------------- Kazuaki Tsuchiya (E-mail:tsuchi@ebina.hitachi.co.jp) Hitachi, Ltd. Server & Network Development Division Phone:+81-462-32-2111(ex.2458) Fax:+81-462-35-8324 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 10 17:01:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA28916 for ipng-dist; Wed, 10 Mar 1999 16:57:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28909 for ; Wed, 10 Mar 1999 16:57:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id QAA29620 for ; Wed, 10 Mar 1999 16:57:37 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA19543 for ; Wed, 10 Mar 1999 16:57:37 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA11686; Wed, 10 Mar 1999 16:57:31 -0800 (PST) Message-Id: <3.0.5.32.19990310165702.007c83a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Mar 1999 16:57:02 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7299) Draft Minutes from the Grenoble IPng w.g. 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 Working Group meeting held on February 2-4 in Grenoble. Comments and corrections to me. Thanks, Bob ____________________________________________________________________ IPng Working Group Meeting February 2-4, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco IPng Co-Chairs Bob Fink / LBNL Tony Hain / Microsoft NGTRANS Co-Chairs Minutes taken by Tony Hain, Steve Deering, Bob Fink and Bob Hinden. Edited by Bob Hinden. Minutes for NGTRANS and deployment activities published separately. ----------- IPng / NGTRANS INTERIM MEETING February 2-4, 1999 Steve Deering introduced meeting. Alain Durand gave local arrangements, terminal room information, daily schedule. 92 registered to attend. 25 from France 32 from elsewhere in Europe 28 from North America 7 from Japan SCHEDULE Tuesday 8:00 Registration 9:00 Welcome speech by IMAG's director 9:10 Morning session 11:30 Lunch break & registration 13:00 Afternoon session 1 15:00 Afternoon break 15:30 Afternoon session 2 18:00 End 20:00 Rendezvous at Bus station (next to the train station) to take a bus to go to the social. 23:00 Return from the social Wednesday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End Thursday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End First day is an IPng w.g. meeting. Second day is an NGTRANS meeting. Third day is deployment activities (this is not an IETF meeting). ---------------------------------------------------------------------- ---------------------------------------------------------------------- IPng WORKING GROUP February 2, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco Co-Chairs Introduction / S. Deering ------------------------- Steve Deering introduced the meeting and collected the attendee required issue lists. Chairs will review lunch break and present the results. IPng charter basically complete, documents are at various points in the standards process. Document review for completeness, followed by issues or additional work. Continue, Recharter, hibernate decision. Review and update agenda / S. Deering -------------------------------------- The agenda was reviewed. The following agenda resulted: IPng AGENDA - Introduction / S. Deering - Collect attendee required issue lists (S. Deering) - Review and update agenda (S. Deering) - Review state/completeness of current IPv6-related protocols (B. Hinden) - Identify important new IPv6 protocol/standards work (detailed agenda follows) - Formulate recommendations to the IESG/IAB, re: future IPv6 work (detailed agenda follows) AGENDA: NEW PROTOCOL / STANDARDS WORK - Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) - Securing ICMP/ND/MLD (M. Crawford) - State of Plug-and-Play (B. Hinden) - Site Scoping Issues (T. Narten) - Issues in IPv6 Multihoming (J. Hagino) - Better Support for Multihomed Hosts (R. Draves) - Better Support for Multihomed Sites (E. Nordmark) - Privacy issues with use of EUI-64 IDs (T. Narten) - Source and Destination Address Selection (T. Narten) - Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) AGENDA: FORMULATE RECOMMENDATIONS / S. Deering, B. Hinden - Disposition of IPng w.g. - Extend charter? go on hiatus? - Distribution of work to other existing WGs? - Evaluation of all IETF protocols for "IPv6-readiness"? - Recommendations for establishing new WG(s) or RG(s)? Review State/Completeness of Current IPv6-Related Protocols (B. Hinden) ----------------------------------------------------------------------- REVIEW STATE OF IPv6 PROTOCOLS - Draft Standards - Proposed Standards - Informational - Experimental - Current Internet Drafts DRAFT STANDARDS - RFC2460 Internet Protocol, Version 6 (IPv6) Specification Issue of advancement to full standard over what time period. IESG will want to insure that protocols are mature. Discussion on what IESG will require to move base protocols to Standard. Conclusion that we should get a clear statement of what the IESG will be looking for. - RFC2463 Internet Control Message Protocol (ICMPv6) Add scope-exceeded ICMP error msg code RFC-editor suggested edits Prohibit ICMP error message in response to redirects ACTION: Document editor to do editing pass and resubmit to IESG for same status - RFC2461 Neighbor Discovery for IP Version 6 (IPv6) Forbid RAs from non-forwarding interfaces Issue of NAs without link-layer address Suggestion: guidance/interpretations document - RFC2462 IPv6 Stateless Address Autoconfiguration No issues - RFC1981 Path MTU Discovery for IP version 6 No issues. Note this was the only spec that progressed without recycling! PROPOSED STANDARDS - RFC2373 IP Version 6 Addressing Architecture No issues - RFC2374 An IPv6 Aggregatable Global Unicast Format No issues Should decide on what the "core set" of documents is. - RFC1886 DNS Extensions to support IP version 6 Should this be advanced? Not unless something else that depends on it needs to advance to next level. M. Crawford reported that new specification does not include specification of AAAA, does describe compatibility. Conclusion that both specs will need to coexist with each other. The new specification will need to have it's title changed. It is currently has the same title as RFC1886. - RFC2147 TCP and UDP over IPv6 Jumbograms To be merged with jumbogram hop-by-hop option spec to produce combined document. Work in progress. - RFC2080 RIPng for IPv6 ACTION: Document editor to poke RIP wg to advance to Draft Standard. - RFC2283 Multiprotocol Extensions for BGP-4 Francis reports there will be a new version of this spec, going to draft standard; a separate IPv6 specific part is supposed to be published as Proposed standard. Narten: This is hung in the IESG on a normative reference for another doc Summary: Update to RFC2283 to include IPv6 will be forwarded as proposed; how to it use is drafted, but not published; ACTION: Document editor will poke chairs (or ADs if necessary). PROPOSED STANDARDS - RFC2464 IPv6 Packets over Ethernet Networks No issues - RFC2467 IPv6 Packets over FDDI Networks No issues - RFC2470 IPv6 Packets over Token Ring Networks No issues - RFC2472 IPv6 over PPP No issues General conclusion is that IPv6 over Ethernet/FDDI/TR/ PPP should move to draft standard when 6 month time goes off. Need to start collecting implementation information and issue last call. ACTION: Document Editor start collecting implementation information on IPv6 over Ethernet/FDDI/TR/ PPP and issue last call for Draft Standard when 6 month timer goes off. - RFC2473 Generic Packet Tunneling in IPv6 Specification Need to add language about bidirectional tunnels and recycle at Proposed Standard. - RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks No issues PROPOSED STANDARDS - RFC2492 IPv6 over ATM Networks No issues - RFC2452 MIB for IPv6: TCP No issues - RFC2454 MIB for IPv6: UDP Bert Weinen: plan to merge with the IPv4 versions of TCP & UDP. Pick up with authors and merge. Could be done in the ops area. May not be sufficient in other area. ACTION: O&M AD's to resolve. - RFC2465 MIB for IPv6: Textual Conventions & General Group Question about support for site ids - RFC2466 MIB for IPv6: ICMPv6 Group No issues Question about any Implementations? Nordmark: instrumentation is done to support this, but the MIB browser interface is not done. Dupont: INRIA has complete implementation. PROPOSED STANDARDS - IP Header Compression (Internet Draft) No issues - Transmission of IPv6 over ARCnet Networks (Internet Draft) No issues - Transmission of IPv6 Packets over IPv4 Networks without Explicit Tunnels (Internet Draft) No issues - Reserved IPv6 Subnet Anycast Addresses (Internet Draft) No issues - RFC1752 The Recommendation for IP Next Generation Protocol Question what to do about this? Perhaps time for BCP? ACTION: Document authors (Mankin & Bradner) to decide what to do. INFORMATIONAL - RFC2450 Proposed TLA and NLA Assignment Rules No issues - RFC1881 IPv6 Address Allocation No issues - RFC2375 IPv6 Multicast Address Assignments ACTION: Document editor needs to get IANA to publish this on their web pages - RFC2133 Basic Socket Interface Extensions for IPv6 No issues. Will become historic when new back socket document is published. - Basic Socket Interface Extensions for IPv6 (Internet Draft) No issues - RFC2292 Advanced Sockets API for IPv6 Possible issue with support for home address option from Mobile IP Perhaps pass these to API stds bodies, e.g., Xopen, winsock EXPERIMENTAL - RFC2471 IPv6 Testing Address Allocation No issues - RFC1888 OSI NSAPs and IPv6 Matt C. notes that this is only current way to embed phone numbers in IPv6 addresses CURRENT INTERNET DRAFTS - Initial IPv6 Sub-TLA ID Assignments No issues - Router Renumbering for IPv6 Being revised to support reliability mechanisms; will be another WG last call - Link Local Addressing and Name Resolution in IPv6 There is interest in this - GSE - An Alternate Addressing Architecture for IPv6 ACTION: Document editor will inform secretariate that this has timed out - IPng Analysis of the GSE Proposal Has been submitted to IESG for Informational. CURRENT INTERNET DRAFTS - A method of flexible IPv6 address assignments Waiting for additional comments, then w.g. last call for Informational. - IPv6 Router Alert Option Waiting resolution of differences between IPv4 and IPv6 versions. - The IPv6 Jumbo Payload Option Will be combined with TCP/UDP jumbograms to create single document. - Multicast Listener Discovery (MLD) for IPv6 ACTION: Deering to reissue by ID deadline for Minneapolis - DNS Extensions to support IP version 6 [See discussion on "RFC1886 DNS Extensions to support IP version 6" above] - IPv6 Name Lookups Through ICMP [No notes] - Reverse Address lookup in DNS for IPng ACTION: Document editor will inform secretariate that this has timed out CURRENT INTERNET DRAFTS - OSPF for IPv6 - Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Continue work. - Site Prefixes in Neighbor Discovery Continue work. - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Work progressing slowly in DHCP w.g. - Extensions for DHCPv6 Work progressing slowly in DHCP w.g. - Mobility Support in IPv6 About to start last call in Mobile IP w.g. CURRENT INTERNET DRAFTS - IPv6 over Point-to-Point ATM Link ACTION: Document editor will inform secretariate that this has timed out - Transmission of IPv6 Packets over IEEE 1394 Networks Would like see progress in IPover1284 w.g. - Transmission of IPv6 Packets over Frame Relay Networks ION w.g. about to do w.g. last call. - Forcing Fragmentation to Network MTU [No notes] - The Case for IPv6 Author working on new draft. Reviewed submitted tasks / S. Deering, B. Fink ---------------------------------------------- Summary of submitted tasks with counts of times topic appeared in "[ ]"s followed by sub-topics. Flow ID [7] Multicastcast routing [8] snooping [1] doing it better [1] dns [1] 6 over 4 [1] VoIP [3] mobility [18] dns site local security API dns discovery [1] site multihoming [15] routing usage v6 apps readyness [5] renumbering v6 compatibility text security [10] ND ICMP MLD v6 over v6 management [4] nd mibs snmpv6 tools interior routing [13] isisv6 ospv6 other address allocation [3] aggregation addressing [3] encourage implementers [2] public relations [1] plug & play [11] renumbering [3] tcp survival AAA - dialup [2] diameter VPN [1] Host & router requirements [3] Conformance / compliance [3] Secure DNS [1] Dynamic DNS [1] Exchanges [2] Anycast [5] tcp / udp DNS [4] zones number of roots Measurement [1] Host multihoming [5] Router autoconfig [2] Site definition [1] IPv4 competition [1] Service location [1] QOS - hop by hop reservation [1] Building the 6ren [1] DHCPv6 [3] Ipv6 over IOG [1] IPv6 over 1394 [2] Compatibility testing organization structure [1] Filtering [1] Source & destination selection [3] ND v6 spec problems [1] Free implementations [1] Killer app [1] Transition [2] smooth Diff serv [1] Who are you [1] Icmp scope [1] Link & site local addressing in multihoming [1] V6 interface identifier [1] V6 socket api [2] NIS & NIS + [1] Site local address usage [1] Multi-link subnets [1] Scope discovery [1] Firewalls into the host [1] IPv6 addresses in URL's [1] Discussion of new topics receiving the most votes. Flow label ---------- Deering described current state. One issue is if it has end-to-end semantics, or hop-by-hop. Currently it is end-to-end. No one has defined other usage, though there has been a lot of discussion. C. Jung described how it might relate to MPLS and it could be us to carry the MPLS label. This may be OBE. Matt Crawford noted that MPLS is "multiprotocol", hence it should not deal w/ IPv6 differently from IPv4 or any other protocol J. Bound said that RSVP for IPv6 currently uses the flow label field. C. Jung is uncomfortable with current flow label definition. Telabit said they have implemented flow label and found it useful. Bound see a lot of value with current definition because it is very important for applications for bandwidth brokers in corporate intranets. Deering suggested that we could define flow label to have either end-end or hop-hop semantics by using one bit. Another suggestion that e-e flow label would also be very helpful for user authentication and billing applications. Examples: accountable premium bandwidth. Flow label is a very good place to carry subscription information. Hinden thought there was a loose consensus on keeping the existing wording, authors could provide flow label detail in additional documents Deering outlined what we could do. Choices were: 1) Drop flow label 2) Standardize current flow label 3) Standardize hop-by-hop FL 4) Standardize hybrid 5) Leave as is Polled group. 1) 1 2) 11 3) 0 4) 13 5) 26 No consensus to change behavior or current text. Multicast Routing ----------------- Deering reported that PIM, MOSPF, MBGP have IPv6 extensions. Thinks work is going along well. Action here is to keep them moving forward. Mobility -------- Work is already in another WG charter (e.g., Mobile IP). Is the question mobility in general v.s. mobile IP? Answer: Mobility in general Wireless is one of the media. M. Crawford suggested that we get E163/E164 into IPv6 and let the phone system take it over Routing, Interior and Exterior ----------------------------- Should be in other groups; Noted that OSPF for IPv6 is only a draft. Needs to be advanced. Durand: strange feedback, spec is in draft state but WG is holding due to lack of implementations, but lack of implementations due to lack of spec; little pressure to move v6 related work forward Hinden: routing protocols actually require interoperable implementations to move forward. Deering: OSPF is not a high risk since there is not a competing proposal ISIS is a IPv6 hostile WG so they may have left it out of their charter. -------------------------------------- AGENDA: NEW PROTOCOL / STANDARDS WORK -------------------------------------- Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) --------------------------------------------------------------------------- MOBILE PHONES - More Mobile Phones Sold Yearly than PC's o 163 Million sold in 1998 - Currently 300 Million Users o Expect to reach a Billion in 2005 - Every Phone is Networked - Next version of GSM has IP in it o Every phone will have an IP stack! Phone networks decided v6 was not applicable since it was not a std Deering: new groups now taking std status label more seriously Hinden: Missing piece is wireless mobile, and scale is not addressed Nordmark: Do the implementers understand the scaling issues Bound: Problem is ISP's looking at GSM, others misleading that IETF declared v6 dead T'sirtis: TV's have the same problems Hinden: More things are network appliances, all this has scaling issues PDA's are getting more networking, and converging with phones. PDA'S - PDA Market growing Exponentially - Networking coming to PDA o Wireless just starting - Some PDA's look like Mobile Phones o Some Mobile Phones look like PDA's - IP Stacks are available for PDA's now REQUIREMENTS - Global Addresses o 2 x number of devices o Server Applications - Auto Configuration o Minimum of manual configuration - Security o Encrypted Transmissions o Authenticated Node - Mobility o Roam between Providers - Efficient use of Link o Limited bandwidth available - Compact Implementations o Limited code space HOW DOES IPv6 DO? - Global Addresses o Lots of addresses o Supports large subnets - Auto Configuration o Basic functions fine o DNS? o Secure? - Security o Basic mechanisms OK o Plug and Play? - Mobility o Mobile IPv6 OK - Efficient use of Link o Can Header Compression be used? o With Security? - Compact Implementations o Should be OK NEXT STEPS - Need to Address o Secure Neighbor Discovery and Autoconfiguration o Simpler Service Discovery - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Nordmark: No foreign agent in current spec, general problem is authentication of guest ethernet. Generally calls are dropped when switching providers, so roaming registration happens on startup Securing ICMP/ND/MLD (M. Crawford) ------------------------------------------------ Authenticating an error message - Security policy for informational ICMP ND - Spoofing & DOS attacks MLD ? what is the problem Deering: How do you restrict access to multicast? Crawford: Payload encryption solves the problem, and the key distribution is someone else's ICMP errors & informational - IPsec errors subgroup has worked Solution space for ND - NA security concerns the right of a node to make assertions about an address - RA it is not clear how to delegate the authority ; store certificate at subnet router anycast Draves: how do you resolve NA Crawford: unauthenticated neighbor cache used just to create authenticated cache Nordmark: router authentication Crawford: how do you understand that a given prefix is valid for this subnet; Draves: auto config problem, how do you figure out who is the authority ???: AAA addresses this with pre-configured shared secret Deering: multiple smart card slots in every host Mankin: work in trusted third party solution space as thesis. Solution space for MLD - (blank) Work items - ICMP errors - Invade the IPsec WG and demand more Nordmark: No one is working on the problem of how to make this better ICMP info - Done deal ND - V6 specific as spin-off of this group ; RA is harder MLD - Almost congruent to IGMP? Site Scoping Issues (T. Narten) ------------------------------- Multi-homing Source address selection becomes the key issue How to assign block to multihomed site How to assign addresses to nodes within site Outbound packet filters may block from wrong source Scope must be same for source & destination is a debated issue State of Plug-and-Play (B. Hinden) ----------------------------------- "Dentist's office" Secure "Dentist's office" CONTEXT - Plug and Play likely to be IPv6's Carrot - Makes IP Easy to Use! - Lowers Cost of Ownership for Enterprises and ISP's - Enables Network Appliances o Phones, PDAs, Games, household appliances, etc. SCENARIO 1 - ISOLATED [isolated figure] SCENARIO 2 - CONNECTED [connected figure] SECURE PLUG AND PLAY? - Is Security and Plug and Play an Oxymoron? o Security requires knowledge of a Secret o Autoconfiguration wants to be Stateless - If a node knew the Secret o Could everything else be automatic? o Use Hardware token? WHERE ARE WE NOW - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Service Location for IPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map Comment SLP uses URL's Action: Hinden will write a draft defining preferred literal URL format. WHAT IS MISSING? - DNS o How to find DNS Server o How to register Node DNS name - Services o How to find Printers, File Servers, etc. o Enterprise and Home Office solution - Secure Plug and Play o Simple, Easy, and Still Secure? SOLUTIONS - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Can simple client only version suffice? o Are people implementing it? - DNS Server Location o Need Something New - DNS Name Registration o Status of Dynamic DNS Updating? DNS SERVER LOCATION - Need to Learn o Server Address(s) o Default Domain o Domain Suffix Search list o Others? - Issues o Authentication o Lifetimes o Changing APPROACHES - Add Attribute to ND Router Advertisements o Requires configuring this info in Routers o What if no Router? - DNS Server Advertisements? o Does SL do this? - Anycast Address for DNS Servers o Requires further communication w/ DNS server to get other related information - Multicast Address for DNS Servers o Use Expanding Ring (TTL) Search NEXT STEPS - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Discussion: Nordmark: Will router to the Internet be a substantial services platform as well? Hinden: There will not be a single answer, some want minimalist router, others want full load. Deering: We need something that works like appletalk; when the magic do-it-all box is broken the network still needs to work. Bound: Scenario 2 the box wants to be both a router & host How can telco provide a service on minimal end point, it is important scenario. Durand: It is now my home network so now I the last thing I want is a DNS server. Conclusions: Making the isolated case work well, and securing auto-configuration appear to be the important issues. Issues in IPv6 Multihoming (J. Hagino) -------------------------------------- [No notes] Better Support for Multihomed Hosts (R. Draves) ----------------------------------------------- Multi-homed hosts defined several ways - Host with 2 interfaces into different networks Host with 2 interfaces into the same network - Host with 2 interfaces onto the same link Interfaces have several definitions - Physical interfaces - Virtual interface (will do ND on this) - Pseudo interfaces (will not do ND, just exists as a matter of convenience) VPN's & dial-to ISP becoming more popular Transition mechanisms encourage multi-homing Firewalls exist in this space Problems: Next hop determination (really next link) - ND has conceptual data structures per interface, but no mechanism to identify interface - Proposal to add info to RA Policy decision by user via multicast announced scope - Partial Aggregation is likely to cause more trouble than it helps Detecting same link - Work in IEEE may address this Switching to different interface - General case of the router renumbering issue Weak v.s. strong host model Deering: Old issues that will not converge, best we can do is document the consequences for each choice Better Support for Multihomed Sites (E. Nordmark) ------------------------------------------------- API is the only thing missing from the day's discussion Bound: What part is the API v.s. network layer Deering: The appropriate place for now it the API doc Syn6 scope ID - context dependent definition Modifying all apps is not realistic, so get addr info Bound: Get addr info is not scaling well in deployment Source and Destination Address Selection (T. Narten) ---------------------------------------------------- When initiating which address to choose, selecting 'best' is not easy for applications Favor preferred addresses over deprecated Site local v.s. global scope; choose global if expectation is to be mobile One way to scale multi-homed site; assign prefix for both ISP's Consider adding a 'middleware' layer that addresses policy Privacy issues with use of EUI-64 IDs (T. Narten) ------------------------------------------------- Link prefix obtained from RA. IID could be exploited to identify user. Uproar from privacy groups over hardware serial numbers Potential negative PR Is there a need to change IID more often than each reboot. Use clock value to randomize? Bound: This could be a lot of work, and we already have a lot of work Caller ID as a model Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) --------------------------------------------------------------------- [No notes] Formulate recommendations to the IESG/IAB, re: future IPv6 work (S. Deering, B. Hinden) ---------------------------------------------------------------- Note: This session was held on Thursday Feb 4. WG Docs to Finish up - MLD - ICMP revision o Scope-exceeded err, no error to redirect, editorial - Advanced API - router renumbering - merged jumbo gram specs - generic tunneling (add bidirectional tunnels) Unfinished IPng W.G. work - Flow label standardization (no action now) - scope issues, source address selection - multihomed host/site issues - autoconfig <-> DNS <-> mobile IP story - URL format for IPv6 literal address. - dial-up issues? Work still covered under original charter. Discussion about what "autoconfig <-> DNS story" means. Mechanisms may be there, but need to describe. Additional discussion. Comment that the story is written. Probably no IPng protocol work required. Nordmark made comment that what about creating names for devices w/out keyboards (e.g., phones, light switches, etc.). Need generic names and/or way of updating name via the network. New IPng w.g. Tasks - Specify transient interface IDs for privacy concerns - Specify E.164-in-IPv6 addressing - Specify IPv6 over additional media o USB ? o Bluetooth ? o 1O Gig pipe ? o IEEE 1394 ? - Start an IPv6 "Host/Router requirements" document Other Current w.g. chores - Keep all w.g. docs moving along publication / standardization track - Identify "base spec" of docs for advancement to full standard Other lower-layers WGs to prod - DNS, DHCPv6, IPv6-over-Firewire, Mobile IP, RIPv2, OSPF,ISIS, IDR, MOSPF, PIM, Diff-Serv, AAA (Diameter), Malloc (maybe) New work for other W.G.s - IPv6 readiness check (incl. MIBS, etc.) - Secure ICMP/ND (IPSEC) - Authenticate, Autoconfiged hosts (IPSEC) Other idea to pursue, perhaps in new w.g.(s) - Specify how exchanges can work - TCP/UDP/host use of anycast - Next level of plug-n-play ("appletalk"-like) - 6-over-4 cut-through (NHRP-like) - More complete story for billions of mobile devices (esp. phones) - Multi-link subnets (single subnet spans multiple links) - Scope-name discovery - Conformance tests - Tools for reducing network mgt costs Possible items for IRTF - Transport use of global interface IDs - Higher-layer survival of renumbering - Router auto-config / auto subnet numbering - "Better" multicast address alloc. - "Better" VPNs - "Better" billing/accounting opportunities - Architected MLD snooping - Firewall in the host - ICMPv3 -> MLD Suggestion to add better multicast routing for IPv6. Other - Convey message that "IPv6" is done"; time to implement deploy, and port applications - Review/strengthen "cast for IPv6", "case against NAT" docs - Keep prodding IP address registry - Develop a voice-over-IPv6 story - Participate move in other WGs - Pass API docs to other stds bodies Suggestion to find individuals to track work in other working groups. A specific individual for each group. Will do a call for volunteers on mailing list. Suggestion by AD that we should update charter focus on remaining work and how to get to completion. Discussion about how/when to wrap up the working group. Suggestion that we go on "hiatus" after "base specs" are completed (Draft standard). Other comments that it is important to continue the w.g. to have an "official" forum to communicate / send recommendations to ICAN, IAB, IP registries, etc. Chairs will discuss future w.g. steps w/ AD's and make recommendation to w.g. ------------------------------------------------------------------------- ------------------------------------------------------------------------- Meeting Adjourned ------------------------------------------------------------------------- ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 10 17:58:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA29000 for ipng-dist; Wed, 10 Mar 1999 17:40:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28993 for ; Wed, 10 Mar 1999 17:39:54 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id RAA28699 for ; Wed, 10 Mar 1999 17:39:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA11524 for ; Wed, 10 Mar 1999 17:39:52 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA13916; Wed, 10 Mar 1999 17:39:51 -0800 (PST) Message-Id: <3.0.5.32.19990310173923.00acf470@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Mar 1999 17:39:23 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7300) Update to IPng web pages Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have completed a set of updates to the IPng web pages at: http://playground.sun.com/ipng Changes include new specs, current standardization status, meeting minutes, 6REN link, and new implementations. Please send changes and corrections to me. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 10 19:08:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA29085 for ipng-dist; Wed, 10 Mar 1999 18:59:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29077 for ; Wed, 10 Mar 1999 18:59:23 -0800 (PST) From: hinden@iprg.nokia.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id SAA24832 for ; Wed, 10 Mar 1999 18:59:23 -0800 (PST) Received: from praseodumium (praseodumium.btinternet.com [194.73.73.82]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA14687 for ; Wed, 10 Mar 1999 18:59:21 -0800 (PST) Received: from [195.99.53.81] (helo=thss-barney.THSS-BARNEY) by praseodumium with esmtp (Exim 2.05 #1) id 10KveE-0000Hy-00 for ipng@sunroof.eng.sun.com; Thu, 11 Mar 1999 02:56:35 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GRLTDT05; Thu, 11 Mar 1999 03:00:10 -0000 Message-Id: Date: Thu, 11 Mar 1999 02:56:35 +0000 To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.eng.sun.com Thu Mar 11 01:06:45 1999 Received: from [193.113.210.238] (helo=mail2.) by rhenium with smtp (Exim 2.05 #1) id 10Ktvx-0000r7-00 for nbc@btinternet.com; Thu, 11 Mar 1999 01:06:45 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id BAA23093; Thu, 11 Mar 1999 01:08:07 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP) with ESMTP; Thu, 11 Mar 1999 01:08:05 +0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA09417; Wed, 10 Mar 1999 17:03:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id RAA23945; Wed, 10 Mar 1999 17:03:38 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA28916 for ipng-dist; Wed, 10 Mar 1999 16:57:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28909 for ; Wed, 10 Mar 1999 16:57:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id QAA29620 for ; Wed, 10 Mar 1999 16:57:37 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA19543 for ; Wed, 10 Mar 1999 16:57:37 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA11686; Wed, 10 Mar 1999 16:57:31 -0800 (PST) Message-Id: <3.0.5.32.19990310165702.007c83a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Mar 1999 16:57:02 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7299) Draft Minutes from the Grenoble IPng w.g. 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 Working Group meeting held on February 2-4 in Grenoble. Comments and corrections to me. Thanks, Bob ____________________________________________________________________ IPng Working Group Meeting February 2-4, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco IPng Co-Chairs Bob Fink / LBNL Tony Hain / Microsoft NGTRANS Co-Chairs Minutes taken by Tony Hain, Steve Deering, Bob Fink and Bob Hinden. Edited by Bob Hinden. Minutes for NGTRANS and deployment activities published separately. ----------- IPng / NGTRANS INTERIM MEETING February 2-4, 1999 Steve Deering introduced meeting. Alain Durand gave local arrangements, terminal room information, daily schedule. 92 registered to attend. 25 from France 32 from elsewhere in Europe 28 from North America 7 from Japan SCHEDULE Tuesday 8:00 Registration 9:00 Welcome speech by IMAG's director 9:10 Morning session 11:30 Lunch break & registration 13:00 Afternoon session 1 15:00 Afternoon break 15:30 Afternoon session 2 18:00 End 20:00 Rendezvous at Bus station (next to the train station) to take a bus to go to the social. 23:00 Return from the social Wednesday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End Thursday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End First day is an IPng w.g. meeting. Second day is an NGTRANS meeting. Third day is deployment activities (this is not an IETF meeting). ---------------------------------------------------------------------- ---------------------------------------------------------------------- IPng WORKING GROUP February 2, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco Co-Chairs Introduction / S. Deering ------------------------- Steve Deering introduced the meeting and collected the attendee required issue lists. Chairs will review lunch break and present the results. IPng charter basically complete, documents are at various points in the standards process. Document review for completeness, followed by issues or additional work. Continue, Recharter, hibernate decision. Review and update agenda / S. Deering -------------------------------------- The agenda was reviewed. The following agenda resulted: IPng AGENDA - Introduction / S. Deering - Collect attendee required issue lists (S. Deering) - Review and update agenda (S. Deering) - Review state/completeness of current IPv6-related protocols (B. Hinden) - Identify important new IPv6 protocol/standards work (detailed agenda follows) - Formulate recommendations to the IESG/IAB, re: future IPv6 work (detailed agenda follows) AGENDA: NEW PROTOCOL / STANDARDS WORK - Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) - Securing ICMP/ND/MLD (M. Crawford) - State of Plug-and-Play (B. Hinden) - Site Scoping Issues (T. Narten) - Issues in IPv6 Multihoming (J. Hagino) - Better Support for Multihomed Hosts (R. Draves) - Better Support for Multihomed Sites (E. Nordmark) - Privacy issues with use of EUI-64 IDs (T. Narten) - Source and Destination Address Selection (T. Narten) - Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) AGENDA: FORMULATE RECOMMENDATIONS / S. Deering, B. Hinden - Disposition of IPng w.g. - Extend charter? go on hiatus? - Distribution of work to other existing WGs? - Evaluation of all IETF protocols for "IPv6-readiness"? - Recommendations for establishing new WG(s) or RG(s)? Review State/Completeness of Current IPv6-Related Protocols (B. Hinden) ----------------------------------------------------------------------- REVIEW STATE OF IPv6 PROTOCOLS - Draft Standards - Proposed Standards - Informational - Experimental - Current Internet Drafts DRAFT STANDARDS - RFC2460 Internet Protocol, Version 6 (IPv6) Specification Issue of advancement to full standard over what time period. IESG will want to insure that protocols are mature. Discussion on what IESG will require to move base protocols to Standard. Conclusion that we should get a clear statement of what the IESG will be looking for. - RFC2463 Internet Control Message Protocol (ICMPv6) Add scope-exceeded ICMP error msg code RFC-editor suggested edits Prohibit ICMP error message in response to redirects ACTION: Document editor to do editing pass and resubmit to IESG for same status - RFC2461 Neighbor Discovery for IP Version 6 (IPv6) Forbid RAs from non-forwarding interfaces Issue of NAs without link-layer address Suggestion: guidance/interpretations document - RFC2462 IPv6 Stateless Address Autoconfiguration No issues - RFC1981 Path MTU Discovery for IP version 6 No issues. Note this was the only spec that progressed without recycling! PROPOSED STANDARDS - RFC2373 IP Version 6 Addressing Architecture No issues - RFC2374 An IPv6 Aggregatable Global Unicast Format No issues Should decide on what the "core set" of documents is. - RFC1886 DNS Extensions to support IP version 6 Should this be advanced? Not unless something else that depends on it needs to advance to next level. M. Crawford reported that new specification does not include specification of AAAA, does describe compatibility. Conclusion that both specs will need to coexist with each other. The new specification will need to have it's title changed. It is currently has the same title as RFC1886. - RFC2147 TCP and UDP over IPv6 Jumbograms To be merged with jumbogram hop-by-hop option spec to produce combined document. Work in progress. - RFC2080 RIPng for IPv6 ACTION: Document editor to poke RIP wg to advance to Draft Standard. - RFC2283 Multiprotocol Extensions for BGP-4 Francis reports there will be a new version of this spec, going to draft standard; a separate IPv6 specific part is supposed to be published as Proposed standard. Narten: This is hung in the IESG on a normative reference for another doc Summary: Update to RFC2283 to include IPv6 will be forwarded as proposed; how to it use is drafted, but not published; ACTION: Document editor will poke chairs (or ADs if necessary). PROPOSED STANDARDS - RFC2464 IPv6 Packets over Ethernet Networks No issues - RFC2467 IPv6 Packets over FDDI Networks No issues - RFC2470 IPv6 Packets over Token Ring Networks No issues - RFC2472 IPv6 over PPP No issues General conclusion is that IPv6 over Ethernet/FDDI/TR/ PPP should move to draft standard when 6 month time goes off. Need to start collecting implementation information and issue last call. ACTION: Document Editor start collecting implementation information on IPv6 over Ethernet/FDDI/TR/ PPP and issue last call for Draft Standard when 6 month timer goes off. - RFC2473 Generic Packet Tunneling in IPv6 Specification Need to add language about bidirectional tunnels and recycle at Proposed Standard. - RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks No issues PROPOSED STANDARDS - RFC2492 IPv6 over ATM Networks No issues - RFC2452 MIB for IPv6: TCP No issues - RFC2454 MIB for IPv6: UDP Bert Weinen: plan to merge with the IPv4 versions of TCP & UDP. Pick up with authors and merge. Could be done in the ops area. May not be sufficient in other area. ACTION: O&M AD's to resolve. - RFC2465 MIB for IPv6: Textual Conventions & General Group Question about support for site ids - RFC2466 MIB for IPv6: ICMPv6 Group No issues Question about any Implementations? Nordmark: instrumentation is done to support this, but the MIB browser interface is not done. Dupont: INRIA has complete implementation. PROPOSED STANDARDS - IP Header Compression (Internet Draft) No issues - Transmission of IPv6 over ARCnet Networks (Internet Draft) No issues - Transmission of IPv6 Packets over IPv4 Networks without Explicit Tunnels (Internet Draft) No issues - Reserved IPv6 Subnet Anycast Addresses (Internet Draft) No issues - RFC1752 The Recommendation for IP Next Generation Protocol Question what to do about this? Perhaps time for BCP? ACTION: Document authors (Mankin & Bradner) to decide what to do. INFORMATIONAL - RFC2450 Proposed TLA and NLA Assignment Rules No issues - RFC1881 IPv6 Address Allocation No issues - RFC2375 IPv6 Multicast Address Assignments ACTION: Document editor needs to get IANA to publish this on their web pages - RFC2133 Basic Socket Interface Extensions for IPv6 No issues. Will become historic when new back socket document is published. - Basic Socket Interface Extensions for IPv6 (Internet Draft) No issues - RFC2292 Advanced Sockets API for IPv6 Possible issue with support for home address option from Mobile IP Perhaps pass these to API stds bodies, e.g., Xopen, winsock EXPERIMENTAL - RFC2471 IPv6 Testing Address Allocation No issues - RFC1888 OSI NSAPs and IPv6 Matt C. notes that this is only current way to embed phone numbers in IPv6 addresses CURRENT INTERNET DRAFTS - Initial IPv6 Sub-TLA ID Assignments No issues - Router Renumbering for IPv6 Being revised to support reliability mechanisms; will be another WG last call - Link Local Addressing and Name Resolution in IPv6 There is interest in this - GSE - An Alternate Addressing Architecture for IPv6 ACTION: Document editor will inform secretariate that this has timed out - IPng Analysis of the GSE Proposal Has been submitted to IESG for Informational. CURRENT INTERNET DRAFTS - A method of flexible IPv6 address assignments Waiting for additional comments, then w.g. last call for Informational. - IPv6 Router Alert Option Waiting resolution of differences between IPv4 and IPv6 versions. - The IPv6 Jumbo Payload Option Will be combined with TCP/UDP jumbograms to create single document. - Multicast Listener Discovery (MLD) for IPv6 ACTION: Deering to reissue by ID deadline for Minneapolis - DNS Extensions to support IP version 6 [See discussion on "RFC1886 DNS Extensions to support IP version 6" above] - IPv6 Name Lookups Through ICMP [No notes] - Reverse Address lookup in DNS for IPng ACTION: Document editor will inform secretariate that this has timed out CURRENT INTERNET DRAFTS - OSPF for IPv6 - Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Continue work. - Site Prefixes in Neighbor Discovery Continue work. - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Work progressing slowly in DHCP w.g. - Extensions for DHCPv6 Work progressing slowly in DHCP w.g. - Mobility Support in IPv6 About to start last call in Mobile IP w.g. CURRENT INTERNET DRAFTS - IPv6 over Point-to-Point ATM Link ACTION: Document editor will inform secretariate that this has timed out - Transmission of IPv6 Packets over IEEE 1394 Networks Would like see progress in IPover1284 w.g. - Transmission of IPv6 Packets over Frame Relay Networks ION w.g. about to do w.g. last call. - Forcing Fragmentation to Network MTU [No notes] - The Case for IPv6 Author working on new draft. Reviewed submitted tasks / S. Deering, B. Fink ---------------------------------------------- Summary of submitted tasks with counts of times topic appeared in "[ ]"s followed by sub-topics. Flow ID [7] Multicastcast routing [8] snooping [1] doing it better [1] dns [1] 6 over 4 [1] VoIP [3] mobility [18] dns site local security API dns discovery [1] site multihoming [15] routing usage v6 apps readyness [5] renumbering v6 compatibility text security [10] ND ICMP MLD v6 over v6 management [4] nd mibs snmpv6 tools interior routing [13] isisv6 ospv6 other address allocation [3] aggregation addressing [3] encourage implementers [2] public relations [1] plug & play [11] renumbering [3] tcp survival AAA - dialup [2] diameter VPN [1] Host & router requirements [3] Conformance / compliance [3] Secure DNS [1] Dynamic DNS [1] Exchanges [2] Anycast [5] tcp / udp DNS [4] zones number of roots Measurement [1] Host multihoming [5] Router autoconfig [2] Site definition [1] IPv4 competition [1] Service location [1] QOS - hop by hop reservation [1] Building the 6ren [1] DHCPv6 [3] Ipv6 over IOG [1] IPv6 over 1394 [2] Compatibility testing organization structure [1] Filtering [1] Source & destination selection [3] ND v6 spec problems [1] Free implementations [1] Killer app [1] Transition [2] smooth Diff serv [1] Who are you [1] Icmp scope [1] Link & site local addressing in multihoming [1] V6 interface identifier [1] V6 socket api [2] NIS & NIS + [1] Site local address usage [1] Multi-link subnets [1] Scope discovery [1] Firewalls into the host [1] IPv6 addresses in URL's [1] Discussion of new topics receiving the most votes. Flow label ---------- Deering described current state. One issue is if it has end-to-end semantics, or hop-by-hop. Currently it is end-to-end. No one has defined other usage, though there has been a lot of discussion. C. Jung described how it might relate to MPLS and it could be us to carry the MPLS label. This may be OBE. Matt Crawford noted that MPLS is "multiprotocol", hence it should not deal w/ IPv6 differently from IPv4 or any other protocol J. Bound said that RSVP for IPv6 currently uses the flow label field. C. Jung is uncomfortable with current flow label definition. Telabit said they have implemented flow label and found it useful. Bound see a lot of value with current definition because it is very important for applications for bandwidth brokers in corporate intranets. Deering suggested that we could define flow label to have either end-end or hop-hop semantics by using one bit. Another suggestion that e-e flow label would also be very helpful for user authentication and billing applications. Examples: accountable premium bandwidth. Flow label is a very good place to carry subscription information. Hinden thought there was a loose consensus on keeping the existing wording, authors could provide flow label detail in additional documents Deering outlined what we could do. Choices were: 1) Drop flow label 2) Standardize current flow label 3) Standardize hop-by-hop FL 4) Standardize hybrid 5) Leave as is Polled group. 1) 1 2) 11 3) 0 4) 13 5) 26 No consensus to change behavior or current text. Multicast Routing ----------------- Deering reported that PIM, MOSPF, MBGP have IPv6 extensions. Thinks work is going along well. Action here is to keep them moving forward. Mobility -------- Work is already in another WG charter (e.g., Mobile IP). Is the question mobility in general v.s. mobile IP? Answer: Mobility in general Wireless is one of the media. M. Crawford suggested that we get E163/E164 into IPv6 and let the phone system take it over Routing, Interior and Exterior ----------------------------- Should be in other groups; Noted that OSPF for IPv6 is only a draft. Needs to be advanced. Durand: strange feedback, spec is in draft state but WG is holding due to lack of implementations, but lack of implementations due to lack of spec; little pressure to move v6 related work forward Hinden: routing protocols actually require interoperable implementations to move forward. Deering: OSPF is not a high risk since there is not a competing proposal ISIS is a IPv6 hostile WG so they may have left it out of their charter. -------------------------------------- AGENDA: NEW PROTOCOL / STANDARDS WORK -------------------------------------- Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) --------------------------------------------------------------------------- MOBILE PHONES - More Mobile Phones Sold Yearly than PC's o 163 Million sold in 1998 - Currently 300 Million Users o Expect to reach a Billion in 2005 - Every Phone is Networked - Next version of GSM has IP in it o Every phone will have an IP stack! Phone networks decided v6 was not applicable since it was not a std Deering: new groups now taking std status label more seriously Hinden: Missing piece is wireless mobile, and scale is not addressed Nordmark: Do the implementers understand the scaling issues Bound: Problem is ISP's looking at GSM, others misleading that IETF declared v6 dead T'sirtis: TV's have the same problems Hinden: More things are network appliances, all this has scaling issues PDA's are getting more networking, and converging with phones. PDA'S - PDA Market growing Exponentially - Networking coming to PDA o Wireless just starting - Some PDA's look like Mobile Phones o Some Mobile Phones look like PDA's - IP Stacks are available for PDA's now REQUIREMENTS - Global Addresses o 2 x number of devices o Server Applications - Auto Configuration o Minimum of manual configuration - Security o Encrypted Transmissions o Authenticated Node - Mobility o Roam between Providers - Efficient use of Link o Limited bandwidth available - Compact Implementations o Limited code space HOW DOES IPv6 DO? - Global Addresses o Lots of addresses o Supports large subnets - Auto Configuration o Basic functions fine o DNS? o Secure? - Security o Basic mechanisms OK o Plug and Play? - Mobility o Mobile IPv6 OK - Efficient use of Link o Can Header Compression be used? o With Security? - Compact Implementations o Should be OK NEXT STEPS - Need to Address o Secure Neighbor Discovery and Autoconfiguration o Simpler Service Discovery - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Nordmark: No foreign agent in current spec, general problem is authentication of guest ethernet. Generally calls are dropped when switching providers, so roaming registration happens on startup Securing ICMP/ND/MLD (M. Crawford) ------------------------------------------------ Authenticating an error message - Security policy for informational ICMP ND - Spoofing & DOS attacks MLD ? what is the problem Deering: How do you restrict access to multicast? Crawford: Payload encryption solves the problem, and the key distribution is someone else's ICMP errors & informational - IPsec errors subgroup has worked Solution space for ND - NA security concerns the right of a node to make assertions about an address - RA it is not clear how to delegate the authority ; store certificate at subnet router anycast Draves: how do you resolve NA Crawford: unauthenticated neighbor cache used just to create authenticated cache Nordmark: router authentication Crawford: how do you understand that a given prefix is valid for this subnet; Draves: auto config problem, how do you figure out who is the authority ???: AAA addresses this with pre-configured shared secret Deering: multiple smart card slots in every host Mankin: work in trusted third party solution space as thesis. Solution space for MLD - (blank) Work items - ICMP errors - Invade the IPsec WG and demand more Nordmark: No one is working on the problem of how to make this better ICMP info - Done deal ND - V6 specific as spin-off of this group ; RA is harder MLD - Almost congruent to IGMP? Site Scoping Issues (T. Narten) ------------------------------- Multi-homing Source address selection becomes the key issue How to assign block to multihomed site How to assign addresses to nodes within site Outbound packet filters may block from wrong source Scope must be same for source & destination is a debated issue State of Plug-and-Play (B. Hinden) ----------------------------------- "Dentist's office" Secure "Dentist's office" CONTEXT - Plug and Play likely to be IPv6's Carrot - Makes IP Easy to Use! - Lowers Cost of Ownership for Enterprises and ISP's - Enables Network Appliances o Phones, PDAs, Games, household appliances, etc. SCENARIO 1 - ISOLATED [isolated figure] SCENARIO 2 - CONNECTED [connected figure] SECURE PLUG AND PLAY? - Is Security and Plug and Play an Oxymoron? o Security requires knowledge of a Secret o Autoconfiguration wants to be Stateless - If a node knew the Secret o Could everything else be automatic? o Use Hardware token? WHERE ARE WE NOW - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Service Location for IPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map Comment SLP uses URL's Action: Hinden will write a draft defining preferred literal URL format. WHAT IS MISSING? - DNS o How to find DNS Server o How to register Node DNS name - Services o How to find Printers, File Servers, etc. o Enterprise and Home Office solution - Secure Plug and Play o Simple, Easy, and Still Secure? SOLUTIONS - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Can simple client only version suffice? o Are people implementing it? - DNS Server Location o Need Something New - DNS Name Registration o Status of Dynamic DNS Updating? DNS SERVER LOCATION - Need to Learn o Server Address(s) o Default Domain o Domain Suffix Search list o Others? - Issues o Authentication o Lifetimes o Changing APPROACHES - Add Attribute to ND Router Advertisements o Requires configuring this info in Routers o What if no Router? - DNS Server Advertisements? o Does SL do this? - Anycast Address for DNS Servers o Requires further communication w/ DNS server to get other related information - Multicast Address for DNS Servers o Use Expanding Ring (TTL) Search NEXT STEPS - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Discussion: Nordmark: Will router to the Internet be a substantial services platform as well? Hinden: There will not be a single answer, some want minimalist router, others want full load. Deering: We need something that works like appletalk; when the magic do-it-all box is broken the network still needs to work. Bound: Scenario 2 the box wants to be both a router & host How can telco provide a service on minimal end point, it is important scenario. Durand: It is now my home network so now I the last thing I want is a DNS server. Conclusions: Making the isolated case work well, and securing auto-configuration appear to be the important issues. Issues in IPv6 Multihoming (J. Hagino) -------------------------------------- [No notes] Better Support for Multihomed Hosts (R. Draves) ----------------------------------------------- Multi-homed hosts defined several ways - Host with 2 interfaces into different networks Host with 2 interfaces into the same network - Host with 2 interfaces onto the same link Interfaces have several definitions - Physical interfaces - Virtual interface (will do ND on this) - Pseudo interfaces (will not do ND, just exists as a matter of convenience) VPN's & dial-to ISP becoming more popular Transition mechanisms encourage multi-homing Firewalls exist in this space Problems: Next hop determination (really next link) - ND has conceptual data structures per interface, but no mechanism to identify interface - Proposal to add info to RA Policy decision by user via multicast announced scope - Partial Aggregation is likely to cause more trouble than it helps Detecting same link - Work in IEEE may address this Switching to different interface - General case of the router renumbering issue Weak v.s. strong host model Deering: Old issues that will not converge, best we can do is document the consequences for each choice Better Support for Multihomed Sites (E. Nordmark) ------------------------------------------------- API is the only thing missing from the day's discussion Bound: What part is the API v.s. network layer Deering: The appropriate place for now it the API doc Syn6 scope ID - context dependent definition Modifying all apps is not realistic, so get addr info Bound: Get addr info is not scaling well in deployment Source and Destination Address Selection (T. Narten) ---------------------------------------------------- When initiating which address to choose, selecting 'best' is not easy for applications Favor preferred addresses over deprecated Site local v.s. global scope; choose global if expectation is to be mobile One way to scale multi-homed site; assign prefix for both ISP's Consider adding a 'middleware' layer that addresses policy Privacy issues with use of EUI-64 IDs (T. Narten) ------------------------------------------------- Link prefix obtained from RA. IID could be exploited to identify user. Uproar from privacy groups over hardware serial numbers Potential negative PR Is there a need to change IID more often than each reboot. Use clock value to randomize? Bound: This could be a lot of work, and we already have a lot of work Caller ID as a model Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) --------------------------------------------------------------------- [No notes] Formulate recommendations to the IESG/IAB, re: future IPv6 work (S. Deering, B. Hinden) ---------------------------------------------------------------- Note: This session was held on Thursday Feb 4. WG Docs to Finish up - MLD - ICMP revision o Scope-exceeded err, no error to redirect, editorial - Advanced API - router renumbering - merged jumbo gram specs - generic tunneling (add bidirectional tunnels) Unfinished IPng W.G. work - Flow label standardization (no action now) - scope issues, source address selection - multihomed host/site issues - autoconfig <-> DNS <-> mobile IP story - URL format for IPv6 literal address. - dial-up issues? Work still covered under original charter. Discussion about what "autoconfig <-> DNS story" means. Mechanisms may be there, but need to describe. Additional discussion. Comment that the story is written. Probably no IPng protocol work required. Nordmark made comment that what about creating names for devices w/out keyboards (e.g., phones, light switches, etc.). Need generic names and/or way of updating name via the network. New IPng w.g. Tasks - Specify transient interface IDs for privacy concerns - Specify E.164-in-IPv6 addressing - Specify IPv6 over additional media o USB ? o Bluetooth ? o 1O Gig pipe ? o IEEE 1394 ? - Start an IPv6 "Host/Router requirements" document Other Current w.g. chores - Keep all w.g. docs moving along publication / standardization track - Identify "base spec" of docs for advancement to full standard Other lower-layers WGs to prod - DNS, DHCPv6, IPv6-over-Firewire, Mobile IP, RIPv2, OSPF,ISIS, IDR, MOSPF, PIM, Diff-Serv, AAA (Diameter), Malloc (maybe) New work for other W.G.s - IPv6 readiness check (incl. MIBS, etc.) - Secure ICMP/ND (IPSEC) - Authenticate, Autoconfiged hosts (IPSEC) Other idea to pursue, perhaps in new w.g.(s) - Specify how exchanges can work - TCP/UDP/host use of anycast - Next level of plug-n-play ("appletalk"-like) - 6-over-4 cut-through (NHRP-like) - More complete story for billions of mobile devices (esp. phones) - Multi-link subnets (single subnet spans multiple links) - Scope-name discovery - Conformance tests - Tools for reducing network mgt costs Possible items for IRTF - Transport use of global interface IDs - Higher-layer survival of renumbering - Router auto-config / auto subnet numbering - "Better" multicast address alloc. - "Better" VPNs - "Better" billing/accounting opportunities - Architected MLD snooping - Firewall in the host - ICMPv3 -> MLD Suggestion to add better multicast routing for IPv6. Other - Convey message that "IPv6" is done"; time to implement deploy, and port applications - Review/strengthen "cast for IPv6", "case against NAT" docs - Keep prodding IP address registry - Develop a voice-over-IPv6 story - Participate move in other WGs - Pass API docs to other stds bodies Suggestion to find individuals to track work in other working groups. A specific individual for each group. Will do a call for volunteers on mailing list. Suggestion by AD that we should update charter focus on remaining work and how to get to completion. Discussion about how/when to wrap up the working group. Suggestion that we go on "hiatus" after "base specs" are completed (Draft standard). Other comments that it is important to continue the w.g. to have an "official" forum to communicate / send recommendations to ICAN, IAB, IP registries, etc. Chairs will discuss future w.g. steps w/ AD's and make recommendation to w.g. ------------------------------------------------------------------------- ------------------------------------------------------------------------- Meeting Adjourned ------------------------------------------------------------------------- ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 10 19:08:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA29080 for ipng-dist; Wed, 10 Mar 1999 18:59:28 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29069 for ; Wed, 10 Mar 1999 18:59:14 -0800 (PST) From: hinden@iprg.nokia.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id SAA22131 for ; Wed, 10 Mar 1999 18:59:14 -0800 (PST) Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA14638 for ; Wed, 10 Mar 1999 18:59:14 -0800 (PST) Received: from [195.99.53.81] (helo=thss-barney.THSS-BARNEY) by tantalum with esmtp (Exim 2.05 #1) id 10Kvgm-000562-00 for ipng@sunroof.eng.sun.com; Thu, 11 Mar 1999 02:59:12 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GRLTDT07; Thu, 11 Mar 1999 03:00:15 -0000 Message-Id: Date: Thu, 11 Mar 1999 02:59:12 +0000 To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.eng.sun.com Thu Mar 11 02:03:18 1999 Received: from [193.113.210.238] (helo=mail2.) by carbon with smtp (Exim 2.05 #1) id 10Kuog-0005uw-00 for nbc@btinternet.com; Thu, 11 Mar 1999 02:03:18 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id CAA16926; Thu, 11 Mar 1999 02:06:14 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP) with ESMTP; Thu, 11 Mar 1999 02:06:12 +0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA00525; Wed, 10 Mar 1999 18:04:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id SAA14646; Wed, 10 Mar 1999 18:04:35 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA29000 for ipng-dist; Wed, 10 Mar 1999 17:40:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28993 for ; Wed, 10 Mar 1999 17:39:54 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id RAA28699 for ; Wed, 10 Mar 1999 17:39:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA11524 for ; Wed, 10 Mar 1999 17:39:52 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA13916; Wed, 10 Mar 1999 17:39:51 -0800 (PST) Message-Id: <3.0.5.32.19990310173923.00acf470@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Mar 1999 17:39:23 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7300) Update to IPng web pages Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have completed a set of updates to the IPng web pages at: http://playground.sun.com/ipng Changes include new specs, current standardization status, meeting minutes, 6REN link, and new implementations. Please send changes and corrections to me. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 11 00:14:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA29203 for ipng-dist; Thu, 11 Mar 1999 00:11:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29196 for ; Thu, 11 Mar 1999 00:11:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id AAA27503 for ; Thu, 11 Mar 1999 00:11:15 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA26808 for ; Thu, 11 Mar 1999 00:11:17 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA03848; Thu, 11 Mar 1999 09:11:13 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id JAA05470; Thu, 11 Mar 1999 09:11:13 +0100 (MET) Message-Id: <199903110811.JAA05470@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Cc: mobile-ip@smallworks.com Subject: (IPng 7303) mobility and IPsec tunnel mode Date: Thu, 11 Mar 1999 09:11:12 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The interaction between IPv6 mobility and IPsec in tunnel mode is both interesting and not (yet) described in I-Ds. Usually your get: from correspondent to mobile: IPv6 header destination=care-of address Routing header final destination=home address IPSec header authentication and replay prevention Higher level data from mobile to correspondent: IPv6 header source=care-of address IPSec header authentication and replay prevention Destination Options home address=home address Higher level data If you use tunnel mode in place of transport mode for common packets (ie without binding options) you can use: from correspondent to mobile: Outer IPv6 header destination=care-of address IPSec header authentication and replay prevention Inner IPv6 header destination=home address Higher level data from mobile to correspondent: Outer IPv6 header source=care-of address IPSec header authentication and replay prevention Inner IPv6 header source=home address Higher level data The two ways are in fact independent. The interesting thing is you don't need special things like routing headers or home address destination options which is not a real surprise because the key point is to get *two* addresses for the mobile which is provided by encapsulation... Then when IPsec tunnel mode is used, mobility has *no* extra cost for common packets (if my remark is applied). This should be written down in the specs? 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 Thu Mar 11 01:18:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA29255 for ipng-dist; Thu, 11 Mar 1999 01:16:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29248 for ; Thu, 11 Mar 1999 01:16:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id BAA27585 for ; Thu, 11 Mar 1999 01:16:10 -0800 (PST) Received: from hcoss.uia.ac.be (hcoss.uia.ac.be [143.169.1.8]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA18085 for ; Thu, 11 Mar 1999 01:16:00 -0800 (PST) Received: from hcoss.uia.ac.be by hcoss.uia.ac.be; (8.8.6/1.1.8.2/22Feb95-0943AM) id KAA19921; Thu, 11 Mar 1999 10:15:48 +0100 (MET) Message-Id: <199903110915.KAA19921@hcoss.uia.ac.be> Date: Thu, 11 Mar 1999 10:15:48 +0100 (MET) From: "Benny.VanHoudt" Reply-To: "Benny.VanHoudt" Subject: (IPng 7304) Mobile IPv6 Binding Acks. To: ipng@sunroof.eng.sun.com Cc: mobile-ip@smallworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +otw4EiiLhTJANpMEgcdJw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This was probably notice before, but just in case: In the Mobile IPv6 Internet-Draft of 18/11/98 it is stated (line 6) in section 5.2 that a binding acknowledgement MUST be returned upon receiving a binding Update with A = 1. Later in section 8.5 it is mentioned (line 2) that it SHOULD be returned. Which one is correct? vanhoudt@uia.ua.ac.be -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 11 08:28:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA29414 for ipng-dist; Thu, 11 Mar 1999 08:25:26 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29407 for ; Thu, 11 Mar 1999 08:25:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id IAA19473 for ; Thu, 11 Mar 1999 08:25:16 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA06796 for ; Thu, 11 Mar 1999 08:25:15 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id LAA22109; Thu, 11 Mar 1999 11:26:21 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000002616; Thu, 11 Mar 1999 11:25:12 -0500 (EST) From: Jim Bound Message-Id: <199903111625.LAA0000002616@quarry.zk3.dec.com> To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: (IPng 7305) Re: Draft Minutes from the Grenoble IPng w.g. In-reply-to: Your message of "Wed, 10 Mar 1999 16:57:02 PST." <3.0.5.32.19990310165702.007c83a0@mailhost.iprg.nokia.com> Date: Thu, 11 Mar 1999 11:25:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good job. 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 Thu Mar 11 10:33:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA29483 for ipng-dist; Thu, 11 Mar 1999 10:26:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29476 for ; Thu, 11 Mar 1999 10:26:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id KAA26714 for ; Thu, 11 Mar 1999 10:25:58 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA04427 for ; Thu, 11 Mar 1999 10:25:59 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 11 Mar 1999 10:25:59 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81F2D@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 7306) RE: mobility and IPsec tunnel mode Date: Thu, 11 Mar 1999 10:25:57 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you use tunnel mode in place of transport mode for common > packets (ie without binding options) you can use: > > from correspondent to mobile: > > Outer IPv6 header > destination=care-of address > IPSec header > authentication and replay prevention > Inner IPv6 header > destination=home address > Higher level data This is an interesting idea. I think it would work IF the receiving mobile node has enabled forwarding on the receiving interface, ie, is behaving as a security gateway. That's because this packet looks exactly like a packet sent with a tunnel-mode association with a security gateway. When the implementation processes the inner IPv6 header and sees that the destination address is different than the destination address in the outer IPv6 header, it will invoke the security gateway / forwarding path, and a normal host will drop the packet. The advantage of the routing header is that hosts implement routing headers. 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 Mar 11 12:01:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA29668 for ipng-dist; Thu, 11 Mar 1999 11:57:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29661 for ; Thu, 11 Mar 1999 11:57:41 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id LAA12618 for ; Thu, 11 Mar 1999 11:57:34 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA09255 for ; Thu, 11 Mar 1999 11:55:59 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA20081; Thu, 11 Mar 1999 11:55:58 -0800 (PST) Message-Id: <3.0.5.32.19990311115527.03abd910@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Mar 1999 11:55:27 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7307) Updated IPng w.g. Minutes from Grenoble Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Working Group Meeting February 2-4, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco IPng Co-Chairs Bob Fink / LBNL Tony Hain / Microsoft NGTRANS Co-Chairs Minutes taken by Tony Hain, Steve Deering, Bob Fink and Bob Hinden. Edited by Bob Hinden. Minutes for NGTRANS and deployment activities published separately. ----------- IPng / NGTRANS INTERIM MEETING February 2-4, 1999 Steve Deering introduced meeting. Alain Durand gave local arrangements, terminal room information, daily schedule. 92 registered to attend. 25 from France 32 from elsewhere in Europe 28 from North America 7 from Japan SCHEDULE Tuesday 8:00 Registration 9:00 Welcome speech by IMAG's director 9:10 Morning session 11:30 Lunch break & registration 13:00 Afternoon session 1 15:00 Afternoon break 15:30 Afternoon session 2 18:00 End 20:00 Rendezvous at Bus station (next to the train station) to take a bus to go to the social. 23:00 Return from the social Wednesday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End Thursday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End First day is an IPng w.g. meeting. Second day is an NGTRANS meeting. Third day is deployment activities (this is not an IETF meeting). ---------------------------------------------------------------------- ---------------------------------------------------------------------- IPng WORKING GROUP February 2, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco Co-Chairs Introduction / S. Deering ------------------------- Steve Deering introduced the meeting and collected the attendee required issue lists. Chairs will review lunch break and present the results. IPng charter basically complete, documents are at various points in the standards process. Document review for completeness, followed by issues or additional work. Continue, Recharter, hibernate decision. Review and update agenda / S. Deering -------------------------------------- The agenda was reviewed. The following agenda resulted: IPng AGENDA - Introduction / S. Deering - Collect attendee required issue lists (S. Deering) - Review and update agenda (S. Deering) - Review state/completeness of current IPv6-related protocols (B. Hinden) - Identify important new IPv6 protocol/standards work (detailed agenda follows) - Formulate recommendations to the IESG/IAB, re: future IPv6 work (detailed agenda follows) AGENDA: NEW PROTOCOL / STANDARDS WORK - Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) - Securing ICMP/ND/MLD (M. Crawford) - State of Plug-and-Play (B. Hinden) - Site Scoping Issues (T. Narten) - Issues in IPv6 Multihoming (J. Hagino) - Better Support for Multihomed Hosts (R. Draves) - Better Support for Multihomed Sites (E. Nordmark) - Privacy issues with use of EUI-64 IDs (T. Narten) - Source and Destination Address Selection (T. Narten) - Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) AGENDA: FORMULATE RECOMMENDATIONS / S. Deering, B. Hinden - Disposition of IPng w.g. - Extend charter? go on hiatus? - Distribution of work to other existing WGs? - Evaluation of all IETF protocols for "IPv6-readiness"? - Recommendations for establishing new WG(s) or RG(s)? Review State/Completeness of Current IPv6-Related Protocols (B. Hinden) ----------------------------------------------------------------------- REVIEW STATE OF IPv6 PROTOCOLS - Draft Standards - Proposed Standards - Informational - Experimental - Current Internet Drafts DRAFT STANDARDS - RFC2460 Internet Protocol, Version 6 (IPv6) Specification Issue of advancement to full standard over what time period. IESG will want to insure that protocols are mature. Discussion on what IESG will require to move base protocols to Standard. Conclusion that we should get a clear statement of what the IESG will be looking for. - RFC2463 Internet Control Message Protocol (ICMPv6) Add scope-exceeded ICMP error msg code RFC-editor suggested edits Prohibit ICMP error message in response to redirects ACTION: Document editor to do editing pass and resubmit to IESG for same status - RFC2461 Neighbor Discovery for IP Version 6 (IPv6) Forbid RAs from non-forwarding interfaces Issue of NAs without link-layer address Suggestion: guidance/interpretations document - RFC2462 IPv6 Stateless Address Autoconfiguration No issues - RFC1981 Path MTU Discovery for IP version 6 No issues. Note this was the only spec that progressed without recycling! PROPOSED STANDARDS - RFC2373 IP Version 6 Addressing Architecture No issues - RFC2374 An IPv6 Aggregatable Global Unicast Format No issues Should decide on what the "core set" of documents is. - RFC1886 DNS Extensions to support IP version 6 Should this be advanced? Not unless something else that depends on it needs to advance to next level. M. Crawford reported that new specification does not include specification of AAAA, does describe compatibility. Conclusion that both specs will need to coexist with each other. The new specification will need to have it's title changed. It is currently has the same title as RFC1886. - RFC2147 TCP and UDP over IPv6 Jumbograms To be merged with jumbogram hop-by-hop option spec to produce combined document. Work in progress. - RFC2080 RIPng for IPv6 ACTION: Document editor to poke RIP wg to advance to Draft Standard. - RFC2283 Multiprotocol Extensions for BGP-4 Francis reports there will be a new version of this spec, going to draft standard; a separate IPv6 specific part is supposed to be published as Proposed standard. Narten: This is hung in the IESG on a normative reference for another doc Summary: Update to RFC2283 to include IPv6 will be forwarded as proposed; how to it use is drafted, but not published; ACTION: Document editor will poke chairs (or ADs if necessary). PROPOSED STANDARDS - RFC2464 IPv6 Packets over Ethernet Networks No issues - RFC2467 IPv6 Packets over FDDI Networks No issues - RFC2470 IPv6 Packets over Token Ring Networks No issues - RFC2472 IPv6 over PPP No issues General conclusion is that IPv6 over Ethernet/FDDI/TR/ PPP should move to draft standard when 6 month time goes off. Need to start collecting implementation information and issue last call. ACTION: Document Editor start collecting implementation information on IPv6 over Ethernet/FDDI/TR/ PPP and issue last call for Draft Standard when 6 month timer goes off. - RFC2473 Generic Packet Tunneling in IPv6 Specification Need to add language about bidirectional tunnels and recycle at Proposed Standard. - RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks No issues PROPOSED STANDARDS - RFC2492 IPv6 over ATM Networks No issues - RFC2452 MIB for IPv6: TCP No issues - RFC2454 MIB for IPv6: UDP Bert Weinen: plan to merge with the IPv4 versions of TCP & UDP. Pick up with authors and merge. Could be done in the ops area. May not be sufficient in other area. ACTION: O&M AD's to resolve. - RFC2465 MIB for IPv6: Textual Conventions & General Group Question about support for site ids - RFC2466 MIB for IPv6: ICMPv6 Group No issues Question about any Implementations? Nordmark: instrumentation is done to support this, but the MIB browser interface is not done. Dupont: INRIA has complete implementation. PROPOSED STANDARDS - IP Header Compression (Internet Draft) No issues - Transmission of IPv6 over ARCnet Networks (Internet Draft) No issues - Transmission of IPv6 Packets over IPv4 Networks without Explicit Tunnels (Internet Draft) No issues - Reserved IPv6 Subnet Anycast Addresses (Internet Draft) No issues - RFC1752 The Recommendation for IP Next Generation Protocol Question what to do about this? Perhaps time for BCP? ACTION: Document authors (Mankin & Bradner) to decide what to do. INFORMATIONAL - RFC2450 Proposed TLA and NLA Assignment Rules No issues - RFC1881 IPv6 Address Allocation No issues - RFC2375 IPv6 Multicast Address Assignments ACTION: Document editor needs to get IANA to publish this on their web pages - RFC2133 Basic Socket Interface Extensions for IPv6 No issues. Will become historic when new back socket document is published. - Basic Socket Interface Extensions for IPv6 (Internet Draft) No issues - RFC2292 Advanced Sockets API for IPv6 Possible issue with support for home address option from Mobile IP Perhaps pass these to API stds bodies, e.g., Xopen, winsock EXPERIMENTAL - RFC2471 IPv6 Testing Address Allocation No issues - RFC1888 OSI NSAPs and IPv6 Matt C. notes that this is only current way to embed phone numbers in IPv6 addresses CURRENT INTERNET DRAFTS - Initial IPv6 Sub-TLA ID Assignments No issues - Router Renumbering for IPv6 Being revised to support reliability mechanisms; will be another WG last call - Link Local Addressing and Name Resolution in IPv6 There is interest in this - GSE - An Alternate Addressing Architecture for IPv6 ACTION: Document editor will inform secretariate that this has timed out - IPng Analysis of the GSE Proposal Has been submitted to IESG for Informational. CURRENT INTERNET DRAFTS - A method of flexible IPv6 address assignments Waiting for additional comments, then w.g. last call for Informational. - IPv6 Router Alert Option Waiting resolution of differences between IPv4 and IPv6 versions. - The IPv6 Jumbo Payload Option Will be combined with TCP/UDP jumbograms to create single document. - Multicast Listener Discovery (MLD) for IPv6 ACTION: Deering to reissue by ID deadline for Minneapolis - DNS Extensions to support IP version 6 [See discussion on "RFC1886 DNS Extensions to support IP version 6" above] - IPv6 Name Lookups Through ICMP [No notes] - Reverse Address lookup in DNS for IPng ACTION: Document editor will inform secretariate that this has timed out CURRENT INTERNET DRAFTS - OSPF for IPv6 - Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Continue work. - Site Prefixes in Neighbor Discovery Continue work. - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Work progressing slowly in DHCP w.g. - Extensions for DHCPv6 Work progressing slowly in DHCP w.g. - Mobility Support in IPv6 About to start last call in Mobile IP w.g. CURRENT INTERNET DRAFTS - IPv6 over Point-to-Point ATM Link ACTION: Document editor will inform secretariate that this has timed out - Transmission of IPv6 Packets over IEEE 1394 Networks Would like see progress in IPover1284 w.g. - Transmission of IPv6 Packets over Frame Relay Networks ION w.g. about to do w.g. last call. - Forcing Fragmentation to Network MTU [No notes] - The Case for IPv6 Author working on new draft. Reviewed submitted tasks / S. Deering, B. Fink ---------------------------------------------- Summary of submitted tasks with counts of times topic appeared in "[ ]"s followed by sub-topics. Flow ID [7] Multicastcast routing [8] snooping [1] doing it better [1] dns [1] 6 over 4 [1] VoIP [3] mobility [18] dns site local security API dns discovery [1] site multihoming [15] routing usage v6 apps readyness [5] renumbering v6 compatibility text security [10] ND ICMP MLD v6 over v6 management [4] nd mibs snmpv6 tools interior routing [13] isisv6 ospv6 other address allocation [3] aggregation addressing [3] encourage implementers [2] public relations [1] plug & play [11] renumbering [3] tcp survival AAA - dialup [2] diameter VPN [1] Host & router requirements [3] Conformance / compliance [3] Secure DNS [1] Dynamic DNS [1] Exchanges [2] Anycast [5] tcp / udp DNS [4] zones number of roots Measurement [1] Host multihoming [5] Router autoconfig [2] Site definition [1] IPv4 competition [1] Service location [1] QOS - hop by hop reservation [1] Building the 6ren [1] DHCPv6 [3] Ipv6 over IOG [1] IPv6 over 1394 [2] Compatibility testing organization structure [1] Filtering [1] Source & destination selection [3] ND v6 spec problems [1] Free implementations [1] Killer app [1] Transition [2] smooth Diff serv [1] Who are you [1] Icmp scope [1] Link & site local addressing in multihoming [1] V6 interface identifier [1] V6 socket api [2] NIS & NIS + [1] Site local address usage [1] Multi-link subnets [1] Scope discovery [1] Firewalls into the host [1] IPv6 addresses in URL's [1] Discussion of new topics receiving the most votes. Flow label ---------- Deering described current state. One issue is if it has end-to-end semantics, or hop-by-hop. Currently it is end-to-end. No one has defined other usage, though there has been a lot of discussion. C. Jung described how it might relate to MPLS and it could be us to carry the MPLS label. This may be OBE. Matt Crawford noted that MPLS is "multiprotocol", hence it should not deal w/ IPv6 differently from IPv4 or any other protocol J. Bound said that RSVP for IPv6 currently uses the flow label field. C. Jung is uncomfortable with current flow label definition. Telabit said they have implemented flow label and found it useful. Bound see a lot of value with current definition because it is very important for applications for bandwidth brokers in corporate intranets. Deering suggested that we could define flow label to have either end-end or hop-hop semantics by using one bit. Another suggestion that e-e flow label would also be very helpful for user authentication and billing applications. Examples: accountable premium bandwidth. Flow label is a very good place to carry subscription information. Hinden thought there was a loose consensus on keeping the existing wording, authors could provide flow label detail in additional documents Deering outlined what we could do. Choices were: 1) Drop flow label 2) Standardize current flow label 3) Standardize hop-by-hop FL 4) Standardize hybrid 5) Leave as is Polled group. 1) 1 2) 11 3) 0 4) 13 5) 26 No consensus to change behavior or current text. Multicast Routing ----------------- Deering reported that PIM, MOSPF, MBGP have IPv6 extensions. Thinks work is going along well. Action here is to keep them moving forward. Mobility -------- Work is already in another WG charter (e.g., Mobile IP). Is the question mobility in general v.s. mobile IP? Answer: Mobility in general Wireless is one of the media. M. Crawford suggested that we get E163/E164 into IPv6 and let the phone system take it over Routing, Interior and Exterior ----------------------------- Should be in other groups; Noted that OSPF for IPv6 is only a draft. Needs to be advanced. Durand: strange feedback, spec is in draft state but WG is holding due to lack of implementations, but lack of implementations due to lack of spec; little pressure to move v6 related work forward Hinden: routing protocols actually require interoperable implementations to move forward. Deering: OSPF is not a high risk since there is not a competing proposal ISIS is a IPv6 hostile WG so they may have left it out of their charter. -------------------------------------- AGENDA: NEW PROTOCOL / STANDARDS WORK -------------------------------------- Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) --------------------------------------------------------------------------- MOBILE PHONES - More Mobile Phones Sold Yearly than PC's o 163 Million sold in 1998 - Currently 300 Million Users o Expect to reach a Billion in 2005 - Every Phone is Networked - Next version of GSM has IP in it o Every phone will have an IP stack! Phone networks decided v6 was not applicable since it was not a std Deering: new groups now taking std status label more seriously Hinden: Missing piece is wireless mobile, and scale is not addressed Nordmark: Do the implementers understand the scaling issues Bound: Problem is ISP's looking at GSM, others misleading that IETF declared v6 dead T'sirtis: TV's have the same problems Hinden: More things are network appliances, all this has scaling issues PDA's are getting more networking, and converging with phones. PDA'S - PDA Market growing Exponentially - Networking coming to PDA o Wireless just starting - Some PDA's look like Mobile Phones o Some Mobile Phones look like PDA's - IP Stacks are available for PDA's now REQUIREMENTS - Global Addresses o 2 x number of devices o Server Applications - Auto Configuration o Minimum of manual configuration - Security o Encrypted Transmissions o Authenticated Node - Mobility o Roam between Providers - Efficient use of Link o Limited bandwidth available - Compact Implementations o Limited code space HOW DOES IPv6 DO? - Global Addresses o Lots of addresses o Supports large subnets - Auto Configuration o Basic functions fine o DNS? o Secure? - Security o Basic mechanisms OK o Plug and Play? - Mobility o Mobile IPv6 OK - Efficient use of Link o Can Header Compression be used? o With Security? - Compact Implementations o Should be OK NEXT STEPS - Need to Address o Secure Neighbor Discovery and Autoconfiguration o Simpler Service Discovery - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Nordmark: No foreign agent in current spec, general problem is authentication of guest ethernet. Generally calls are dropped when switching providers, so roaming registration happens on startup Securing ICMP/ND/MLD (M. Crawford) ------------------------------------------------ Authenticating an error message - Security policy for informational ICMP ND - Spoofing & DOS attacks MLD ? what is the problem Deering: How do you restrict access to multicast? Crawford: Payload encryption solves the problem, and the key distribution is someone else's ICMP errors & informational - IPsec errors subgroup has worked Solution space for ND - NA security concerns the right of a node to make assertions about an address - RA it is not clear how to delegate the authority ; store certificate at subnet router anycast Draves: how do you resolve NA Crawford: unauthenticated neighbor cache used just to create authenticated cache Nordmark: router authentication Crawford: how do you understand that a given prefix is valid for this subnet; Draves: auto config problem, how do you figure out who is the authority ???: AAA addresses this with pre-configured shared secret Deering: multiple smart card slots in every host Mankin: work in trusted third party solution space as thesis. Solution space for MLD - (blank) Work items - ICMP errors - Invade the IPsec WG and demand more Nordmark: No one is working on the problem of how to make this better ICMP info - Done deal ND - V6 specific as spin-off of this group ; RA is harder MLD - Almost congruent to IGMP? Site Scoping Issues (T. Narten) ------------------------------- Multi-homing Source address selection becomes the key issue How to assign block to multihomed site How to assign addresses to nodes within site Outbound packet filters may block from wrong source Scope must be same for source & destination is a debated issue State of Plug-and-Play (B. Hinden) ----------------------------------- "Dentist's office" Secure "Dentist's office" CONTEXT - Plug and Play likely to be IPv6's Carrot - Makes IP Easy to Use! - Lowers Cost of Ownership for Enterprises and ISP's - Enables Network Appliances o Phones, PDAs, Games, household appliances, etc. SCENARIO 1 - ISOLATED [isolated figure] SCENARIO 2 - CONNECTED [connected figure] SECURE PLUG AND PLAY? - Is Security and Plug and Play an Oxymoron? o Security requires knowledge of a Secret o Autoconfiguration wants to be Stateless - If a node knew the Secret o Could everything else be automatic? o Use Hardware token? WHERE ARE WE NOW - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Service Location for IPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map Comment SLP uses URL's Action: Hinden will write a draft defining preferred literal URL format. WHAT IS MISSING? - DNS o How to find DNS Server o How to register Node DNS name - Services o How to find Printers, File Servers, etc. o Enterprise and Home Office solution - Secure Plug and Play o Simple, Easy, and Still Secure? SOLUTIONS - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Can simple client only version suffice? o Are people implementing it? - DNS Server Location o Need Something New - DNS Name Registration o Status of Dynamic DNS Updating? DNS SERVER LOCATION - Need to Learn o Server Address(s) o Default Domain o Domain Suffix Search list o Others? - Issues o Authentication o Lifetimes o Changing APPROACHES - Add Attribute to ND Router Advertisements o Requires configuring this info in Routers o What if no Router? - DNS Server Advertisements? o Does SL do this? - Anycast Address for DNS Servers o Requires further communication w/ DNS server to get other related information - Multicast Address for DNS Servers o Use Expanding Ring (TTL) Search NEXT STEPS - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Discussion: Nordmark: Will router to the Internet be a substantial services platform as well? Hinden: There will not be a single answer, some want minimalist router, others want full load. Deering: We need something that works like appletalk; when the magic do-it-all box is broken the network still needs to work. Bound: Scenario 2 the box wants to be both a router & host How can telco provide a service on minimal end point, it is important scenario. Durand: It is now my home network so now I the last thing I want is a DNS server. Conclusions: Making the isolated case work well, and securing auto-configuration appear to be the important issues. Issues in IPv6 Multihoming (J. Hagino) -------------------------------------- [Slides by Kazu Yamamoto] Outline - Site multihoming o Good for having more robust internet connectivity o Have been messy in IPv4 o How can we do it in IPv6? - Source address selection is the key issue o Assigning multiple prefixes into a site is harder than you might expect, especially when you have ingress filters in ISPs - What needs to be done? IPv4 multihoming - Use single prefix and non-CIDR route advertisement o Bad for backbone route aggregation - Via NAT box with full route o Single point of failure o Breaks end-to-end bidirectional communication, and uniqueness of addrs - Both are unacceptable for IPv6 Issues in IPv6 multihoming - How to assign address block to multihomed site? o Standard rule or define special rules? - How to assign addresses to nodes in site? o Multiple address/single address How to exchange route with upstream provider? o Both steady state and non-steady state o Aggregation issues - Source address selection o Ingress filtering Issues with outbound packets - Inbound packets are easy o Follows global routing table - Src addr for outbound will be important o Packets may be filtered by ingress filters in upstream ISPs o Src addr should match the provider to be used for exit - End node must be clever enough to choose the appropriate src addr o Routers will not rewrite src addr for you Src addr selection and scoped addr - Scope must be the same for src and dst o There is no reason to choose addrs with different scope! o Reply will not be reaching you o site-local -> global is similar to 10.1.1.1 -> 133.138.1.1 [yamamoto-wideipv6-comm-model (expired) must be revisited - Src addr must be in the same scope as the dest addr - Longest match against dst addr will pick the most appropriate src addr Src addr and outbound provider selection - Operational solutions o Special deal with ISP - all upstream ISPs? - Routing protocol and router extension o Tag default route with provider's prefix o Src addr helps route lookup on routers o Notify bad src addr by ICMP from border routers o Endhost will try all available global source address - Tunnelling between border routers o Check the source, tunnel outgoing packet to proper border router o How can we discover "proper" border router? Wrap-up - Issues o How to assign address block to multihomed site? o How to assign addresses to nodes in site? o How to exchange route with upstream provider? o Source address selection - Many proposals for multi-homing o draft-rfced-info-bates-multihoming-01 looks promising - Source address issues must be nailed down What to do next o Clarify assumptions and goals o Provide sample configurations for multihoming o Routing issues o Address allocation/source address issues o Experiments - Good motivation to move to IPv6, if we can nail this down Source selection: Kazu's extension - Advertise multiple default route into a site, with provider's prefix o Extension necessary to routing protocol - Endhost will choose appropriate source address o Based on try-and-error - Border router or provider will send error reports to endhost Source selection algorithm - Appilcations will try to contact multiple endpoint o D1 -> D2 -> D3 - Kernel or library will try using multiple source o S1 -> S2 -> S3 - It makes: o S1-D1, S2-D1, S3-D1, S1-D2, ... - n^2 algorithm o May be bad if a site connects to 100 ISPs - ICMPv6 reports from border routers o dst unreach, address unreach/no route - choose next destination o dst unreach, access prohibited (new code) - choose next source Open issues - Extension to routing protocol o Advertise provider's prefix into the site with routes o Exchange external routes among border routers - OSPF with some modifications? - Make the assumptions more clear o Site must get full route from providers - How the border router know that he IS the border router? o Configuration variable? - Modification to endhost in this late stage? - Too much knowledge about network toward destination on an endhost - What if border router cannot References - draft-ietf-esd-analysis-03 - draft-berkowitz-multirqmt-01 - draft-rfced-info-bates-multihoming-01 / rfc2260 - draft-akkiraju-nat-multihoming-00 - rfc1887 - draft-ietf-grip-isp-07 - rfc2267 Proposals for IPv6 multihoming - rfc1887 o Assign single prefix to each host o Possibilities for prefix usage - draft-rfced-info-bates-multihoming-01 / rfc2260 o Assign multiple prefixes to each host o BGP issues in border routers - draft-ietf-esd-analysis-03 o Mentions multi-homing issues to some extent - draft-rfced-info-bates-multihoming-01 o looks promising for border router issues o GRE tunnel in non-steady state - opinion may vary - None of these address source address issues Ingress filters in providers - Providers filter packets with invalid src addr o Filter non-customer addr o Prevents addr spoofing - This trend will become more popular o Private addr leakage to global net o Leakage of IPv6 scoped (non-global) addr o Just a matter of router performance and maintenance cost - RFC2267 and draft-ietf-grip-isp-xx encourages ingress filters - There are providers doing this for IPv4 Better Support for Multihomed Hosts (R. Draves) ----------------------------------------------- Multi-homed hosts defined several ways - Host with 2 interfaces into different networks Host with 2 interfaces into the same network - Host with 2 interfaces onto the same link Interfaces have several definitions - Physical interfaces - Virtual interface (will do ND on this) - Pseudo interfaces (will not do ND, just exists as a matter of convenience) VPN's & dial-to ISP becoming more popular Transition mechanisms encourage multi-homing Firewalls exist in this space Problems: Next hop determination (really next link) - ND has conceptual data structures per interface, but no mechanism to identify interface - Proposal to add info to RA Policy decision by user via multicast announced scope - Partial Aggregation is likely to cause more trouble than it helps Detecting same link - Work in IEEE may address this Switching to different interface - General case of the router renumbering issue Weak v.s. strong host model Deering: Old issues that will not converge, best we can do is document the consequences for each choice Better Support for Multihomed Sites (E. Nordmark) ------------------------------------------------- API is the only thing missing from the day's discussion Bound: What part is the API v.s. network layer Deering: The appropriate place for now it the API doc Syn6 scope ID - context dependent definition Modifying all apps is not realistic, so get addr info Bound: Get addr info is not scaling well in deployment Source and Destination Address Selection (T. Narten) ---------------------------------------------------- When initiating which address to choose, selecting 'best' is not easy for applications Favor preferred addresses over deprecated Site local v.s. global scope; choose global if expectation is to be mobile One way to scale multi-homed site; assign prefix for both ISP's Consider adding a 'middleware' layer that addresses policy Privacy issues with use of EUI-64 IDs (T. Narten) ------------------------------------------------- Link prefix obtained from RA. IID could be exploited to identify user. Uproar from privacy groups over hardware serial numbers Potential negative PR Is there a need to change IID more often than each reboot. Use clock value to randomize? Bound: This could be a lot of work, and we already have a lot of work Caller ID as a model Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) --------------------------------------------------------------------- [No notes] Formulate recommendations to the IESG/IAB, re: future IPv6 work (S. Deering, B. Hinden) ---------------------------------------------------------------- Note: This session was held on Thursday Feb 4. WG Docs to Finish up - MLD - ICMP revision o Scope-exceeded err, no error to redirect, editorial - Advanced API - router renumbering - merged jumbo gram specs - generic tunneling (add bidirectional tunnels) Unfinished IPng W.G. work - Flow label standardization (no action now) - scope issues, source address selection - multihomed host/site issues - autoconfig <-> DNS <-> mobile IP story - URL format for IPv6 literal address. - dial-up issues? Work still covered under original charter. Discussion about what "autoconfig <-> DNS story" means. Mechanisms may be there, but need to describe. Additional discussion. Comment that the story is written. Probably no IPng protocol work required. Nordmark made comment that what about creating names for devices w/out keyboards (e.g., phones, light switches, etc.). Need generic names and/or way of updating name via the network. New IPng w.g. Tasks - Specify transient interface IDs for privacy concerns - Specify E.164-in-IPv6 addressing - Specify IPv6 over additional media o USB ? o Bluetooth ? o 1O Gig pipe ? o IEEE 1394 ? - Start an IPv6 "Host/Router requirements" document Other Current w.g. chores - Keep all w.g. docs moving along publication / standardization track - Identify "base spec" of docs for advancement to full standard Other lower-layers WGs to prod - DNS, DHCPv6, IPv6-over-Firewire, Mobile IP, RIPv2, OSPF,ISIS, IDR, MOSPF, PIM, Diff-Serv, AAA (Diameter), Malloc (maybe) New work for other W.G.s - IPv6 readiness check (incl. MIBS, etc.) - Secure ICMP/ND (IPSEC) - Authenticate, Autoconfiged hosts (IPSEC) Other idea to pursue, perhaps in new w.g.(s) - Specify how exchanges can work - TCP/UDP/host use of anycast - Next level of plug-n-play ("appletalk"-like) - 6-over-4 cut-through (NHRP-like) - More complete story for billions of mobile devices (esp. phones) - Multi-link subnets (single subnet spans multiple links) - Scope-name discovery - Conformance tests - Tools for reducing network mgt costs Possible items for IRTF - Transport use of global interface IDs - Higher-layer survival of renumbering - Router auto-config / auto subnet numbering - "Better" multicast address alloc. - "Better" VPNs - "Better" billing/accounting opportunities - Architected MLD snooping - Firewall in the host - ICMPv3 -> MLD Suggestion to add better multicast routing for IPv6. Other - Convey message that "IPv6" is done"; time to implement deploy, and port applications - Review/strengthen "cast for IPv6", "case against NAT" docs - Keep prodding IP address registry - Develop a voice-over-IPv6 story - Participate move in other WGs - Pass API docs to other stds bodies Suggestion to find individuals to track work in other working groups. A specific individual for each group. Will do a call for volunteers on mailing list. Suggestion by AD that we should update charter focus on remaining work and how to get to completion. Discussion about how/when to wrap up the working group. Suggestion that we go on "hiatus" after "base specs" are completed (Draft standard). Other comments that it is important to continue the w.g. to have an "official" forum to communicate / send recommendations to ICAN, IAB, IP registries, etc. Chairs will discuss future w.g. steps w/ AD's and make recommendation to w.g. ------------------------------------------------------------------------- ------------------------------------------------------------------------- Meeting Adjourned ------------------------------------------------------------------------- ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 11 14:03:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA29948 for ipng-dist; Thu, 11 Mar 1999 13:59:35 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29941 for ; Thu, 11 Mar 1999 13:59:26 -0800 (PST) From: hinden@iprg.nokia.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id NAA28781 for ; Thu, 11 Mar 1999 13:59:24 -0800 (PST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA27574 for ; Thu, 11 Mar 1999 13:59:24 -0800 (PST) Received: from [195.99.52.230] (helo=thss-barney.THSS-BARNEY) by carbon with esmtp (Exim 2.05 #1) id 10LDRz-0003oU-00 for ipng@sunroof.eng.sun.com; Thu, 11 Mar 1999 21:57:08 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GRLTD4GT; Thu, 11 Mar 1999 22:00:10 -0000 Message-Id: Date: Thu, 11 Mar 1999 21:57:08 +0000 To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.eng.sun.com Thu Mar 11 21:07:34 1999 Received: from [193.113.210.238] (helo=mail2.) by praseodumium with smtp (Exim 2.05 #1) id 10LCg2-0004o9-00 for nbc@btinternet.com; Thu, 11 Mar 1999 21:07:34 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id UAA14536; Thu, 11 Mar 1999 20:14:47 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP) with ESMTP; Thu, 11 Mar 1999 20:14:45 +0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29242; Thu, 11 Mar 1999 12:12:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id MAA16867; Thu, 11 Mar 1999 12:12:28 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA29668 for ipng-dist; Thu, 11 Mar 1999 11:57:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29661 for ; Thu, 11 Mar 1999 11:57:41 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id LAA12618 for ; Thu, 11 Mar 1999 11:57:34 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA09255 for ; Thu, 11 Mar 1999 11:55:59 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA20081; Thu, 11 Mar 1999 11:55:58 -0800 (PST) Message-Id: <3.0.5.32.19990311115527.03abd910@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Mar 1999 11:55:27 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7307) Updated IPng w.g. Minutes from Grenoble Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Working Group Meeting February 2-4, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco IPng Co-Chairs Bob Fink / LBNL Tony Hain / Microsoft NGTRANS Co-Chairs Minutes taken by Tony Hain, Steve Deering, Bob Fink and Bob Hinden. Edited by Bob Hinden. Minutes for NGTRANS and deployment activities published separately. ----------- IPng / NGTRANS INTERIM MEETING February 2-4, 1999 Steve Deering introduced meeting. Alain Durand gave local arrangements, terminal room information, daily schedule. 92 registered to attend. 25 from France 32 from elsewhere in Europe 28 from North America 7 from Japan SCHEDULE Tuesday 8:00 Registration 9:00 Welcome speech by IMAG's director 9:10 Morning session 11:30 Lunch break & registration 13:00 Afternoon session 1 15:00 Afternoon break 15:30 Afternoon session 2 18:00 End 20:00 Rendezvous at Bus station (next to the train station) to take a bus to go to the social. 23:00 Return from the social Wednesday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End Thursday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End First day is an IPng w.g. meeting. Second day is an NGTRANS meeting. Third day is deployment activities (this is not an IETF meeting). ---------------------------------------------------------------------- ---------------------------------------------------------------------- IPng WORKING GROUP February 2, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco Co-Chairs Introduction / S. Deering ------------------------- Steve Deering introduced the meeting and collected the attendee required issue lists. Chairs will review lunch break and present the results. IPng charter basically complete, documents are at various points in the standards process. Document review for completeness, followed by issues or additional work. Continue, Recharter, hibernate decision. Review and update agenda / S. Deering -------------------------------------- The agenda was reviewed. The following agenda resulted: IPng AGENDA - Introduction / S. Deering - Collect attendee required issue lists (S. Deering) - Review and update agenda (S. Deering) - Review state/completeness of current IPv6-related protocols (B. Hinden) - Identify important new IPv6 protocol/standards work (detailed agenda follows) - Formulate recommendations to the IESG/IAB, re: future IPv6 work (detailed agenda follows) AGENDA: NEW PROTOCOL / STANDARDS WORK - Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) - Securing ICMP/ND/MLD (M. Crawford) - State of Plug-and-Play (B. Hinden) - Site Scoping Issues (T. Narten) - Issues in IPv6 Multihoming (J. Hagino) - Better Support for Multihomed Hosts (R. Draves) - Better Support for Multihomed Sites (E. Nordmark) - Privacy issues with use of EUI-64 IDs (T. Narten) - Source and Destination Address Selection (T. Narten) - Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) AGENDA: FORMULATE RECOMMENDATIONS / S. Deering, B. Hinden - Disposition of IPng w.g. - Extend charter? go on hiatus? - Distribution of work to other existing WGs? - Evaluation of all IETF protocols for "IPv6-readiness"? - Recommendations for establishing new WG(s) or RG(s)? Review State/Completeness of Current IPv6-Related Protocols (B. Hinden) ----------------------------------------------------------------------- REVIEW STATE OF IPv6 PROTOCOLS - Draft Standards - Proposed Standards - Informational - Experimental - Current Internet Drafts DRAFT STANDARDS - RFC2460 Internet Protocol, Version 6 (IPv6) Specification Issue of advancement to full standard over what time period. IESG will want to insure that protocols are mature. Discussion on what IESG will require to move base protocols to Standard. Conclusion that we should get a clear statement of what the IESG will be looking for. - RFC2463 Internet Control Message Protocol (ICMPv6) Add scope-exceeded ICMP error msg code RFC-editor suggested edits Prohibit ICMP error message in response to redirects ACTION: Document editor to do editing pass and resubmit to IESG for same status - RFC2461 Neighbor Discovery for IP Version 6 (IPv6) Forbid RAs from non-forwarding interfaces Issue of NAs without link-layer address Suggestion: guidance/interpretations document - RFC2462 IPv6 Stateless Address Autoconfiguration No issues - RFC1981 Path MTU Discovery for IP version 6 No issues. Note this was the only spec that progressed without recycling! PROPOSED STANDARDS - RFC2373 IP Version 6 Addressing Architecture No issues - RFC2374 An IPv6 Aggregatable Global Unicast Format No issues Should decide on what the "core set" of documents is. - RFC1886 DNS Extensions to support IP version 6 Should this be advanced? Not unless something else that depends on it needs to advance to next level. M. Crawford reported that new specification does not include specification of AAAA, does describe compatibility. Conclusion that both specs will need to coexist with each other. The new specification will need to have it's title changed. It is currently has the same title as RFC1886. - RFC2147 TCP and UDP over IPv6 Jumbograms To be merged with jumbogram hop-by-hop option spec to produce combined document. Work in progress. - RFC2080 RIPng for IPv6 ACTION: Document editor to poke RIP wg to advance to Draft Standard. - RFC2283 Multiprotocol Extensions for BGP-4 Francis reports there will be a new version of this spec, going to draft standard; a separate IPv6 specific part is supposed to be published as Proposed standard. Narten: This is hung in the IESG on a normative reference for another doc Summary: Update to RFC2283 to include IPv6 will be forwarded as proposed; how to it use is drafted, but not published; ACTION: Document editor will poke chairs (or ADs if necessary). PROPOSED STANDARDS - RFC2464 IPv6 Packets over Ethernet Networks No issues - RFC2467 IPv6 Packets over FDDI Networks No issues - RFC2470 IPv6 Packets over Token Ring Networks No issues - RFC2472 IPv6 over PPP No issues General conclusion is that IPv6 over Ethernet/FDDI/TR/ PPP should move to draft standard when 6 month time goes off. Need to start collecting implementation information and issue last call. ACTION: Document Editor start collecting implementation information on IPv6 over Ethernet/FDDI/TR/ PPP and issue last call for Draft Standard when 6 month timer goes off. - RFC2473 Generic Packet Tunneling in IPv6 Specification Need to add language about bidirectional tunnels and recycle at Proposed Standard. - RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks No issues PROPOSED STANDARDS - RFC2492 IPv6 over ATM Networks No issues - RFC2452 MIB for IPv6: TCP No issues - RFC2454 MIB for IPv6: UDP Bert Weinen: plan to merge with the IPv4 versions of TCP & UDP. Pick up with authors and merge. Could be done in the ops area. May not be sufficient in other area. ACTION: O&M AD's to resolve. - RFC2465 MIB for IPv6: Textual Conventions & General Group Question about support for site ids - RFC2466 MIB for IPv6: ICMPv6 Group No issues Question about any Implementations? Nordmark: instrumentation is done to support this, but the MIB browser interface is not done. Dupont: INRIA has complete implementation. PROPOSED STANDARDS - IP Header Compression (Internet Draft) No issues - Transmission of IPv6 over ARCnet Networks (Internet Draft) No issues - Transmission of IPv6 Packets over IPv4 Networks without Explicit Tunnels (Internet Draft) No issues - Reserved IPv6 Subnet Anycast Addresses (Internet Draft) No issues - RFC1752 The Recommendation for IP Next Generation Protocol Question what to do about this? Perhaps time for BCP? ACTION: Document authors (Mankin & Bradner) to decide what to do. INFORMATIONAL - RFC2450 Proposed TLA and NLA Assignment Rules No issues - RFC1881 IPv6 Address Allocation No issues - RFC2375 IPv6 Multicast Address Assignments ACTION: Document editor needs to get IANA to publish this on their web pages - RFC2133 Basic Socket Interface Extensions for IPv6 No issues. Will become historic when new back socket document is published. - Basic Socket Interface Extensions for IPv6 (Internet Draft) No issues - RFC2292 Advanced Sockets API for IPv6 Possible issue with support for home address option from Mobile IP Perhaps pass these to API stds bodies, e.g., Xopen, winsock EXPERIMENTAL - RFC2471 IPv6 Testing Address Allocation No issues - RFC1888 OSI NSAPs and IPv6 Matt C. notes that this is only current way to embed phone numbers in IPv6 addresses CURRENT INTERNET DRAFTS - Initial IPv6 Sub-TLA ID Assignments No issues - Router Renumbering for IPv6 Being revised to support reliability mechanisms; will be another WG last call - Link Local Addressing and Name Resolution in IPv6 There is interest in this - GSE - An Alternate Addressing Architecture for IPv6 ACTION: Document editor will inform secretariate that this has timed out - IPng Analysis of the GSE Proposal Has been submitted to IESG for Informational. CURRENT INTERNET DRAFTS - A method of flexible IPv6 address assignments Waiting for additional comments, then w.g. last call for Informational. - IPv6 Router Alert Option Waiting resolution of differences between IPv4 and IPv6 versions. - The IPv6 Jumbo Payload Option Will be combined with TCP/UDP jumbograms to create single document. - Multicast Listener Discovery (MLD) for IPv6 ACTION: Deering to reissue by ID deadline for Minneapolis - DNS Extensions to support IP version 6 [See discussion on "RFC1886 DNS Extensions to support IP version 6" above] - IPv6 Name Lookups Through ICMP [No notes] - Reverse Address lookup in DNS for IPng ACTION: Document editor will inform secretariate that this has timed out CURRENT INTERNET DRAFTS - OSPF for IPv6 - Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Continue work. - Site Prefixes in Neighbor Discovery Continue work. - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Work progressing slowly in DHCP w.g. - Extensions for DHCPv6 Work progressing slowly in DHCP w.g. - Mobility Support in IPv6 About to start last call in Mobile IP w.g. CURRENT INTERNET DRAFTS - IPv6 over Point-to-Point ATM Link ACTION: Document editor will inform secretariate that this has timed out - Transmission of IPv6 Packets over IEEE 1394 Networks Would like see progress in IPover1284 w.g. - Transmission of IPv6 Packets over Frame Relay Networks ION w.g. about to do w.g. last call. - Forcing Fragmentation to Network MTU [No notes] - The Case for IPv6 Author working on new draft. Reviewed submitted tasks / S. Deering, B. Fink ---------------------------------------------- Summary of submitted tasks with counts of times topic appeared in "[ ]"s followed by sub-topics. Flow ID [7] Multicastcast routing [8] snooping [1] doing it better [1] dns [1] 6 over 4 [1] VoIP [3] mobility [18] dns site local security API dns discovery [1] site multihoming [15] routing usage v6 apps readyness [5] renumbering v6 compatibility text security [10] ND ICMP MLD v6 over v6 management [4] nd mibs snmpv6 tools interior routing [13] isisv6 ospv6 other address allocation [3] aggregation addressing [3] encourage implementers [2] public relations [1] plug & play [11] renumbering [3] tcp survival AAA - dialup [2] diameter VPN [1] Host & router requirements [3] Conformance / compliance [3] Secure DNS [1] Dynamic DNS [1] Exchanges [2] Anycast [5] tcp / udp DNS [4] zones number of roots Measurement [1] Host multihoming [5] Router autoconfig [2] Site definition [1] IPv4 competition [1] Service location [1] QOS - hop by hop reservation [1] Building the 6ren [1] DHCPv6 [3] Ipv6 over IOG [1] IPv6 over 1394 [2] Compatibility testing organization structure [1] Filtering [1] Source & destination selection [3] ND v6 spec problems [1] Free implementations [1] Killer app [1] Transition [2] smooth Diff serv [1] Who are you [1] Icmp scope [1] Link & site local addressing in multihoming [1] V6 interface identifier [1] V6 socket api [2] NIS & NIS + [1] Site local address usage [1] Multi-link subnets [1] Scope discovery [1] Firewalls into the host [1] IPv6 addresses in URL's [1] Discussion of new topics receiving the most votes. Flow label ---------- Deering described current state. One issue is if it has end-to-end semantics, or hop-by-hop. Currently it is end-to-end. No one has defined other usage, though there has been a lot of discussion. C. Jung described how it might relate to MPLS and it could be us to carry the MPLS label. This may be OBE. Matt Crawford noted that MPLS is "multiprotocol", hence it should not deal w/ IPv6 differently from IPv4 or any other protocol J. Bound said that RSVP for IPv6 currently uses the flow label field. C. Jung is uncomfortable with current flow label definition. Telabit said they have implemented flow label and found it useful. Bound see a lot of value with current definition because it is very important for applications for bandwidth brokers in corporate intranets. Deering suggested that we could define flow label to have either end-end or hop-hop semantics by using one bit. Another suggestion that e-e flow label would also be very helpful for user authentication and billing applications. Examples: accountable premium bandwidth. Flow label is a very good place to carry subscription information. Hinden thought there was a loose consensus on keeping the existing wording, authors could provide flow label detail in additional documents Deering outlined what we could do. Choices were: 1) Drop flow label 2) Standardize current flow label 3) Standardize hop-by-hop FL 4) Standardize hybrid 5) Leave as is Polled group. 1) 1 2) 11 3) 0 4) 13 5) 26 No consensus to change behavior or current text. Multicast Routing ----------------- Deering reported that PIM, MOSPF, MBGP have IPv6 extensions. Thinks work is going along well. Action here is to keep them moving forward. Mobility -------- Work is already in another WG charter (e.g., Mobile IP). Is the question mobility in general v.s. mobile IP? Answer: Mobility in general Wireless is one of the media. M. Crawford suggested that we get E163/E164 into IPv6 and let the phone system take it over Routing, Interior and Exterior ----------------------------- Should be in other groups; Noted that OSPF for IPv6 is only a draft. Needs to be advanced. Durand: strange feedback, spec is in draft state but WG is holding due to lack of implementations, but lack of implementations due to lack of spec; little pressure to move v6 related work forward Hinden: routing protocols actually require interoperable implementations to move forward. Deering: OSPF is not a high risk since there is not a competing proposal ISIS is a IPv6 hostile WG so they may have left it out of their charter. -------------------------------------- AGENDA: NEW PROTOCOL / STANDARDS WORK -------------------------------------- Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) --------------------------------------------------------------------------- MOBILE PHONES - More Mobile Phones Sold Yearly than PC's o 163 Million sold in 1998 - Currently 300 Million Users o Expect to reach a Billion in 2005 - Every Phone is Networked - Next version of GSM has IP in it o Every phone will have an IP stack! Phone networks decided v6 was not applicable since it was not a std Deering: new groups now taking std status label more seriously Hinden: Missing piece is wireless mobile, and scale is not addressed Nordmark: Do the implementers understand the scaling issues Bound: Problem is ISP's looking at GSM, others misleading that IETF declared v6 dead T'sirtis: TV's have the same problems Hinden: More things are network appliances, all this has scaling issues PDA's are getting more networking, and converging with phones. PDA'S - PDA Market growing Exponentially - Networking coming to PDA o Wireless just starting - Some PDA's look like Mobile Phones o Some Mobile Phones look like PDA's - IP Stacks are available for PDA's now REQUIREMENTS - Global Addresses o 2 x number of devices o Server Applications - Auto Configuration o Minimum of manual configuration - Security o Encrypted Transmissions o Authenticated Node - Mobility o Roam between Providers - Efficient use of Link o Limited bandwidth available - Compact Implementations o Limited code space HOW DOES IPv6 DO? - Global Addresses o Lots of addresses o Supports large subnets - Auto Configuration o Basic functions fine o DNS? o Secure? - Security o Basic mechanisms OK o Plug and Play? - Mobility o Mobile IPv6 OK - Efficient use of Link o Can Header Compression be used? o With Security? - Compact Implementations o Should be OK NEXT STEPS - Need to Address o Secure Neighbor Discovery and Autoconfiguration o Simpler Service Discovery - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Nordmark: No foreign agent in current spec, general problem is authentication of guest ethernet. Generally calls are dropped when switching providers, so roaming registration happens on startup Securing ICMP/ND/MLD (M. Crawford) ------------------------------------------------ Authenticating an error message - Security policy for informational ICMP ND - Spoofing & DOS attacks MLD ? what is the problem Deering: How do you restrict access to multicast? Crawford: Payload encryption solves the problem, and the key distribution is someone else's ICMP errors & informational - IPsec errors subgroup has worked Solution space for ND - NA security concerns the right of a node to make assertions about an address - RA it is not clear how to delegate the authority ; store certificate at subnet router anycast Draves: how do you resolve NA Crawford: unauthenticated neighbor cache used just to create authenticated cache Nordmark: router authentication Crawford: how do you understand that a given prefix is valid for this subnet; Draves: auto config problem, how do you figure out who is the authority ???: AAA addresses this with pre-configured shared secret Deering: multiple smart card slots in every host Mankin: work in trusted third party solution space as thesis. Solution space for MLD - (blank) Work items - ICMP errors - Invade the IPsec WG and demand more Nordmark: No one is working on the problem of how to make this better ICMP info - Done deal ND - V6 specific as spin-off of this group ; RA is harder MLD - Almost congruent to IGMP? Site Scoping Issues (T. Narten) ------------------------------- Multi-homing Source address selection becomes the key issue How to assign block to multihomed site How to assign addresses to nodes within site Outbound packet filters may block from wrong source Scope must be same for source & destination is a debated issue State of Plug-and-Play (B. Hinden) ----------------------------------- "Dentist's office" Secure "Dentist's office" CONTEXT - Plug and Play likely to be IPv6's Carrot - Makes IP Easy to Use! - Lowers Cost of Ownership for Enterprises and ISP's - Enables Network Appliances o Phones, PDAs, Games, household appliances, etc. SCENARIO 1 - ISOLATED [isolated figure] SCENARIO 2 - CONNECTED [connected figure] SECURE PLUG AND PLAY? - Is Security and Plug and Play an Oxymoron? o Security requires knowledge of a Secret o Autoconfiguration wants to be Stateless - If a node knew the Secret o Could everything else be automatic? o Use Hardware token? WHERE ARE WE NOW - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Service Location for IPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map Comment SLP uses URL's Action: Hinden will write a draft defining preferred literal URL format. WHAT IS MISSING? - DNS o How to find DNS Server o How to register Node DNS name - Services o How to find Printers, File Servers, etc. o Enterprise and Home Office solution - Secure Plug and Play o Simple, Easy, and Still Secure? SOLUTIONS - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Can simple client only version suffice? o Are people implementing it? - DNS Server Location o Need Something New - DNS Name Registration o Status of Dynamic DNS Updating? DNS SERVER LOCATION - Need to Learn o Server Address(s) o Default Domain o Domain Suffix Search list o Others? - Issues o Authentication o Lifetimes o Changing APPROACHES - Add Attribute to ND Router Advertisements o Requires configuring this info in Routers o What if no Router? - DNS Server Advertisements? o Does SL do this? - Anycast Address for DNS Servers o Requires further communication w/ DNS server to get other related information - Multicast Address for DNS Servers o Use Expanding Ring (TTL) Search NEXT STEPS - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Discussion: Nordmark: Will router to the Internet be a substantial services platform as well? Hinden: There will not be a single answer, some want minimalist router, others want full load. Deering: We need something that works like appletalk; when the magic do-it-all box is broken the network still needs to work. Bound: Scenario 2 the box wants to be both a router & host How can telco provide a service on minimal end point, it is important scenario. Durand: It is now my home network so now I the last thing I want is a DNS server. Conclusions: Making the isolated case work well, and securing auto-configuration appear to be the important issues. Issues in IPv6 Multihoming (J. Hagino) -------------------------------------- [Slides by Kazu Yamamoto] Outline - Site multihoming o Good for having more robust internet connectivity o Have been messy in IPv4 o How can we do it in IPv6? - Source address selection is the key issue o Assigning multiple prefixes into a site is harder than you might expect, especially when you have ingress filters in ISPs - What needs to be done? IPv4 multihoming - Use single prefix and non-CIDR route advertisement o Bad for backbone route aggregation - Via NAT box with full route o Single point of failure o Breaks end-to-end bidirectional communication, and uniqueness of addrs - Both are unacceptable for IPv6 Issues in IPv6 multihoming - How to assign address block to multihomed site? o Standard rule or define special rules? - How to assign addresses to nodes in site? o Multiple address/single address How to exchange route with upstream provider? o Both steady state and non-steady state o Aggregation issues - Source address selection o Ingress filtering Issues with outbound packets - Inbound packets are easy o Follows global routing table - Src addr for outbound will be important o Packets may be filtered by ingress filters in upstream ISPs o Src addr should match the provider to be used for exit - End node must be clever enough to choose the appropriate src addr o Routers will not rewrite src addr for you Src addr selection and scoped addr - Scope must be the same for src and dst o There is no reason to choose addrs with different scope! o Reply will not be reaching you o site-local -> global is similar to 10.1.1.1 -> 133.138.1.1 [yamamoto-wideipv6-comm-model (expired) must be revisited - Src addr must be in the same scope as the dest addr - Longest match against dst addr will pick the most appropriate src addr Src addr and outbound provider selection - Operational solutions o Special deal with ISP - all upstream ISPs? - Routing protocol and router extension o Tag default route with provider's prefix o Src addr helps route lookup on routers o Notify bad src addr by ICMP from border routers o Endhost will try all available global source address - Tunnelling between border routers o Check the source, tunnel outgoing packet to proper border router o How can we discover "proper" border router? Wrap-up - Issues o How to assign address block to multihomed site? o How to assign addresses to nodes in site? o How to exchange route with upstream provider? o Source address selection - Many proposals for multi-homing o draft-rfced-info-bates-multihoming-01 looks promising - Source address issues must be nailed down What to do next o Clarify assumptions and goals o Provide sample configurations for multihoming o Routing issues o Address allocation/source address issues o Experiments - Good motivation to move to IPv6, if we can nail this down Source selection: Kazu's extension - Advertise multiple default route into a site, with provider's prefix o Extension necessary to routing protocol - Endhost will choose appropriate source address o Based on try-and-error - Border router or provider will send error reports to endhost Source selection algorithm - Appilcations will try to contact multiple endpoint o D1 -> D2 -> D3 - Kernel or library will try using multiple source o S1 -> S2 -> S3 - It makes: o S1-D1, S2-D1, S3-D1, S1-D2, ... - n^2 algorithm o May be bad if a site connects to 100 ISPs - ICMPv6 reports from border routers o dst unreach, address unreach/no route - choose next destination o dst unreach, access prohibited (new code) - choose next source Open issues - Extension to routing protocol o Advertise provider's prefix into the site with routes o Exchange external routes among border routers - OSPF with some modifications? - Make the assumptions more clear o Site must get full route from providers - How the border router know that he IS the border router? o Configuration variable? - Modification to endhost in this late stage? - Too much knowledge about network toward destination on an endhost - What if border router cannot References - draft-ietf-esd-analysis-03 - draft-berkowitz-multirqmt-01 - draft-rfced-info-bates-multihoming-01 / rfc2260 - draft-akkiraju-nat-multihoming-00 - rfc1887 - draft-ietf-grip-isp-07 - rfc2267 Proposals for IPv6 multihoming - rfc1887 o Assign single prefix to each host o Possibilities for prefix usage - draft-rfced-info-bates-multihoming-01 / rfc2260 o Assign multiple prefixes to each host o BGP issues in border routers - draft-ietf-esd-analysis-03 o Mentions multi-homing issues to some extent - draft-rfced-info-bates-multihoming-01 o looks promising for border router issues o GRE tunnel in non-steady state - opinion may vary - None of these address source address issues Ingress filters in providers - Providers filter packets with invalid src addr o Filter non-customer addr o Prevents addr spoofing - This trend will become more popular o Private addr leakage to global net o Leakage of IPv6 scoped (non-global) addr o Just a matter of router performance and maintenance cost - RFC2267 and draft-ietf-grip-isp-xx encourages ingress filters - There are providers doing this for IPv4 Better Support for Multihomed Hosts (R. Draves) ----------------------------------------------- Multi-homed hosts defined several ways - Host with 2 interfaces into different networks Host with 2 interfaces into the same network - Host with 2 interfaces onto the same link Interfaces have several definitions - Physical interfaces - Virtual interface (will do ND on this) - Pseudo interfaces (will not do ND, just exists as a matter of convenience) VPN's & dial-to ISP becoming more popular Transition mechanisms encourage multi-homing Firewalls exist in this space Problems: Next hop determination (really next link) - ND has conceptual data structures per interface, but no mechanism to identify interface - Proposal to add info to RA Policy decision by user via multicast announced scope - Partial Aggregation is likely to cause more trouble than it helps Detecting same link - Work in IEEE may address this Switching to different interface - General case of the router renumbering issue Weak v.s. strong host model Deering: Old issues that will not converge, best we can do is document the consequences for each choice Better Support for Multihomed Sites (E. Nordmark) ------------------------------------------------- API is the only thing missing from the day's discussion Bound: What part is the API v.s. network layer Deering: The appropriate place for now it the API doc Syn6 scope ID - context dependent definition Modifying all apps is not realistic, so get addr info Bound: Get addr info is not scaling well in deployment Source and Destination Address Selection (T. Narten) ---------------------------------------------------- When initiating which address to choose, selecting 'best' is not easy for applications Favor preferred addresses over deprecated Site local v.s. global scope; choose global if expectation is to be mobile One way to scale multi-homed site; assign prefix for both ISP's Consider adding a 'middleware' layer that addresses policy Privacy issues with use of EUI-64 IDs (T. Narten) ------------------------------------------------- Link prefix obtained from RA. IID could be exploited to identify user. Uproar from privacy groups over hardware serial numbers Potential negative PR Is there a need to change IID more often than each reboot. Use clock value to randomize? Bound: This could be a lot of work, and we already have a lot of work Caller ID as a model Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) --------------------------------------------------------------------- [No notes] Formulate recommendations to the IESG/IAB, re: future IPv6 work (S. Deering, B. Hinden) ---------------------------------------------------------------- Note: This session was held on Thursday Feb 4. WG Docs to Finish up - MLD - ICMP revision o Scope-exceeded err, no error to redirect, editorial - Advanced API - router renumbering - merged jumbo gram specs - generic tunneling (add bidirectional tunnels) Unfinished IPng W.G. work - Flow label standardization (no action now) - scope issues, source address selection - multihomed host/site issues - autoconfig <-> DNS <-> mobile IP story - URL format for IPv6 literal address. - dial-up issues? Work still covered under original charter. Discussion about what "autoconfig <-> DNS story" means. Mechanisms may be there, but need to describe. Additional discussion. Comment that the story is written. Probably no IPng protocol work required. Nordmark made comment that what about creating names for devices w/out keyboards (e.g., phones, light switches, etc.). Need generic names and/or way of updating name via the network. New IPng w.g. Tasks - Specify transient interface IDs for privacy concerns - Specify E.164-in-IPv6 addressing - Specify IPv6 over additional media o USB ? o Bluetooth ? o 1O Gig pipe ? o IEEE 1394 ? - Start an IPv6 "Host/Router requirements" document Other Current w.g. chores - Keep all w.g. docs moving along publication / standardization track - Identify "base spec" of docs for advancement to full standard Other lower-layers WGs to prod - DNS, DHCPv6, IPv6-over-Firewire, Mobile IP, RIPv2, OSPF,ISIS, IDR, MOSPF, PIM, Diff-Serv, AAA (Diameter), Malloc (maybe) New work for other W.G.s - IPv6 readiness check (incl. MIBS, etc.) - Secure ICMP/ND (IPSEC) - Authenticate, Autoconfiged hosts (IPSEC) Other idea to pursue, perhaps in new w.g.(s) - Specify how exchanges can work - TCP/UDP/host use of anycast - Next level of plug-n-play ("appletalk"-like) - 6-over-4 cut-through (NHRP-like) - More complete story for billions of mobile devices (esp. phones) - Multi-link subnets (single subnet spans multiple links) - Scope-name discovery - Conformance tests - Tools for reducing network mgt costs Possible items for IRTF - Transport use of global interface IDs - Higher-layer survival of renumbering - Router auto-config / auto subnet numbering - "Better" multicast address alloc. - "Better" VPNs - "Better" billing/accounting opportunities - Architected MLD snooping - Firewall in the host - ICMPv3 -> MLD Suggestion to add better multicast routing for IPv6. Other - Convey message that "IPv6" is done"; time to implement deploy, and port applications - Review/strengthen "cast for IPv6", "case against NAT" docs - Keep prodding IP address registry - Develop a voice-over-IPv6 story - Participate move in other WGs - Pass API docs to other stds bodies Suggestion to find individuals to track work in other working groups. A specific individual for each group. Will do a call for volunteers on mailing list. Suggestion by AD that we should update charter focus on remaining work and how to get to completion. Discussion about how/when to wrap up the working group. Suggestion that we go on "hiatus" after "base specs" are completed (Draft standard). Other comments that it is important to continue the w.g. to have an "official" forum to communicate / send recommendations to ICAN, IAB, IP registries, etc. Chairs will discuss future w.g. steps w/ AD's and make recommendation to w.g. ------------------------------------------------------------------------- ------------------------------------------------------------------------- Meeting Adjourned ------------------------------------------------------------------------- ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 11 16:17:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA00207 for ipng-dist; Thu, 11 Mar 1999 16:10:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00199 for ; Thu, 11 Mar 1999 16:10:16 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id QAA12724 for ; Thu, 11 Mar 1999 16:10:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA21131 for ; Thu, 11 Mar 1999 16:10:14 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA03753; Thu, 11 Mar 1999 16:10:13 -0800 (PST) Message-Id: <3.0.5.32.19990311160943.00ab7970@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Mar 1999 16:09:43 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7308) Proposed Minneapolis IPng W.G. Agenda Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The IPng working group will meet for two sessions at the Minneapolis IETF. The current sessions are: MONDAY, March 15, 1999 0930-1130 (Salon D) 1930-2200 (Salon D) Both sessions will be Multicast. Also, the NGTRANS w.g. will be meeting at the Minneapolis IETF on TUESDAY, March 16, 1999 0900-1115 (Salon G) 1545-1800 (Salon A) Attached is the proposed agenda for the IPng w.g. meeting. Please send us any changes and additions. Please note that if you are listed to speak on a particular topic/document (and had not request an agenda slot) it is because the chairs think there has been an update or change since the last meeting and it is useful to discuss this at the w.g. meeting. Thanks, Bob Hinden / Steve Deering -------------------------------------------- MONDAY, March 15, 1999 0930-1130 (Salon D) MONDAY, March 15, 1999 1930-2200 (Salon D) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) New Internet Draft Procedure / R. Hinden (5 min) Current Deployment Activities / P. Metzger (10 min) UNH Interoperability Testing / W. Lenharth (5 min) 6REN Status / R. Fink (5 min) Document Status / R. Hinden (15 min) Report from IPng Grenoble Meeting / S. Deering (45 min) Mobile IPv6 Status / D. Johnson (5 min) DNS Extension Status / M. Crawford (5 min) Router Renumbering Status / M. Crawford (5 min) Multicast Listener Discovery Protocol / S. Deering (5 min) Tunnel broker / I. Guardini (10 min) Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura (10 min) Link local address resolution without DNS / A. Durand (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 Thu Mar 11 21:54:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA00411 for ipng-dist; Thu, 11 Mar 1999 21:46:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00404 for ; Thu, 11 Mar 1999 21:46:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id VAA04816 for ; Thu, 11 Mar 1999 21:46:27 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA14413 for ; Thu, 11 Mar 1999 21:46:27 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 11 Mar 1999 21:46:27 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81F4C@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 7309) redirect validation Date: Thu, 11 Mar 1999 21:46:26 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's a relatively minor interpretation issue that came up at Connectathon earlier this week... In section 8.1 of the ND spec, one of the rules for validation of a redirect is: - The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. I would interpret this to mean 1. If there is already a destination cache entry for the destination, then the source of the redirect is the current next-hop neighbor in the destination cache entry. 2. If there is not an existing destination cache entry, then the source of the redirect is a plausible next-hop neighbor for the destination. Eg, the source of the redirect is on the default router list. Does this sound right? Just checking... Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 12 02:39:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00589 for ipng-dist; Fri, 12 Mar 1999 02:35:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00580 for ; Fri, 12 Mar 1999 02:35:26 -0800 (PST) From: vanhoudt@hcoss.uia.ac.be Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA10167 for ; Fri, 12 Mar 1999 02:35:26 -0800 (PST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA23769 for ; Fri, 12 Mar 1999 02:35:25 -0800 (PST) Received: from [195.99.53.129] (helo=thss-barney.THSS-BARNEY) by carbon with esmtp (Exim 2.05 #1) id 10LPFn-0006OY-00 for ipng@sunroof.eng.sun.com; Fri, 12 Mar 1999 10:33:20 +0000 Received: from THSS-1-SUP-1 by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GRLTD4H2; Fri, 12 Mar 1999 10:36:16 -0000 Message-Id: Date: Fri, 12 Mar 1999 10:33:20 +0000 To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.eng.sun.com Fri Mar 12 01:14:02 1999 Received: from [193.113.210.238] (helo=mail2.) by rhenium with smtp (Exim 2.05 #1) id 10LGWW-0001kE-00 for nbc@btinternet.com; Fri, 12 Mar 1999 01:14:00 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id JAA04976; Thu, 11 Mar 1999 09:24:19 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP) with ESMTP; Thu, 11 Mar 1999 09:24:17 +0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09223; Thu, 11 Mar 1999 01:21:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id BAA28159; Thu, 11 Mar 1999 01:21:07 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA29255 for ipng-dist; Thu, 11 Mar 1999 01:16:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29248 for ; Thu, 11 Mar 1999 01:16:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id BAA27585 for ; Thu, 11 Mar 1999 01:16:10 -0800 (PST) Received: from hcoss.uia.ac.be (hcoss.uia.ac.be [143.169.1.8]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA18085 for ; Thu, 11 Mar 1999 01:16:00 -0800 (PST) Received: from hcoss.uia.ac.be by hcoss.uia.ac.be; (8.8.6/1.1.8.2/22Feb95-0943AM) id KAA19921; Thu, 11 Mar 1999 10:15:48 +0100 (MET) Message-Id: <199903110915.KAA19921@hcoss.uia.ac.be> Date: Thu, 11 Mar 1999 10:15:48 +0100 (MET) From: "Benny.VanHoudt" Reply-To: "Benny.VanHoudt" Subject: (IPng 7304) Mobile IPv6 Binding Acks. To: ipng@sunroof.eng.sun.com Cc: mobile-ip@smallworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +otw4EiiLhTJANpMEgcdJw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This was probably notice before, but just in case: In the Mobile IPv6 Internet-Draft of 18/11/98 it is stated (line 6) in section 5.2 that a binding acknowledgement MUST be returned upon receiving a binding Update with A = 1. Later in section 8.5 it is mentioned (line 2) that it SHOULD be returned. Which one is correct? vanhoudt@uia.ua.ac.be -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 12 02:40:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00572 for ipng-dist; Fri, 12 Mar 1999 02:35:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00563 for ; Fri, 12 Mar 1999 02:35:15 -0800 (PST) From: hinden@iprg.nokia.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA04862 for ; Fri, 12 Mar 1999 02:35:14 -0800 (PST) Received: from tungsten (tungsten.btinternet.com [194.73.73.81]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA23714 for ; Fri, 12 Mar 1999 02:35:14 -0800 (PST) Received: from [195.99.53.129] (helo=thss-barney.THSS-BARNEY) by tungsten with esmtp (Exim 2.05 #1) id 10LPHI-00024n-00 for ipng@sunroof.eng.sun.com; Fri, 12 Mar 1999 10:34:53 +0000 Received: from THSS-1-SUP-1 by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GRLTD4HG; Fri, 12 Mar 1999 10:36:12 -0000 Message-Id: Date: Fri, 12 Mar 1999 10:34:53 +0000 To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.eng.sun.com Fri Mar 12 00:19:54 1999 Received: from [193.113.211.246] (helo=mailhub.btwebworld.com) by tantalum with smtp (Exim 2.05 #1) id 10LFg9-0005os-00 for nbc@btinternet.com; Fri, 12 Mar 1999 00:19:53 +0000 Received: from mail.btwebworld.com by mailhub.btwebworld.com (SMI-8.6/SMI-SVR4) id AAA26303; Fri, 12 Mar 1999 00:19:56 GMT Received: by mail.btwebworld.com (SMI-8.6/SMI-SVR4) id AAA16867; Fri, 12 Mar 1999 00:19:09 GMT Received: from mercury.Sun.COM by mail.btwebworld.com with SMTP (XT-PP) with ESMTP; Fri, 12 Mar 1999 00:19:05 +0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14133; Thu, 11 Mar 1999 16:19:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id QAA23316; Thu, 11 Mar 1999 16:19:04 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA00207 for ipng-dist; Thu, 11 Mar 1999 16:10:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00199 for ; Thu, 11 Mar 1999 16:10:16 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id QAA12724 for ; Thu, 11 Mar 1999 16:10:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA21131 for ; Thu, 11 Mar 1999 16:10:14 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA03753; Thu, 11 Mar 1999 16:10:13 -0800 (PST) Message-Id: <3.0.5.32.19990311160943.00ab7970@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Mar 1999 16:09:43 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7308) Proposed Minneapolis IPng W.G. Agenda Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The IPng working group will meet for two sessions at the Minneapolis IETF. The current sessions are: MONDAY, March 15, 1999 0930-1130 (Salon D) 1930-2200 (Salon D) Both sessions will be Multicast. Also, the NGTRANS w.g. will be meeting at the Minneapolis IETF on TUESDAY, March 16, 1999 0900-1115 (Salon G) 1545-1800 (Salon A) Attached is the proposed agenda for the IPng w.g. meeting. Please send us any changes and additions. Please note that if you are listed to speak on a particular topic/document (and had not request an agenda slot) it is because the chairs think there has been an update or change since the last meeting and it is useful to discuss this at the w.g. meeting. Thanks, Bob Hinden / Steve Deering -------------------------------------------- MONDAY, March 15, 1999 0930-1130 (Salon D) MONDAY, March 15, 1999 1930-2200 (Salon D) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) New Internet Draft Procedure / R. Hinden (5 min) Current Deployment Activities / P. Metzger (10 min) UNH Interoperability Testing / W. Lenharth (5 min) 6REN Status / R. Fink (5 min) Document Status / R. Hinden (15 min) Report from IPng Grenoble Meeting / S. Deering (45 min) Mobile IPv6 Status / D. Johnson (5 min) DNS Extension Status / M. Crawford (5 min) Router Renumbering Status / M. Crawford (5 min) Multicast Listener Discovery Protocol / S. Deering (5 min) Tunnel broker / I. Guardini (10 min) Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura (10 min) Link local address resolution without DNS / A. Durand (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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 12 02:39:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00583 for ipng-dist; Fri, 12 Mar 1999 02:35:32 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00571 for ; Fri, 12 Mar 1999 02:35:22 -0800 (PST) From: Francis.Dupont@inria.fr Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA10158 for ; Fri, 12 Mar 1999 02:35:21 -0800 (PST) Received: from neodymium (neodymium.btinternet.com [194.73.73.83]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA23741 for ; Fri, 12 Mar 1999 02:35:21 -0800 (PST) Received: from [195.99.53.129] (helo=thss-barney.THSS-BARNEY) by neodymium with esmtp (Exim 2.05 #1) id 10LPG1-0005UQ-00 for ipng@sunroof.eng.sun.com; Fri, 12 Mar 1999 10:33:34 +0000 Received: from THSS-1-SUP-1 by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GRLTD4HK; Fri, 12 Mar 1999 10:36:19 -0000 Message-Id: Date: Fri, 12 Mar 1999 10:33:34 +0000 To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.eng.sun.com Fri Mar 12 01:14:05 1999 Received: from [193.113.210.238] (helo=mail2.) by rhenium with smtp (Exim 2.05 #1) id 10LGWa-0001lJ-00 for nbc@btinternet.com; Fri, 12 Mar 1999 01:14:04 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id IAA09680; Thu, 11 Mar 1999 08:19:44 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP) with ESMTP; Thu, 11 Mar 1999 08:19:42 +0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25999; Thu, 11 Mar 1999 00:16:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id AAA28072; Thu, 11 Mar 1999 00:16:13 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA29203 for ipng-dist; Thu, 11 Mar 1999 00:11:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29196 for ; Thu, 11 Mar 1999 00:11:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id AAA27503 for ; Thu, 11 Mar 1999 00:11:15 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA26808 for ; Thu, 11 Mar 1999 00:11:17 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA03848; Thu, 11 Mar 1999 09:11:13 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id JAA05470; Thu, 11 Mar 1999 09:11:13 +0100 (MET) Message-Id: <199903110811.JAA05470@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Cc: mobile-ip@smallworks.com Subject: (IPng 7303) mobility and IPsec tunnel mode Date: Thu, 11 Mar 1999 09:11:12 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The interaction between IPv6 mobility and IPsec in tunnel mode is both interesting and not (yet) described in I-Ds. Usually your get: from correspondent to mobile: IPv6 header destination=care-of address Routing header final destination=home address IPSec header authentication and replay prevention Higher level data from mobile to correspondent: IPv6 header source=care-of address IPSec header authentication and replay prevention Destination Options home address=home address Higher level data If you use tunnel mode in place of transport mode for common packets (ie without binding options) you can use: from correspondent to mobile: Outer IPv6 header destination=care-of address IPSec header authentication and replay prevention Inner IPv6 header destination=home address Higher level data from mobile to correspondent: Outer IPv6 header source=care-of address IPSec header authentication and replay prevention Inner IPv6 header source=home address Higher level data The two ways are in fact independent. The interesting thing is you don't need special things like routing headers or home address destination options which is not a real surprise because the key point is to get *two* addresses for the mobile which is provided by encapsulation... Then when IPsec tunnel mode is used, mobility has *no* extra cost for common packets (if my remark is applied). This should be written down in the specs? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 12 02:40:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00597 for ipng-dist; Fri, 12 Mar 1999 02:35:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00590 for ; Fri, 12 Mar 1999 02:35:40 -0800 (PST) From: richdr@microsoft.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA03904 for ; Fri, 12 Mar 1999 02:35:39 -0800 (PST) Received: from tungsten (tungsten.btinternet.com [194.73.73.81]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA23831 for ; Fri, 12 Mar 1999 02:35:38 -0800 (PST) Received: from [195.99.53.129] (helo=thss-barney.THSS-BARNEY) by tungsten with esmtp (Exim 2.05 #1) id 10LPHh-0002FJ-00 for ipng@sunroof.eng.sun.com; Fri, 12 Mar 1999 10:35:18 +0000 Received: from THSS-1-SUP-1 by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GRLTD4HV; Fri, 12 Mar 1999 10:36:38 -0000 Message-Id: Date: Fri, 12 Mar 1999 10:35:18 +0000 To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.eng.sun.com Fri Mar 12 05:54:24 1999 Received: from [193.113.210.238] (helo=mail2.) by praseodumium with smtp (Exim 2.05 #1) id 10LKtr-00076O-00 for nbc@btinternet.com; Fri, 12 Mar 1999 05:54:23 +0000 Received: by mail2. (SMI-8.6/SMI-SVR4) id FAA17871; Fri, 12 Mar 1999 05:57:55 GMT Received: from mercury.Sun.COM by mail2.btwebworld.com with SMTP (XT-PP) with ESMTP; Fri, 12 Mar 1999 05:57:51 +0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00146; Thu, 11 Mar 1999 21:56:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id VAA02332; Thu, 11 Mar 1999 21:56:22 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA00411 for ipng-dist; Thu, 11 Mar 1999 21:46:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00404 for ; Thu, 11 Mar 1999 21:46:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id VAA04816 for ; Thu, 11 Mar 1999 21:46:27 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA14413 for ; Thu, 11 Mar 1999 21:46:27 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 11 Mar 1999 21:46:27 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81F4C@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 7309) redirect validation Date: Thu, 11 Mar 1999 21:46:26 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's a relatively minor interpretation issue that came up at Connectathon earlier this week... In section 8.1 of the ND spec, one of the rules for validation of a redirect is: - The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. I would interpret this to mean 1. If there is already a destination cache entry for the destination, then the source of the redirect is the current next-hop neighbor in the destination cache entry. 2. If there is not an existing destination cache entry, then the source of the redirect is a plausible next-hop neighbor for the destination. Eg, the source of the redirect is on the default router list. Does this sound right? Just checking... Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 12 16:34:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA01436 for ipng-dist; Fri, 12 Mar 1999 16:30:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01429 for ; Fri, 12 Mar 1999 16:30:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id QAA12470 for ; Fri, 12 Mar 1999 16:30:49 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA05637 for ; Fri, 12 Mar 1999 16:30:38 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA01998; Fri, 12 Mar 1999 16:30:38 -0800 (PST) Message-Id: <3.0.5.32.19990312163004.00a7a100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Mar 1999 16:30:04 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7310) Updated Minneapolis IPng W.G. Agenda Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Attached is the updated agenda for the IPng w.g. meeting. Please send us any additional changes and additions. See you in Minneapolis! Thanks, Bob Hinden / Steve Deering -------------------------------------------- MONDAY, March 15, 1999 0930-1130 (Salon D) MONDAY, March 15, 1999 1930-2200 (Salon D) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) New Internet Draft Procedure / R. Hinden (5 min) Current Deployment Activities / P. Metzger (10 min) UNH Interoperability Testing / W. Lenharth (5 min) 6REN Status / R. Fink (5 min) Document Status / R. Hinden (15 min) Report from IPng Grenoble Meeting / S. Deering (45 min) Chairs' Recommendation on IPng w.g. / S. Deering, R. Hinden (15 min) Mobile IPv6 Status / D. Johnson (5 min) DNS Extension Status / M. Crawford (5 min) Router Renumbering Status / M. Crawford (5 min) Multicast Listener Discovery Protocol / S. Deering (5 min) Tunnel broker / I. Guardini (10 min) Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura (10 min) Link local address resolution without DNS / A. Durand (15 min) Steal This Slide / M. Crawford (10 min) ND Extensions for Frame Relay / A. Conta (15 min) Current State of IPng Multihoming / S. Deering (30 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 Mar 12 19:29:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA01556 for ipng-dist; Fri, 12 Mar 1999 19:26:16 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01549 for ; Fri, 12 Mar 1999 19:26:06 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA13060; Fri, 12 Mar 1999 19:26:04 -0800 (PST) Date: Fri, 12 Mar 1999 19:26:04 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7311) Re: redirect validation To: Richard Draves Cc: "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81F4C@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In section 8.1 of the ND spec, one of the rules for validation of a redirect > is: > - The IP source address of the Redirect is the same as the current > first-hop router for the specified ICMP Destination Address. > > I would interpret this to mean > 1. If there is already a destination cache entry for the destination, then > the source of the redirect is the current next-hop neighbor in the > destination cache entry. > 2. If there is not an existing destination cache entry, then the source of > the redirect is a plausible next-hop neighbor for the destination. Eg, the > source of the redirect is on the default router list. Sounds very reasonable. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 01:20:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA02340 for ipng-dist; Mon, 15 Mar 1999 01:12:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02333 for ; Mon, 15 Mar 1999 01:12:36 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id BAA18064 for ; Mon, 15 Mar 1999 01:12:35 -0800 (PST) Received: from alf.fe.up.pt (alf.fe.up.pt [193.136.28.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA06949 for ; Mon, 15 Mar 1999 01:12:32 -0800 (PST) Received: from fe.up.pt (bean.fe.up.pt [193.136.28.69]) by alf.fe.up.pt (8.9.1a/8.9.1) with ESMTP id JAA09249 for ; Mon, 15 Mar 1999 09:03:46 GMT Message-ID: <36ECCEFC.A3A75605@fe.up.pt> Date: Mon, 15 Mar 1999 09:12:29 +0000 From: "Tito Carlos S. Vieira" X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 7313) Re: Updated Minneapolis IPng W.G. Agenda References: <3.0.5.32.19990312163004.00a7a100@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Can you publish the presentation and articles of conferencing in the WWW? Thanks Tito Bob Hinden wrote: > Folks, > > Attached is the updated agenda for the IPng w.g. meeting. Please send us > any additional changes and additions. > > See you in Minneapolis! > > Thanks, > > Bob Hinden / Steve Deering > > -------------------------------------------- > > MONDAY, March 15, 1999 0930-1130 (Salon D) > MONDAY, March 15, 1999 1930-2200 (Salon D) > > Introduction / S. Deering (5 min) > Review Agenda / S. Deering (5 min) > New Internet Draft Procedure / R. Hinden (5 min) > Current Deployment Activities / P. Metzger (10 min) > UNH Interoperability Testing / W. Lenharth (5 min) > 6REN Status / R. Fink (5 min) > Document Status / R. Hinden (15 min) > Report from IPng Grenoble Meeting / S. Deering (45 min) > Chairs' Recommendation on IPng w.g. / S. Deering, R. Hinden (15 min) > Mobile IPv6 Status / D. Johnson (5 min) > DNS Extension Status / M. Crawford (5 min) > Router Renumbering Status / M. Crawford (5 min) > Multicast Listener Discovery Protocol / S. Deering (5 min) > Tunnel broker / I. Guardini (10 min) > Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura (10 min) > Link local address resolution without DNS / A. Durand (15 min) > Steal This Slide / M. Crawford (10 min) > ND Extensions for Frame Relay / A. Conta (15 min) > Current State of IPng Multihoming / S. Deering (30 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 01:38:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA02375 for ipng-dist; Mon, 15 Mar 1999 01:35:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02368 for ; Mon, 15 Mar 1999 01:35:29 -0800 (PST) From: Rolf.Kozlowski@cam-comp.de Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id BAA07595 for ; Mon, 15 Mar 1999 01:35:26 -0800 (PST) Received: from popmail.space.net (popmail.Space.Net [195.30.0.14]) by earth.sun.com (8.9.1/8.9.1) with SMTP id BAA17759 for ; Mon, 15 Mar 1999 01:35:23 -0800 (PST) Received: (qmail 27398 invoked from network); 15 Mar 1999 09:35:21 -0000 Received: from websrv1.cam-comp.de (195.30.54.222) by popmail.space.net with SMTP; 15 Mar 1999 09:35:21 -0000 Received: by websrv1 with Internet Mail Service (5.5.2448.0) id ; Mon, 15 Mar 1999 10:35:02 +0100 Message-ID: To: ipng@sunroof.eng.sun.com Subject: (IPng 7314) IPv6 over X.25 Date: Mon, 15 Mar 1999 10:34:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are there any investigations concerning IPv6 over X.25 and is already some documentation available ? Thanks Rolf -- CAM-TW Dr. Rolf Kozlowski Rudolf-Diesel-Str. 7a 82205 Gilching Rolf.Kozlowski@cam-comp.de -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 08:02:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA02532 for ipng-dist; Mon, 15 Mar 1999 07:52:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02525; Mon, 15 Mar 1999 07:52:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id HAA06588; Mon, 15 Mar 1999 07:52:00 -0800 (PST) Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA15605; Mon, 15 Mar 1999 07:51:59 -0800 (PST) Received: from loshin.com (loshin.ne.mediaone.net [24.128.200.158]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA21177; Mon, 15 Mar 1999 10:51:37 -0500 (EST) Message-ID: <36ED2CB5.311E3B5F@loshin.com> Date: Mon, 15 Mar 1999 10:52:21 -0500 From: Pete Loshin X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: deployment@ipv6.org CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 7315) Upcoming article on IPv6--moving the story forward References: <199902181802.NAA0000005487@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First off, please pardon the cross-posting but I wanted to make sure I reach everyone in the IPv6 community. I've been approached by an editor at Data Communications magazine to write an article about the state of the art of IPv6 implementations. This is an opportunity to advance the story in the media from "What is IPv6?" to "What tools are available that will help my company deploy IPv6?" It's not about what IPv6 is, but rather, what can corporate technology consumers start doing about it. This means I've got to round up information about products that support IPv6, right now. This will also mean coming up with information about products that are due to be offered real soon. The IPv6.org site has a list of implementations, but I know it's not 100% comprehensive or current. So, if you use an IPv6 product, tell me about it. If you're building an IPv6 product, tell me about it. Even if you've only heard of an IPv6 product, tell me about it. Tell me about these software and hardware products, even if that means just sending a one-line email pointing me to a company and a product (and hopefully a contact person who can tell me more). When I've got a comprehensive product listing (vendors, URLs, product info) I will turn it over for the IPv6.org site as well as incorporate it into the article. And any other appropriate information that I generate from doing the article as well. If you can help in any way, I truly appreciate it--and I truly believe this will benefit the IPv6 community. warm regards, -pl +-------------------------------------------------------------+ | Pete Loshin +1 781/646-6318 | | | | _IPv6 Clearly Explained_ Morgan Kaufmann 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 14:32:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA02896 for ipng-dist; Mon, 15 Mar 1999 14:22:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02889 for ; Mon, 15 Mar 1999 14:22:29 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id OAA17294 for ; Mon, 15 Mar 1999 14:22:27 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA00123 for ; Mon, 15 Mar 1999 14:22:24 -0800 (PST) Received: from spruce (host257.44IETF.MR.Net [209.32.93.7]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA10553; Mon, 15 Mar 1999 14:22:18 -0800 (PST) Message-Id: <3.0.5.32.19990315142137.035cc1b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 15 Mar 1999 14:21:37 -0800 To: "Tito Carlos S. Vieira" From: Bob Hinden Subject: (IPng 7316) Re: Updated Minneapolis IPng W.G. Agenda Cc: ipng@sunroof.eng.sun.com In-Reply-To: <36ECCEFC.A3A75605@fe.up.pt> References: <3.0.5.32.19990312163004.00a7a100@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tito, >Can you publish the presentation and articles of conferencing in the WWW? The minutes for this and previous IPng meetings are available at http://playground.sun.com/ipng The minutes for all IETF working groups (including IPng) can be found at http://www.ietf.org Regards, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 19:03:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA03124 for ipng-dist; Mon, 15 Mar 1999 18:59:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03117 for ; Mon, 15 Mar 1999 18:59:20 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id SAA04151; Mon, 15 Mar 1999 18:59:15 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA29606; Mon, 15 Mar 1999 18:59:10 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id WAA14297; Mon, 15 Mar 1999 22:01:24 -0500 (EST) To: Charles Perkins Cc: ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com, "Alex A.M.R. Slingerland" In-Reply-To: Your message of "Thu, 25 Feb 1999 07:19:16 PST" <199902251524.HAA01625@hsmpka.eng.sun.com> From: Dave Johnson Reply-To: Dave Johnson Subject: (IPng 7318) Re: (mobile-ip) Re: IPv6 mobility support Date: Mon, 15 Mar 1999 22:01:24 -0500 Message-ID: <14295.921553284@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A while ago, "Alex A.M.R. Slingerland" asked: >> 1. Section 10.5 of draft-ietf-mobileip-ipv6-0{67}.txt _suggests_ that a >> MN, after changing primary care of address, _must_ send the first/next >> BindingUpdate to its Home Agent (HA). Does the first paragraph of >> Section 10.5 just say that the MN must inform the HA of the care of >> address change, or that the MN must do so before informing any other >> nodes? Would it reduce packet loss if the MN could first tell the old >> Default Router of the new care of address (i.e. allow the MN to have >> it's own policy)? To which Charles Perkins replied: >This is a good point. I would agree that the MN could send a >binding update to its old default router before sending the >binding update to the Home Agent. This has never come up in the >discussion before, and so as far as I know no one thought about it. I don't remember this has been discussed before, but the design I intended in writing the text was simply what it literally says. That is, the mobile node MUST register the new care-of address in order to make it its primary care-of address. The primary care-of address is the address of the mobile node as registered at the home agent. This is used to tunnel intercepted packets from the home agent. This says nothing (and is intended to say nothing) about what the mobile nodes uses as the care-of address it sends to correspondent nodes. The paragraph in Section 10.5 only talks about registering the primary care-of address. See the definition of primary care-of address on page 8. So, the specific answer to your question is, yes, the mobile node can send a Binding Update to correspondent nodes before it sends the Binding Update to its home agent. "Alex A.M.R. Slingerland" also asked: >> 2. (Section 10.10) Is MAX_UPDATE_RATE intended to limit the total rate >> of Binding_Updates that leave a MN, or does it apply to the rate of >> Binding_Updates to individual nodes/IP-addresses? >> - If the former is the case (limit total rate), after sending the >> BindingUpdate to the HA, the MN has to wait Max_Update_Rate (=1) seconds >> before it can send another BindingUpdate, to any other node (e.g. its >> old Default Router)? >> - If the latter is the case (limit rate to individual nodes), the more >> CN's a MN is communicating with, the higher the (aggregate) rate of >> Binding_Updates after a care-of-address-update, correct? Would this >> cause load spikes, even if the Binding_Updates are put in packets that >> are destined for the CN anyway (perhaps the common case, if the MN's >> communicating with a CN)? To which Charles Perkins replied: >A good solution would be to define two update rates. The MAX_UPDATE_RATE >for a correspondent node could be 1 second. I don't think it was ever >the intention to restrict the total update rate to one per second. >Indeed, I would even go further to say that the MAX_UPDATE_RATE should >only apply to _empty_ packets. The update rate for Binding Update >options that are inserted into normal data traffic might well be >unrestricted, or perhaps instead restricted to a small percentage >of the overall data volume. The value MAX_UPDATE_RATE relates only to Binding Updates sent by some node about a specific binding. It is not a global value to be applied to all Binding Updates sent by that node, since the need to send updates about one binding has no logical relationship about the need to send updates about a different binding. So that means, for different home addresses (if the mobile nodes has more than one), the rate is limited saparately. If the mobile node sends a different care-of address, the rate is limited separately. If the update is going to a different destination, the rate is limited separately. If you are worried about "load spikes", you can limit the rate further, but that is not the point of MAX_UPDATE_RATE. THe limit here is intended to prevent you from saying the same thing to the same person too frequently. In looking back at the text in the draft right now, I see that this isn't explained very clearly, though, so thanks for asking. I'll clarify the text. Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 19:09:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA03142 for ipng-dist; Mon, 15 Mar 1999 19:07:40 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03135 for ; Mon, 15 Mar 1999 19:07:30 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id TAA06764 for ; Mon, 15 Mar 1999 19:07:31 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA03078 for ; Mon, 15 Mar 1999 19:07:30 -0800 (PST) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id WAA14314; Mon, 15 Mar 1999 22:09:44 -0500 (EST) To: "Benny.VanHoudt" Cc: ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com In-Reply-To: Your message of "Thu, 11 Mar 1999 10:15:48 +0100" <199903110915.KAA19921@hcoss.uia.ac.be> From: Dave Johnson Reply-To: Dave Johnson Subject: (IPng 7319) Re: Mobile IPv6 Binding Acks. Date: Mon, 15 Mar 1999 22:09:44 -0500 Message-ID: <14312.921553784@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This was probably notice before, but just in case: > >In the Mobile IPv6 Internet-Draft of 18/11/98 it is stated (line 6) >in section 5.2 that a binding acknowledgement MUST be returned >upon receiving a binding Update with A = 1. >Later in section 8.5 it is mentioned (line 2) that it SHOULD be returned. > >Which one is correct? > >vanhoudt@uia.ua.ac.be The intention is that, in general, you naturally always return a Binding Acknowledgement when you receive a Binding Update with the Acknowledgement (A) bit set. Thus, it sort of should be a MUST. However, the general convention seems to be to write such requirements as a SHOULD, so that a node has the slight option of not sending an acknowledgement in strange cases, such as when it is being flooded with Binding Updates. So, the MUST you noticed in Section 5.2 is really supposed to be a SHOULD, with this definition of SHOULD. Thanks for catching this smal inconsistency. I'll fix the text. Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 20:29:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA03191 for ipng-dist; Mon, 15 Mar 1999 20:26:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03184 for ; Mon, 15 Mar 1999 20:26:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id UAA12813 for ; Mon, 15 Mar 1999 20:26:31 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA01044 for ; Mon, 15 Mar 1999 20:26:30 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA13153; Tue, 16 Mar 1999 13:26:01 +0900 (JST) To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 7320) name->addr discovery From: Jun-ichiro itojun Hagino Date: Tue, 16 Mar 1999 13:26:01 +0900 Message-ID: <13149.921558361@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, In your talk in IETF44 titled 'steal this slide', you mentioned name->addr discovery without namesevers. There are several attempts presented in nits BOF, and one of them was draft-manning-multicast-dns-01.txt. I dunno if it is the right way to take but it is one possibility. (BTW it is sad that ther's no IPv6 multicast address in the draft!) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 15 23:58:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA03250 for ipng-dist; Mon, 15 Mar 1999 23:56:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03243 for ; Mon, 15 Mar 1999 23:55:57 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id XAA15673 for ; Mon, 15 Mar 1999 23:55:56 -0800 (PST) Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA07729 for ; Mon, 15 Mar 1999 23:55:55 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA09036; Mon, 15 Mar 1999 23:55:44 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA78347; Mon, 15 Mar 1999 20:51:56 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA02495; Mon, 15 Mar 1999 20:51:55 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199903160451.UAA02495@bossette.engr.sgi.com> Subject: (IPng 7321) Re: name->addr discovery To: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Mon, 15 Mar 1999 20:51:54 -0800 (PST) Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com In-Reply-To: <13149.921558361@coconut.itojun.org> from "Jun-ichiro itojun Hagino" at Mar 16, 99 01:26:01 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > In your talk in IETF44 titled 'steal this slide', you mentioned > name->addr discovery without namesevers. Unfortunately I was not able to attend the Mineapolis IETF so I didn't follow any of this. We have a prototype protocol, called the Plug and Play Name Resolution Protocol which provides name resolution for automatically configured IPv6 addresses and requires no centralised nameserver. It is designed to work together with other name resolution techniques such as DNS and NIS. We have a working implementation for IRIX. I am currently writing a document describing this protocol and will send it to the list soon. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 16 02:34:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA03341 for ipng-dist; Tue, 16 Mar 1999 02:32:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03334 for ; Tue, 16 Mar 1999 02:32:37 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id CAA17998 for ; Tue, 16 Mar 1999 02:32:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA25989 for ; Tue, 16 Mar 1999 02:32:19 -0800 (PST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id CAA17465; Tue, 16 Mar 1999 02:32:00 -0800 (PST) From: Bill Manning Message-Id: <199903161032.CAA17465@boreas.isi.edu> Subject: (IPng 7322) Re: name->addr discovery To: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Tue, 16 Mar 1999 02:32:00 -0800 (PST) Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com In-Reply-To: <13149.921558361@coconut.itojun.org> from "Jun-ichiro itojun Hagino" at Mar 16, 99 01:26:01 pm 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 > > Matt, > In your talk in IETF44 titled 'steal this slide', you mentioned > name->addr discovery without namesevers. There are several attempts > presented in nits BOF, and one of them was > draft-manning-multicast-dns-01.txt. I dunno if it is the right way > to take but it is one possibility. > (BTW it is sad that ther's no IPv6 multicast address in the draft!) > > itojun > -------------------------------------------------------------------- To clarify, There are two main techniques for doing addr<->name translation. The traditional nameserver techniques (we know they work and pretty well) to things like ICMP hacks, which can work, in small scale environments. multicast-dns-03.txt has alot of potential for expanding its reach, but it is specifically targeted to solving one problem. -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 16 04:21:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA03384 for ipng-dist; Tue, 16 Mar 1999 04:18:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03377; Tue, 16 Mar 1999 04:18:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id NAA04460; Mon, 15 Mar 1999 13:50:14 -0800 (PST) Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA08456; Mon, 15 Mar 1999 13:50:14 -0800 (PST) Received: from loshin.com (loshin.ne.mediaone.net [24.128.200.158]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id QAA24673; Mon, 15 Mar 1999 16:50:07 -0500 (EST) Message-ID: <36ED80C0.507F377F@loshin.com> Date: Mon, 15 Mar 1999 16:50:56 -0500 From: Pete Loshin X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: deployment@ipv6.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 7323) Re: Upcoming article on IPv6--moving the story forward References: <199902181802.NAA0000005487@wasted.zk3.dec.com> <36ED2CB5.311E3B5F@loshin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, sorry to bother everyone, again, with this--but it is a real opportunity to get the trade press to start doing substantive IPv6 coverage and move beyond the "What is IPv6?" stage. The editor from Data Communications just told me the focus of this article has changed from a "what vendors are doing about IPv6" to an IPv6 migration story. That means giving a technical overview--as well as technical specifics--to what is necessary for an organization to migrate to IPv6. From an architectural discussion of the options for transition, to a discussion of the technical objectives, what issues need to be considered, how do you plan for the change, what happens when you convert a system/network. It also means some discussion of the relative merits of putting IPv6 on production systems and on different platforms. It also means providing some resources relating to IPv6 (e.g., 6bone, where to get addresses, vendors, organizations). It also means treating the business case for IPv6 (benefits and costs). It also means coming up with some kind of management decision tree that shows what needs to be done/what objectives can be met with the transition. Why am I coming to the list? Because I need to determine where I can get answers to some of the hard questions raised here, and to see whether there are people involved with the IPv6 standards process, with 6bone, with vendors, and with organizations actually deploying IPv6, who can make themselves available to provide answers to these questions for the readers of Data Communications. Unfortunately, my time is quite limited, so I won't be able to do this unless I feel comfortable that I can find all the answers relatively quickly--and I think it is important to do. So: if you know the answers to any of these questions--that is, if you are an "authority" on deploying IPv6--if you've done it for your organization, or if you're planning to do it for your organization--contact me by e-mail. This is an opportunity to get the IPv6 transition message across to a broad technical audience. With attribution if you want the publicity, but also without attribution if you prefer anonymity. Please let me know, by email, if you can help out or if you can point me to any resources. As I mentioned before, this is a good opportunity to start getting people to think in terms of implementing IPv6, not just thinking about it. warm regards, -pl +-------------------------------------------------------------+ | Pete Loshin +1 781/646-6318 | | | | _IPv6 Clearly Explained_ Morgan Kaufmann 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 16 06:36:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA03421 for ipng-dist; Tue, 16 Mar 1999 06:29:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03414 for ; Tue, 16 Mar 1999 06:29:22 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id GAA20782 for ; Tue, 16 Mar 1999 06:29:16 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.192.13]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA10011 for ; Tue, 16 Mar 1999 06:29:10 -0800 (PST) Received: from [209.32.95.9] (ssh.cisco.com [171.69.10.34]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id GAA15433; Tue, 16 Mar 1999 06:27:16 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: <199903161032.CAA17465@boreas.isi.edu> References: <13149.921558361@coconut.itojun.org> from "Jun-ichiro itojun Hagino" at Mar 16, 99 01:26:01 pm Date: Tue, 16 Mar 1999 06:28:35 -0800 To: Bill Manning From: Steve Deering Subject: (IPng 7324) Re: name->addr discovery Cc: itojun@iijlab.net (Jun-ichiro itojun Hagino), crawdad@fnal.gov, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:32 AM -0800 3/16/99, Bill Manning wrote: >> (BTW it is sad that ther's no IPv6 multicast address in the draft!) >> >> itojun >> -------------------------------------------------------------------- > > To clarify, > There are two main techniques for doing addr<->name translation. > The traditional nameserver techniques (we know they work and > pretty well) to things like ICMP hacks, which can work, in small > scale environments. multicast-dns-03.txt has alot of potential > for expanding its reach, but it is specifically targeted to solving > one problem. Bill, Are you saying that that one problem is not relevant in IPv6? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 16 08:51:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA03568 for ipng-dist; Tue, 16 Mar 1999 08:44:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03561 for ; Tue, 16 Mar 1999 08:44:24 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id IAA07354 for ; Tue, 16 Mar 1999 08:44:21 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA29047 for ; Tue, 16 Mar 1999 08:44:22 -0800 (PST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id IAA27842; Tue, 16 Mar 1999 08:44:13 -0800 (PST) From: Bill Manning Message-Id: <199903161644.IAA27842@boreas.isi.edu> Subject: (IPng 7325) Re: name->addr discovery To: deering@cisco.com (Steve Deering) Date: Tue, 16 Mar 1999 08:44:13 -0800 (PST) Cc: bmanning@ISI.EDU, itojun@iijlab.net, crawdad@fnal.gov, ipng@sunroof.eng.sun.com In-Reply-To: from "Steve Deering" at Mar 16, 99 06:28:35 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 > > At 2:32 AM -0800 3/16/99, Bill Manning wrote: > >> (BTW it is sad that ther's no IPv6 multicast address in the draft!) > >> > >> itojun > >> -------------------------------------------------------------------- > > > > To clarify, > > There are two main techniques for doing addr<->name translation. > > The traditional nameserver techniques (we know they work and > > pretty well) to things like ICMP hacks, which can work, in small > > scale environments. multicast-dns-03.txt has alot of potential > > for expanding its reach, but it is specifically targeted to solving > > one problem. > > Bill, > > Are you saying that that one problem is not relevant in IPv6? > > Steve There is the stated objective to find a viable alternative to the Appletalk Chooser. Is that relevent to IPv6? --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 Wed Mar 17 07:40:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA04766 for ipng-dist; Wed, 17 Mar 1999 07:33:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04759 for ; Wed, 17 Mar 1999 07:33:29 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id HAA23535 for ; Wed, 17 Mar 1999 07:33:27 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA22823 for ; Wed, 17 Mar 1999 07:33:27 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA18454; Wed, 17 Mar 1999 09:33:09 -0600 (CST) Message-Id: <199903171533.JAA18454@gungnir.fnal.gov> To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 7331) Re: name->addr discovery In-reply-to: Your message of Tue, 16 Mar 1999 13:26:01 +0900. <13149.921558361@coconut.itojun.org> Date: Wed, 17 Mar 1999 09:33:09 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are what I consider the most important differences between name-based neighbor discovery and multicast dns. N-ND: Allows discovery of addresses only, or possibly a small set of other data. Queries would be received by a very small set of nodes determined by the hash function, including the one of interest if it exists. M-DNS: Allows lookup of any DNSR type. All participating nodes must process each query. In addition, I have a gripe with the multicast DNS document. It claims that it "consists of a single change to the method of use" of DNS, specifically, sending DNS queries to a multicast address. But in actuality, it demands a new meaning of wildcards in queries, where 1034 says, "A * label appearing in a query name has no special effect, but can be used to test for wildcards in an authoritative zone ... The result of such a query should not be cached." Also, I don't see a clear way for a site that becomes large enough to want to introduce a real DNS server to gather up all the data in the devices' "stub" servers, whereas Service Location, the other naturaul choice for this function, handles the transition from DA-less to with-DA deployment. ______________________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab "A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment, thoroughly smash them with a hammer or an ax, and scatter the pieces." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 17 11:04:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA04927 for ipng-dist; Wed, 17 Mar 1999 10:54:31 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04920 for ; Wed, 17 Mar 1999 10:54:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA29786 for ipng@sunroof.eng.sun.com; Wed, 17 Mar 1999 10:53:31 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04607 for ; Wed, 17 Mar 1999 03:18:58 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id DAA03657; Wed, 17 Mar 1999 03:18:55 -0800 (PST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA03360; Wed, 17 Mar 1999 03:18:55 -0800 (PST) Received: from myrtilos.cs.utwente.nl (myrtilos.cs.utwente.nl [130.89.16.9]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with SMTP id MAA06365; Wed, 17 Mar 1999 12:18:32 +0100 (MET) Received: from ctit.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id MAA10092; Wed, 17 Mar 1999 12:18:24 +0100 Message-ID: <36EF8F7F.9BB93CC8@ctit.utwente.nl> Date: Wed, 17 Mar 1999 12:18:23 +0100 From: "Alex A.M.R. Slingerland" Organization: CTIT, University of Twente X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dave Johnson CC: Charles Perkins , ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com Subject: (IPng 7332) Re: (mobile-ip) Re: IPv6 mobility support References: <14295.921553284@maredsous.monarch.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Johnson wrote: > > A while ago, "Alex A.M.R. Slingerland" asked: > > >> 1. Section 10.5 of draft-ietf-mobileip-ipv6-0{67}.txt _suggests_ that a > >> MN, after changing primary care of address, _must_ send the first/next > >> BindingUpdate to its Home Agent (HA). Does the first paragraph of > >> Section 10.5 just say that the MN must inform the HA of the care of > >> address change, or that the MN must do so before informing any other > >> nodes? Would it reduce packet loss if the MN could first tell the old > >> Default Router of the new care of address (i.e. allow the MN to have > >> it's own policy)? > > To which Charles Perkins replied: > > >This is a good point. I would agree that the MN could send a > >binding update to its old default router before sending the > >binding update to the Home Agent. This has never come up in the > >discussion before, and so as far as I know no one thought about it. > > I don't remember this has been discussed before, but the design > I intended in writing the text was simply what it literally says. > That is, the mobile node MUST register the new care-of address in > order to make it its primary care-of address. The primary > care-of address is the address of the mobile node as registered > at the home agent. This is used to tunnel intercepted packets > from the home agent. This says nothing (and is intended to say > nothing) about what the mobile nodes uses as the care-of address > it sends to correspondent nodes. The paragraph in Section 10.5 > only talks about registering the primary care-of address. See the > definition of primary care-of address on page 8. > > So, the specific answer to your question is, yes, the mobile node > can send a Binding Update to correspondent nodes before it sends > the Binding Update to its home agent. > > "Alex A.M.R. Slingerland" also asked: > > >> 2. (Section 10.10) Is MAX_UPDATE_RATE intended to limit the total rate > >> of Binding_Updates that leave a MN, or does it apply to the rate of > >> Binding_Updates to individual nodes/IP-addresses? > >> - If the former is the case (limit total rate), after sending the > >> BindingUpdate to the HA, the MN has to wait Max_Update_Rate (=1) seconds > >> before it can send another BindingUpdate, to any other node (e.g. its > >> old Default Router)? > >> - If the latter is the case (limit rate to individual nodes), the more > >> CN's a MN is communicating with, the higher the (aggregate) rate of > >> Binding_Updates after a care-of-address-update, correct? Would this > >> cause load spikes, even if the Binding_Updates are put in packets that > >> are destined for the CN anyway (perhaps the common case, if the MN's > >> communicating with a CN)? > > To which Charles Perkins replied: > > >A good solution would be to define two update rates. The MAX_UPDATE_RATE > >for a correspondent node could be 1 second. I don't think it was ever > >the intention to restrict the total update rate to one per second. > >Indeed, I would even go further to say that the MAX_UPDATE_RATE should > >only apply to _empty_ packets. The update rate for Binding Update > >options that are inserted into normal data traffic might well be > >unrestricted, or perhaps instead restricted to a small percentage > >of the overall data volume. > > The value MAX_UPDATE_RATE relates only to Binding Updates sent by some > node about a specific binding. It is not a global value to be applied > to all Binding Updates sent by that node, since the need to send > updates about one binding has no logical relationship about the need > to send updates about a different binding. So that means, for > different home addresses (if the mobile nodes has more than one), the > rate is limited saparately. If the mobile node sends a different > care-of address, the rate is limited separately. If the update is > going to a different destination, the rate is limited separately. > If you are worried about "load spikes", you can limit the rate > further, but that is not the point of MAX_UPDATE_RATE. THe limit > here is intended to prevent you from saying the same thing to the > same person too frequently. In looking back at the text in the draft > right now, I see that this isn't explained very clearly, though, > so thanks for asking. I'll clarify the text. Thanks for the clarifications. The other part of my question was *whether it would reduce packet loss* if the MN would first inform the previous default router of the new CoA (note that section 10.8 says the previous DR is informed *after* changing the primary CoA). If "after changing primary CoA" means "after sending the Binding Update to the HA", I deduce from the above that the answer is "no" or "not much", as the MN could send a binding update to the previous DR *immediately* after (as rate limiting on binding updates is done on a per binding, per destination basis) sending the binding update to the HA. You say the MN can even do this before informing the HA of the to-be-primary CoA. Do I understand you correctly? Regards, Alex. -- ___o___ ___ | | | Alex Slingerland / \ | | | University of Twente Tel. +31 53 489 4099 | | | | Centre for Telematics and Information Technology \___/ | | | P.O. Box 217 NL-7500 AE Enschede The Netherlands -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 18 16:26:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA07005 for ipng-dist; Thu, 18 Mar 1999 16:16:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06998 for ; Thu, 18 Mar 1999 16:16:20 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id QAA24099 for ; Thu, 18 Mar 1999 16:16:17 -0800 (PST) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA01557 for ; Thu, 18 Mar 1999 16:16:15 -0800 (PST) Received: from fantail.rose.hp.com (fantail.rose.hp.com [15.67.226.117]) by atlrel2.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id TAA01051 for ; Thu, 18 Mar 1999 19:15:53 -0500 (EST) Received: from fantail.rose.hp.com (fantail.rose.hp.com [15.67.226.117]) by fantail.rose.hp.com with ESMTP (8.7.6/8.7.1) id QAA07031 for ; Thu, 18 Mar 1999 16:16:09 -0800 (PST) Message-ID: <36F19748.F193859B@fantail.rose.hp.com> Date: Thu, 18 Mar 1999 16:16:08 -0800 From: Mark Aring Organization: Hewlett Packard X-Mailer: Mozilla 4.5 [en] (X11; I; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPv6 mailing list Subject: (IPng 7334) tcpdump-3.4a6 error Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I apologize if this has been discussed before on a list, but I am having a problem with compiling tcpdump using Peter Bieringer's Linux How-to page. Below is the error I get when compiling, either with inet6-apps-0.34 or inet6-apps-0.30. Does this look familiar to anyone? ./print-ipv6.c: In function `ipv6_print': ./print-ipv6.c:251: `IPPROTO_HOP' undeclared (first use this function) ./print-ipv6.c:251: (Each undeclared identifier is reported only once ./print-ipv6.c:251: for each function it appears in.) ./print-ipv6.c:259: warning: unreachable code at beginning of switch statement ./print-ipv6.c:280: warning: unreachable code at beginning of switch statement ./print-ipv6.c:312: `IPPROTO_DST' undeclared (first use this function) make[1]: *** [print-ipv6.o] Error 1 make[1]: Leaving directory `/usr/src/tcpdump-3.4a6' make: *** [all] Error 2 Thanks, Mark Aring -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 19 14:02:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA08252 for ipng-dist; Fri, 19 Mar 1999 13:56:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08245 for ; Fri, 19 Mar 1999 13:56:38 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id NAA18180 for ; Fri, 19 Mar 1999 13:56:36 -0800 (PST) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA07459 for ; Fri, 19 Mar 1999 13:56:31 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id EB55B183; Fri, 19 Mar 1999 16:56:18 -0500 (EST) To: Mark Aring Cc: IPv6 mailing list Subject: (IPng 7336) Re: tcpdump-3.4a6 error References: <36F19748.F193859B@fantail.rose.hp.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 19 Mar 1999 16:56:18 -0500 In-Reply-To: Mark Aring's message of "Thu, 18 Mar 1999 16:16:08 -0800" Message-ID: <877lsdi1od.fsf@jekyll.piermont.com> Lines: 34 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This sort of question really is probably better sent to "users@ipv6.org", which is meant for this sort of question... Mark Aring writes: > I apologize if this has been discussed before on a list, but I am having > a problem with compiling tcpdump using Peter Bieringer's Linux How-to > page. Below is the error I get when compiling, either with > inet6-apps-0.34 or inet6-apps-0.30. Does this look familiar to anyone? > > ./print-ipv6.c: In function `ipv6_print': > ./print-ipv6.c:251: `IPPROTO_HOP' undeclared (first use this function) > ./print-ipv6.c:251: (Each undeclared identifier is reported only once > ./print-ipv6.c:251: for each function it appears in.) > ./print-ipv6.c:259: warning: unreachable code at beginning of switch > statement > ./print-ipv6.c:280: warning: unreachable code at beginning of switch > statement > ./print-ipv6.c:312: `IPPROTO_DST' undeclared (first use this function) > make[1]: *** [print-ipv6.o] Error 1 > make[1]: Leaving directory `/usr/src/tcpdump-3.4a6' > make: *** [all] Error 2 > > Thanks, > > Mark Aring > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 19 19:04:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA08688 for ipng-dist; Fri, 19 Mar 1999 18:56:16 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08681 for ; Fri, 19 Mar 1999 18:56:09 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id SAA02959 for ipng@sunroof.eng.sun.com; Fri, 19 Mar 1999 18:55:15 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04607 for ; Wed, 17 Mar 1999 03:18:58 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id DAA03657; Wed, 17 Mar 1999 03:18:55 -0800 (PST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA03360; Wed, 17 Mar 1999 03:18:55 -0800 (PST) Received: from myrtilos.cs.utwente.nl (myrtilos.cs.utwente.nl [130.89.16.9]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with SMTP id MAA06365; Wed, 17 Mar 1999 12:18:32 +0100 (MET) Received: from ctit.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id MAA10092; Wed, 17 Mar 1999 12:18:24 +0100 Message-ID: <36EF8F7F.9BB93CC8@ctit.utwente.nl> Date: Wed, 17 Mar 1999 12:18:23 +0100 From: "Alex A.M.R. Slingerland" Organization: CTIT, University of Twente X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dave Johnson CC: Charles Perkins , ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com Subject: (IPng 7338) Re: (mobile-ip) Re: IPv6 mobility support References: <14295.921553284@maredsous.monarch.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Johnson wrote: > > A while ago, "Alex A.M.R. Slingerland" asked: > > >> 1. Section 10.5 of draft-ietf-mobileip-ipv6-0{67}.txt _suggests_ that a > >> MN, after changing primary care of address, _must_ send the first/next > >> BindingUpdate to its Home Agent (HA). Does the first paragraph of > >> Section 10.5 just say that the MN must inform the HA of the care of > >> address change, or that the MN must do so before informing any other > >> nodes? Would it reduce packet loss if the MN could first tell the old > >> Default Router of the new care of address (i.e. allow the MN to have > >> it's own policy)? > > To which Charles Perkins replied: > > >This is a good point. I would agree that the MN could send a > >binding update to its old default router before sending the > >binding update to the Home Agent. This has never come up in the > >discussion before, and so as far as I know no one thought about it. > > I don't remember this has been discussed before, but the design > I intended in writing the text was simply what it literally says. > That is, the mobile node MUST register the new care-of address in > order to make it its primary care-of address. The primary > care-of address is the address of the mobile node as registered > at the home agent. This is used to tunnel intercepted packets > from the home agent. This says nothing (and is intended to say > nothing) about what the mobile nodes uses as the care-of address > it sends to correspondent nodes. The paragraph in Section 10.5 > only talks about registering the primary care-of address. See the > definition of primary care-of address on page 8. > > So, the specific answer to your question is, yes, the mobile node > can send a Binding Update to correspondent nodes before it sends > the Binding Update to its home agent. > > "Alex A.M.R. Slingerland" also asked: > > >> 2. (Section 10.10) Is MAX_UPDATE_RATE intended to limit the total rate > >> of Binding_Updates that leave a MN, or does it apply to the rate of > >> Binding_Updates to individual nodes/IP-addresses? > >> - If the former is the case (limit total rate), after sending the > >> BindingUpdate to the HA, the MN has to wait Max_Update_Rate (=1) seconds > >> before it can send another BindingUpdate, to any other node (e.g. its > >> old Default Router)? > >> - If the latter is the case (limit rate to individual nodes), the more > >> CN's a MN is communicating with, the higher the (aggregate) rate of > >> Binding_Updates after a care-of-address-update, correct? Would this > >> cause load spikes, even if the Binding_Updates are put in packets that > >> are destined for the CN anyway (perhaps the common case, if the MN's > >> communicating with a CN)? > > To which Charles Perkins replied: > > >A good solution would be to define two update rates. The MAX_UPDATE_RATE > >for a correspondent node could be 1 second. I don't think it was ever > >the intention to restrict the total update rate to one per second. > >Indeed, I would even go further to say that the MAX_UPDATE_RATE should > >only apply to _empty_ packets. The update rate for Binding Update > >options that are inserted into normal data traffic might well be > >unrestricted, or perhaps instead restricted to a small percentage > >of the overall data volume. > > The value MAX_UPDATE_RATE relates only to Binding Updates sent by some > node about a specific binding. It is not a global value to be applied > to all Binding Updates sent by that node, since the need to send > updates about one binding has no logical relationship about the need > to send updates about a different binding. So that means, for > different home addresses (if the mobile nodes has more than one), the > rate is limited saparately. If the mobile node sends a different > care-of address, the rate is limited separately. If the update is > going to a different destination, the rate is limited separately. > If you are worried about "load spikes", you can limit the rate > further, but that is not the point of MAX_UPDATE_RATE. THe limit > here is intended to prevent you from saying the same thing to the > same person too frequently. In looking back at the text in the draft > right now, I see that this isn't explained very clearly, though, > so thanks for asking. I'll clarify the text. Thanks for the clarifications. The other part of my question was *whether it would reduce packet loss* if the MN would first inform the previous default router of the new CoA (note that section 10.8 says the previous DR is informed *after* changing the primary CoA). If "after changing primary CoA" means "after sending the Binding Update to the HA", I deduce from the above that the answer is "no" or "not much", as the MN could send a binding update to the previous DR *immediately* after (as rate limiting on binding updates is done on a per binding, per destination basis) sending the binding update to the HA. You say the MN can even do this before informing the HA of the to-be-primary CoA. Do I understand you correctly? Regards, Alex. -- ___o___ ___ | | | Alex Slingerland / \ | | | University of Twente Tel. +31 53 489 4099 | | | | Centre for Telematics and Information Technology \___/ | | | P.O. Box 217 NL-7500 AE Enschede The Netherlands From owner-ipng@sunroof.eng.sun.com Fri Mar 19 12:00:59 1999 X-Unix-From: owner-ipng@sunroof.eng.sun.com Fri Mar 19 12:00:59 1999 Return-Path: Received: from sunroof.eng.sun.com (sunroof [129.146.168.88]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13298 for ; Fri, 19 Mar 1999 12:00:59 -0800 (PST) From: owner-ipng@sunroof.eng.sun.com Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA08008; Fri, 19 Mar 1999 12:00:57 -0800 (PST) Date: Fri, 19 Mar 1999 12:00:57 -0800 (PST) Message-Id: <199903192000.MAA08008@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from ["Peder Chr. Norgaard" ] Content-Length: 2252 Status: RO X-Status: $$$T X-UID: 0000000005 From owner-ipng Fri Mar 19 12:00:46 1999 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08001 for ; Fri, 19 Mar 1999 12:00:45 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id MAA02498 for ; Fri, 19 Mar 1999 12:00:43 -0800 (PST) Received: from dur.tbit.dk (dur.tbit.dk [194.182.135.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA28191 for ; Fri, 19 Mar 1999 12:00:39 -0800 (PST) Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id VAA01309; Fri, 19 Mar 1999 21:00:25 +0100 (MET) Date: Fri, 19 Mar 1999 21:00:25 +0100 (MET) From: "Peder Chr. Norgaard" To: snmpv3@lists.tislabs.com, ipng@sunroof.eng.sun.com Subject: SNMP Transport Method, snmpDomains value for IPv6? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT I am not sure whether this is an IPv6 or SNMP topic - thus I've chosen to put the question to both lists. By now I have implemented (most of) the newly issued IPv6-related MIBs - then I would very much like to *run* SNMP over IPv6 That in itself is not difficult. But for various SNMP-internal housekeeping purposes I find that an extension to the SNMPv2-TM definitions is needed - one that specify a transport domain "UDP over IPv6" and a mapping of the related address to a replacement for the TAddress textual convention. I find nothing of the sort in the IPv6-related MIBs. If I understand the IETF process right, this more or less calls for a re-issuing of the SNMPv2-TM specification; at the very least the issuing of a new snmpDomains value from IANA. Is that a process that is being started anywhere? best regards --peder chr. Peder Chr. Nørgaard System Developer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 49 Fabrikvej 11 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 23 18:31:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA11961 for ipng-dist; Tue, 23 Mar 1999 18:11:35 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11954 for ; Tue, 23 Mar 1999 18:11:11 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id SAA08967 for ; Tue, 23 Mar 1999 18:10:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA09597 for ; Tue, 23 Mar 1999 18:10:04 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id SAA01092; Tue, 23 Mar 1999 18:10:04 -0800 (PST) Message-Id: <3.0.5.32.19990323180916.008c73c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 23 Mar 1999 18:09:16 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7340) Draft IPng Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, You can find the draft meeting minutes for last weeks IPng meeting at: ftp://playground.sun.com/pub/hinden/ipng-minutes-mar99.txt Please send me corrections. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 02:22:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA12196 for ipng-dist; Wed, 24 Mar 1999 02:18:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12189 for ; Wed, 24 Mar 1999 02:17:59 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id CAA08118 for ; Wed, 24 Mar 1999 02:17:58 -0800 (PST) Received: from globe.v6.sfc.wide.ad.jp (globe.v6.sfc.wide.ad.jp [203.178.141.9]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA29969 for ; Wed, 24 Mar 1999 02:17:53 -0800 (PST) Received: from localhost (ring.v6.linux.or.jp [3ffe:505:d::1] (may be forged)) by globe.v6.sfc.wide.ad.jp (8.9.1+3.1W/3.7W) with ESMTP id TAA27450; Wed, 24 Mar 1999 19:18:28 +0900 (JST) To: hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7342) The expression of IPv6 addresses. From: =?iso-2022-jp?B?GyRCJDskLSRkJGYkJiQ4GyhCLw==?= Yuji SEKIYA X-Mailer: Mew version 1.94b15 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990324191735H.sekiya@sfc.wide.ad.jp> Date: Wed, 24 Mar 1999 19:17:35 +0900 X-Dispatcher: imput version 990323(IM111) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Bob. In case of using IPv6 addresses for URLs or commands, we used to use []. For example, http://[3ffe:501:100f:1000::1]:8080 . However, we can't use [] in case of using scp6. scp 3ffe:501:10ff:1000::1:aaa.txt doesn't indicate a file name clearly, and scp [3ffe:501:10ff:1000::1]:aaa.txt . will be expanded as regular expression by shell. So we can't use IPv6 addresses with scp6. Kazu says that he can't use [] and goes mad. What do you think ? Thanks. ------------ Yuji SEKIYA sekiya@sfc.wide.ad.jp / sekiya@v6.linux.or.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 02:23:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA12205 for ipng-dist; Wed, 24 Mar 1999 02:20:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12198 for ; Wed, 24 Mar 1999 02:20:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id CAA08981 for ; Wed, 24 Mar 1999 02:20:20 -0800 (PST) Received: from dur.tbit.dk (dur.tbit.dk [194.182.135.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA01366 for ; Wed, 24 Mar 1999 02:20:17 -0800 (PST) Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id LAA19815 for ; Wed, 24 Mar 1999 11:20:15 +0100 (MET) Date: Wed, 24 Mar 1999 11:20:15 +0100 (MET) From: "Peder Chr. Norgaard" To: ipng@sunroof.eng.sun.com Subject: (IPng 7343) SNMP Transport Method, snmpDomains value for IPv6? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not sure whether this is an IPv6 or SNMP topic - thus I've chosen to put the question to both lists. By now I have implemented (most of) the newly issued IPv6-related MIBs - then I would very much like to *run* SNMP over IPv6 That in itself is not difficult. But for various SNMP-internal housekeeping purposes I find that an extension to the SNMPv2-TM definitions is needed - one that specify a transport domain "UDP over IPv6" and a mapping of the related address to a replacement for the TAddress textual convention. I find nothing of the sort in the IPv6-related MIBs. If I understand the IETF process right, this more or less calls for a re-issuing of the SNMPv2-TM specification; at the very least the issuing of a new snmpDomains value from IANA. Is that a process that is being started anywhere? best regards --peder chr. Peder Chr. Nørgaard System Developer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 49 Fabrikvej 11 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 02:39:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA12249 for ipng-dist; Wed, 24 Mar 1999 02:36:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12242 for ; Wed, 24 Mar 1999 02:36:25 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id CAA09027 for ; Wed, 24 Mar 1999 02:36:23 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA10239 for ; Wed, 24 Mar 1999 02:36:23 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA17458; Wed, 24 Mar 1999 11:36:15 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id LAA11061; Wed, 24 Mar 1999 11:36:14 +0100 (MET) Message-ID: <19990324113614.B10916@cs.uni-bonn.de> Date: Wed, 24 Mar 1999 11:36:14 +0100 From: "I. Souvatzis" To: "?$B$;$-$d$f$&$8?(B/ Yuji SEKIYA" , hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7344) Re: The expression of IPv6 addresses. References: <19990324191735H.sekiya@sfc.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <19990324191735H.sekiya@sfc.wide.ad.jp>; from ?$B$;$-$d$f$&$8?(B/ Yuji SEKIYA on Wed, Mar 24, 1999 at 07:17:35PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Mar 24, 1999 at 07:17:35PM +0900, ?$B$;$-$d$f$&$8?(B/ Yuji SEKIYA wrote: > In case of using IPv6 addresses for URLs or commands, we used to use []. > For example, http://[3ffe:501:100f:1000::1]:8080 . > However, we can't use [] in case of using scp6. > > scp 3ffe:501:10ff:1000::1:aaa.txt > doesn't indicate a file name clearly, and > > scp [3ffe:501:10ff:1000::1]:aaa.txt . > will be expanded as regular expression by shell. > > So we can't use IPv6 addresses with scp6. > > Kazu says that he can't use [] and goes mad. > What do you think ? Escape the brackets, or quote the name: scp \[3ffe:501:10ff:1000::1\]:aaa.txt . scp '[3ffe:501:10ff:1000::1]:aaa.txt' . -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 02:53:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA12279 for ipng-dist; Wed, 24 Mar 1999 02:46:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12272 for ; Wed, 24 Mar 1999 02:46:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id CAA04181 for ; Wed, 24 Mar 1999 02:46:47 -0800 (PST) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA13118 for ; Wed, 24 Mar 1999 02:46:48 -0800 (PST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id TAA07618 for ; Wed, 24 Mar 1999 19:46:47 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id TAA19423 for ; Wed, 24 Mar 1999 19:46:46 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id TAA04760 for ; Wed, 24 Mar 1999 19:46:46 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7345) Re: The expression of IPv6 addresses. From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <19990324113614.B10916@cs.uni-bonn.de> References: <19990324191735H.sekiya@sfc.wide.ad.jp> <19990324113614.B10916@cs.uni-bonn.de> X-Mailer: Mew version 1.94b15 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990324194653C.kazu@iijlab.net> Date: Wed, 24 Mar 1999 19:46:53 +0900 X-Dispatcher: imput version 990323(IM111) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "I. Souvatzis" Subject: (IPng 7344) Re: The expression of IPv6 addresses. Date: Wed, 24 Mar 1999 11:36:14 +0100 > Escape the brackets, or quote the name: Of couse, we know. > scp \[3ffe:501:10ff:1000::1\]:aaa.txt . > scp '[3ffe:501:10ff:1000::1]:aaa.txt' . Our point is why not choose shell-safe characters. It's easy to say escaping and/or quoting works. But it is not easy to use. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 03:06:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA12306 for ipng-dist; Wed, 24 Mar 1999 03:02:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12299 for ; Wed, 24 Mar 1999 03:02:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id DAA10698 for ; Wed, 24 Mar 1999 03:02:31 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA18347 for ; Wed, 24 Mar 1999 03:02:21 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id MAA18177; Wed, 24 Mar 1999 12:01:19 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id MAA11135; Wed, 24 Mar 1999 12:01:18 +0100 (MET) Message-ID: <19990324120117.A11101@cs.uni-bonn.de> Date: Wed, 24 Mar 1999 12:01:17 +0100 From: "I. Souvatzis" To: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: (IPng 7346) Re: The expression of IPv6 addresses. References: <19990324191735H.sekiya@sfc.wide.ad.jp> <19990324113614.B10916@cs.uni-bonn.de> <19990324194653C.kazu@iijlab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <19990324194653C.kazu@iijlab.net>; from Kazu Yamamoto on Wed, Mar 24, 1999 at 07:46:53PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Mar 24, 1999 at 07:46:53PM +0900, Kazu Yamamoto wrote: > From: "I. Souvatzis" > Subject: (IPng 7344) Re: The expression of IPv6 addresses. > Date: Wed, 24 Mar 1999 11:36:14 +0100 > > > Escape the brackets, or quote the name: > > Of couse, we know. > > > scp \[3ffe:501:10ff:1000::1\]:aaa.txt . > > scp '[3ffe:501:10ff:1000::1]:aaa.txt' . > > Our point is why not choose shell-safe characters. > > It's easy to say escaping and/or quoting works. But it is not easy to > use. Only if you aren't used to it. I guess the problem is that it can't really be avoided. If you change it, somebody will speak up who uses a shell with the new characters. [] have the advantage that they are already in wide use for specifying numeric IPv4 addresses (in E-mail addresses). -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 03:16:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA12344 for ipng-dist; Wed, 24 Mar 1999 03:13:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12337 for ; Wed, 24 Mar 1999 03:13:14 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id DAA05283 for ; Wed, 24 Mar 1999 03:13:13 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id DAA21476 for ; Wed, 24 Mar 1999 03:13:11 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.58) id LA32000; Wed, 24 Mar 1999 22:13:00 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7347) Re: The expression of IPv6 addresses. In-Reply-To: Your message of "Wed, 24 Mar 1999 19:46:53 +0900." <19990324194653C.kazu@iijlab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Mar 1999 22:12:59 +1100 Message-Id: <14880.922273979@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 24 Mar 1999 19:46:53 +0900 From: Kazu Yamamoto Message-ID: <19990324194653C.kazu@iijlab.net> | It's easy to say escaping and/or quoting works. But it is not easy to | use. It doesn't have to be easy to use. IPv6 addresses by their very nature (128 bits of gibberish) are not going to be easy to use. however they're written. Except in the very rare cases where the DNS isn't working, names should be used instead of addresses. All that is required after that is that it be possible to use an IPv6 address literally, for the odd times when name translation isn't working - it doesn't have to be easy. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 06:46:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA12452 for ipng-dist; Wed, 24 Mar 1999 06:38:20 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12445 for ; Wed, 24 Mar 1999 06:38:09 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id GAA26328 for ; Wed, 24 Mar 1999 06:38:08 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA13122 for ; Wed, 24 Mar 1999 06:38:08 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA21440; Wed, 24 Mar 1999 08:38:01 -0600 (CST) Message-Id: <199903241438.IAA21440@gungnir.fnal.gov> To: =?iso-2022-jp?B?GyRCJDskLSRkJGYkJiQ4GyhCLw==?= Yuji SEKIYA Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 7348) Re: The expression of IPv6 addresses. In-reply-to: Your message of Wed, 24 Mar 1999 19:17:35 +0900. <19990324191735H.sekiya@sfc.wide.ad.jp> Date: Wed, 24 Mar 1999 08:38:01 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ..., and > > scp [3ffe:501:10ff:1000::1]:aaa.txt . > will be expanded as regular expression by shell. There are already a lot of standard unix commands that want some shell-special characters in their arguments and hence require quoting. Requiring shell quoting for address literals wouldn't bother me in the least. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 08:54:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA12652 for ipng-dist; Wed, 24 Mar 1999 08:49:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12645 for ; Wed, 24 Mar 1999 08:49:25 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id IAA01666 for ; Wed, 24 Mar 1999 08:49:22 -0800 (PST) Received: from karmosin08.nada.kth.se (karmosin08.nada.kth.se [130.237.226.37]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA17298 for ; Wed, 24 Mar 1999 08:49:21 -0800 (PST) Received: (from d95-mah@localhost) by karmosin08.nada.kth.se (8.8.7/8.8.7) id RAA03104; Wed, 24 Mar 1999 17:49:07 +0100 (MET) To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7349) Re: The expression of IPv6 addresses. References: <19990324191735H.sekiya@sfc.wide.ad.jp> <19990324113614.B10916@cs.uni-bonn.de> <19990324194653C.kazu@iijlab.net> From: Magnus Ahltorp Date: 24 Mar 1999 17:49:07 +0100 In-Reply-To: Kazu Yamamoto's message of "Wed, 24 Mar 1999 19:46:53 +0900" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > scp \[3ffe:501:10ff:1000::1\]:aaa.txt . > > scp '[3ffe:501:10ff:1000::1]:aaa.txt' . > > Our point is why not choose shell-safe characters. Because shells are not uniform. For example, in VMS, the [foo] would indicate a path. '/' would indicate a parameter. You have a more serious problem when the names of the files that should be copied include ':' (legal on Unix type systems). /Magnus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 09:10:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA12671 for ipng-dist; Wed, 24 Mar 1999 09:06:28 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12664 for ; Wed, 24 Mar 1999 09:06:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA24956 for ; Wed, 24 Mar 1999 09:06:18 -0800 (PST) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA02765 for ; Wed, 24 Mar 1999 09:06:18 -0800 (PST) Received: (qmail 3178 invoked from network); 24 Mar 1999 17:06:15 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 24 Mar 1999 17:06:15 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA11306; Wed, 24 Mar 1999 12:06:11 -0500 (EST) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.0/8.9.0) with SMTP id MAA15067; Wed, 24 Mar 1999 12:06:04 -0500 (EST) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Wed, 24 Mar 1999 12:06:04 -0500 (EST) From: Shane Kerr X-Sender: kerr@sunshine To: Magnus Ahltorp cc: ipng@sunroof.eng.sun.com Subject: (IPng 7350) Re: The expression of IPv6 addresses. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 24 Mar 1999, Magnus Ahltorp wrote: > > > scp \[3ffe:501:10ff:1000::1\]:aaa.txt . > > > scp '[3ffe:501:10ff:1000::1]:aaa.txt' . > > > > Our point is why not choose shell-safe characters. > > Because shells are not uniform. For example, in VMS, the [foo] would > indicate a path. '/' would indicate a parameter. > > You have a more serious problem when the names of the files that > should be copied include ':' (legal on Unix type systems). This is not really an IPv6-related problem, however. The current rcp/scp syntax uses the colon character. The IPv6-related problem is how to disambiguate the colons present in the address from the colon seperator character in rcp/scp and URL formats. The proposed notation achieves this goal. I remember looking through some old mail archives a couple of months ago from circa 1994 discussing this problem, and the general concensus seemed to be that almost any change in syntax was just too darn hard for URL parsers. Is this no longer the case? (I hope.) -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 09:16:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA12701 for ipng-dist; Wed, 24 Mar 1999 09:14:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12694 for ; Wed, 24 Mar 1999 09:14:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA05668 for ; Wed, 24 Mar 1999 09:14:16 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA08935 for ; Wed, 24 Mar 1999 09:14:17 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 24 Mar 1999 09:14:17 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81FC3@RED-MSG-50> From: Richard Draves To: ipng@sunroof.eng.sun.com Subject: (IPng 7351) Re: The expression of IPv6 addresses. Date: Wed, 24 Mar 1999 09:14:12 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I remember looking through some old mail archives a couple of > months ago > from circa 1994 discussing this problem, and the general > concensus seemed > to be that almost any change in syntax was just too darn hard for URL > parsers. Is this no longer the case? (I hope.) IE5 might well be a different story, but I found it to be quite easy to modify IE4 to understand the [] syntax. 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 Mar 24 09:52:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA12810 for ipng-dist; Wed, 24 Mar 1999 09:39:44 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12803 for ; Wed, 24 Mar 1999 09:39:39 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA08187 for ipng@sunroof.eng.sun.com; Wed, 24 Mar 1999 09:38:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12117 for ; Tue, 23 Mar 1999 23:30:53 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id XAA24248 for ; Tue, 23 Mar 1999 23:30:51 -0800 (PST) Received: from dur.tbit.dk (dur.tbit.dk [194.182.135.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA24677 for ; Tue, 23 Mar 1999 23:30:52 -0800 (PST) Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id IAA06911 for ; Wed, 24 Mar 1999 08:30:51 +0100 (MET) Date: Wed, 24 Mar 1999 08:30:49 +0100 (MET) From: "Peder Chr. Norgaard" To: ipng@sunroof.eng.sun.com Subject: (IPng 7352) SNMP Transport Method, snmpDomains value for IPv6? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not sure whether this is an IPv6 or SNMP topic - thus I've chosen to put the question to both lists. By now I have implemented (most of) the newly issued IPv6-related MIBs - then I would very much like to *run* SNMP over IPv6 That in itself is not difficult. But for various SNMP-internal housekeeping purposes I find that an extension to the SNMPv2-TM definitions is needed - one that specify a transport domain "UDP over IPv6" and a mapping of the related address to a replacement for the TAddress textual convention. I find nothing of the sort in the IPv6-related MIBs. If I understand the IETF process right, this more or less calls for a re-issuing of the SNMPv2-TM specification; at the very least the issuing of a new snmpDomains value from IANA. Is that a process that is being started anywhere? best regards --peder chr. Peder Chr. Nørgaard System Developer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 49 Fabrikvej 11 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 17:57:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA13443 for ipng-dist; Wed, 24 Mar 1999 17:33:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13436 for ; Wed, 24 Mar 1999 17:33:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id RAA25287 for ; Wed, 24 Mar 1999 17:32:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA04999 for ; Wed, 24 Mar 1999 17:32:20 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA27808; Wed, 24 Mar 1999 17:32:19 -0800 (PST) Message-Id: <3.0.5.32.19990324173125.007d0290@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 24 Mar 1999 17:31:25 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7353) W.G. Last Call on "IPv6 Jumbograms" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : IPv6 Jumbograms Author(s) : D. Borman, S. Deering, R. Hinden Filename : draft-ietf-ipngwg-jumbograms-00.txt Pages : 8 Date : 01-Mar-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on April 7, 1999. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 18:00:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA13483 for ipng-dist; Wed, 24 Mar 1999 17:55:20 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13476 for ; Wed, 24 Mar 1999 17:55:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id RAA19082 for ; Wed, 24 Mar 1999 17:54:55 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA21944 for ; Wed, 24 Mar 1999 17:54:54 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA29326; Wed, 24 Mar 1999 17:54:53 -0800 (PST) Message-Id: <3.0.5.32.19990324175312.007d8d50@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 24 Mar 1999 17:53:12 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7357) Informal W.G. Last Call on "The Case for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a informal IPng working group last call for comments on advancing the following document as an Informational RFC: Title : The Case for IPv6 Author(s) : S. King, R. Fax, D. Haskin, W. Ling, T. Meehan, B. Fink, C. Perkins Filename : draft-ietf-iab-case-for-ipv6-04.txt Pages : 51 Date : 01-Mar-99 This is an informal w.g. last call because the document is not an IPng w.g. document (i.e., it is an IAB document) and the IAB requested that it be reviewed by the IPng w.g. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on April 7, 1999. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 18:00:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA13464 for ipng-dist; Wed, 24 Mar 1999 17:42:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13457 for ; Wed, 24 Mar 1999 17:41:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id RAA17097 for ; Wed, 24 Mar 1999 17:41:00 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA11284 for ; Wed, 24 Mar 1999 17:40:59 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA28239; Wed, 24 Mar 1999 17:40:59 -0800 (PST) Message-Id: <3.0.5.32.19990324173712.00a87e40@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 24 Mar 1999 17:37:12 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7355) W.G. Last Call on "Multicast Listener Discovery (MLD) for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Multicast Listener Discovery (MLD) for IPv6 Author(s) : S. Deering, B. Fenner, B. Haberman Filename : draft-ietf-ipngwg-mld-01.txt Pages : 20 Date : 01-Mar-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on April 7, 1999. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 18:00:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA13475 for ipng-dist; Wed, 24 Mar 1999 17:55:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13467 for ; Wed, 24 Mar 1999 17:54:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id RAA28584 for ; Wed, 24 Mar 1999 17:54:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA21938 for ; Wed, 24 Mar 1999 17:54:53 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA29323; Wed, 24 Mar 1999 17:54:52 -0800 (PST) Message-Id: <3.0.5.32.19990324175004.00aee960@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 24 Mar 1999 17:50:04 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7356) W.G. Last Call on "A Method for flexible IPv6 Address Assignments" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Informational RFC: Title : A Method for flexible IPv6 Address Assignments Author(s) : M. Blanchet Filename : draft-ietf-ipngwg-ipaddressassign-00.txt Pages : 5 Date : 17-October-1009 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on April 7, 1999. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 24 18:04:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA13455 for ipng-dist; Wed, 24 Mar 1999 17:41:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13448 for ; Wed, 24 Mar 1999 17:41:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id RAA12916 for ; Wed, 24 Mar 1999 17:40:57 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA11277 for ; Wed, 24 Mar 1999 17:40:59 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA28236; Wed, 24 Mar 1999 17:40:58 -0800 (PST) Message-Id: <3.0.5.32.19990324173517.00a89d70@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 24 Mar 1999 17:35:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7354) W.G. Last Call on "Router Renumbering for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-08.txt Pages : 30 Date : 01-Mar-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on April 7, 1999. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 06:11:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA13879 for ipng-dist; Thu, 25 Mar 1999 05:50:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13872 for ; Thu, 25 Mar 1999 05:50:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id FAA03866 for ; Thu, 25 Mar 1999 05:50:30 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA00238 for ; Thu, 25 Mar 1999 05:50:29 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id NAA37366; Thu, 25 Mar 1999 13:50:23 GMT Received: from hursley.ibm.com (9-20-31-53.dhcp.hursley.ibm.com [9.20.31.53]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id NAA20526; Thu, 25 Mar 1999 13:50:22 GMT Message-ID: <36FA3EEF.AAC8F415@hursley.ibm.com> Date: Thu, 25 Mar 1999 13:49:35 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Richard Draves CC: ipng@sunroof.eng.sun.com Subject: (IPng 7358) Re: The expression of IPv6 addresses. References: <4D0A23B3F74DD111ACCD00805F31D8100AF81FC3@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The problem as expressed by the Webheads is not that modifying IE and Netscape is hard, but that there are literally hundreds of URL parsers "out there" in Perl scripts and the like, and IPv6 literals with or without [] break all of those. Brian Richard Draves wrote: > > > I remember looking through some old mail archives a couple of > > months ago > > from circa 1994 discussing this problem, and the general > > concensus seemed > > to be that almost any change in syntax was just too darn hard for URL > > parsers. Is this no longer the case? (I hope.) > > IE5 might well be a different story, but I found it to be quite easy to > modify IE4 to understand the [] syntax. > > Rich > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 09:03:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA14016 for ipng-dist; Thu, 25 Mar 1999 08:59:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14006 for ; Thu, 25 Mar 1999 08:59:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id IAA03146 for ; Thu, 25 Mar 1999 08:59:00 -0800 (PST) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA23591 for ; Thu, 25 Mar 1999 08:58:59 -0800 (PST) Received: (qmail 1123 invoked from network); 25 Mar 1999 16:58:58 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 25 Mar 1999 16:58:58 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA20261 for ; Thu, 25 Mar 1999 11:58:58 -0500 (EST) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.0/8.9.0) with SMTP id LAA15768 for ; Thu, 25 Mar 1999 11:58:49 -0500 (EST) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Thu, 25 Mar 1999 11:58:49 -0500 (EST) From: Shane Kerr X-Sender: kerr@sunshine Reply-To: Shane Kerr To: ipng@sunroof.eng.sun.com Subject: (IPng 7359) Re: W.G. Last Call on "A Method for flexible IPv6 Address Assignments" In-Reply-To: <3.0.5.32.19990324175004.00aee960@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 24 Mar 1999, Bob Hinden wrote: > This is a IPng working group last call for comments on advancing the > following document as a Informational RFC: > > Title : A Method for flexible IPv6 Address Assignments > Author(s) : M. Blanchet > Filename : draft-ietf-ipngwg-ipaddressassign-00.txt > Pages : 5 > Date : 17-October-1009 The first Y2K bug I've experienced. ^^^^ Unless this draft is MUCH older than 6 months. (Okay, maybe it's just a typo.) > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the author. This last call period will end two > week from today on April 7, 1999. Is it just me, or does IPv6 seem very classful? With all of this TLA, sub-TLA, NLA, SLA, and now sub-NLA stuff, that is. I much prefer to think in terms of /13, /29, /35, /48, or /40, especially since the definitions of the aggregation levels are subject to change. "I can't route from my SLA." "Is that a new-style SLA or an old-style SLA?" Yuck. Anyway, to address this draft, I do indeed like the suggestion of using the RFC1219 style of numbering from the leftmost bits on allocation, but am concerned with how general the applicability is, especially when the centermost numbering is added. RFC1219 deals with the problem of allowing a network operator to grow (and shrink, I suppose) network sizes gracefully. However it assumes that the administrator decides what number are going to be assigned on both the leftmost and rightmost ends of the bit-field. While this is possibly true in an organization, I suspect that there aren't nearly so many organizations that control network assignments at THREE levels. This draft has little or no applicability to registries, since we can't really make any kinds of assumptions about how address space will be used - maybe the context should be refocused towards bodies that have some control over multiple levels of the address hierarchy (large ISP's, multi-building corporations, or universities perhaps). Personally, I'm operating under the assumption that an initial /35 allocation will be enough space for any one organization for the forseeable future (after all, this is a number of networks 1/8 the size of the existing IPv4 address space). -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 09:43:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA14070 for ipng-dist; Thu, 25 Mar 1999 09:37:35 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14063 for ; Thu, 25 Mar 1999 09:37:26 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA09111 for ; Thu, 25 Mar 1999 09:37:24 -0800 (PST) Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA20675 for ; Thu, 25 Mar 1999 09:37:22 -0800 (PST) Received: from alderhill.wins.lbl.gov (alderhill) [128.3.9.220] by mail1.es.net with smtp (Exim 1.81 #2) id 10QE4E-0003OQ-00; Thu, 25 Mar 1999 09:37:18 -0800 Message-Id: <4.1.19990325092743.01b41300@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 25 Mar 1999 09:37:17 -0800 To: Shane Kerr From: Bob Fink Subject: (IPng 7360) Re: W.G. Last Call on "A Method for flexible IPv6 Address Assignments" Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <3.0.5.32.19990324175004.00aee960@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shane, At 11:58 AM 3/25/99 -0500, Shane Kerr wrote: ... >Personally, I'm operating under the assumption that an initial /35 >allocation will be enough space for any one organization for the >forseeable future (after all, this is a number of networks 1/8 the size of >the existing IPv4 address space). I disagree that a /35 is reasonable as it removes the possibility for a larger provider to allocate space from the NLA below them (which would only be 13 bits in the case of the /35 Sub-TLA) in a hierarchical manner to downstream transits/networks and leave those networks any space to work with. For example, if you imagined a Sprint or UUNET or MCI as the Sub-TLA, they could easily have hundreds of downstream local ISPs. If you used a 6-8 bit NLA1 space for these downstream ISPs, then each would only have 7-5 bits for their customers NLA2 space below them... hardly enough in any real world situation for them to number many customers. And saying that the ISP could just come back for more of their /29 Sub-TLA space doesn't make it work as you are already committed to staying to the right of the /35 unless serious and continuous renumbering takes place. Return to a /29 Sub-TLA initial assignment and let the ISPs get about their business, IMO. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 10:20:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA14110 for ipng-dist; Thu, 25 Mar 1999 10:10:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14103 for ; Thu, 25 Mar 1999 10:09:59 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id KAA14204 for ; Thu, 25 Mar 1999 10:09:57 -0800 (PST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA13221 for ; Thu, 25 Mar 1999 10:09:38 -0800 (PST) Received: from alden (ALDEN.maxware.no [10.128.9.11] (may be forged)) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id TAA12024; Thu, 25 Mar 1999 19:09:32 +0100 Message-Id: <4.1.19990324195416.0515c3a0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 24 Mar 1999 19:58:53 +0100 To: "Peder Chr. Norgaard" , ipng@sunroof.eng.sun.com From: Harald Tveit Alvestrand Subject: (IPng 7361) Re: SNMP Transport Method, snmpDomains value for IPv6? Cc: snmpv3@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:20 24.03.99 +0100, Peder Chr. Norgaard wrote: >That in itself is not difficult. But for various SNMP-internal >housekeeping purposes I find that an extension to the SNMPv2-TM >definitions is needed - one that specify a transport domain "UDP over >IPv6" and a mapping of the related address to a replacement for the >TAddress textual convention. I find nothing of the sort in the >IPv6-related MIBs. > Mike Daniele has been trying to get people interested in this. See draft-daniele-iana-addr-mib-00.txt Do add your voice to his - this work needs to be done. The responsible ADs are, I believe, Randy Bush and Bert Wijnen. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 10:40:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA14238 for ipng-dist; Thu, 25 Mar 1999 10:36:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14228 for ; Thu, 25 Mar 1999 10:36:47 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id KAA08849 for ; Thu, 25 Mar 1999 10:36:43 -0800 (PST) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA02482 for ; Thu, 25 Mar 1999 10:36:43 -0800 (PST) Received: (qmail 12637 invoked from network); 25 Mar 1999 18:36:42 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 25 Mar 1999 18:36:42 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA29739; Thu, 25 Mar 1999 13:36:41 -0500 (EST) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.0/8.9.0) with SMTP id NAA15823; Thu, 25 Mar 1999 13:36:33 -0500 (EST) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Thu, 25 Mar 1999 13:36:33 -0500 (EST) From: Shane Kerr X-Sender: kerr@sunshine Reply-To: Shane Kerr To: Bob Fink cc: ipng@sunroof.eng.sun.com Subject: (IPng 7362) Re: IPv6 allocations, was: Re: last call for draft In-Reply-To: <4.1.19990325092743.01b41300@imap2.es.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 25 Mar 1999, Bob Fink wrote: > At 11:58 AM 3/25/99 -0500, Shane Kerr wrote: > ... > >Personally, I'm operating under the assumption that an initial /35 > >allocation will be enough space for any one organization for the > >forseeable future (after all, this is a number of networks 1/8 the size of > >the existing IPv4 address space). > > I disagree that a /35 is reasonable as it removes the possibility for a > larger provider to allocate space from the NLA below them (which would > only be 13 bits in the case of the /35 Sub-TLA) in a hierarchical manner > to downstream transits/networks and leave those networks any space to > work with. See, this is exactly the kind of classful thinking that I was talking about in my e-mail! By restricting ourselves to these TLA/NLA/SLA notions we've sucessfully turned a 128-bit address into a 13-bit address, even though there are 29 bits available. Forcing arbritrary bit boundaries causes artificial shortages, as we observe here. > For example, if you imagined a Sprint or UUNET or MCI as the Sub-TLA, > they could easily have hundreds of downstream local ISPs. If you used a > 6-8 bit NLA1 space for these downstream ISPs, then each would only have > 7-5 bits for their customers NLA2 space below them... hardly enough in > any real world situation for them to number many customers. And saying > that the ISP could just come back for more of their /29 Sub-TLA space > doesn't make it work as you are already committed to staying to the > right of the /35 unless serious and continuous renumbering takes place. > > Return to a /29 Sub-TLA initial assignment and let the ISPs get about > their business, IMO. I'm just a humble engineer, without any say in these earth-shaking political policy decisions. Nevertheless, we intend to reserve a /29 for all comers initially, even though we only assign them a /35. For those organizations that actually need a /29, there will be no trouble in getting the additional space, without any renumbering. I'm not really sure what your comment about us being "committed to staying to the right of the /35" means. I would also like to raise a point that I mentioned briefly to Bob Hinden at the IETF, which is the inability to renumber easily is going to create another source of artificial shortage of numbers. Given that renumbering is hard, organizations are going to try to get larger space than they need in order to avoid renumbering. As an employee of a registry, I'd like to do everything in my power to reduce the tug-of-war that's going to occur between the registries and organizations, as we try to limit the number of TLA's (for routing - really!) and they try to avoid increased operational costs of renumbering. I guess I'd just like to raise awareness that this is an actual issue, and not just something to dismiss as being "hard". BTW, Matt Crawford's work on router renumber is an excellent start, although as he indicated in his "Steal this Slide" presentation he will probably not be able to do further work on this (as in cascading renumbering protocols and so on). Personally, I just want a /63 from my ISP. Is that even possible as things are planned today? "I'm sorry, SLA or single-IP only." -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 11:23:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA14264 for ipng-dist; Thu, 25 Mar 1999 11:15:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14257 for ; Thu, 25 Mar 1999 11:14:54 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id LAA17721 for ; Thu, 25 Mar 1999 11:14:46 -0800 (PST) Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA00486 for ; Thu, 25 Mar 1999 11:14:46 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id TAA06132; Thu, 25 Mar 1999 19:11:52 GMT Message-Id: <199903251911.TAA06132@inner.net> To: Shane Kerr cc: Bob Fink , ipng@sunroof.eng.sun.com Subject: (IPng 7363) Re: IPv6 allocations, was: Re: last call for draft In-reply-to: Your message of "Thu, 25 Mar 1999 13:36:33 EST." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 25 Mar 1999 14:13:33 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >I'm just a humble engineer, without any say in these earth-shaking >political policy decisions. Nevertheless, we intend to reserve a /29 for >all comers initially, even though we only assign them a /35. For those >organizations that actually need a /29, there will be no trouble in >getting the additional space, without any renumbering. Aside: Given that both human-printable addresses and current-generation IPv6 DNS use hexadecimal digits, splitting the assignment prefix on something not a hexadecimal digits encourages configuration errors. It may be way too late now, but IMO the registries should seriously reconsider any boundary choice that is not a multiple of four bits. On /29 vs /35, if my understanding is correct, even when registrants are only "allowed" to use the first /35 slice, they have the /29 reserved for them and are supposed to use a /29 top-level route. If the /29 is reserved for them and they have a route for /29, then what motivation is there for a site to go through the headache of getting approval from the registries to use the rest of their /29 instead of just doing it? That, in turn, appears to defeat the entire purpose of the /35's existence. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 11:26:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA14289 for ipng-dist; Thu, 25 Mar 1999 11:24:18 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14275 for ; Thu, 25 Mar 1999 11:24:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id LAA28524 for ; Thu, 25 Mar 1999 11:24:02 -0800 (PST) Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA06799 for ; Thu, 25 Mar 1999 11:24:01 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id TAA06138; Thu, 25 Mar 1999 19:21:17 GMT Message-Id: <199903251921.TAA06138@inner.net> To: Shane Kerr cc: Bob Fink , ipng@sunroof.eng.sun.com Subject: (IPng 7364) Re: IPv6 allocations, was: Re: last call for draft In-reply-to: Your message of "Thu, 25 Mar 1999 13:36:33 EST." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 25 Mar 1999 14:22:57 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >Personally, I just want a /63 from my ISP. Is that even possible as >things are planned today? "I'm sorry, SLA or single-IP only." On the 6Bone, many providers do what's right, not what the specs says you're necessarily supposed to do. For example, point-to-point links are generally set up as /126 subnets, even though there's a decent argument based on the addressing specs that you shouldn't do that (they'd be /127 if we didn't burn the zero-host address for anycast). I expect that operational practice will match this. If, understanding the consequences of your actions (e.g., possible future renumbering), you ask your provider for an allocation that conserves address space, most will probably be happy to give it to you. In the IPv4 world, if you ask your ISP to give you less address space, most ISPs won't argue with you ;) -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 12:35:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA14384 for ipng-dist; Thu, 25 Mar 1999 12:27:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14377 for ; Thu, 25 Mar 1999 12:27:11 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id MAA00549 for ; Thu, 25 Mar 1999 12:27:08 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA17509 for ; Thu, 25 Mar 1999 12:27:09 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA28423; Thu, 25 Mar 1999 14:27:00 -0600 (CST) Message-Id: <199903252027.OAA28423@gungnir.fnal.gov> To: Shane Kerr Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 7365) Re: W.G. Last Call on "A Method for flexible IPv6 Address Assignments" In-reply-to: Your message of Thu, 25 Mar 1999 11:58:49 EST. Date: Thu, 25 Mar 1999 14:27:00 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is it just me, or does IPv6 seem very classful? Yes and no. From the site's point of view there's only one class. > I much prefer to think in terms of /13, /29, /35, /48, or /40, ... I'm with you on that, but I can't agree with the following. > Personally, I'm operating under the assumption that an initial /35 > allocation will be enough space for any one organization for the > forseeable future (after all, this is a number of networks 1/8 the > size of the existing IPv4 address space). This is a distortion. Leaving aside the home dialup customers for the moment, all "Sites" get a /48. No more, no less. That is a choice which has been made and has some technical reasons behind it. It's not, begging your pardon, for registries or ISPs to haggle about. It's changeable only by IETF action, if at all. That means that a /35 allows numbering of up to 2^13 sites. The registries and ISPs know better than I do what efficiency there may be if there are one, two or three intermediate levels of delegation. We may assume that IPv6 renumbering will become much less painful than IPv4 renumbering is today but even so, it is very well that room is being reserved for growth of the initial /35's without renumbering. I'm hoping that someone else will write about the other goal of aggressive aggregation -- limiting the size and volatility of the default-free routing tables. ______________________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab "A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment, thoroughly smash them with a hammer or an ax, and scatter the pieces." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 25 15:04:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA14462 for ipng-dist; Thu, 25 Mar 1999 15:00:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14455 for ; Thu, 25 Mar 1999 15:00:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id PAA02255 for ; Thu, 25 Mar 1999 15:00:12 -0800 (PST) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA25563 for ; Thu, 25 Mar 1999 15:00:11 -0800 (PST) Received: from classic (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with SMTP id RAA04789; Thu, 25 Mar 1999 17:52:02 -0500 (EST) Prefer-Language: fr, en Message-Id: <4.1.19990325163635.00c9a810@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 25 Mar 1999 16:55:23 -0600 To: Shane Kerr , ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: (IPng 7366) Re: W.G. Last Call on "A Method for flexible IPv6 Address Assignments" In-Reply-To: References: <3.0.5.32.19990324175004.00aee960@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:58 99-03-25 -0500, Shane Kerr wrote: >On Wed, 24 Mar 1999, Bob Hinden wrote: > >> This is a IPng working group last call for comments on advancing the >> following document as a Informational RFC: >> >> Title : A Method for flexible IPv6 Address Assignments >> Author(s) : M. Blanchet >> Filename : draft-ietf-ipngwg-ipaddressassign-00.txt >> Pages : 5 >> Date : 17-October-1009 > >The first Y2K bug I've experienced. ^^^^ Unless this draft is MUCH >older than 6 months. (Okay, maybe it's just a typo.) The draft is ok. > >> Please send substantive comments to the ipng mailing list, and minor >> editorial comments to the author. This last call period will end two >> week from today on April 7, 1999. > >Is it just me, or does IPv6 seem very classful? With all of this TLA, >sub-TLA, NLA, SLA, and now sub-NLA stuff, that is. I much prefer to think >in terms of /13, /29, /35, /48, or /40, especially since the definitions >of the aggregation levels are subject to change. "I can't route from my >SLA." "Is that a new-style SLA or an old-style SLA?" Yuck. The use of *LA in the draft was just to identify each party. This draft does not define a new assignment scheme. > >Anyway, to address this draft, I do indeed like the suggestion of using >the RFC1219 style of numbering from the leftmost bits on allocation, > but am concerned with how general the applicability is, especially when the >centermost numbering is added. You use it if you need it. The registries may not want to use it. But I know already major networks that are using the draft for making the assignments. You can also think about the large organisations that have been assigned a prefix and want to delegate the task of assignments to divisions and the divisions delegate to departements and furthermore. Then using this scheme enables you to have more flexibility if the network changes, or 10 new divisions of a company that has been bought, like it seems to happen often!. > >RFC1219 deals with the problem of allowing a network operator to grow (and >shrink, I suppose) network sizes gracefully. Assignment is not only done by "network operators". >However it assumes that the >administrator decides what number are going to be assigned on both the >leftmost and rightmost ends of the bit-field. While this is possibly true >in an organization, I suspect that there aren't nearly so many >organizations that control network assignments at THREE levels. See the comment before. > >This draft has little or no applicability to registries, since we can't >really make any kinds of assumptions about how address space will be used as said, you choose if you want to use it. >- maybe the context should be refocused towards bodies that have some >control over multiple levels of the address hierarchy (large ISP's, >multi-building corporations, or universities perhaps). that was the intent. Maybe, I can change the wording to be more precise on this. > >Personally, I'm operating under the assumption that an initial /35 >allocation will be enough space for any one organization for the >forseeable future (after all, this is a number of networks 1/8 the size of >the existing IPv4 address space). > >-- >Shane Kerr >Software Engineer >American Registry for Internet Numbers > Thanks for your comments. Marc. > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 26 01:38:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA14783 for ipng-dist; Fri, 26 Mar 1999 01:32:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14776 for ; Fri, 26 Mar 1999 01:32:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id BAA26867 for ; Fri, 26 Mar 1999 01:32:20 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA14157 for ; Fri, 26 Mar 1999 01:32:19 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id JAA46760; Fri, 26 Mar 1999 09:32:16 GMT Received: from hursley.ibm.com (9-20-31-53.dhcp.hursley.ibm.com [9.20.31.53]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id JAA15396; Fri, 26 Mar 1999 09:32:06 GMT Message-ID: <36FB53E4.D0CB2E90@hursley.ibm.com> Date: Fri, 26 Mar 1999 09:31:16 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Shane Kerr CC: Bob Fink , ipng@sunroof.eng.sun.com Subject: (IPng 7368) Re: IPv6 allocations, was: Re: last call for draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shane, Let's not confuse the discussion of the TLA address format and structure, which is a done deal already decided by the IETF, and TLA/subTLA allocation policy, which is a non-IETF matter currently being debated among the registries. You are correct that getting renumbering to work (more) easily is key, and that is what the IETF should be worrying about now. Brian Shane Kerr wrote: > > On Thu, 25 Mar 1999, Bob Fink wrote: > > > At 11:58 AM 3/25/99 -0500, Shane Kerr wrote: > > ... > > >Personally, I'm operating under the assumption that an initial /35 > > >allocation will be enough space for any one organization for the > > >forseeable future (after all, this is a number of networks 1/8 the size of > > >the existing IPv4 address space). > > > > I disagree that a /35 is reasonable as it removes the possibility for a > > larger provider to allocate space from the NLA below them (which would > > only be 13 bits in the case of the /35 Sub-TLA) in a hierarchical manner > > to downstream transits/networks and leave those networks any space to > > work with. > > See, this is exactly the kind of classful thinking that I was talking > about in my e-mail! By restricting ourselves to these TLA/NLA/SLA notions > we've sucessfully turned a 128-bit address into a 13-bit address, even > though there are 29 bits available. Forcing arbritrary bit boundaries > causes artificial shortages, as we observe here. > > > For example, if you imagined a Sprint or UUNET or MCI as the Sub-TLA, > > they could easily have hundreds of downstream local ISPs. If you used a > > 6-8 bit NLA1 space for these downstream ISPs, then each would only have > > 7-5 bits for their customers NLA2 space below them... hardly enough in > > any real world situation for them to number many customers. And saying > > that the ISP could just come back for more of their /29 Sub-TLA space > > doesn't make it work as you are already committed to staying to the > > right of the /35 unless serious and continuous renumbering takes place. > > > > Return to a /29 Sub-TLA initial assignment and let the ISPs get about > > their business, IMO. > > I'm just a humble engineer, without any say in these earth-shaking > political policy decisions. Nevertheless, we intend to reserve a /29 for > all comers initially, even though we only assign them a /35. For those > organizations that actually need a /29, there will be no trouble in > getting the additional space, without any renumbering. I'm not really > sure what your comment about us being "committed to staying to the right > of the /35" means. > > I would also like to raise a point that I mentioned briefly to Bob Hinden > at the IETF, which is the inability to renumber easily is going to create > another source of artificial shortage of numbers. Given that renumbering > is hard, organizations are going to try to get larger space than they need > in order to avoid renumbering. As an employee of a registry, I'd like to > do everything in my power to reduce the tug-of-war that's going to occur > between the registries and organizations, as we try to limit the number of > TLA's (for routing - really!) and they try to avoid increased operational > costs of renumbering. I guess I'd just like to raise awareness that this > is an actual issue, and not just something to dismiss as being "hard". > BTW, Matt Crawford's work on router renumber is an excellent start, > although as he indicated in his "Steal this Slide" presentation he will > probably not be able to do further work on this (as in cascading > renumbering protocols and so on). > > Personally, I just want a /63 from my ISP. Is that even possible as > things are planned today? "I'm sorry, SLA or single-IP only." > > -- > Shane Kerr > Software Engineer > American Registry for Internet Numbers > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 26 02:16:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA14809 for ipng-dist; Fri, 26 Mar 1999 02:13:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14802 for ; Fri, 26 Mar 1999 02:13:29 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id CAA24763 for ; Fri, 26 Mar 1999 02:13:27 -0800 (PST) Received: from dur.tbit.dk (dur.tbit.dk [194.182.135.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA25799 for ; Fri, 26 Mar 1999 02:13:27 -0800 (PST) Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id LAA26699; Fri, 26 Mar 1999 11:13:24 +0100 (MET) Date: Fri, 26 Mar 1999 11:13:22 +0100 (MET) From: "Peder Chr. Norgaard" To: Harald Tveit Alvestrand cc: ipng@sunroof.eng.sun.com, snmpv3@lists.tislabs.com Subject: (IPng 7369) Re: SNMP Transport Method, snmpDomains value for IPv6? In-Reply-To: <4.1.19990324195416.0515c3a0@dokka.maxware.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 24 Mar 1999, Harald Tveit Alvestrand wrote: > At 11:20 24.03.99 +0100, Peder Chr. Norgaard wrote: > > >That in itself is not difficult. But for various SNMP-internal > >housekeeping purposes I find that an extension to the SNMPv2-TM > >definitions is needed - one that specify a transport domain "UDP over > >IPv6" and a mapping of the related address to a replacement for the > >TAddress textual convention. I find nothing of the sort in the > >IPv6-related MIBs. > > > > Mike Daniele has been trying to get people interested in this. > See draft-daniele-iana-addr-mib-00.txt > > Do add your voice to his - this work needs to be done. > The responsible ADs are, I believe, Randy Bush and Bert Wijnen. You are perfectly right, thank you very much. The draft has exactly what I need - except that it is not standardized yet ..... I will contact Mike Daniele directly now. best regards --peder chr. Peder Chr. Nørgaard System Developer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 49 Fabrikvej 11 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 26 03:46:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA14846 for ipng-dist; Fri, 26 Mar 1999 03:38:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14839 for ; Fri, 26 Mar 1999 03:38:41 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id DAA09406 for ; Fri, 26 Mar 1999 03:38:39 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA16818 for ; Fri, 26 Mar 1999 03:38:33 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA42140 for ; Fri, 26 Mar 1999 11:38:31 GMT Received: from hursley.ibm.com (9-20-31-53.dhcp.hursley.ibm.com [9.20.31.53]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA20250 for ; Fri, 26 Mar 1999 11:38:30 GMT Message-ID: <36FB7184.79ED1530@hursley.ibm.com> Date: Fri, 26 Mar 1999 11:37:40 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 7370) Re: W.G. Last Call on "A Method for flexible IPv6 Address Assignments" References: <3.0.5.32.19990324175004.00aee960@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I can see no argument against publishing this as informational, though whether the registries implement it is another matter. > 5. Implementation > > While describing this method is easier displaying bits, it is not useful > to do the assignment using bits. Programs implementing this method will > be useful. This is very unclear to me; there seem to be many logic steps compressed into this, and the last sentence is not useful without considerable explanation. > 7. Security Considerations > > Address assignment doesn't seem to have any specific security consideration. > I'm sure that "doesn't seem to have any" won't get past the IESG. "has no known" would be better. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 26 03:49:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA14864 for ipng-dist; Fri, 26 Mar 1999 03:48:04 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14857 for ; Fri, 26 Mar 1999 03:47:55 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id DAA10133 for ; Fri, 26 Mar 1999 03:47:54 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA18941 for ; Fri, 26 Mar 1999 03:47:49 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA39210 for ; Fri, 26 Mar 1999 11:47:47 GMT Received: from hursley.ibm.com (9-20-31-53.dhcp.hursley.ibm.com [9.20.31.53]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA18586 for ; Fri, 26 Mar 1999 11:47:47 GMT Message-ID: <36FB73B0.AD7BAD0E@hursley.ibm.com> Date: Fri, 26 Mar 1999 11:46:56 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 7371) Re: W.G. Last Call on "IPv6 Jumbograms" References: <3.0.5.32.19990324173125.007d0290@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm in favour of advancing this. One obvious question you might get from the IESG is whether there are any non-editorial changes from RFC 1883 and 2147. Brian P.S. the WG charter page also points to an obsolete draft, draft-ietf-ipngwg-jumbo-00.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 Fri Mar 26 12:40:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA15365 for ipng-dist; Fri, 26 Mar 1999 12:24:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15358 for ; Fri, 26 Mar 1999 12:24:11 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id MAA03323 for ; Fri, 26 Mar 1999 12:24:08 -0800 (PST) Received: from send205.yahoomail.com (web134.yahoomail.com [205.180.60.221]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA25093 for ; Fri, 26 Mar 1999 12:24:09 -0800 (PST) Message-ID: <19990326202416.2164.rocketmail@send205.yahoomail.com> Received: from [138.111.39.180] by web134.yahoomail.com; Fri, 26 Mar 1999 12:24:16 PST Date: Fri, 26 Mar 1999 12:24:16 -0800 (PST) From: "Raghu V.V.J Vadapalli" Subject: (IPng 7373) Reg:W.G. Last Call on "IPv6 Jumbograms" To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1.Do we need to mention that IPv6 path MTU discovery is a strict requirementbefore using the IPv6 jumbo payload option in this draft. or The IPv6 path MTU made strict requirement in the IPv6 implementation itself. 2. Do we need include the following error: IPv6 Payload Length !=0 and Fragment Header is present and Jumbo Payload option present. With Regards -Raghu. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 26 15:04:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA15561 for ipng-dist; Fri, 26 Mar 1999 14:58:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15554 for ; Fri, 26 Mar 1999 14:58:44 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id OAA22097 for ; Fri, 26 Mar 1999 14:58:42 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA27025 for ; Fri, 26 Mar 1999 14:58:42 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA04247; Fri, 26 Mar 1999 16:58:39 -0600 (CST) Message-Id: <199903262258.QAA04247@gungnir.fnal.gov> To: "Raghu V.V.J Vadapalli" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 7375) Re: Reg:W.G. Last Call on "IPv6 Jumbograms" In-reply-to: Your message of Fri, 26 Mar 1999 12:24:16 PST. <19990326202416.2164.rocketmail@send205.yahoomail.com> Date: Fri, 26 Mar 1999 16:58:39 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1.Do we need to mention that IPv6 path MTU discovery is a strict > requirementbefore using the IPv6 jumbo payload option in this draft. > or > The IPv6 path MTU made strict requirement in the IPv6 implementation > itself. RFC 2460, section 5, comes within a millimeter of saying that nodes which send packets greater than 1280 octets MUST implement PMTUD, but doesn't quite get there. > 2. Do we need include the following error: > IPv6 Payload Length !=0 and Fragment Header is present and > Jumbo Payload option present. The HBH options have to come before the fragment header (because they must be seen without reassembly), so this is just a non-special case of the second error case in section 3. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 29 13:13:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA17341 for ipng-dist; Mon, 29 Mar 1999 13:05:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17334 for ; Mon, 29 Mar 1999 13:05:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id NAA29548 for ; Mon, 29 Mar 1999 13:05:21 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA00642 for ; Mon, 29 Mar 1999 13:05:19 -0800 (PST) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA03317; Mon, 29 Mar 1999 13:05:15 -0800 (PST) Message-Id: <3.0.5.32.19990329130420.007c77d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Mar 1999 13:04:20 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7379) IPng Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The meeting minutes for the IPng meeting held at the Minneapolis IETF are available as: http://playground.sun.com/ipng/minutes/ipng-minutes-mar99.txt Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 31 04:40:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA19223 for ipng-dist; Wed, 31 Mar 1999 04:38:05 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19216 for ; Wed, 31 Mar 1999 04:37:56 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id EAA04713 for ; Wed, 31 Mar 1999 04:37:55 -0800 (PST) Received: from buffalo.ru.ac.za (buffalo.ru.ac.za [146.231.128.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA26647 for ; Wed, 31 Mar 1999 04:37:48 -0800 (PST) Received: from sunbird.ru.ac.za ([146.231.192.51]) by buffalo.ru.ac.za with esmtp (Exim 2.10 #1) id 10SKFY-0006Hm-00 for ipng@sunroof.eng.sun.com; Wed, 31 Mar 1999 14:37:40 +0200 Received: from SUNBIRD/SpoolDir by sunbird.ru.ac.za (Mercury 1.21); 31 Mar 99 14:48:04 GMT+2 Received: from SpoolDir by SUNBIRD (Mercury 1.30); 31 Mar 99 14:47:43 GMT+2 Received: from dodo by sunbird.ru.ac.za (Mercury 1.30); 31 Mar 99 14:47:37 GMT+2 From: "Nakkiran Sunassee" To: ipng@sunroof.eng.sun.com Date: Thu, 1 Apr 1999 02:38:26 +0200 MIME-Version: 1.0 Content-type: text/enriched; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: (IPng 7384) paper X-mailer: Pegasus Mail for Win32 (v3.01d) Message-ID: <18054ED471E@sunbird.ru.ac.za> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 0100,0100,0100Hi I am doing a paper on the following topic: Comic Sans MS"ArialTowards a model of the transition from Internet Protocol version 4 to Internet Protocol version 6 for the business." If you have any papers/ideas, please send them to me or point me in the right direction? thanx :) -- NN Sunassee Bsc(Information Systems) Email: nakiz@rucus.ru.ac.za Phone: (w) +27 46 6038251 (h) +27 46 6229050 'Atheism: a non-prophet organisation' -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 31 12:05:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA19838 for ipng-dist; Wed, 31 Mar 1999 11:59:51 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19831 for ; Wed, 31 Mar 1999 11:59:39 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id LAA19032 for ; Wed, 31 Mar 1999 11:59:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA23185 for ; Wed, 31 Mar 1999 11:59:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28416; Wed, 31 Mar 1999 14:59:19 -0500 (EST) Message-Id: <199903311959.OAA28416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7386) I-D ACTION:draft-ietf-ipngwg-mld-mib-00.txt Date: Wed, 31 Mar 1999 14:59:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-00.txt Pages : 13 Date : 30-Mar-99 This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module which defines managed objects for implementations of the Multicast Listener Discovery Protocol [MLD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990331121153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990331121153.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 --------------------------------------------------------------------