From owner-ipng Fri Mar 1 05:43:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19277; Fri, 1 Mar 96 05:43:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19271; Fri, 1 Mar 96 05:43:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26307; Fri, 1 Mar 1996 05:41:53 -0800 Received: by mercury.Sun.COM (Sun.COM) id FAA04506; Fri, 1 Mar 1996 05:41:54 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id IAA05600; Fri, 1 Mar 1996 08:41:51 -0500 (EST) Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id IAA00488; Fri, 1 Mar 1996 08:38:58 -0500 (EST) Received: from localhost (malis@localhost) by phish.nexen.com (8.7.3/8.7.3) with SMTP id IAA23436; Fri, 1 Mar 1996 08:38:55 -0500 (EST) Message-Id: <199603011338.IAA23436@phish.nexen.com> To: rolc@nexen.com, ip-atm@nexen.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com Cc: malis@nexen.com Subject: (IPng 1515) Seeking volunteers for minutes, and a note for presenters Date: Fri, 01 Mar 1996 08:38:55 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Your friendly chairs are soliciting volunteers to assist with minute taking for one (or more) of the following sessions in LA: Routing Over Large Clouds (rolc) WG, Monday 3/4 at 1300-1500 and 1530-1730, chaired by Andy Malis IP Over ATM (ipatm) WG, Tuesday 3/5 at 1300-1500 and Wednesday 3/6 at 1300-1500, chaired by Mark Laubach and Andy Malis RSVP and INTSERV over ATM (tspatm) BOF, ipatm/rsvp/intserv joint session on Wednesday 3/6 at 1530-1730, chaired by Andy Malis IPv6 over NBMA (nbmav6) BOF, ipatm/rolc/ipng joint session on Thursday 3/7 at 1300-1500, chaired by Allison Mankin The only qualifications are the ability to write legibly or type on your laptap. :-) You don't have to record discussions or the contents of overheads - just the major points that are made in the meeting, and of course, any consensus that is formed by a WG. The intent is to be able to accurately convey what happened for those folks that couldn't attend. Handwritten minutes are fine as well - I'll even type them in and email you your own notes! The official guidelines are: "The minutes must contain complete sentences, not phrases; outlines are not acceptable. Minutes should provide a thorough summary of the issues discussed during the working group/BOF sessions. They should not follow a "Mortimer said," then "Agnes said," then "Duane said," format, nor should they contain a detailed list of changes to a document. While these forms may be helpful to the folks who actually attend the sessions, they are less helpful to those who have a more general interest in the groups' activities." Also, a word to those of you making presentations: you must bring an extra hard copy of your overheads for the secretariate to include in the proceedings (and so the minute takers don't have to write down their content), and sometime before the conclusion of the week, email postscript and/or source form of your presentations to me so that I can put them up for FTP and the secretariate can include them in the electronic version of the proceedings. You can also give them to me on a floppy (Mac or PC format) instead of email. The secretariate also asked me to say that they like overheads with borders. Please check out http://www.ietf.cnri.reston.va.us/instructions/slides.html for the official guidelines. Thanks in advance! Andy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 10:43:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19466; Fri, 1 Mar 96 10:43:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19460; Fri, 1 Mar 96 10:43:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17689; Fri, 1 Mar 1996 10:42:07 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA27252; Fri, 1 Mar 1996 10:41:43 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.4/8.7.1) id NAA01017 for ipng@sunroof.eng.sun.com; Fri, 1 Mar 1996 13:41:37 -0500 Received: via switchmail; Fri, 1 Mar 1996 13:41:36 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 1 Mar 1996 13:40:07 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 1 Mar 1996 13:40:01 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 1 Mar 1996 13:39:55 -0500 (EST) Message-Id: Date: Fri, 1 Mar 1996 13:39:55 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1516) Re: Thoughts on DNS and API In-Reply-To: <9603010148.AA04124@gemini.tuc.noao.edu> References: <9603010148.AA04124@gemini.tuc.noao.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk rstevens@noao.edu (Richard Stevens) writes: > > On the other hand, I get uncomfortable with the idea of specifying > > addressing information with setsockopt(). > > You're not specifying "addressing information" with a socket option, > you're specifying how to interpret the array of addresses that can > be passed to other functions. The statement of mine you quoted was in response to the following: Matt Thomas writes: > > First, how would it work with TCP? The application certainly could > > use sendmsg() on a TCP socket to specify a source route to use *after* > > the connection had been established. How would an application specify > > a source route to be used at connect() time? What about a passively > > accepted connection? > > As Dennis has said, this can be done via setsockopts (and probably should > given that is one has to be once per connection). So your response puts my statement in the wrong context and does not address any issues I've raised. > I think the array of addresses is a handy, simple way of doing what > the draft API proposes. All the functions that can return an array > already have a value-result argument that returns the size of the > array. I think the array is a reasonable way of returning this information. What I object to are the IPV6_RECVSRCRT, IPV6_RECVIF, and IPV6_SENDIF options. Apparently, if either of the first two options are set wrong, say by a process such as inetd out of the application's control, the information is irretrievably lost. The API should be designed to behave as if they are always set, or some other method should be used for passing the information. It has occured to me that a cleaner way of passing the source route and interface information would be to include it in the struct sockaddr_in6 -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 11:19:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19492; Fri, 1 Mar 96 11:19:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19486; Fri, 1 Mar 96 11:19:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25742; Fri, 1 Mar 1996 11:17:58 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA09592; Fri, 1 Mar 1996 11:17:56 -0800 Received: (from evi@localhost) by piper.cs.colorado.edu (8.7.4/8.7.3) id MAA14223; Fri, 1 Mar 1996 12:17:45 -0700 (MST) Date: Fri, 1 Mar 1996 12:17:45 -0700 (MST) From: Evi Nemeth Message-Id: <199603011917.MAA14223@piper.cs.colorado.edu> To: int-serv@isi.edu, ip-atm@nexen.com, ipng@sunroof.eng.sun.com, malis@nexen.com, rolc@nexen.com, rsvp@isi.edu Subject: (IPng 1517) Re: Seeking volunteers for minutes, and a note for presenters Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk and please get me postscript of any presentations that are to go on the mbone. each slide needs to be < 32k for wb to be happy, i have tools to split them and can sometimes compress them to make them fit. but avoiding fancy company logos is the best way to make them fit. if you are in an mbone session and your slides are done, please email me an ftp pointer or postscript now and indicate your session. if they arent done yet, find us at the mbone carts well before your talk to get us the postscript. thanks. -evi ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 12:17:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19562; Fri, 1 Mar 96 12:17:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19556; Fri, 1 Mar 96 12:16:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07556; Fri, 1 Mar 1996 12:15:13 -0800 Received: by mercury.Sun.COM (Sun.COM) id MAA26609; Fri, 1 Mar 1996 12:15:09 -0800 Received: from muggsy.lkg.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA16302; Fri, 1 Mar 1996 15:13:00 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA09831; Fri, 1 Mar 1996 15:12:58 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id UAA08340; Fri, 1 Mar 1996 20:13:52 GMT Message-Id: <199603012013.UAA08340@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1518) Re: Thoughts on DNS and API In-Reply-To: Your message of "Fri, 01 Mar 1996 13:39:55 EST." X-Mailer: exmh version 1.5omega 10/6/94 Date: Fri, 01 Mar 1996 20:13:52 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In , John Gardiner Myers wrote: > It has occured to me that a cleaner way of passing the source route > and interface information would be to include it in the > struct sockaddr_in6 I've toyed with the same idea. struct sockaddr_in6 { u_int8_t sin6_len; u_int8_t sin6_family; u_int16_t sin6_port; u_int32_t sin6_flowlabel; u_int8_t sin6_addrcount; u_int8_t sin6_flags; u_int16_t sin6_ifindex; u_int32_t sin6_srinfo; struct in6_addr sin6_addrlist[1] #define sin6_addr sin6_addrlist[0]; }; Note that the interface identifier is not an address, but a "small" integer. The interface identifier can not uniquely identify an address (since there may be multiple addresses per interface) but there should be a way to derive an interface index from an address. One of the major problems with this is that under 4.3 Reno or later the sin6_len field can only 8 bits wide which limits the sockaddr to 255 bytes. Unless we impose the semantic that if the sin6_len is 0, then you the length must be derived from other means. The address list would be from destination to source. This would allow for easier route lookups. Actually, you could insert a source route into the routing table (assuming you use a BSD 4.4 like routing table). Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 12:37:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19595; Fri, 1 Mar 96 12:37:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19589; Fri, 1 Mar 96 12:36:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11188; Fri, 1 Mar 1996 12:35:18 -0800 Received: by mercury.Sun.COM (Sun.COM) id MAA02213; Fri, 1 Mar 1996 12:35:14 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id PAA11778; Fri, 1 Mar 1996 15:35:07 -0500 (EST) Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id PAA08307; Fri, 1 Mar 1996 15:25:59 -0500 (EST) Received: from localhost (malis@localhost) by phish.nexen.com (8.7.3/8.7.3) with SMTP id PAA08030; Fri, 1 Mar 1996 15:25:56 -0500 (EST) Message-Id: <199603012025.PAA08030@phish.nexen.com> To: int-serv@isi.edu, ip-atm@nexen.com, ipng@sunroof.eng.sun.com, rolc@nexen.com, rsvp@isi.edu Cc: malis@nexen.com, Evi Nemeth Subject: (IPng 1519) Re: Seeking volunteers for minutes, and a note for presenters Date: Fri, 01 Mar 1996 15:25:56 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Evi's message applies to the two joint sessions, which are both on the mbone: RSVP and INTSERV over ATM (tspatm) BOF, ipatm/rsvp/intserv joint session on Wednesday 3/6 at 1530-1730, chaired by Andy Malis IPv6 over NBMA (nbmav6) BOF, ipatm/rolc/ipng joint session on Thursday 3/7 at 1300-1500, chaired by Allison Mankin Andy ------- In message <199603011917.MAA14223@piper.cs.colorado.edu>, Evi Nemeth writes: > and please get me postscript of any presentations that are to go on > the mbone. each slide needs to be < 32k for wb to be happy, i have > tools to split them and can sometimes compress them to make them fit. > but avoiding fancy company logos is the best way to make them fit. > > if you are in an mbone session and your slides are done, please email > me an ftp pointer or postscript now and indicate your session. if > they arent done yet, find us at the mbone carts well before your talk > to get us the postscript. > > thanks. > > -evi ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 12:39:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19607; Fri, 1 Mar 96 12:39:56 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19601; Fri, 1 Mar 96 12:39:37 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id MAA29151; Fri, 1 Mar 1996 12:37:08 -0800 (PST) Date: Fri, 1 Mar 1996 12:43:48 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1520) Re: Thoughts on DNS and API To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > It has occured to me that a cleaner way of passing the source route > > and interface information would be to include it in the > > struct sockaddr_in6 > > I've toyed with the same idea. I toyed with the idea too! > . . . > One of the major problems with this is that under 4.3 Reno > or later the sin6_len field can only 8 bits wide which limits the > sockaddr to 255 bytes. This is one of the reasons why we settled on the address array design in the API spec. In IPv6, the max number of elements of a source route is 23, so: 23 * 16 = 368 which is too big to fit into sa_len. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 15:55:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19782; Fri, 1 Mar 96 15:55:08 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19775; Fri, 1 Mar 96 15:54:52 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id PAA06240; Fri, 1 Mar 1996 15:52:22 -0800 (PST) Date: Fri, 1 Mar 1996 15:59:03 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1521) Re: Thoughts on DNS and API To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > getconninfo(): > > I think this needs to be in our spec now. POSIX will put it in if we > > don't. I think it wise our API spec be as close to what POSIX will do > > as possible. getconninfo() will be used by POSIX IMHO. > > I agree with this. When I compared the POSIX getaddrinfo() and getconninfo() > they were nearly identical, just different names for the same things. Why > not just pick up the POSIX.12 definition and include it in the IPv6 sockets > API? (I see Keith Sklower's I-D on getconninfo() has already expired.) Yes, given that the function in the API spec, hostname2addr(), has evolved to look alot like getaddrinfo(), and since Posix appears to be standardizing on the latter function, it might make sense for us to adopt getaddrinfo(). One issue is that we have designed a mechanism to return lifetime along with an address with hostname2addr(). I don't believe getaddrinfo() supports this. Would we have to add this feature, or could we drop it? If we do decide to "adopt" getaddrinfo, we could simply delete section 5.1 of the API spec, and replace it with some text referencing the Posix draft. How would others feel about this change? Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 16:16:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19824; Fri, 1 Mar 96 16:16:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19818; Fri, 1 Mar 96 16:16:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25980; Fri, 1 Mar 1996 16:15:13 -0800 Received: by mercury.Sun.COM (Sun.COM) id QAA04769; Fri, 1 Mar 1996 16:15:13 -0800 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id QAA11578 for ipng@sunroof.Eng.Sun.COM; Fri, 1 Mar 1996 16:12:58 -0800 (PST) Date: Fri, 1 Mar 1996 16:12:58 -0800 (PST) From: Keith Sklower Message-Id: <199603020012.QAA11578@vangogh.CS.Berkeley.EDU> To: ipng@sunroof.eng.sun.com Subject: (IPng 1522) re: "adopting" getaddrinfo() Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Gilligan wrote: Yes, given that the function in the API spec, hostname2addr(), has evolved to look alot like getaddrinfo(), and since Posix appears to be standardizing on the latter function, it might make sense for us to adopt getaddrinfo(). One issue is that we have designed a mechanism to return lifetime along with an address with hostname2addr(). I don't believe getaddrinfo() supports this. Would we have to add this feature, or could we drop it? If we do decide to "adopt" getaddrinfo, we could simply delete section 5.1 of the API spec, and replace it with some text referencing the Posix draft. How would others feel about this change? The rules of the POSIX game are such that if you add an additional structure element (like the lifetime of the translation) on a returned value (like the struct addrinfo) you are still deemed "in compliance" with the spec. The reason that the names are different between getconninfo and getaddrinfo was that getconninfo was written up first, and since I wrote it from scratch before submitting it to POSIX, I could be reasonably certain I wasn't violating any copyrights. I think that if you completely omit it from the IPv6 API, it makes it look like a second-class citizen whose use is discouraged. I certainly don't object to using exactly POSIX names, and would you encourage somebody to write up a section which describes as part of the IPv6 API without violating any IEEE copyrights. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 17:41:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19927; Fri, 1 Mar 96 17:41:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19921; Fri, 1 Mar 96 17:41:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10302; Fri, 1 Mar 1996 17:39:43 -0800 Received: by mercury.Sun.COM (Sun.COM) id RAA21486; Fri, 1 Mar 1996 17:39:42 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA13632; Fri, 1 Mar 1996 17:39:32 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Mar 1996 17:42:15 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1523) Updated IPng Web Pages Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng web pages have been updated. The URL is: http://playground.sun.com/ipng Changes include current RFC's and Internet Drafts, new implementations, and recent presentations on IPv6. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 17:56:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19958; Fri, 1 Mar 96 17:56:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19951; Fri, 1 Mar 96 17:56:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11858; Fri, 1 Mar 1996 17:54:56 -0800 Received: by mercury.Sun.COM (Sun.COM) id RAA23572; Fri, 1 Mar 1996 17:54:55 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G105) id AA09426; Fri, 1 Mar 96 18:54:53 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA15226; Fri, 1 Mar 96 18:54:52 MST; for ipng@sunroof.eng.sun.com Message-Id: <9603020154.AA15226@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Fri, 1 Mar 1996 18:54:52 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bob Gilligan Subject: (IPng 1524) Re: Thoughts on DNS and API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Mar 1, 3:59pm you write:] > > If we do decide to "adopt" getaddrinfo, we could simply delete section > 5.1 of the API spec, and replace it with some text referencing the > Posix draft. How would others feel about this change? One thing in Keith's draft that POSIX does not have is the getinfobysockaddr() function. I think that should be in the IPv6 spec also, since it looks like a handy function for logging purposes. I also agree with Keith that I'd prefer to include it rather than omit it and just reference the POSIX spec. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 18:38:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19992; Fri, 1 Mar 96 18:38:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19983; Fri, 1 Mar 96 18:37:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16363; Fri, 1 Mar 1996 18:36:30 -0800 Received: by mercury.Sun.COM (Sun.COM) id SAA29245; Fri, 1 Mar 1996 18:36:28 -0800 From: conta@zk3.dec.com Received: from galpha.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05525; Fri, 1 Mar 1996 21:30:13 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA22542; Fri, 1 Mar 1996 21:30:11 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA17000; Fri, 1 Mar 1996 21:32:27 -0500 Message-Id: <9603020232.AA17000@brigit.zk3.dec.com> To: rstevens@noao.edu Cc: ipng@sunroof.eng.sun.com, conta@zk3.dec.com Subject: (IPng 1525) Re: Thoughts on DNS and API Date: Fri, 01 Mar 96 21:32:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: Message of: "Thu, 29 Feb 96 18:48:16 MST." Message-Id: <9603010148.AA04124@gemini.tuc.noao.edu> Subject: (IPng 1512) Re: Thoughts on DNS and API Received From: Richard Stevens Sent To: John Gardiner Myers , ipng@sunroof.eng.sun.com -------- Delivery-Date: Thu, 29 Feb 96 21:31:10 -0500 X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) Precedence: bulk > On the other hand, I get uncomfortable with the idea of specifying > addressing information with setsockopt(). You're not specifying "addressing information" with a socket option, you're specifying how to interpret the array of addresses that can be passed to other functions. Just like SO_REUSEADDR tells bind() what to do with an IP address; just like fcntl() tells read() and write() whether to block or not; just like SO_BROADCAST tells sendto() whether to accept a broadcast address or not; just like SO_LINGER tells close() what to do if there is still data queued to be sent; just like SO_SNDTIMEO tells write() how long to block; ... This is very valid. I just don't follow this reasoning that control information is the "approved" way to do this with sockets and that an array of addresses somehow violates the sockets API. The only thing control information is used for today with TCP/IP is to return the destination address of a UDP datagram (and even that is broken; it doesn't work for broadcast or multicast datagrams, which is when you really want the information). In the posting of the code from 4.4BSD the other day, notice that two of the three uses have never been implemented. Control information is also used for passing descriptors across a Unix domain socket, and for lots of things that I've never looked at in the OSI code. (Hopefully we won't use the OSI code as the model.) I think the array of addresses is a handy, simple way of doing what the draft API proposes. All the functions that can return an array already have a value-result argument that returns the size of the array. Rich Stevens As a pure personal opinion, I also prefer the way in which the current API proposes to pass IPv6 socket ddress arrays. In my view it is a nice extension of the IPv4 API. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 1 18:51:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20007; Fri, 1 Mar 96 18:51:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20001; Fri, 1 Mar 96 18:51:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17702; Fri, 1 Mar 1996 18:50:12 -0800 Received: by mercury.Sun.COM (Sun.COM) id SAA01107; Fri, 1 Mar 1996 18:50:11 -0800 From: conta@zk3.dec.com Received: from galpha.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA06025; Fri, 1 Mar 1996 21:48:50 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA23378; Fri, 1 Mar 1996 21:48:47 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA17059; Fri, 1 Mar 1996 21:50:32 -0500 Message-Id: <9603020250.AA17059@brigit.zk3.dec.com> To: Bob Gilligan Cc: Matt Thomas , ipng@sunroof.eng.sun.com, conta@zk3.dec.com Subject: (IPng 1526) Re: Thoughts on DNS and API Date: Fri, 01 Mar 96 21:50:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: Message of: "Fri, 01 Mar 96 12:43:48 PST." Message-Id: Subject: (IPng 1520) Re: Thoughts on DNS and API Received From: Bob Gilligan Sent To: Matt Thomas cc: ipng@sunroof.eng.sun.com -------- Delivery-Date: Fri, 01 Mar 96 16:15:17 -0500 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > It has occured to me that a cleaner way of passing the source route > > and interface information would be to include it in the > > struct sockaddr_in6 > > I've toyed with the same idea. I toyed with the idea too! > . . . > One of the major problems with this is that under 4.3 Reno > or later the sin6_len field can only 8 bits wide which limits the > sockaddr to 255 bytes. This is one of the reasons why we settled on the address array design in the API spec. In IPv6, the max number of elements of a source route is 23, so: 23 * 16 = 368 which is too big to fit into sa_len. Bob. I consider Matt's idea as a nice try. But the IPv6 socket structure as defined by the current API specs scales elegantly, in fact I could say prefectly, upward to an array of addresses, theoretically of any number of elements, while the array scales elegantly, could say again perfectly, downward to one address. Furthermore, the mechanism of specifying the array, also scales well, from one element to many. This is really hard to match. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 5 13:44:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22071; Tue, 5 Mar 96 13:44:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22065; Tue, 5 Mar 96 13:44:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02154; Tue, 5 Mar 1996 13:43:02 -0800 Received: by mercury.Sun.COM (Sun.COM) id NAA16324; Tue, 5 Mar 1996 13:42:58 -0800 Received: from [130.128.2.93] (laptop93.ietf.interop.net [130.128.2.93]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id OAA09197; Tue, 5 Mar 1996 14:01:17 -0800 X-Sender: hinden@tester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Mar 1996 13:44:27 -0800 To: mankin@isi.edu, sob@harvard.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1527) Request to Advance "IPv6 over Token Ring" Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : A Method for the Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas Filename : draft-ietf-ipngwg-token-ring-01.txt Pages : 7 Date : 01/24/1996 The working group last call on this document ended on February 22. In addition the working group was polled at the first IPng w.g. session at the Los Angeles IETF and the working group agreed to move this document forward to Proposed Standard. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 6 12:07:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22575; Wed, 6 Mar 96 12:07:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22569; Wed, 6 Mar 96 12:07:15 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB00784; Wed, 6 Mar 1996 12:05:38 -0800 Received: by venus.Sun.COM (Sun.COM) id MAA04986; Wed, 6 Mar 1996 12:05:31 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.12/8.6.11) with ESMTP id PAA24816; Wed, 6 Mar 1996 15:04:13 -0500 Message-Id: <199603062004.PAA24816@thumper.bellcore.com> To: ip-atm@nexen.com Cc: ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1528) 3rd idea, draft, transient neighbours. Date: Wed, 06 Mar 1996 15:03:45 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few days ago it occurred to me that there may be a useful synthesis of the models that Peter Schulter and Ran Atkinson are promoting. Unfortunately since it occurred to me on the plane to LA I haven't had the time to write up a proper draft. Nevertheless, here's a first pass at describing my idea. I'll be presenting it at the joint ipng/ipatm meeting tomorrow afternoon, after Peter and Ran have presented theirs. I'm figuring that, although sketchy, emailing this now allows interested parties a period of time (albeit short) to digest before the meeting itself. Title: Flow Driven Neighbourliness. Abstract: The problem of Neighbour Discovery ('ND') over NBMA networks can be broken into two parts - distributing ND messages among querying hosts, and making neighbours of enpoints who may be logically a number of IP hops away (aka 'cut through' in the IPv4 world). This proposal suggests that within the a logical Link, IPv6 hosts utilize the Neighbour Discovery protocol exactly as defined for use of existing link technologies such as Ethernet. Distribution of ND messages at the ATM level is achieved through a dedicated multicast server, transparent to ND. When an IPv6 host on the logical Link transmits packets to a destination not currently believed to be on-link, the packets are sent to the appropriate router for traditional hop-by-hop forwarding. When the router discovers this active flow of traffic, it issues an NHRP request towards the IPv6 destination (while continuing to forward the data packets towards this destination). When the NHRP reply arrives, the router constructs an unsolicited ND Advertisement identifying the IP and NBMA addresses of the destination node, and transmits this on the source's logical Link. This causes the source to now consider the destination to be a neighbour, and so it constructs a direct VC and begins forwarding packets directly. The IPv6 destination has, in effect, been declared a transient neighbour. Provided there are no insurmountable flaws in this plan, its merits are that the host side architecture for ND ends up being media independent, but we still utilize NHRP within the core of the network to locate and create transient neighbourliness. 1. Intra-Link ND. In [Schulter] intra-link ND is solved by dedicating what is essentially a multicast server within each logical Link for the distribution of ND messages (although he terms it a Neighbour Discovery Server, NDS). A key benefit of this approach is that the IP/ATM device driver emulates the intra-link message distribution service that ND currently expects over media such as Ethernet. As a consequence ND runs 'as normal' over ATM. This general idea deserves to be applied for the intra-Link case. It can be implemented within the IP/ATM device drivers of hosts trivially. Since multicasting will be a required feature of IPv6, at least in the first instance we can assume that IPv6/ATM device drivers will implement a MARS client. MARS supports the use of MCSs (which may be co-resident within routers, but this is irrelevant to the logical intra-Link structure). Ensure that the IPv6 all-nodes multicast group is supported by an MCS, and then in the IP/ATM driver (as described in [Schulter]) map all traffic to the all-nodes, all-routers, and solicited-node multicast groups onto the MCS/sharedtree built for the all-nodes multicast group. The idea of using a multicast server model to distribute ND messages in an ATM environment is not new, and is explicitly noted in section 2.2 of the current (and earlier) Neighbour Discovery I-D (under 'multicast' capable link layers). 2. Inter-Link (aka 'cut through') NHRP is ideally suited to discovering the (IP,NBMA) mappings of endpoints outside the scope of one's local logical Link (or LIS, in the IPv4 case). It is valuable to build on this emerging technology, as noted in [Atkinson]. In the Abstract I used the term 'transient neighbour', which is the real core to this solution. When a router notices that a flow of IPv6 traffic is originating on one of the logical Links it is attached to, the router may decide to utilize NHRP to discover if the IPv6 destination could be considered a neighbour. If the discovery process (using NHRP) is successful, the identity of this transient neighbour is advertised on the source's logical Link using conventional ND mechanisms. Whether this should be a faked Neighbour Advertisement (unsolicited), or a Redirect from the router (which p.26 of the ND spec suggests might be used by routers to tell someone that the "destination is in fact a neighbour"), is not quite clear to me. How a router notices a traffic flow is an open question (e.g. watching packet flow, using hints from RSVP PATH and RESV messages flowing back and forth, etc). 3. But what happens at the far end logical Link? When your local router uses NHRP the NHRP Request propagates to the closest NHS to the actual destination. This NHS resides in a router, which is likely to be the mirror image of the router originating the request. As such, this NHS/router can use ND Solicitation on the destination's Link to ascertain its IP/NBMA mapping, and turn this into an NHRP Reply. A fundamental consequence of this approach is that the routers on the edges of logical Links actually hide some of NHRP from hosts. Only NHS-NHS is required for discovery, hosts dont register with their local NHS. Since the resolution of an NHRP Request is actually achieved using ND at the remote Link, the destination IPv6 node has the choice on what NBMA address to return (for load sharing reasons). 4. Conclusion. This is very drafty. There are a number of holes. Its a compromise between the existing two proposals. I'd like to know how we can make this work (barring insurmountable major flaws). gja ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 6 17:03:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22750; Wed, 6 Mar 96 17:03:27 PST Received: from snail.Sun.COM by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22744; Wed, 6 Mar 96 17:03:09 PST Received: from mercury.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA28213; Wed, 6 Mar 96 17:01:35 PST Received: by mercury.Sun.COM (Sun.COM) id RAA24427; Wed, 6 Mar 1996 17:01:23 -0800 Received: by lillen.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00722; Wed, 6 Mar 1996 14:46:56 -0800 Date: Wed, 6 Mar 1996 14:46:56 -0800 From: nordmark@lillen (Erik Nordmark) Message-Id: <199603062246.OAA00722@lillen.eng.sun.com> To: conta@zk3.dec.com Subject: (IPng 1529) Comments on draft-ietf-ipngwg-ipv6-tunnel-01.spec Cc: ipng@sunroof Reply-To: nordmark@eng Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm trying to parse section 3.4 but I;m having problems. Is it trying to say that there are no link-local address assigned to the tunnel "virtual link"? Section 7.1 could be clarified to specify why there are two cases (which is to ensure that the tunnel virtual link has an MTU of at least 576 bytes - the minimal IPv6 MTU). I think there is a case missing in 7.1. If the original packet is larger than 576 bytes but the resulting tunnel MTU is less than 576 bytes the ICMPv6 Packet too big message should contain 576 as the MTU. The algorithm as specified might end up returning ICMP packet too big messages with an MTU smaller than 576. Section 7.2 case a: This case should apply independent of the size of the original packet. Thus this case applies any time the DF bit is set. Section 7.2 case b: I think this case needs to apply when the DF bit is not and be independent of the original packet size. With these changes in section 7.2 the rules for IPv4 original datagrams become: If the source is doing PMTU discovery (i.e. setting the DF bit) report the MTU back to the source. Otherwise, the tunnel entrypoint needs to fragment. This assumes that the MTU reported back to the source does not drop below the minimum for IPv4 (68 bytes). This is hopefully a only a theoretical problem since the IPv6 tunnel with have at least a 576 byte MTU so it is only in the case that the tunnel entrypoint adds more than 576-68=508 bytes of IPv6 headers. The text in section 8.2 has the same issue as the text in section 7.1. The text that reads: "... an ICMP packet too big message is sent to the original packet source node only if the original packet size is larger than 576 bytes" have the addition: "In the ICMP packet too big message report the maximum of (tunnel MTU - size of tunnel headers) and 576 bytes. Finally, the last 3 paragraphs in section 8.3 seem to use IPv6 when they mean IPv4. Also, as I mentioned above for section 7.2 I think the rules need to be fixed. In the last paragraph I actually think you want fragment IPv4 before encapsulating. When fragmenting after encapsulting you force the tunnel exitpoint to reassemble and, since tunnel exit points might be routers, I think it makes sense to minimize the dependency on reassembly at the tunnel exit point. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 6 20:12:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22880; Wed, 6 Mar 96 20:12:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22874; Wed, 6 Mar 96 20:11:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11342; Wed, 6 Mar 1996 20:10:00 -0800 Received: by mercury.Sun.COM (Sun.COM) id UAA14751; Wed, 6 Mar 1996 20:10:01 -0800 Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA22167; Wed, 6 Mar 1996 23:01:41 -0500 Received: from dogfish.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05968; Wed, 6 Mar 1996 23:01:39 -0500 From: Peter Schulter USEG Received: by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA28326; Wed, 6 Mar 1996 23:01:38 -0500 Date: Wed, 6 Mar 1996 23:01:38 -0500 Message-Id: <9603070401.AA28326@dogfish.zk3.dec.com> To: gja@bellcore.com, ip-atm@nexen.com Subject: (IPng 1530) Re: 3rd idea, draft, transient neighbours. Cc: gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville, This souonds like we may be converging on some ideas. While I will be presenting my ideas on how to do cut-through using ND, I have also been exploring other mechanisms. One of these (which I will mention in a slide tomorrow) is quite similar to what you suggest (and I had some general language in by I-d along these lines). That is, to resolve off-link addresses using NHRP /routers which could either redirect or provide an unsolicited NA. The far end NHS would have to NS the endpoint. I've worked up all the cases for this, maybe we can discuss them. Another thing that occurred to me today at the joint Intsrv ATM BOF was using RSVP (based on Dilip's presentation). That is, I can see certain advantages of using RSVP to do cut-through for the QoS cases, since this works (presumably) for both unicast and multicast cases. Having a single method to signal both QoS on all links, and which can provide some cut-through capabilities on ATM/NBMA seems a good thing to me. This could also solve the (as yet undiscussed) problem of how applications signal if they want cut-through or not. The RSVP protocol seems to be a very good and consistent way to handle this so applications can signal their requirements in a media independent way. The default case for best effort could always be packet forwarding. Just a thought that I'm tossing out to everyone. Depending on the results of the BOF tomorrow I may re-organize by draft and address some of these issues too. I also have some ideas on multicast using the NDS tree which I'm looking at for the next draft too. See you at the BOF. I look forward to hearing more about your ideas. --- pete ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 6 22:07:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22929; Wed, 6 Mar 96 22:07:01 PST Received: from snail.Sun.COM by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22923; Wed, 6 Mar 96 22:06:37 PST Received: from mercury.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA15596; Wed, 6 Mar 96 22:05:03 PST Received: by mercury.Sun.COM (Sun.COM) id WAA29931; Wed, 6 Mar 1996 22:05:02 -0800 Received: by lillen.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA00634; Wed, 6 Mar 1996 17:41:31 -0800 Date: Wed, 6 Mar 1996 17:41:31 -0800 From: nordmark@lillen (Erik Nordmark) Message-Id: <199603070141.RAA00634@lillen.eng.sun.com> To: gja@bellcore.com Subject: (IPng 1531) Re: 3rd idea, draft, transient neighbours. Cc: ip-atm@nexen.com, ipng@sunroof Reply-To: nordmark@eng Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Instead of using an unsolicited proxy Neighbor Advertisement why not just use a Redirect. Note that the ND Redirect - allows you to specify the link-layer address of the target - the target can be either a router or the final destination (the latter case is when the destination is directly reachable at the link-layer) The disadvantage of using the proxy solution is that the host might not be aware that it is using a router. Thus if the router is reconfigured to be a host instead of a router the host will not be able to tell that its packets are dropped on the floor. With redirect the host knows whether or not the first hop is a router and it will inspect the 'R' flag in the Neighbor Advertisements to verify that the router hasn't been reconfigured to be a host. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 7 16:27:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23788; Thu, 7 Mar 96 16:27:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23782; Thu, 7 Mar 96 16:26:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16775; Thu, 7 Mar 1996 16:24:49 -0800 Received: from mailrelay.ipsilon.com ([205.226.0.201]) by Sun.COM (sun-barr.Sun.COM) id AA23132; Thu, 7 Mar 96 09:20:24 PST Received: from [130.128.2.93] (laptop93.ietf.interop.net [130.128.2.93]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id JAA18680; Thu, 7 Mar 1996 09:38:39 -0800 X-Sender: hinden@tester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Mar 1996 09:21:44 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1532) WG last call: Path MTU Discovery for IP version 6 Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an ipng working group last call for comments on advancing the following document to Proposed Standard: Title : Path MTU Discovery for IP version 6 Author(s) : J. McCann, S. Deering Filename : draft-ietf-ipngwg-pmtuv6-01.txt Pages : 16 Date : 02/21/1996 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on Thursday March 21. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 11 07:14:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25953; Mon, 11 Mar 96 07:14:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25947; Mon, 11 Mar 96 07:14:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03249; Mon, 11 Mar 1996 07:12:36 -0800 Received: by mercury.Sun.COM (Sun.COM) id HAA23078; Mon, 11 Mar 1996 07:12:35 -0800 Received: from ms.BTNA.COM by server1.BTNA.COM with SMTP (1.38.193.4/16.2) id AA23659; Mon, 11 Mar 1996 10:12:33 -0500 Received: by reston.btna.com with Microsoft Mail id <31446CFA@reston.btna.com>; Mon, 11 Mar 96 10:12:10 PST From: "Silverman, Steve" To: bt-ietf-addr , bt-ipng , IPng Subject: (IPng 1533) Proposed v6 Addressing, open ended routing tables Date: Mon, 11 Mar 96 10:20:00 PST Message-Id: <31446CFA@reston.btna.com> Encoding: 71 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At last weeks meeting in Los Angeles, the proposed Ipv6 unicast addressing format was presented. The format involves: 3 bit format identifier (010) Provider based Unicast 5 bit Registry ID N bit Service Provider ID The length of this field is set by the registry organization 56-N bit Subscribing Organization 64 bit Internal Subscriber ID The problem with this is that every SPID becomes an entry in all of the backbone routers in the world. If one registry sets a 4 byte SPID field (N=32), and assigns a number to every village of 100 people, we could have a few million entries in a hurry. The key problem today with IPv4 is that every network (with the recent exception of CIDRized nets) requires an entry in the Router Tables. While there are fewer SPs than networks, it still does not make sense to me to repeat the error of inserting an open ended field into the header that has an impact on every backbone router. Another related issue is that the last 5 bits of the first byte of the address must now be extracted as part of the routing decision. This might slow down the routers. I would like to hear from router vendors on this subject. PROPOSAL I think the second byte of the address should be a top level routing code which allows each router to make an immediate routing decision if that value is not the routers own "routing region". Instead of 60 k table entries and doubling every year, this would be a 256 entry table that would not grow. This would avoid a repeat of our current routing table problem. The derivation of this field is secondary. I think that the most important this is limiting the routing table. There are two obvious methods of defining this table. Top Level Service Provider -- This would mean a set of no more than 250 SPs would be designated as Top Level SPs and all other SPs would get their longhaul traffic through the TL SPs. The TLSPs would have to be chosen so as to cover the entire globe. Some values would be reserved for areas that are not served in the original definition. Area -- The world would be divided into 250 areas (I assume a few values should be reserved for escape values). All of the SPs in an area wanting to be a TLSP would agree to route traffic to the other TLSPs in that area. Secondary SPs would get their address space from the TLSPs. An SP located in several areas could get an ID in each area it operates it. The Unicast Addressing Format lists a number of different types of addresses, geographical, SP based, etc. However, does anyone really want to support many different formats simultaneously? As the current v6 transition is planned, v6 will not help the Routing Table Problem in the near future. For many years, v6 machines will be dual-stack v4 machines and v6 addresses will be v4 compatible. This means that the routing tables will not shrink but rather will increase sharply to handle all of the old v4 network space plus the new v6 addressing space. I believe that we need a solution that will not kill the backbone. I think the proposal outlined above, particularly the use of "area codes" would be the most practical approach to the situation but I am open to other methods that will not create an open ended routing table. As a former switch architect, I would like to see a design that is reasonably implementable. The opinions expressed above are my own, not my employer's. :-) Steve Silverman ssilverman@reston.btna.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 11 08:07:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25999; Mon, 11 Mar 96 08:07:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25993; Mon, 11 Mar 96 08:06:53 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07976; Mon, 11 Mar 1996 08:05:06 -0800 Received: by venus.Sun.COM (Sun.COM) id IAA24911; Mon, 11 Mar 1996 08:05:04 -0800 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1534) Re: Proposed v6 Addressing, open ended routing tables To: ssilverman@reston.btna.com (Silverman Steve) Date: Mon, 11 Mar 1996 15:50:28 +0000 (GMT) Cc: bt-ietf-addr@msn.bt.co.uk, bt-ipng@ntserver2.BTNA.COM, ipng@sunroof.eng.sun.com In-Reply-To: <31446CFA@reston.btna.com> from "Silverman, Steve" at Mar 11, 96 10:20:00 am Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 3 bit format identifier (010) Provider based Unicast > 5 bit Registry ID > N bit Service Provider ID The length of this field is set > by the registry organization This is very very bad. > PROPOSAL > I think the second byte of the address should be a top level routing code > which allows each router to make an immediate routing decision if that value > is not the routers own "routing region". Instead of 60 k table entries and > doubling every year, this would be a 256 entry table that would not grow. > This would avoid a repeat of our current routing table problem. I think we should look very hard at making the routing code the TOP of the address. Its better to think in terms of "over there, sprint" than "sprint, over there" Firstly this means we can expand the service provider fields to be any length prefix we happen to need. Secondly we bound the top level tables for big routers [in theory anyway] and hopefully make parallelisation easier. The receiver can do if(destination==US) throw_at(US_ROUTER_MODULE) else throw_at(INTERNATIONAL_ROUTER_MODULE) [extrapolate to sensible example] so we can seriously think of big backbone meeting points having a CPU per major target area. Sure some routes are exceptions but the processors can send those back and the cost should be minimal compared with the gains. 250 areas , 250 CPU's ;) > Area -- The world would be divided into 250 areas (I assume a few > values should be reserved for escape values). All of the SPs in an area > wanting to be a TLSP would agree to route traffic to the other TLSPs in that > area. Secondary SPs would get their address space from the TLSPs. > An SP located in several areas could get an ID in each area it operates it. By allocating by area/routing properties we also eliminate issues relating to "Who gets one of the 64 registry numbers" - because if sprint are allowed to be a registry so am I - and there will be more than 64 registries once we get going - to start with there are well over 64 countries, and I can't see taiwan and china sharing a registry somehow. > is planned, v6 will not help the Routing Table Problem in the near future. > For many years, v6 machines will be dual-stack v4 machines and v6 addresses > will be v4 compatible. This means that the routing tables will not shrink Over time you simply start to route the v4 prefix addresses to a slower and slower (in relative terms) processor board. Or in the internet world let your v4 performance stand still - that will help make people switch. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 11 11:10:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26195; Mon, 11 Mar 96 11:10:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26186; Mon, 11 Mar 96 11:10:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09299; Mon, 11 Mar 1996 11:08:53 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA15074; Mon, 11 Mar 1996 11:08:41 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15760; 11 Mar 96 14:07 EST To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1535) Last Call: A Method for the Transmission of IPv6 Packets over Token Ring Networks to Proposed Standard Reply-To: iesg@IETF.CNRI.Reston.VA.US Date: Mon, 11 Mar 96 14:07:02 -0500 Message-Id: <9603111407.aa15760@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider "A Method for the Transmission of IPv6 Packets over Token Ring Networks" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by March 25, 1996. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 11 13:17:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26481; Mon, 11 Mar 96 13:17:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26475; Mon, 11 Mar 96 13:16:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02915; Mon, 11 Mar 1996 13:15:03 -0800 Received: by mercury.Sun.COM (Sun.COM) id NAA00071; Mon, 11 Mar 1996 13:15:01 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07077 Tue, 12 Mar 1996 08:12:53 +1100 (from kre@munnari.OZ.AU) To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: ssilverman@reston.btna.com (Silverman Steve), bt-ietf-addr@msn.bt.co.uk, bt-ipng@ntserver2.BTNA.COM, ipng@sunroof.eng.sun.com Subject: (IPng 1536) Re: Proposed v6 Addressing, open ended routing tables In-Reply-To: Your message of "Mon, 11 Mar 1996 15:50:28 -0000." Date: Tue, 12 Mar 1996 08:13:10 +1100 Message-Id: <24013.826578790@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 11 Mar 1996 15:50:28 +0000 (GMT) From: iialan@iifeak.swan.ac.uk (Alan Cox) Message-ID: I think we should look very hard at making the routing code the TOP of the address. Its better to think in terms of "over there, sprint" than "sprint, over there" That was the proposal. The thing that was proposed to be before the "over there" wasn't the provider, but the registry (and format identifier). Personally, I've never been able to figure out why we want to needlessly multiply the size of the routing tables by including info in the address (which is intended to be used by routing) for the sole purpose of indicating who allocated the address - which information is later useless for anything (if that is needed, stick it in the whois databases...) For sure, allocating addresses by multiple registries into the one number space is more difficult, but it certainly isn't impossible. One current proposal is to have multiple registries allocating names in the top level domains (the three letter ones anyway), I see this as being the same problem in a different sphere. If it was likely to actually be used in practice (globally) I'd oppose the format identifier too, but realistically, all global addresses we'll end up seeing will have the same upper bits, their only purpose will be to split off multicast/site-local/link-local/(etc) from the global addressing, and so can basically be ignored. The larger problem with this scheme is the requirement that you be able to simply dump packets on anyone in some region, and expect that someone to forward for you. That's what the ISP's call "free transit" and detest. With some kind of "region" identifier, you have in fact, basically reinvented geographic addressing (in some sense)_ - if it was this simple I'm sure we'd have had a draft out on it before this. That's why the provider field was (ignoring region and registry) basically at the head of the address - so you could always route directly to the destination provider (or super provider, or whatever) with no free transit involved. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 11 14:48:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26612; Mon, 11 Mar 96 14:48:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26606; Mon, 11 Mar 96 14:48:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19844; Mon, 11 Mar 1996 14:46:32 -0800 Received: by mercury.Sun.COM (Sun.COM) id OAA01237; Mon, 11 Mar 1996 14:46:28 -0800 Received: from ftp.com by ftp.com ; Mon, 11 Mar 1996 17:45:09 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 11 Mar 1996 17:45:09 -0500 Received: from kasten.d-cell.ftp.com by MAILSERV-D.FTP.COM (5.x/SMI-SVR4) id AA02967; Mon, 11 Mar 1996 17:44:03 -0500 Date: Mon, 11 Mar 1996 17:44:03 -0500 Message-Id: <9603112244.AA02967@MAILSERV-D.FTP.COM> To: ssilverman@reston.btna.com Subject: (IPng 1537) Re: Proposed v6 Addressing, open ended routing tables From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: bt-ietf-addr , bt-ipng , IPng Repository: mailserv-d.ftp.com, [message accepted at Mon Mar 11 17:44:00 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At last weeks meeting in Los Angeles, the proposed Ipv6 unicast addressing > format was presented. The format involves: > > 3 bit format identifier (010) Provider based Unicast > 5 bit Registry ID > N bit Service Provider ID The length of this field is set > by the registry organization > 56-N bit Subscribing Organization > 64 bit Internal Subscriber ID > > The problem with this is that every SPID becomes an entry in all of the > backbone routers in the world. If one registry sets a 4 byte SPID field > (N=32), and assigns a number to every village of 100 people, we could have a > few million entries in a hurry. Actually, a service provider is supposed to be just that, some entity which provides service. For example, one of the service providers in my part of the world is bbn-planet. They would get one service provider. They would use the 'subscribing organization' part of the address to further subdivide their subscribers up. They could just simply assign numbers as 'serial numbers' with no cognizance of the topological location of the subscriber. Or they could chop up the 'subscribing organization' bits to provide some sort of 'network-region' and then 'subscriber-within-that-region' division. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 11 16:23:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26747; Mon, 11 Mar 96 16:23:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26741; Mon, 11 Mar 96 16:23:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08187; Mon, 11 Mar 1996 16:21:58 -0800 Received: by mercury.Sun.COM (Sun.COM) id QAA04123; Mon, 11 Mar 1996 16:21:54 -0800 Received: by stb.info.com (Smail3.1.28.1 #4) id m0twHot-000ZBTC; Mon, 11 Mar 96 16:20 PST Message-Id: Date: Mon, 11 Mar 96 16:20 PST From: Michael Gersten To: bt-ietf-addr@msn.bt.co.uk, bt-ipng@ntserver2.BTNA.COM, ipng@sunroof.eng.sun.com, ssilverman@reston.btna.com Subject: (IPng 1538) Re: Proposed v6 Addressing, open ended routing tables Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One serious problem that I see with saying, "There are 250 privileged entities, and everyone else is second class", is that you have to tell when someone is no longer in first class. What happens if three years from now sprint is no longer one of the main routers? What would have happened if this had been done two years ago, and now ATT wants to get into the business? What happens when one of the now regional ISP's wants to go national? Any thing like this, that limits -- rather strictly -- the ability of the net to adapt, that restricts what the people who make up the net can do, gets a no vote from me. (However, I think that 2 bytes worth is a different story. But then, doesn't that make the routing tables too large?) Here's another idea: As long as the V6 address assignment is done in a way that renumbering is trivial and automatic, then the only thing that a backbone router needs to know is what outgoing interface(s) to use for a given prefix. If we say that N bits (be it 5 bits for the registry, or 8 or 16 bits for a TLISP number) are sufficent, then that is enough for a router to decide what outgoing port to use, and it is sufficient to reach a router for that (registry, ISP, etc). At that point, that entity knows how big the next field is, and has a complete table for routing that field. In other words, no one has, or needs, the complete table. The main routers for sprint know how to route to all the large groups that sprint routes to (meaning local ISP's that get serviced through sprint), those local ISP's know how to reach all their currently logged on customers, etc. As I'm not sure this is clear enough, let's try that again. 1. A top level, registry router, will have 31 entries for (registry ID, list of output interfaces to use) for each of the other 31 registries. They will also have an entry for each of the N-bits of ISP's that they serve. So, if one registry were to register 4 bytes of villiage ID's, then that registry would have to maintain routers that could deal with billions of possible addresses. The rest of the internet would only have one address for "how to reach one of their routers". 2. Something on the "backbone", such as a sprint router, would have 32 entries for all of the registries. It would also have details on everything at the sprint level -- all of the local ISP's that get served through sprint, all of the sprint internal routings, etc. But it has no details, nor does it care to care, about the details of the routings at MCI nor registry #21. 3. It's entirely possible that, given 56 bits to identify the combination of , that there's enough bits in there for a third level. That would be more than 16 bits for each. In other words, a given registry might have 16 bits set aside for identifying the next lower layer that it knows how to reach. That's only 64K entries, max, that it needs to have. Lets say that this is the village registry. It could decide to break the 56 bits that it has into 8 bits of country ID. (256 entries at the top, plus the other 31 registries, or a total of 289 total entries in the routing table.) Within each country, there would be an agency that decided how to break that down -- some smaller countries would have nothing but zero's in the remaining 48 bits. Others might use 16 bits of zero for padding, and the remaining 32 bits would be broken up into 6 bits of state id, and then at the state level would be routers that use the remaining 26 bits for whatever was wanted at that level. Now, this manages to keep the routing tables small. How well does it actually route packets? Lets say that I've got a node in california, and I'm two hops direct from a node in las vegas. I don't talk direct to that node. I send it to my higher up (the county level router), from there to the california level router, from there to the las vegas level router, from there to the reno router, and then to the casino, which then sends it to the slot machine. (just kidding). The fact that I have a neighbor node across town in las vegas is ignored as the destination is not a neighboring site. Hmm. Well, this idea keeps routing tables small, at the expense of greater traffic, especially at the registry level (if I'm in the fido registry, and someone else is in the telephone registry, then we'll talk by going all the way to the top). The only solution to that that I see is to have a mechanism to automatically build source route tunnels. Maybe when a TCP connection is opened, there might be some way to say, "This is going to be a heavy volume connection -- find a faster connection", followed by some way to query routers (which I can't see without major network flooding). So how does this compare with the "use 8 bits for 250 top level routers/areas"? Well, I'm looking at 32 top level registries, and from there, each of them has as many "areas" as they can handle. Other than that, about the only difference is that I'm explicitly not saying anything about how many sublayers of subrouters may be enountered before the destination. Michael p.s. An initial idea/proposal for those router questions. As the neighbor discovery/router advertisements will contain things like prefix bits, you can find out when a neighbor is in a different routing area than your main router. So, if someone were to send a "anyone have a better route to foo" message upstream past you, you could send it, not only upstream to your router, but also across that other connection. So, it would be something like, 1. A node with a non-local neighbor can tell it's router(s) this fact, 2. "is there a better way?" would go upstream to the routers, 3. When the router sees one of these with a prefix that seems to match part or all of one of the non local prefixes it was sent, then that router will construct a loose source route message that first goes to the site "nearby", then across the gateway, and then to the all routers address, asking if any of them have a faster way to X than through the top. This doesn't flood, it only goes where there are cross boundary connections, and then only if the neighbor is in the destination area. Comments? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 11 18:41:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26897; Mon, 11 Mar 96 18:41:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26891; Mon, 11 Mar 96 18:41:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02898; Mon, 11 Mar 1996 18:39:55 -0800 Received: by mercury.Sun.COM (Sun.COM) id SAA15846; Mon, 11 Mar 1996 18:39:54 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14936(14)>; Mon, 11 Mar 1996 18:39:48 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 11 Mar 1996 18:39:41 -0800 To: ipng@sunroof.eng.sun.com Cc: hinden@ipsilon.com, deering@parc.xerox.com Subject: (IPng 1539) order of addresses in IPv6 header Date: Mon, 11 Mar 1996 18:39:33 PST From: Steve Deering Message-Id: <96Mar11.183941pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Background: If you attended Wednesday's ipngwg meeting in LA, or if you listened to it over the MBone, you will know that we had a lively discussion about possibly swapping the order of the Source Address and Destination Address fields in the IPv6 header. Several folks argued that changing the address order would allow for faster software forwarding of IPv6 packets in particular implementations (e.g., for particular cache line sizes), and for those impementations where it didn't help, it also didn't hurt to change the order. The potential (but unproven) performance benefit had to be weighed against the less tangible costs of making such a fundamental change at this late state in the process, such as confusion in the implementor community, further delay in progressing the specs, and possible negative "PR" consequences. A poll of the meeting attendees showed no strong consensus one way or the other, but a modest majority were in favor of leaving the order as is. So in my role as chair of the meeting (and co-chair of the WG), I made a snap "ruling" to leave the address order as is. After doing so, I had serious second thoughts. I concluded that I had let non-technical concerns override my best technical judgement (given the information at hand, admittedly incomplete), and that that was inappropriate for the IETF. So at the end of the WG meeting, I said I wanted to change my "ruling" and swap the two address fields. Then things got really animated, and much more vigorous arguments were made for leaving the address order as is. Finally, I conducted another poll, and this time the number in favor and the number opposed to swapping the address were approximately equal (!), with many abstentions. In the face of this clear lack of consensus, the two co-chairs were delegated to make a decision and announce it to the mailing list. Decision by Deering and Hinden: *** The order of the addresses in the IPv6 header stays as is. *** *** That is, source address first, destination address second. *** Rationale: (1) Swapping the addresses would not be "harmless", performance-wise, in all circumstances, contrary to what I claimed in the meeting. As Tracy Mallory pointed out, for packets with non-zero flow labels, moving the source address after the destination address would force the router to look further into the header than would otherwise be necessary. Thus, on those architectures that benefit from not having to read the whole header, flow-based traffic would be penalized by a change of address order. (2) As Christian Huitema pointed out, necessary improvements in congestion handling for non-flow-based traffic, such as fair queueing or a statistical approximation of fair queueing, are likely to require examination of the full source address of every forwarded packet anyway, in which case moving the source address to the end buys nothing, and defeats the possible gain described in the next point... (3) Assuming adoption of the proposed unicast addressing plan in which the low-order 64-bits of an IPv6 unicast address are used only for intra-site purposes, all inter-site forwarding can be done without looking at the last 64 bits of the destination address. Thus if we leave the address order as-is, we can still exploit the benefit of not fetching the trailing 64 bits of the header for inter-site routing, where the highest throughputs are going to be needed. Note: Mike Carlton, who initiated the discussion of swapping the addresses in his presentation on cache effects on IPv6 header processing, agrees with this analysis and has withdrawn his request to change the address order. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 12 05:40:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27113; Tue, 12 Mar 96 05:40:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27107; Tue, 12 Mar 96 05:40:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16617; Tue, 12 Mar 1996 05:38:22 -0800 Received: by mercury.Sun.COM (Sun.COM) id FAA09978; Tue, 12 Mar 1996 05:38:21 -0800 Received: from ms.BTNA.COM by server1.BTNA.COM with SMTP (1.38.193.4/16.2) id AA26212; Tue, 12 Mar 1996 08:38:15 -0500 Received: by reston.btna.com with Microsoft Mail id <3145A85F@reston.btna.com>; Tue, 12 Mar 96 08:37:51 PST From: "Silverman, Steve" To: ipng , Michael Gersten Subject: (IPng 1540) Re: Proposed v6 Addressing, open ended routing tables Date: Tue, 12 Mar 96 08:47:00 PST Message-Id: <3145A85F@reston.btna.com> Encoding: 150 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I understand the proposal, registry is not a routing facility. Only the Service Providers are routing facilities. There is no geographic or topological significance to the registries, hence one can not route on the registry code. The registry value plus the SPID (5 + N bits) is the only value that could be used for the first level routing. (If I am wrong, please let us know.) If one registry sets N = 24 and then designates 200 k SPs, that is 200 k entries in all default free routers. ---------- From: Michael Gersten To: ssilverman; bt-ietf-addr; bt-ipng; ipng Subject: Re: (IPng 1533) Proposed v6 Addressing, open ended routing tables Date: Monday, March 11, 1996 4:20PM ---------------------------------------------------------------------------- -- One serious problem that I see with saying, "There are 250 privileged entities, and everyone else is second class", is that you have to tell when someone is no longer in first class. What happens if three years from now sprint is no longer one of the main routers? What would have happened if this had been done two years ago, and now ATT wants to get into the business? What happens when one of the now regional ISP's wants to go national? Any thing like this, that limits -- rather strictly -- the ability of the net to adapt, that restricts what the people who make up the net can do, gets a no vote from me. (However, I think that 2 bytes worth is a different story. But then, doesn't that make the routing tables too large?) Here's another idea: As long as the V6 address assignment is done in a way that renumbering is trivial and automatic, then the only thing that a backbone router needs to know is what outgoing interface(s) to use for a given prefix. If we say that N bits (be it 5 bits for the registry, or 8 or 16 bits for a TLISP number) are sufficent, then that is enough for a router to decide what outgoing port to use, and it is sufficient to reach a router for that (registry, ISP, etc). At that point, that entity knows how big the next field is, and has a complete table for routing that field. In other words, no one has, or needs, the complete table. The main routers for sprint know how to route to all the large groups that sprint routes to (meaning local ISP's that get serviced through sprint), those local ISP's know how to reach all their currently logged on customers, etc. As I'm not sure this is clear enough, let's try that again. 1. A top level, registry router, will have 31 entries for (registry ID, list of output interfaces to use) for each of the other 31 registries. They will also have an entry for each of the N-bits of ISP's that they serve. So, if one registry were to register 4 bytes of villiage ID's, then that registry would have to maintain routers that could deal with billions of possible addresses. The rest of the internet would only have one address for "how to reach one of their routers". 2. Something on the "backbone", such as a sprint router, would have 32 entries for all of the registries. It would also have details on everything at the sprint level -- all of the local ISP's that get served through sprint, all of the sprint internal routings, etc. But it has no details, nor does it care to care, about the details of the routings at MCI nor registry #21. 3. It's entirely possible that, given 56 bits to identify the combination of , that there's enough bits in there for a third level. That would be more than 16 bits for each. In other words, a given registry might have 16 bits set aside for identifying the next lower layer that it knows how to reach. That's only 64K entries, max, that it needs to have. Lets say that this is the village registry. It could decide to break the 56 bits that it has into 8 bits of country ID. (256 entries at the top, plus the other 31 registries, or a total of 289 total entries in the routing table.) Within each country, there would be an agency that decided how to break that down -- some smaller countries would have nothing but zero's in the remaining 48 bits. Others might use 16 bits of zero for padding, and the remaining 32 bits would be broken up into 6 bits of state id, and then at the state level would be routers that use the remaining 26 bits for whatever was wanted at that level. Now, this manages to keep the routing tables small. How well does it actually route packets? Lets say that I've got a node in california, and I'm two hops direct from a node in las vegas. I don't talk direct to that node. I send it to my higher up (the county level router), from there to the california level router, from there to the las vegas level router, from there to the reno router, and then to the casino, which then sends it to the slot machine. (just kidding). The fact that I have a neighbor node across town in las vegas is ignored as the destination is not a neighboring site. Hmm. Well, this idea keeps routing tables small, at the expense of greater traffic, especially at the registry level (if I'm in the fido registry, and someone else is in the telephone registry, then we'll talk by going all the way to the top). The only solution to that that I see is to have a mechanism to automatically build source route tunnels. Maybe when a TCP connection is opened, there might be some way to say, "This is going to be a heavy volume connection -- find a faster connection", followed by some way to query routers (which I can't see without major network flooding). So how does this compare with the "use 8 bits for 250 top level routers/areas"? Well, I'm looking at 32 top level registries, and from there, each of them has as many "areas" as they can handle. Other than that, about the only difference is that I'm explicitly not saying anything about how many sublayers of subrouters may be enountered before the destination. Michael p.s. An initial idea/proposal for those router questions. As the neighbor discovery/router advertisements will contain things like prefix bits, you can find out when a neighbor is in a different routing area than your main router. So, if someone were to send a "anyone have a better route to foo" message upstream past you, you could send it, not only upstream to your router, but also across that other connection. So, it would be something like, 1. A node with a non-local neighbor can tell it's router(s) this fact, 2. "is there a better way?" would go upstream to the routers, 3. When the router sees one of these with a prefix that seems to match part or all of one of the non local prefixes it was sent, then that router will construct a loose source route message that first goes to the site "nearby", then across the gateway, and then to the all routers address, asking if any of them have a faster way to X than through the top. This doesn't flood, it only goes where there are cross boundary connections, and then only if the neighbor is in the destination area. Comments? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 12 09:46:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27276; Tue, 12 Mar 96 09:46:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27055; Tue, 12 Mar 96 01:56:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06861; Tue, 12 Mar 1996 01:55:15 -0800 Received: by mercury.Sun.COM (Sun.COM) id BAA10279; Tue, 12 Mar 1996 01:55:09 -0800 Date: Tue, 12 Mar 1996 09:44:24 +0000 X400-Originator: A.B.HARRIS@NWH2HP.bt-plc.bt.btx400.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=BT-INTERNET/ADMD=BT/C=GB/;0000430001890516000002] X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: "Harris, Anthony (GSE)" Message-Id: <"00169A28.MAI*/I=AB/S=HARRIS/OU=NWH2HP/O=BT PLC/PRMD=BT/ADMD=BT/C=GB/"@MHS> To: "Silverman, Steve":;@mercury Cc: bt-ietf-addr , "P=BT-INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=bt-ietf-addr-request(" , bt-ipng , IPng Subject: (IPng 1541) RE: Proposed v6 Addressing, open ended routing tables Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Thanks for the report. I support your concerns, but how do you reconcile area routing addresses with BT's (and others') ambitions to be global SPs? Or with the existence of multinational concerns which will want a single, global addressing space which they can manage? I think these point to an SP-based solution, for better or worse. Regards Anthony ---------- From: P=BT-INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=bt-ietf-addr-request(a)msn.bt.co.uk To: bt-ietf-addr; bt-ipng; IPng; HARRIS, A.B. Subject: Proposed v6 Addressing, open ended routing tables Date: 11 March, 1996 21:37 DATE: Mar 11 10:20:00 1996 -08:00 relative to GMT IPMessageID: 31446CFA(a)reston.btna.com FROM: Silverman, Steve [P=BT-INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=ssilverman( a)reston.btna.com] TO: bt-ietf-addr [P=BT-INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=bt-ietf-addr(a)ms n.bt.co.uk] bt-ipng [P=BT-INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=bt-ipng(a)ntserver2.BT NA.COM] IPng [P=BT-INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=ipng(a)sunroof.Eng.Sun.CO M] SUBJECT: Proposed v6 Addressing, open ended routing tables IMPORTANCE: normal AUTO FORWARDED: FALSE PRIORITY: ---------------------------------------------------------------------------- -- At last weeks meeting in Los Angeles, the proposed Ipv6 unicast addressing format was presented. The format involves: 3 bit format identifier (010) Provider based Unicast 5 bit Registry ID N bit Service Provider ID The length of this field is set by the registry organization 56-N bit Subscribing Organization 64 bit Internal Subscriber ID The problem with this is that every SPID becomes an entry in all of the backbone routers in the world. If one registry sets a 4 byte SPID field (N=32), and assigns a number to every village of 100 people, we could have a few million entries in a hurry. The key problem today with IPv4 is that every network (with the recent exception of CIDRized nets) requires an entry in the Router Tables. While there are fewer SPs than networks, it still does not make sense to me to repeat the error of inserting an open ended field into the header that has an impact on every backbone router. Another related issue is that the last 5 bits of the first byte of the address must now be extracted as part of the routing decision. This might slow down the routers. I would like to hear from router vendors on this subject. PROPOSAL I think the second byte of the address should be a top level routing code which allows each router to make an immediate routing decision if that value is not the routers own "routing region". Instead of 60 k table entries and doubling every year, this would be a 256 entry table that would not grow. This would avoid a repeat of our current routing table problem. The derivation of this field is secondary. I think that the most important this is limiting the routing table. There are two obvious methods of defining this table. Top Level Service Provider -- This would mean a set of no more than 250 SPs would be designated as Top Level SPs and all other SPs would get their longhaul traffic through the TL SPs. The TLSPs would have to be chosen so as to cover the entire globe. Some values would be reserved for areas that are not served in the original definition. Area -- The world would be divided into 250 areas (I assume a few values should be reserved for escape values). All of the SPs in an area wanting to be a TLSP would agree to route traffic to the other TLSPs in that area. Secondary SPs would get their address space from the TLSPs. An SP located in several areas could get an ID in each area it operates it. The Unicast Addressing Format lists a number of different types of addresses, geographical, SP based, etc. However, does anyone really want to support many different formats simultaneously? As the current v6 transition is planned, v6 will not help the Routing Table Problem in the near future. For many years, v6 machines will be dual-stack v4 machines and v6 addresses will be v4 compatible. This means that the routing tables will not shrink but rather will increase sharply to handle all of the old v4 network space plus the new v6 addressing space. I believe that we need a solution that will not kill the backbone. I think the proposal outlined above, particularly the use of "area codes" would be the most practical approach to the situation but I am open to other methods that will not create an open ended routing table. As a former switch architect, I would like to see a design that is reasonably implementable. The opinions expressed above are my own, not my employer's. :-) Steve Silverman ssilverman@reston.btna.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 12 10:25:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27401; Tue, 12 Mar 96 10:25:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27395; Tue, 12 Mar 96 10:25:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01708; Tue, 12 Mar 1996 10:23:33 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA12818; Tue, 12 Mar 1996 10:23:16 -0800 Received: by stb.info.com (Smail3.1.28.1 #4) id m0twYim-000ZBTC; Tue, 12 Mar 96 10:22 PST Message-Id: Date: Tue, 12 Mar 96 10:22 PST From: Michael Gersten To: ipng@sunroof.eng.sun.com, michael@stb.info.com, ssilverman@reston.btna.com Subject: (IPng 1542) Re: Proposed v6 Addressing, open ended routing tables Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, then if the registry cannot be used as a routing facility, and the goal is to limit the number of top level entries, then why not restrict a registry to no more than the first 8 bits for the top level routing information? In other words, a village registry can still have N=24 and 200K ISP's. But only the top 8 bits worth would be top level routers. (Hmm, at this point, the idea is the same, the only question is the total number of top level bits -- 8, 13, or 16. I still think that 250 is too little, but I don't know what's enough.) Perhaps a better question: how many entries can the top level routers handle, today, without problem? Michael ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 12 10:57:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27445; Tue, 12 Mar 96 10:57:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27437; Tue, 12 Mar 96 10:57:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07481; Tue, 12 Mar 1996 10:55:19 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA01884; Tue, 12 Mar 1996 10:55:03 -0800 Received: from ms.BTNA.COM by server1.BTNA.COM with SMTP (1.38.193.4/16.2) id AA27166; Tue, 12 Mar 1996 13:54:46 -0500 Received: by reston.btna.com with Microsoft Mail id <3145F28E@reston.btna.com>; Tue, 12 Mar 96 13:54:22 PST From: "Silverman, Steve" To: IPng , Michael Gersten Subject: (IPng 1543) Re: Proposed v6 Addressing, open ended routing tables Date: Tue, 12 Mar 96 14:03:00 PST Message-Id: <3145F28E@reston.btna.com> Encoding: 41 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe that todays routers are handling about 50 - 60 k entries - 16 bits worth or N=11 for all registries. Do we want to split up bytes? There is also an issue of performance for the routers. The more bit twiddling, the slower the routers. But as I understand it, the v6 routing table must coexist with the IPv4 routing table. My impression is that there is not a lot of spare capacity. This is a major part of the motivation for IPv6. It was supposed to alleviate not exacerbate the problem. I'm sure someone on this list knows more accurate values for these numbers. Steve Silverman ---------- From: Michael Gersten To: ssilverman; ipng; michael Subject: Re: (IPng 1533) Proposed v6 Addressing, open ended routing tables Date: Tuesday, March 12, 1996 10:22AM ---------------------------------------------------------------------------- -- Well, then if the registry cannot be used as a routing facility, and the goal is to limit the number of top level entries, then why not restrict a registry to no more than the first 8 bits for the top level routing information? ... (Hmm, at this point, the idea is the same, the only question is the total number of top level bits -- 8, 13, or 16. I still think that 250 is too little, but I don't know what's enough.) Perhaps a better question: how many entries can the top level routers handle, today, without problem? Michael ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 13 03:01:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28404; Wed, 13 Mar 96 03:01:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28398; Wed, 13 Mar 96 03:01:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22199; Wed, 13 Mar 1996 02:59:54 -0800 Received: by mercury.Sun.COM (Sun.COM) id CAA03863; Wed, 13 Mar 1996 02:59:50 -0800 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1544) Re: Proposed v6 Addressing, open ended routing tables To: ssilverman@reston.btna.com (Silverman, Steve) Date: Wed, 13 Mar 1996 10:57:54 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com, michael@stb.info.com In-Reply-To: <3145A85F@reston.btna.com> from "Silverman, Steve" at Mar 12, 96 08:47:00 am Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I understand the proposal, registry is not a routing facility. Only > the Service Providers are routing facilities. There is no geographic or > topological significance to the registries, hence one can not route on the > registry code. The registry value plus the SPID (5 + N bits) is the only > value A registry is a service provider. It provides registry services, and to judge from internic its going to be a very cushy way to rake in money soon. So no way is 5bits of registry enough. Who will be the registry ? Want to explain to the courts why only some people can be registries - how would "Im sorry we only have numbers for 6 phone companies, you'll have to go print books or something" have gone down ??? Want to explain to countries that want goverment controlled registries for their country why there are less registries than countries ? Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 13 04:26:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28461; Wed, 13 Mar 96 04:26:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28455; Wed, 13 Mar 96 04:26:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26037; Wed, 13 Mar 1996 04:24:50 -0800 Received: by mercury.Sun.COM (Sun.COM) id EAA11770; Wed, 13 Mar 1996 04:24:37 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA27025; Wed, 13 Mar 1996 13:24:06 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA27368; Wed, 13 Mar 1996 13:23:54 +0100 Message-Id: <9603131223.AA27368@dxcoms.cern.ch> Subject: (IPng 1545) Re: Proposed v6 Addressing, open ended routing tables To: iialan@iifeak.swan.ac.uk (Alan Cox) Date: Wed, 13 Mar 1996 13:23:53 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ssilverman@reston.btna.com, ipng@sunroof.eng.sun.com, michael@stb.info.com In-Reply-To: from "Alan Cox" at Mar 13, 96 10:57:54 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 Try reading the draft, folks. It does address all your points, and has done so in the last 3 versions. Brian Carpenter > > > As I understand the proposal, registry is not a routing facility. Only > > the Service Providers are routing facilities. There is no geographic or > > topological significance to the registries, hence one can not route on the > > registry code. The registry value plus the SPID (5 + N bits) is the only > > value > > A registry is a service provider. It provides registry services, and to > judge from internic its going to be a very cushy way to rake in money soon. > So no way is 5bits of registry enough. > > Who will be the registry ? > > Want to explain to the courts why only some people can be registries > - how would "Im sorry we only have numbers for 6 phone companies, you'll have > to go print books or something" have gone down ??? > > Want to explain to countries that want goverment controlled registries for > their country why there are less registries than countries ? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 13 11:09:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28713; Wed, 13 Mar 96 11:09:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28707; Wed, 13 Mar 96 11:09:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16212; Wed, 13 Mar 1996 11:07:33 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA29813; Wed, 13 Mar 1996 11:07:26 -0800 Received: by stb.info.com (Smail3.1.28.1 #4) id m0twvtB-000ZBTC; Wed, 13 Mar 96 11:07 PST Message-Id: Date: Wed, 13 Mar 96 11:07 PST From: Michael Gersten To: ipng@sunroof.eng.sun.com, michael@stb.info.com, ssilverman@reston.btna.com Subject: (IPng 1546) Re: Proposed v6 Addressing, open ended routing tables Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If there's currently 60K routing table entries, then I'd propose a goal of v6 to only need about 30K routing table entries. Yes, router CPU speed will increase, but the load will increase more. At 30K, we're talking 15 bits, or an N of 10. I'd further propose the following: 1. 3 bits for registry based id, 5 bits for registry (one byte) 2. 8 bits for provider, two bits reserved for future expansion of provider. Below that, although provider dependend, we might see things like 3. 6 bits of reserved 4. 5 bytes (40 bits) for the provider, split up something like A: two bytes of internal routing info (to route around the internals of alternet, or sprintnet, or mcinet, or aolnet B: one byte reserved C: two bytes of secondary routing info (to route around the internals of rain, or well, or earthlink, or loop, or any of a few thousand regional providers) 5: and finally, 64 bits (8 bytes) of subscriber specific addressing, of which, 48 will be link specific, and 16 will be for it's own subnetworks. With this in mind, we're talking something around the following figures: 1. Initially, we have about 128 top level service providers (backbones, networks) per registry. (reserve one bit to indicate that all 10 are in use). Lets say we're looking at about 500 initially, that's four registries. These need to maintain routing tables for the existing v4 world, and the new v6 world as well. That's the existing 60K, plus another 500. That's not a big imposition from v6. 2. Eventually, as most of the world runs v6 stacks, these routing tables grow. I'm assuming that the v4 world won't get much bigger than it is now. This will work up around 70-80K top level routes, as more registries are assigned. Eventually, the routers need to look at all of the first 18 bits, not just 16. But as most of these have identical first three bits, it still only needs two bytes to store them (bit shifting). This takes more CPU power, but by then the CPU's are faster (maybe?). 3. Finally, ten years from now, as v4 starts to become obsolete, and v8 is being proposed, many sites give up their old v4 address, and stop using them. This starts to shrink the routing tables. 4. And, when v8 is being implemented, we'll only be looking at maintaining 30K or so top level routes, plus however many global multicasting routes exist (figure at least 500 for the TV channels :-) 5. Finally, some of the "local" isps want to expand, and go national. It starts by getting registered under two or three different network providers. It then passes two or three sets of routing info around inside it's routers -- so that packets from person A under network A, to person B under network B, get routed without going through the network layer. Eventually, it expands this to where there are more packets not going across the network layer than are going across the network layer. At this point, it applies to a registry for a direct number, and does a full renumbering. 6. One big assumption that I think I'm making is that renumbering is painless under v6. If renumbering requires redoing the entire DNS for all the hosts being affected, that's no longer true. (If it only requires changing one value to change the values for everything underneath, then it is true.) Michael ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 13 11:59:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28792; Wed, 13 Mar 96 11:59:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28786; Wed, 13 Mar 96 11:59:07 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24849; Wed, 13 Mar 1996 11:57:11 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA15559; Wed, 13 Mar 1996 11:57:00 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id VAA01424; Wed, 13 Mar 1996 21:51:16 +0200 Date: Wed, 13 Mar 1996 21:51:16 +0200 From: Juha Heinanen Message-Id: <199603131951.VAA01424@lohi.dat.tele.fi> To: michael@stb.info.com Cc: ipng@sunroof.eng.sun.com, michael@stb.info.com, ssilverman@reston.btna.com In-Reply-To: (michael@stb.info.com) Subject: (IPng 1547) Re: Proposed v6 Addressing, open ended routing tables Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk my opinion is that the latest provider based address format draft is fine. it should not try to be more specific than it is. it is up to the registries to decide their allcoation policies and up to the provides to decide how they structure their part of the address. -- juha ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 13 14:07:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29111; Wed, 13 Mar 96 14:07:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29105; Wed, 13 Mar 96 14:07:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17341; Wed, 13 Mar 1996 14:05:47 -0800 Received: by mercury.Sun.COM (Sun.COM) id OAA23353; Wed, 13 Mar 1996 14:05:44 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA04786; Wed, 13 Mar 1996 14:05:16 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Mar 1996 14:08:20 -0800 To: iialan@iifeak.swan.ac.uk (Alan Cox), ssilverman@reston.btna.com, michael@stb.info.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1548) Re: Proposed v6 Addressing, open ended routing tables Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:23 AM 3/13/96, Brian Carpenter CERN-CN wrote: >Try reading the draft, folks. It does address all your points, and >has done so in the last 3 versions. > Brian makes a very good point. I would also suggest that reading RFC-1884, IP Version 6 Addressing Architecture RFC-1887, An Architecture for IPv6 Unicast Addressing Allocation They define the framework which was designed to operate in. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 13 15:58:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29345; Wed, 13 Mar 96 15:58:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29339; Wed, 13 Mar 96 15:58:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09303; Wed, 13 Mar 1996 15:56:43 -0800 Received: by mercury.Sun.COM (Sun.COM) id PAA25516; Wed, 13 Mar 1996 15:56:42 -0800 Received: by stb.info.com (Smail3.1.28.1 #4) id m0tx0Ny-000ZBTC; Wed, 13 Mar 96 15:55 PST Message-Id: Date: Wed, 13 Mar 96 15:55 PST From: Michael Gersten To: hinden@Ipsilon.COM, iialan@iifeak.swan.ac.uk, michael@stb.info.com, ssilverman@reston.btna.com Subject: (IPng 1549) Re: Proposed v6 Addressing, open ended routing tables Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I had not seen 1887 before; thank you for pointing it out. Unfortunately, none of draft-ietf-ipngwg-unicast-addr-fmt-03.txt, 1884, nor 1887 make any attempt to address the issue of routing table size. (1887 points out some of the issues involved, but fails to recommend any specific sizes.) The problem that was pointed out was that a registry can make N=20, or some other large amount, and flood the routing tables. I'm arguing that a maximum N of 10 is fine, and that initially we can specify a maximum N of 8, with the provision that at a later time, the next two bits (which will initially be 0) may be used to give another 3X additional addresses. This keeps the routing tables from getting large (tops out around 30K entries, compared to the v4 size of 60K entries), and does not restrict any further subdivisions of the addressing space. It also does not prevent a registry from using a smaller N than that. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 13 23:05:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29600; Wed, 13 Mar 96 23:05:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29594; Wed, 13 Mar 96 23:04:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB28819; Wed, 13 Mar 1996 23:03:02 -0800 Received: by mercury.Sun.COM (Sun.COM) id XAA06293; Wed, 13 Mar 1996 23:02:59 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id IAA01935; Thu, 14 Mar 1996 08:52:04 +0200 Date: Thu, 14 Mar 1996 08:52:04 +0200 From: Juha Heinanen Message-Id: <199603140652.IAA01935@lohi.dat.tele.fi> To: michael@stb.info.com Cc: hinden@Ipsilon.COM, iialan@iifeak.swan.ac.uk, michael@stb.info.com, ssilverman@reston.btna.com, ipng@sunroof.eng.sun.com In-Reply-To: (michael@stb.info.com) Subject: (IPng 1550) Re: Proposed v6 Addressing, open ended routing tables Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The problem that was pointed out was that a registry can make N=20, or some other large amount, and flood the routing tables. i would think that in order to become a registry, one must have some know how of format implications on the size of routing tables. at least in europe, i would be willing to belive that ripe has such a know how. -- juha ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 14 08:34:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29907; Thu, 14 Mar 96 08:34:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29901; Thu, 14 Mar 96 08:33:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06436; Thu, 14 Mar 1996 08:32:13 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA25960; Thu, 14 Mar 1996 08:32:12 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA26615; Thu, 14 Mar 1996 08:30:31 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Mar 1996 08:33:40 -0800 To: Michael Gersten From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1551) Re: Proposed v6 Addressing, open ended routing tables Cc: hinden@Ipsilon.COM, iialan@iifeak.swan.ac.uk, michael@stb.info.com, ssilverman@reston.btna.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael, The intent (once the address formats document moves forward) is to write a separate informational document describing the issues and making suggestions on how a registry and provider should allocate the provider and subscriber space. I do not think we should mandate what a registry does at this time, but given reasonable guidelines the registries will do reasonable things. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 14 08:41:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29923; Thu, 14 Mar 96 08:41:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29917; Thu, 14 Mar 96 08:41:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07385; Thu, 14 Mar 1996 08:39:59 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA28220; Thu, 14 Mar 1996 08:39:55 -0800 Message-Id: <199603141639.IAA28220@mercury.Sun.COM> Date: 14 Mar 96 16:36:00 GMT From: "SPARKS::WEAVER" Subject: (IPng 1552) Outcome-of-Interoperability-tests? To: "ipng" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Where do I get Info. on the IPv6 Inter-Op testing ? Elfed Weaver weaver@hydra.dra.hmg.gb ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 14 09:16:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29977; Thu, 14 Mar 96 09:16:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29971; Thu, 14 Mar 96 09:16:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12972; Thu, 14 Mar 1996 09:14:16 -0800 Received: by mercury.Sun.COM (Sun.COM) id JAA09248; Thu, 14 Mar 1996 09:13:57 -0800 Received: by kro.amtp.cam.ac.uk (Smail-3.1.28.1 #6) id m0txGak-00024kC; Thu, 14 Mar 96 17:13 GMT Message-Id: X-Mailer: exmh version 1.5.1 12/2/94 To: "ipng" Cc: jp107@damtp.cam.ac.uk Subject: (IPng 1553) DHCPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Mar 1996 17:13:33 +0000 From: Jon Peatfield Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is anyone on this list looking at DHCPv6? I've just been reading the inernet drafts and would like to add a few suggestions before it makes it to rfc status. Has anyone got any DHCPv6 clients/servers yet? (I'm planning to implement at least the client side once I've got a v6 stack to play with). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 14 10:36:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00300; Thu, 14 Mar 96 10:36:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00294; Thu, 14 Mar 96 10:35:53 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27053; Thu, 14 Mar 1996 10:34:09 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA07196; Thu, 14 Mar 1996 10:34:08 -0800 Received: by reef.bucknell.edu (5.65/IDA-1.2.8) id AA07665; Thu, 14 Mar 1996 13:32:59 -0500 Date: Thu, 14 Mar 1996 13:32:59 -0500 From: Ralph Droms Message-Id: <9603141832.AA07665@reef.bucknell.edu> To: J.S.Peatfield@damtp.cam.ac.uk, ipng@sunroof.eng.sun.com Subject: (IPng 1554) Re: DHCPv6 Cc: jp107@damtp.cam.ac.uk Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Much of the DHCPv6 discussion is taking place on the dhcp-v6@bucknell.edu mailing list. Send subscription requests to listserv@bucknell.edu - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 14 18:46:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00700; Thu, 14 Mar 96 18:46:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00694; Thu, 14 Mar 96 18:46:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22157; Thu, 14 Mar 1996 18:44:49 -0800 Received: by mercury.Sun.COM (Sun.COM) id SAA27150; Thu, 14 Mar 1996 18:44:46 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20528; 14 Mar 96 11:58 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1555) I-D ACTION:draft-ietf-ipngwg-ethernet-ntwrks-02.txt Date: Thu, 14 Mar 96 11:58:36 -0500 Message-Id: <9603141158.aa20528@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised 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 : A Method for the Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-ethernet-ntwrks-02.txt Pages : 4 Date : 03/13/1996 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an Ethernet. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ethernet-ntwrks-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960314115118.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ethernet-ntwrks-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960314115118.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 15 06:22:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01022; Fri, 15 Mar 96 06:22:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01016; Fri, 15 Mar 96 06:22:10 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14374; Fri, 15 Mar 1996 06:20:20 -0800 Received: by mercury.Sun.COM (Sun.COM) id GAA12983; Fri, 15 Mar 1996 06:19:14 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA14133; Fri, 15 Mar 1996 09:08:19 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23988; Fri, 15 Mar 1996 09:08:16 -0500 Message-Id: <9603151408.AA23988@fwasted.zk3.dec.com> To: Jon Peatfield Cc: "ipng" , jp107@damtp.cam.ac.uk Subject: (IPng 1556) Re: DHCPv6 In-Reply-To: Your message of "Thu, 14 Mar 96 17:13:33 GMT." Date: Fri, 15 Mar 96 09:08:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jon, >Is anyone on this list looking at DHCPv6? I've just been reading the inernet >drafts and would like to add a few suggestions before it makes it to rfc >status. This is getting done on a different mail list. dhcp-v6@bucknell.edu You can send mail there or to me privately. To join send to above via "request" semantics to subscribe. We need to update the spec from L.A. IETF. The basic model did not get changed or protocol just bugs in the spec and some relay agent parts. >Has anyone got any DHCPv6 clients/servers yet? (I'm planning to implement at >least the client side once I've got a v6 stack to play with). Yes I am planning to implement before Montreal IETF June 24-29. The basic server/client model/architecture. Are you building the stack yourself or do you just need an IPv6 stack with the APIs exposed and IOCTLs? If so I may be able to assist with that if you have Digital UNIX running Alpha (or any IPv6 stack that supports the IPv6 API spec with Multicast and Stateless Addr Conf)? thanks /jim thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 15 08:49:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01148; Fri, 15 Mar 96 08:49:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01142; Fri, 15 Mar 96 08:49:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02564; Fri, 15 Mar 1996 08:46:48 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA18532; Fri, 15 Mar 1996 08:46:41 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19203; 15 Mar 96 10:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1557) I-D ACTION:draft-ietf-ipngwg-fddi-ntwrks-03.txt Date: Fri, 15 Mar 96 10:27:31 -0500 Message-Id: <9603151027.aa19203@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised 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 : A Method for the Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-fddi-ntwrks-03.txt Pages : 6 Date : 03/13/1996 This memo specifies the MTU frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an FDDI network. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-fddi-ntwrks-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960314171727.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-fddi-ntwrks-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960314171727.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 15 12:43:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01397; Fri, 15 Mar 96 12:43:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01391; Fri, 15 Mar 96 12:43:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08104; Fri, 15 Mar 1996 12:41:25 -0800 Received: by mercury.Sun.COM (Sun.COM) id MAA06832; Fri, 15 Mar 1996 12:40:14 -0800 Received: from fiu.edu (xlab1 [131.94.128.54]) by rottweiler.fiu.edu (8.7.4/8.7.3) with ESMTP id PAA16186 for ; Fri, 15 Mar 1996 15:40:16 -0500 (EST) Received: (from bparen01@localhost) by fiu.edu (8.7.4/8.7.1) id PAA23949; Fri, 15 Mar 1996 15:43:41 -0500 (EST) Date: Fri, 15 Mar 1996 15:43:40 -0500 (EST) From: bernard c parenteau X-Sender: bparen01@xlab1 To: ipng@sunroof.eng.sun.com Subject: (IPng 1558) RFC1883 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Regarding the priority field (section 7), I have a couple of comments/questions: -Why the distinction between "congestion-controlled" packets and "real-time" packets? Will they be handled differently? -Might it not work to just have, say 8, ordered priority levels without assigning or recommending them to particular applications (except the highest level for network messages)? This would allow higher priority messages to optionally be expedited, presumably for a price, while allowing the user to select the level that suits them. -The extra bit (resulting from 8 levels instead of 16) could be used to indicate initiator, which could be source or destination. (This may be necessary to indicate on whose account the message is expedited). This is obviously anticipating optional usage/priority pricing, which may or may not happen, but which is what the economics of congestible resources tells us should happen. This issue may have already been addressed by this working group, and if so, I apologize. Bernard Parenteau ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 15 14:09:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01462; Fri, 15 Mar 96 14:09:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01456; Fri, 15 Mar 96 14:09:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02457; Fri, 15 Mar 1996 14:07:42 -0800 Received: by mercury.Sun.COM (Sun.COM) id OAA00288; Fri, 15 Mar 1996 14:07:29 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AB20357; Fri, 15 Mar 1996 16:44:32 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA11799; Fri, 15 Mar 1996 16:44:00 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id VAA25779 for ; Fri, 15 Mar 1996 21:47:48 GMT Message-Id: <199603152147.VAA25779@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 1559) Strict source routes and "what is a neighbor?" X-Mailer: exmh version 1.5omega 10/6/94 Date: Fri, 15 Mar 1996 21:47:47 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Assume you receive a type 0 source route with the next hop being marked as a strict hop. That's means the next hop must be neighbor, right? What happens if that next-hop happens to be within a prefix from a routing advertisement which did not have a the on-link bit set (thereby forcing you to forward to a router if you don't already have a neighbor cache entry)? Does source route succeed/fail depending on whether you have a neighbor cache entry or not? Imagine you are on a NBMA network and you have a neighbor cache entry due to cut-through. The same issue applies? Is a strict source route be limited to neighbors in on-link prefixes or additionaly include entries in the neighbor cache?? Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 15 15:47:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01592; Fri, 15 Mar 96 15:47:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01586; Fri, 15 Mar 96 15:47:21 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23056; Fri, 15 Mar 1996 15:45:35 -0800 Received: by mercury.Sun.COM (Sun.COM) id PAA25836; Fri, 15 Mar 1996 15:45:35 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09709; Fri, 15 Mar 96 18:43:34 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA10375; Fri, 15 Mar 96 18:44:17 EST Date: Fri, 15 Mar 96 18:44:17 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9603152344.AA10375@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com, matt@lkg.dec.com Subject: (IPng 1560) Re: Strict source routes and "what is a neighbor?" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, My supposition is that the intend of strict source route is to prevent visiting nodes that are not listed in the routing header. Therefore, IMO, if you can directly forward to the next listed hop, it is all right to do so regardless of on-link prefixes. I agree that use of "neighbor" word in the related section of the rfc1883 is somewhat misleading given the adopted IPv6 terminology. Dimitry > From major@marvin Fri Mar 15 17:26:25 1996 > X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 1559) Strict source routes and "what is a neighbor?" > X-Mailer: exmh version 1.5omega 10/6/94 > Date: Fri, 15 Mar 1996 21:47:47 +0000 > From: Matt Thomas > Sender: owner-ipv6@marvin > Content-Length: 1278 > > > Assume you receive a type 0 source route with the next hop being marked > as a strict hop. That's means the next hop must be neighbor, right? > > What happens if that next-hop happens to be within a prefix from a routing > advertisement which did not have a the on-link bit set (thereby forcing > you to forward to a router if you don't already have a neighbor cache entry)? > Does source route succeed/fail depending on whether you have a neighbor cache > entry or not? > > Imagine you are on a NBMA network and you have a neighbor cache entry due to > cut-through. The same issue applies? > > Is a strict source route be limited to neighbors in on-link prefixes > or additionaly include entries in the neighbor cache?? > > > Matt Thomas Internet: matt@lkg.dec.com > IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ > Digital Equipment Corporation Disclaimer: This message reflects my > Littleton, MA own warped views, etc. > > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 18 07:25:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02551; Mon, 18 Mar 96 07:25:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02545; Mon, 18 Mar 96 07:25:28 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04572; Mon, 18 Mar 1996 07:23:40 -0800 Received: by venus.Sun.COM (Sun.COM) id HAA09253; Mon, 18 Mar 1996 07:23:40 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12179; 18 Mar 96 10:12 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@venus Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1561) I-D ACTION:draft-ietf-ipngwg-discovery-06.txt Date: Mon, 18 Mar 96 10:12:41 -0500 Message-Id: <9603181012.aa12179@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised 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 : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : T. Narten, E. Nordmark, W. Simpson Filename : draft-ietf-ipngwg-discovery-06.txt Pages : 84 Date : 03/15/1996 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-06.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960318095536.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960318095536.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Mar 18 08:16:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02581; Mon, 18 Mar 96 08:16:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02575; Mon, 18 Mar 96 08:16:31 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09334; Mon, 18 Mar 1996 08:14:43 -0800 Received: by venus.Sun.COM (Sun.COM) id IAA16401; Mon, 18 Mar 1996 08:14:43 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA31278; Mon, 18 Mar 1996 11:07:15 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22473; Mon, 18 Mar 1996 11:07:14 -0500 Message-Id: <9603181607.AA22473@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1562) New Discovery Spec ---06 version Date: Mon, 18 Mar 96 11:07:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tom/Erik, Can we get the diffs so we can see the updates you did for the IESG (my assumption). It will save our eyes and some time. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Mar 19 09:15:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03821; Tue, 19 Mar 96 09:15:57 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03815; Tue, 19 Mar 96 09:15:33 PST Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id JAA03427; Tue, 19 Mar 1996 09:12:36 -0800 (PST) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28249; Tue, 19 Mar 1996 09:13:35 -0800 Date: Tue, 19 Mar 1996 09:13:35 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199603191713.JAA28249@bobo.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 1563) Re: New Discovery Spec ---06 version Cc: ipng@sunroof.eng.sun.com Content-Type: multipart/mixed; boundary="=_AABqUgAAYBExTus+" Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=_AABqUgAAYBExTus+ Content-Type: text/plain; charset="us-ascii" (text) Content-Description: text Here are the diffs showing the clarifications to the ND spec made as part of the last call and the IESG review. These diffs are between draft-ietf-ipngwg-discovery-03.txt and draft-ietf-ipngwg-discovery-06.txt The output is "context diffs" as produced by the diff(1) program. A '!' indicates a changed line. A '+' an added line, and a '-' a deleted line. Erik --=_AABqUgAAYBExTus+ Content-Type: application/x-sun-default; charset="us-ascii" (default) Content-Description: diff.03-06 *** out-03.long Tue Mar 12 09:46:08 1996 --- out-06.long Wed Mar 13 11:49:55 1996 *************** *** 5,17 **** INTERNET-DRAFT Thomas Narten, IBM ! November 17, 1995 Erik Nordmark, Sun Microsystems W A Simpson, Daydreamer Neighbor Discovery for IP Version 6 (IPv6) ! Status of this Memo --- 5,17 ---- INTERNET-DRAFT Thomas Narten, IBM ! March 14, 1996 Erik Nordmark, Sun Microsystems W A Simpson, Daydreamer Neighbor Discovery for IP Version 6 (IPv6) ! Status of this Memo *************** *** 34,40 **** Distribution of this memo is unlimited. ! This Internet Draft expires May 17, 1996. --- 34,40 ---- Distribution of this memo is unlimited. ! This Internet Draft expires September 14, 1996. *************** *** 144,156 **** Appendix D.1: Reachability confirmations.................. 1 - APPENDIX E: CHANGES SINCE PREVIOUS VERSION................... 1 - 1. INTRODUCTION This specification defines the Neighbor Discovery (ND) protocol for --- 144,154 ---- *************** *** 164,179 **** layer addresses. When a router or the path to a router fails, a host actively searches for functioning alternates. ! This document is a revision of ! which was itself based on the protocol specified in the two documents: ! , and ! The authors would like to acknowledge the contributions the IPNGWG ! working group an, in particular, (in alphabetical order) Ran Atkinson, ! Jim Bound, Scott Bradner, Stephen Deering, Francis Dupont, Robert Elz, ! Robert Gilligan, Robert Hinden, Allison Mankin, Dan McDonald, Charles ! Perkins, Matt Thomas, and Susan Thomson. 2. TERMINOLOGY --- 162,184 ---- layer addresses. When a router or the path to a router fails, a host actively searches for functioning alternates. ! Unless specified otherwise (in a document that covers operating IP over ! a particular link type) this document applies to all link types. ! However, because ND uses link-layer multicast for some of its services, ! it is possible that on some link types (e.g., NBMA links) alternative ! protocols or mechanisms to implement those services will be specified ! (in the appropriate document covering the operation of IP over a ! particular link type). The services described in this document that are ! not directly dependent on multicast, such as Redirects, Next-hop ! determination, Neighbor Unreachability Detection, etc., are expected to ! be provided as specified in this document. The details of how one uses ! ND on NBMA links is an area for further study. The authors would like to acknowledge the contributions the IPNGWG ! working group and, in particular, (in alphabetical order) Ran Atkinson, ! Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, Francis Dupont, ! Robert Elz, Robert Gilligan, Robert Hinden, Allison Mankin, Dan ! McDonald, Charles Perkins, Matt Thomas, and Susan Thomson. 2. TERMINOLOGY *************** *** 226,231 **** --- 231,245 ---- according to the routing protocol's measure of distance). See [ADDR-ARCH]. + Note that an anycast address is syntactically + indistinguishable from a unicast address. Thus, nodes + sending packets to anycast addresses don't generally + know that an anycast address is being used. Throughout + the rest of this document, references to unicast + addresses also apply to anycast addresses in those + cases where the node is unaware that a unicast address + is actually an anycast address. + prefix - a bit string that consists of some number of initial bits of an address. *************** *** 252,257 **** --- 266,279 ---- off-link - the opposite of "on-link"; an address that is not assigned to any interfaces on the specified link. + longest prefix match + - The process of determining which prefix (if any) in a + set of prefixes covers a target address. A target + address is covered by a prefix if all of the bits in + the prefix match the left-most bits of the target + address. When multiple prefixes cover an address, the + longest prefix is the one that matches. + reachability - whether or not the one-way "forward" path to a neighbor is functioning properly. In particular, whether *************** *** 335,350 **** Different link layers have different properties. The ones of concern to Neighbor Discovery are: ! multicast - a link that supports some mechanism at the link layer for sending packets to all (i.e., broadcast) ! or a subset of all neighbors. Multicast/broadcast ! can be provided by a variety of link layer ! mechanisms such as the physical link layer itself ! (for example, Ethernet), replicated unicast packets ! sent by the link layer software, or multicast ! servers (such as in ATM). Note that all point-to- ! point links are trivially capable of supporting ! multicast. point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast --- 357,365 ---- Different link layers have different properties. The ones of concern to Neighbor Discovery are: ! multicast - a link that supports a native mechanism at the link layer for sending packets to all (i.e., broadcast) ! or a subset of all neighbors. point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast *************** *** 352,359 **** non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, ! but that does not support any form of multicast or ! broadcast (e.g., X.25). shared media - a link that allows direct communication among a number of nodes, but attached nodes are configured --- 367,380 ---- non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, ! but that does not support a native form of multicast ! or broadcast (e.g., X.25, ATM, frame relay, etc.). ! Note that all link types (including NBMA) are ! expected to provide multicast service for IP (e.g., ! using multicast servers), but it is an issue for ! further study whether ND should use such facilities ! or an alternate mechanism that provides the ! equivalent ND services. shared media - a link that allows direct communication among a number of nodes, but attached nodes are configured *************** *** 490,497 **** reachable through a router.) Parameter Discovery: How a node learns such link parameters as the ! link MTU or such Internet parameters as the maximum hop ! limit value to place in outgoing packets. Address Autoconfiguration: How nodes automatically configure an address for an interface. --- 511,518 ---- reachable through a router.) Parameter Discovery: How a node learns such link parameters as the ! link MTU or such Internet parameters as the hop limit ! value to place in outgoing packets. Address Autoconfiguration: How nodes automatically configure an address for an interface. *************** *** 531,538 **** various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefixes that are used for on-link ! determination and/or address configuration, a maximum hop ! limit value, etc. Neighbor Solicitation: Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is --- 552,559 ---- various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefixes that are used for on-link ! determination and/or address configuration, a suggested ! hop limit value, etc. Neighbor Solicitation: Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is *************** *** 573,582 **** address configuration-related information is specified in [ADDRCONF]. Router Advertisement messages also contain Internet parameters such as ! the maximum hop limit that hosts should use in outgoing packets and, ! optionally, link parameters such as the link MTU. This facilitates ! centralized administration of critical parameters that can be set on ! routers and automatically propagated to all attached hosts. Nodes accomplish address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link-layer address. --- 594,603 ---- address configuration-related information is specified in [ADDRCONF]. Router Advertisement messages also contain Internet parameters such as ! the hop limit that hosts should use in outgoing packets and, optionally, ! link parameters such as the link MTU. This facilitates centralized ! administration of critical parameters that can be set on routers and ! automatically propagated to all attached hosts. Nodes accomplish address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link-layer address. *************** *** 728,738 **** The use of link-local addresses to uniquely identify routers (for Router Advertisement and Redirect messages) makes it possible for ! hosts the maintain the router associations in the event of the site renumbering to use new global prefixes. Using the Hop Limit equal to 255 trick Neighbor Discovery is immune ! to off-link senders that accidentally of intentionally send ND messages. In IPv4 off-link senders can send both ICMP Redirects and Router Advertisement messages. --- 749,759 ---- The use of link-local addresses to uniquely identify routers (for Router Advertisement and Redirect messages) makes it possible for ! hosts to maintain the router associations in the event of the site renumbering to use new global prefixes. Using the Hop Limit equal to 255 trick Neighbor Discovery is immune ! to off-link senders that accidentally or intentionally send ND messages. In IPv4 off-link senders can send both ICMP Redirects and Router Advertisement messages. *************** *** 746,771 **** 3.2. Supported Link Types Neighbor Discovery supports links with different properties. In the ! presence of certain properties only a subset of the ND protocol is ! available: point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point to point links, and interfaces can ! be assigned link-local addresses.) ! multicast - All aspects of Neighbor Discovery are available. non-broadcast multiple access (NBMA) ! - The only Neighbor Discovery mechanisms available on ! these links are Redirect handling and Neighbor ! Unreachability Detection. - If hosts support manual configuration of a list of - default routers, the hosts can dynamically acquire - the link-layer addresses for their neighbors from - Redirect messages. - shared media - The Redirect message is modeled after the XRedirect message in [SH-MEDIA] in order to simplify use of the protocol on shared media links. --- 767,796 ---- 3.2. Supported Link Types Neighbor Discovery supports links with different properties. In the ! presence of certain properties only a subset of the ND protocol ! mechanisms are fully specified in this document: point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point to point links, and interfaces can ! be assigned link-local addresses.) Neighbor ! Discovery should be implemented as described in this ! document. ! multicast - Neighbor Discovery should be implemented as ! described in this document. non-broadcast multiple access (NBMA) ! - Redirect, Neighbor Unreachability Detection and ! next-hop determination should be implemented as ! described in this document. Address resolution, and ! the mechanism for delivering Router Solicitations ! and Advertisements on NBMA links is not specified in ! this document. Note that if hosts support manual ! configuration of a list of default routers, hosts ! can dynamically acquire the link-layer addresses for ! their neighbors from Redirect messages. shared media - The Redirect message is modeled after the XRedirect message in [SH-MEDIA] in order to simplify use of the protocol on shared media links. *************** *** 832,840 **** IP Fields: Source Address ! An IP address assigned to the sending interface. If ! no address is assigned the unspecified address can be ! used. Destination Address Typically the all-routers multicast address. --- 857,865 ---- IP Fields: Source Address ! An IP address assigned to the sending interface, or ! the unspecified address if no address is assigned to ! the sending interface. Destination Address Typically the all-routers multicast address. *************** *** 880,886 **** +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | Max Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 905,911 ---- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | Cur Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *************** *** 916,924 **** Checksum The ICMP checksum. See [ICMPv6]. ! Max Hop Limit 8-bit unsigned integer. The maximum hop limit that ! hosts should place in outgoing IP packets. A value of ! zero means unspecified (by this router). M 1-bit "Managed address configuration" flag. When set, hosts use the administered (stateful) protocol for --- 941,950 ---- Checksum The ICMP checksum. See [ICMPv6]. ! Cur Hop Limit 8-bit unsigned integer. The default value that should ! be placed in the Hop Count field of the IP header for ! outgoing IP packets. A value of zero means ! unspecified (by this router). M 1-bit "Managed address configuration" flag. When set, hosts use the administered (stateful) protocol for *************** *** 978,990 **** Prefix Information These options specify the prefixes that are on-link and/or are used for address autoconfiguration. A ! router SHOULD include all its on-link prefixes so that ! multihomed hosts have complete prefix information ! about on-link destinations for the links to which they ! attach. If complete information is lacking, a ! multihomed host may not be able to chose the correct ! outgoing interface when sending traffic to its ! neighbors. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and --- 1004,1016 ---- Prefix Information These options specify the prefixes that are on-link and/or are used for address autoconfiguration. A ! router SHOULD include all its on-link prefixes (except ! the link-local prefix) so that multihomed hosts have ! complete prefix information about on-link destinations ! for the links to which they attach. If complete ! information is lacking, a multihomed host may not be ! able to chose the correct outgoing interface when ! sending traffic to its neighbors. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and *************** *** 1058,1065 **** Possible options: Source link-layer address ! The link-layer address for the sender. SHOULD be ! included on link layers that have addresses. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and --- 1084,1093 ---- Possible options: Source link-layer address ! The link-layer address for the sender. On link layers ! that have addresses this option MUST be included in ! multicast solicitations and SHOULD be included in ! unicast solicitations. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and *************** *** 1236,1248 **** by the sender and MUST be ignored by the receiver. Target Address An IP address that is a better first hop to use for ! the ICMP Destination Address. When the target is a ! router, the Target Address MUST be the router's link- ! local address so that hosts can uniquely identify ! routers. When the target is the actual endpoint of ! communication, i.e., the destination is a neighbor, ! the Target Address field MUST contain the same value ! as the ICMP Destination Address field. Destination Address The IP address of the destination which is redirected --- 1264,1277 ---- by the sender and MUST be ignored by the receiver. Target Address An IP address that is a better first hop to use for ! the ICMP Destination Address. When the target is the ! actual endpoint of communication, i.e., the ! destination is a neighbor, the Target Address field ! MUST contain the same value as the ICMP Destination ! Address field. Otherwise the target is a better ! first-hop router and the Target Address MUST be the ! router's link-local address so that hosts can uniquely ! identify routers. Destination Address The IP address of the destination which is redirected *************** *** 1252,1263 **** Target link-layer address The link-layer address for the target. It SHOULD be ! included (if known). Note that on NBMA links the ! sender of the invoking traffic can not use address ! resolution to determine the link-layer address of the ! target. Routers are advised not to send Redirect ! messages on such links unless they can supply the ! target link-layer address. Redirected Header As much as possible of the IP packet that triggered --- 1281,1292 ---- Target link-layer address The link-layer address for the target. It SHOULD be ! included (if known). Note that on NBMA links, hosts ! may rely on the presence of the Target Link-Layer ! Address option in Redirect messages as the means for ! determining the link-layer addresses of neighbors. In ! such cases, the option MUST be included in Redirect ! messages. Redirected Header As much as possible of the IP packet that triggered *************** *** 1322,1331 **** Link-Layer Address The variable length link-layer address. ! The content and format of this field is expected to be ! specified in specific documents that describe how IPv6 ! operates over different link layers. For instance, ! [IPv6-ETHER]. Description The Source Link-Layer Address option contains the --- 1351,1361 ---- Link-Layer Address The variable length link-layer address. ! The content and format of this field (including byte ! and bit ordering) is expected to be specified in ! specific documents that describe how IPv6 operates ! over different link layers. For instance, [IPv6- ! ETHER]. Description The Source Link-Layer Address option contains the *************** *** 1413,1419 **** leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the ! receiver. Description The Prefix Information option provide hosts with on- --- 1443,1451 ---- leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the ! receiver. A router SHOULD NOT send a prefix option ! for the link-local prefix and a host SHOULD ignore ! such a prefix option. Description The Prefix Information option provide hosts with on- *************** *** 1552,1562 **** provides a level of indirection into the Neighbor Cache; the Destination Cache maps a destination IP address to the IP address of the next-hop neighbor. ! Implementations may find it convenient to store ! additional information not directly related to ! Neighbor Discovery in Destination Cache entries, such ! as the Path MTU (PMTU) and round trip timers ! maintained by transport protocols. Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created --- 1584,1595 ---- provides a level of indirection into the Neighbor Cache; the Destination Cache maps a destination IP address to the IP address of the next-hop neighbor. ! This cache is updated with information learned from ! Redirect messages. Implementations may find it ! convenient to store additional information not ! directly related to Neighbor Discovery in Destination ! Cache entries, such as the Path MTU (PMTU) and round ! trip timers maintained by transport protocols. Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created *************** *** 1568,1573 **** --- 1601,1613 ---- valid forever, unless a new (finite) value is received in a subsequent advertisement. + The link-local prefix is considered to be on the + prefix list with an infinite invalidation timer + regardless of whether routers are advertising a prefix + for it. Received Router Advertisements SHOULD NOT + modify the invalidation timer for the link-local + prefix. + Default Router List - A list of routers to which packets may be sent. Router list entries point to entries in the Neighbor *************** *** 1586,1591 **** --- 1626,1637 ---- entries using that router in order to prevent redundant Neighbor Unreachability Detection probes. + Note also that other protocols (e.g. IPv6 Mobility) might add additional + conceptual data structures. An implementation is at liberty to + implement such data structures in any way it pleases. For example, an + implementation could merge all conceptual data structures into a single + routing table. + The Neighbor Cache contains information maintained by the Neighbor Unreachability Detection algorithm. A key piece of information is a neighbor's reachability state, which is one of five possible values. *************** *** 1625,1649 **** that neighbor. Next-hop determination for a given unicast destination operates as ! follows. The sender examines the Prefix List to determine whether the ! packet's destination is on- or off-link. If the destination is on-link, ! the next-hop address is the same as the packet's destination address. ! Otherwise, the sender selects a router from the Default Router List ! (following the rules described in Section 6.3.6). If the Default Router ! List is empty, the sender assumes that the destination is on-link. For efficiency reasons, next-hop determination is not performed on every packet that is sent. Instead, the results of next-hop determination ! computations are saved in the Destination Cache. When the sending node ! has a packet to send, it first examines the Destination Cache. If no ! entry exists for the destination, next-hop determination is invoked to ! create a Destination Cache entry. Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, ! sends a Neighbor Solicitation message, and then queues the data packet ! pending completion of address resolution. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2. --- 1671,1699 ---- that neighbor. Next-hop determination for a given unicast destination operates as ! follows. The sender performs a longest prefix match against the Prefix ! List to determine whether the packet's destination is on- or off-link. ! If the destination is on-link, the next-hop address is the same as the ! packet's destination address. Otherwise, the sender selects a router ! from the Default Router List (following the rules described in Section ! 6.3.6). If the Default Router List is empty, the sender assumes that ! the destination is on-link. For efficiency reasons, next-hop determination is not performed on every packet that is sent. Instead, the results of next-hop determination ! computations are saved in the Destination Cache (which also contains ! updates learned from Redirect messages). When the sending node has a ! packet to send, it first examines the Destination Cache. If no entry ! exists for the destination, next-hop determination is invoked to create ! a Destination Cache entry. Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, ! initiates Address Resolution, and then queues the data packet pending ! completion of address resolution. For multicast-capable interfaces ! Address Resolution consists of sending a Neighbor Solicitation message ! and waiting for a Neighbor Advertisement. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2. *************** *** 1906,1919 **** Default: 0 ! AdvMaxHopLimit ! The value to be placed in the Max Hop Limit field in ! the Router Advertisement messages sent by the ! router. The value zero means unspecified (by this ! router). ! Default: The value specified in the most recent ! "Assigned Numbers" RFC [ASSIGNED]. AdvDefaultLifetime The value to be placed in the Router Lifetime field --- 1956,1971 ---- Default: 0 ! AdvCurHopLimit ! The default value to be placed in the Cur Hop Limit ! field in the Router Advertisement messages sent by ! the router. The value should be set to that current ! diameter of the Internet. The value zero means ! unspecified (by this router). ! Default: The value specified in the "Assigned ! Numbers" RFC [ASSIGNED] that was in effect at the ! time of implementation. AdvDefaultLifetime The value to be placed in the Router Lifetime field *************** *** 1932,1938 **** Default: all prefixes that the router advertises via routing protocols as being on-link for the interface ! from which the advertisement is sent. Each prefix has an associated: --- 1984,1992 ---- Default: all prefixes that the router advertises via routing protocols as being on-link for the interface ! from which the advertisement is sent. The link- ! local prefix SHOULD NOT be included in the list of ! advertised prefixes. Each prefix has an associated: *************** *** 1976,1982 **** Router Advertisement messages. Hosts use the received information to initialize a set of analogous variables that control their external behavior (see Section 6.3.2). Some of these host variables (e.g., ! MaxHopLimit, RetransTimer, and ReachableTime) apply to all nodes including routers. In practice, these variables may not actually be present on routers, since their contents can be derived from the variables described above. However, external router behavior MUST be --- 2030,2036 ---- Router Advertisement messages. Hosts use the received information to initialize a set of analogous variables that control their external behavior (see Section 6.3.2). Some of these host variables (e.g., ! CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes including routers. In practice, these variables may not actually be present on routers, since their contents can be derived from the variables described above. However, external router behavior MUST be *************** *** 2028,2035 **** - In the M and O flags: the interface's configured AdvManagedFlag and AdvOtherConfigFlag, respectively. See [ADDRCONF]. ! - In the Max Hop Limit field: the interface's configured ! AdvMaxHopLimit. - In the Reachable Time field: the interface's configured AdvReachableTime. --- 2082,2088 ---- - In the M and O flags: the interface's configured AdvManagedFlag and AdvOtherConfigFlag, respectively. See [ADDRCONF]. ! - In the Cur Hop Limit field: the interface's configured CurHopLimit. - In the Reachable Time field: the interface's configured AdvReachableTime. *************** *** 2214,2220 **** be misconfigured and SHOULD be logged to system or network management. The minimum set of information to check includes: ! - Max Hop Limit values (except for the unspecified value of zero). - Values of the M or O flags. --- 2267,2273 ---- be misconfigured and SHOULD be logged to system or network management. The minimum set of information to check includes: ! - Cur Hop Limit values (except for the unspecified value of zero). - Values of the M or O flags. *************** *** 2297,2307 **** that describes how IPv6 operates over the particular link layer (e.g., [IPv6-ETHER]). ! MaxHopLimit The maximum hop limit to be used when sending IP ! packets. ! Default: The value specified in the most recent ! "Assigned Numbers" RFC [ASSIGNED]. BaseReachableTime A base value used for computing the random --- 2350,2361 ---- that describes how IPv6 operates over the particular link layer (e.g., [IPv6-ETHER]). ! CurHopLimit The default hop limit to be used when sending ! (unicast) IP packets. ! Default: The value specified in the "Assigned ! Numbers" RFC [ASSIGNED] that was in effect at the ! time of implementation. BaseReachableTime A base value used for computing the random *************** *** 2339,2354 **** When multiple routers are present, the information advertised collectively by all routers may be a superset of the information ! contained in a single Router Advertisement. Hosts accept the union of ! all advertised information; the receipt of a Router Advertisement MUST ! NOT invalidate all information received in a previous advertisement. However, when received information for a specific parameter (e.g., Link ! MTU) or option (e.g., Lifetime on a specific Prefix) is different than information received earlier, and the parameter/option can only have one value, the most recently-received information is considered authoritative. ! Some Router Advertisement fields (e.g., Max Hop Limit, Reachable Time and Retrans Timer) may contain a value denoting unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using. In particular, a host MUST --- 2393,2410 ---- When multiple routers are present, the information advertised collectively by all routers may be a superset of the information ! contained in a single Router Advertisement. Moreover, information may ! also be obtained through other dynamic means, such as stateful ! autoconfiguration. Hosts accept the union of all received information; ! the receipt of a Router Advertisement MUST NOT invalidate all ! information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link ! MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently-received information is considered authoritative. ! Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time and Retrans Timer) may contain a value denoting unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using. In particular, a host MUST *************** *** 2384,2391 **** router can be found quickly (e.g., without having to wait for the next advertisement to arrive). ! If the received Max Hop Limit value is non-zero the host SHOULD set its ! MaxHopLimit variable to the received value. If the received Reachable Time value is non-zero the host SHOULD set its BaseReachableTime variable to the received value. If the new value --- 2440,2447 ---- router can be found quickly (e.g., without having to wait for the next advertisement to arrive). ! If the received Cur Hop Limit value is non-zero the host SHOULD set its ! CurHopLimit variable to the received value. If the received Reachable Time value is non-zero the host SHOULD set its BaseReachableTime variable to the received value. If the new value *************** *** 2424,2437 **** Prefix Information options that have the "on-link" (L) flag set indicate a prefix identifying a range of addresses that should be considered on- link. Note, however, that a Prefix Information option with the on-link ! flag set to zero does not convey any meaning. In particular, such a ! prefix MUST NOT be considered to be off-link. Prefixes with the on-link ! flag set to zero would normally have the autonomous flag set and be used ! by [ADDRCONF]. For each Prefix Information option with the on-link flag set, a host does the following: - If the prefix is not already present in the Prefix List, and the Prefix Information option's Valid Lifetime field is non-zero, create a new entry for the prefix and initialize its invalidation --- 2480,2502 ---- Prefix Information options that have the "on-link" (L) flag set indicate a prefix identifying a range of addresses that should be considered on- link. Note, however, that a Prefix Information option with the on-link ! flag set to zero conveys no information concerning on-link determination ! and MUST NOT be interpreted to mean that addresses covered by the prefix ! are off-link. The default behavior (see Section 5.2) when no ! information is known about an address is to send the packets to a ! default router and the reception of a Prefix Information option with the ! "on-link " (L) flag set to zero does not change this behavior. The ! reasons for an address being treated as on-link is specified in the ! definition of "on-link" in Section 2.1. Prefixes with the on-link flag ! set to zero would normally have the autonomous flag set and be used by ! [ADDRCONF]. For each Prefix Information option with the on-link flag set, a host does the following: + - If the prefix is the link-local prefix, silently ignore the Prefix + Information option. + - If the prefix is not already present in the Prefix List, and the Prefix Information option's Valid Lifetime field is non-zero, create a new entry for the prefix and initialize its invalidation *************** *** 2685,2695 **** 7.2.2. Sending Neighbor Solicitations When a node has a unicast packet to send to a neighbor, but does not ! know the neighbor's link-layer address, it performs address resolution ! by creating a Neighbor Cache entry in the INCOMPLETE state and ! transmitting a Neighbor Solicitation message targeted at the neighbor. ! The solicitation is sent to the solicited-node multicast address ! corresponding to the target address. If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that --- 2750,2760 ---- 7.2.2. Sending Neighbor Solicitations When a node has a unicast packet to send to a neighbor, but does not ! know the neighbor's link-layer address, it performs address resolution. ! For multicast-capable interfaces this entails creating a Neighbor Cache ! entry in the INCOMPLETE state and transmitting a Neighbor Solicitation ! message targeted at the neighbor. The solicitation is sent to the ! solicited-node multicast address corresponding to the target address. If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that *************** *** 2701,2708 **** be used in subsequent return traffic belonging to the prompting packet's "connection". ! The sender SHOULD include its link-layer address (if it has one) in the ! solicitation as a Source Link-Layer Address option. While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address --- 2766,2778 ---- be used in subsequent return traffic belonging to the prompting packet's "connection". ! If the solicitation is being sent to a solicited-node multicast address, ! the sender MUST include its link-layer address (if it has one) as a ! Source Link-Layer Address option. Otherwise, the sender SHOULD include ! its link-layer address (if it has one) as a Source Link-Layer Address ! option. Including the source link-layer address in a multicast ! solicitation is required to give the target an address to which it can ! send the Neighbor Advertisement. While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address *************** *** 2729,2735 **** A valid Neighbor Solicitation where the Target Address is not a unicast or anycast address assigned to the receiving interface, and the Target Address is not a "tentative" address on which Duplicate Address ! Detection is being performed [ADDRCONF] MUST be silently ignored. Upon receipt of a valid Neighbor Solicitation targeted at the node, the recipient SHOULD update the Neighbor Cache entry for the IP Source --- 2799,2807 ---- A valid Neighbor Solicitation where the Target Address is not a unicast or anycast address assigned to the receiving interface, and the Target Address is not a "tentative" address on which Duplicate Address ! Detection is being performed [ADDRCONF] MUST be silently ignored. If ! the Target Address is tentative, the Neighbor Solicitation should be ! processed as described in [ADDRCONF]. Upon receipt of a valid Neighbor Solicitation targeted at the node, the recipient SHOULD update the Neighbor Cache entry for the IP Source *************** *** 2752,2770 **** 7.2.4. Sending Solicited Neighbor Advertisements A node sends a Neighbor Advertisement in response to a valid Neighbor ! Solicitation targeting one of the node's assigned or "tentative" ! address. The Target Address of the advertisement is copied from the ! Target Address of the solicitation. The Target Link-Layer Address ! option SHOULD be included, using as its value the interface's link-layer ! address. If the node is a router, it MUST set the Router flag to one; ! otherwise it MUST set the flag to zero. If the Target Address is either an anycast address or a unicast address ! for which the node is providing proxy service, the Override flag SHOULD ! be set to zero. Otherwise, it SHOULD be set to one. Proper setting of ! the Override flag insures that nodes give preference to non-proxy ! advertisements, even when received after proxy advertisements, but that ! the first advertisement for an anycast address "wins". If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to --- 2824,2848 ---- 7.2.4. Sending Solicited Neighbor Advertisements A node sends a Neighbor Advertisement in response to a valid Neighbor ! Solicitation targeting one of the node's assigned addresses. The Target ! Address of the advertisement is copied from the Target Address of the ! solicitation. If the solicitation's IP Destination Address is a unicast ! or anycast address, the Target Link-Layer Address option SHOULD NOT be ! included; the neighboring node's cached value must already be current in ! order for the solicitation to have been received. If the solicitation's ! IP Destination Address is a solicited-node multicast address, the Target ! Link-Layer option MUST be included in the advertisement. If the node is ! a router, it MUST set the Router flag to one; otherwise it MUST set the ! flag to zero. If the Target Address is either an anycast address or a unicast address ! for which the node is providing proxy service, or the Target Link-Layer ! Address option is not included in the outgoing advertisement, the ! Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to ! one. Proper setting of the Override flag insures that nodes give ! preference to non-proxy advertisements, even when received after proxy ! advertisements, but that the first advertisement for an anycast address ! "wins". If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to *************** *** 3082,3088 **** link-layer address. If no traffic is sent to a neighbor, no probes are sent. ! When a node needs to performs address resolution on a neighboring address, it creates an entry in the INCOMPLETE state and initiates address resolution as specified in Section 7.2. If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that --- 3160,3166 ---- link-layer address. If no traffic is sent to a neighbor, no probes are sent. ! When a node needs to perform address resolution on a neighboring address, it creates an entry in the INCOMPLETE state and initiates address resolution as specified in Section 7.2. If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that *************** *** 3090,3096 **** next-hop determination at this point insures that alternate default routers are tried. ! When a reachability conformation is received (either through upper-layer advice or a solicited Neighbor Advertisement) an entry's state changes to REACHABLE. The one exception is that upper-layer advice has no effect on entries in the INCOMPLETE state (e.g., for which no link-layer --- 3168,3174 ---- next-hop determination at this point insures that alternate default routers are tried. ! When a reachability confirmation is received (either through upper-layer advice or a solicited Neighbor Advertisement) an entry's state changes to REACHABLE. The one exception is that upper-layer advice has no effect on entries in the INCOMPLETE state (e.g., for which no link-layer *************** *** 3097,3103 **** address is cached). When ReachableTime milliseconds have passed since receipt of the last ! reachability confirmation for a neighbor, the Neighbor Cache entries state changes from REACHABLE to STALE. Note: An implementation may actually defer changing the state from --- 3175,3181 ---- address is cached). When ReachableTime milliseconds have passed since receipt of the last ! reachability confirmation for a neighbor, the Neighbor Cache entry's state changes from REACHABLE to STALE. Note: An implementation may actually defer changing the state from *************** *** 3138,3145 **** known in the STALE state provides assurance that path failures are detected quickly. In addition, should a cached link-layer address be modified due to receiving one of the above messages the state SHOULD ! also be set to STALE to provide prompt verification that the patch to ! the new link-layer address is working. To properly detect the case where a router switches from being a router to being a host (e.g., if its IP forwarding capability is turned off by --- 3216,3223 ---- known in the STALE state provides assurance that path failures are detected quickly. In addition, should a cached link-layer address be modified due to receiving one of the above messages the state SHOULD ! also be set to STALE to provide prompt verification that the path to the ! new link-layer address is working. To properly detect the case where a router switches from being a router to being a host (e.g., if its IP forwarding capability is turned off by *************** *** 3177,3184 **** A router MUST be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address in a Redirect message identifies the neighbor router by its link-local ! address. This may require that routing protocols exchange link-local ! addresses. 8.1. Validation of Redirect Messages --- 3255,3265 ---- A router MUST be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address in a Redirect message identifies the neighbor router by its link-local ! address. For static routing this requirement implies that the next-hop ! router's address should be specified using the link-local address of the ! router. For dynamic routing this requirement implies that all IPv6 ! routing protocols must somehow exchange the link-local addresses of ! neighboring routers. 8.1. Validation of Redirect Messages *************** *** 3235,3241 **** 8.2. Router Specification A router SHOULD send a redirect message, subject to rate limiting, ! whenever it forwards a packet that it not explicitly addressed to itself (i.e. a packet that is not source routed through the router) in which: - the Source Address field of the packet identifies a neighbor, and --- 3316,3322 ---- 8.2. Router Specification A router SHOULD send a redirect message, subject to rate limiting, ! whenever it forwards a packet that is not explicitly addressed to itself (i.e. a packet that is not source routed through the router) in which: - the Source Address field of the packet identifies a neighbor, and *************** *** 3299,3304 **** --- 3380,3391 ---- IsRouter field in the corresponding Neighbor Cache entry to FALSE. Otherwise it MUST set IsRouter to true. + Redirect messages apply to all flows that are being sent to a given + destination. That is, upon receipt of a Redirect for a Destination + Address, all Destination Cache entries to that address should be updated + to use the specified next-hop, regardless of the contents of the Flow + Label field that appears in the Redirected Header option. + A host MAY have a configuration switch that can be set to make it ignore a Redirect message that does not have an IP Authentication header. *************** *** 3437,3446 **** 11. SECURITY CONSIDERATIONS ! Neighbor Discovery is subject attacks that cause IP packets to flow to ! unexpected places. Such attacks can be used to cause denial of service ! but also allow nodes to intercept and optionally modify packets destined ! for other nodes. The protocol reduces the exposure to such threats in the absence of authentication by ignoring ND packets received from off-link senders. --- 3524,3533 ---- 11. SECURITY CONSIDERATIONS ! Neighbor Discovery is subject to attacks that cause IP packets to flow ! to unexpected places. Such attacks can be used to cause denial of ! service but also allow nodes to intercept and optionally modify packets ! destined for other nodes. The protocol reduces the exposure to such threats in the absence of authentication by ignoring ND packets received from off-link senders. *************** *** 3490,3500 **** REFERENCES ! [ADDRCONF] S. Thomson, "IPv6 Address Autoconfiguration", Internet ! Draft. [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing ! Architecture", Internet Draft. [ANYCST] C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. --- 3577,3587 ---- REFERENCES ! [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", ! Work in Progress. [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing ! Architecture", RFC 1884, January, 1996. [ANYCST] C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. *************** *** 3508,3521 **** [ICMPv4] J. Postel, "Internet Control Message Protocol", STD 5, RFC 792, September 1981. ! [ICMPv6] A. Conta, and S. Deering, "ICMP for the Internet Protocol ! Version 6 (IPv6)", Internet Draft. [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 ! (IPv6) Specification", Internet Draft. [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 ! Packets over Ethernet Networks", Internet Draft. [IPv6-SA] R. Atkinson. "Security Architecture for the Internet Protocol". RFC 1825, August 1995. --- 3595,3609 ---- [ICMPv4] J. Postel, "Internet Control Message Protocol", STD 5, RFC 792, September 1981. ! [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol ! (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC ! 1885, January 1996. [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 ! (IPv6) Specification", RFC 1883, January, 1996. [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 ! Packets over Ethernet Networks", Work in Progress. [IPv6-SA] R. Atkinson. "Security Architecture for the Internet Protocol". RFC 1825, August 1995. *************** *** 3549,3556 **** Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 USA USA ! phone: +1 415 336 2788 phone: +1 919 254 7798 ! fax: +1 415 336 6015 fax: +1 919 254 4027 email: nordmark@sun.com email: narten@vnet.ibm.com William Allen Simpson --- 3637,3644 ---- Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 USA USA ! phone: +1 415 786 5166 phone: +1 919 254 7798 ! fax: +1 415 786 5896 fax: +1 919 254 4027 email: nordmark@sun.com email: narten@vnet.ibm.com William Allen Simpson *************** *** 3686,3695 **** retransmissions. INCOMPLETE NA, Solicited=0, Record link-layer STALE ! Override=any address. INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE ! Override=any address. !INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 --- 3774,3785 ---- retransmissions. INCOMPLETE NA, Solicited=0, Record link-layer STALE ! Override=any address. Send queued ! packets. INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE ! Override=any address. Send queued ! packets. !INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 *************** *** 3735,3740 **** --- 3825,3834 ---- - NS, RS, RA, Redirect Create entry. STALE + INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE + address. Send queued + packets. + !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE Different link-layer address address than cached. *************** *** 3795,3804 **** current reachability. For example, new data received 30 minutes after a window has opened up does not constitute a confirmation that the path is currently working. In merely indicates that 30 minutes ago the window ! update reached the peer i.e. the patch was working at that point in ! time. An implementation must also take into account TCP zero-window ! probes that are sent even if the path is broken and the window update ! did not reach the peer. For UDP based applications (RPC, DNS) it is relatively simple to make the client send reachability confirmations when the response packet is --- 3889,3898 ---- current reachability. For example, new data received 30 minutes after a window has opened up does not constitute a confirmation that the path is currently working. In merely indicates that 30 minutes ago the window ! update reached the peer i.e. the path was working at that point in time. ! An implementation must also take into account TCP zero-window probes ! that are sent even if the path is broken and the window update did not ! reach the peer. For UDP based applications (RPC, DNS) it is relatively simple to make the client send reachability confirmations when the response packet is *************** *** 3817,4012 **** - APPENDIX E: CHANGES SINCE PREVIOUS VERSION - There are several changes since the previous version documented in: - - based on feedback from the working group: - Protocol changes: - o Changed redirect ICMP type from 5 to 137 to make it an - informational ICMP message. - o Simplified the technique for filtering out ND packets sent from - off-link sources. This entailed: - o Added the Hop Count 255 rules for transmit and receive - verification to be able to ignore packets sent from off-link - sources. - o Removed the requirement that NS and NA be sent with link-local - source address. This removed the need for the ICMP Sender - Address field in the NA messages. These changes undo many of - the changes between the -01 and -02 revisions of this - document. - o Removed the validity check for all messages that did not allow - a routing header. - o Removed "no NUD for ND Packets" rule - o Setting the IP priority field to 15 in all ND packets. - o Inverted the semantics of the 'N' flag (secondary advertisement - flag) in Neighbor Advertisements and renamed it to the Override - flag. - o Added rules for periodic randomization of ReachableTime to avoid - long-range periodic behavior when there are no routers on the - link. The ReachableTime randomization only takes place when a RA - advertises a different value or once every few hours. - o Made the bits in the prefix after prefix length bit reserved - (zero on transmit and ignored on receipt). - o Allow RS packets to be sent with an unspecified source address so - that duplicate address detection can be done in parallel with - sending a RS. - o Changed the router behavior for responding to RS so that all - solicited RA messages are multicast to all-nodes with a rate - limit (one message at most every 3 seconds) and a random - dithering (of .5 seconds). - o Increased the lower limit on MaxRtrAdvInterval and - MinRtrAdvInterval to match the rate limit imposed on solicited RA - messages. - o Changed the timers for hosts sending RS to match the routers - response. - o Made hosts always send one RS messages when initializing to avoid - problems when routers only send subsets of options in RA - messages. - o Made the RETRANS_TIMER 1 second with the ability for IP-over-foo - documents to override this default value. - o Added general rules that default values for protocol constants - and variables may be overridden by an IP-over-foo document. This - rule allows ND to operate over links with widely varying - performance characteristics. - o Default setting of AdvSendAdvertisements changed to FALSE to - prevent "routers" from connecting to the network "out of the box" - and sending out bogus advertisements prior to being explicitly - configured. - Editorial changes: - o Created standalone Packet Formats Section between Overview and - Conceptual Model sections. Packet Formats had previously - appeared at the start of the section describing a particular - message type. - o Changed AdvertiseDefault flag to AdvSendAdvertisements. Flag now - indicates whether RAs should be sent. The variable - AdvDefaultLifetime controls whether we advertise ourselves as a - default router. Thus, a router can advertise prefixes and other - info without being used as a default router. - o Added paragraph to Requirements section making it clear that - compliance is defined by external behavior, not use of variables - described in the document - o Changed the name of "is_router" flag to IsRouter for consistency - with other names. - o Changed names of all router configuration variables to begin with - the prefix Adv (e.g., AdvRetransTimer) - o Changed deprecation lifetime to preferred lifetime and - invalidation lifetime to valid lifetime to make the names - consistent with [ADDRCONF]. - o Added text to point out that options that don't belong in a - particular ND message (e.g., prefix option on neighbor - solicitation) MUST be silently ignored. - o Added text to state that on-link flag being zero in a prefix - option does not imply that the prefix is off-link. - o Moved the multihoming material to an appendix. - o Added bit numbering to all formats. - o Clarified that the Target link-layer address option in a NA has - to be the address of the sender. - o Introduced the STALE and DELAY states to better explain the - behavior of NUD. - o Clarified that updated cache entries only go to STALE state when - the link-layer address is different than the recorded address. - o Clarified that NUD specifies that reachability confirmations to - change state to REACHABLE independent of current state. - o Created an appendix to illustrate the rules for reachability - state transitions. - o Added some minor text to "Comparison with IPv4" about why IPv4 - router discovery preferences are not needed in ND. - o Added text to "Comparison with IPv4" to point out that the use of - link-local source addresses for RA and Redirect messages makes it - possible for hosts the maintain the router associations in the - event of renumbering. - o Strengthened text pointing out that the conceptual model is not - required by implementations but instead it is only the externally - visible behavior that is specified. - o Added text about implementation issues with positive reachability - advice from upper layers. - o Add wording that says all subsequent text assumes that - message/action applies to a specific interface so we don't always - have to say "receiving interface", etc.? - o Made it more clear that the text in the packet format describes - "common use", e.g., "the destination address is ...". It does - not (always) list hard constraints. - o Added text to point out that when an entry is deleted from the - router list all destination cache entries using that router must - be "updated". - TODO - o Should we change the definition of option lengths so that length - excludes the first 8-byte part? This would make the option - length follow that same rules as the Hdr Ext Len in the base - specification and it would remove the validation checks that - check length > 0. - o This revision increase the minimum values for MinRtrAdvInterval - and MaxRtrAdvInterval from .1 and 1 second respectively to make - the numbers consistent with the Router Advertisement rate limit - of on RA every 3 seconds. If the Router Advertisements will be - use for beaconing in IPv6 mobility those times probably have to - be smaller. With such a change the MIN_DELAY_BETWEEN_RAS would - either have to be configurable or have a lower value. - o Get WG feedback on need for booting hosts to always send out 1 - RS, so that routers know to include all options in outgoing RAs. - Or remove the capability that routers can sent a subset of the - options in their RAs? The reason ND allows RAs that contain a - subset of the options is in anticipation of IPv6 mobility using - RAs for frequent beaconing. - o Make all timer constants be in units of milliseconds? (to - implicitly make it more clear that implementations need higher - timer resolution than 1 second). --- 3911,3972 ---- *************** *** 4195,4199 **** ! draft-ietf-ipngwg-discovery-03.txt [Page 1] --- 4155,4199 ---- ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! draft-ietf-ipngwg-discovery-06.txt [Page 1] --=_AABqUgAAYBExTus+-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 20 06:19:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04827; Wed, 20 Mar 96 06:19:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04821; Wed, 20 Mar 96 06:18:46 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24403; Wed, 20 Mar 1996 06:16:57 -0800 Received: from Aria.u-strasbg.fr by Sun.COM (sun-barr.Sun.COM) id AA12063; Wed, 20 Mar 96 06:16:54 PST Received: by Aria.u-strasbg.fr (4.1/SMI-3.2-jjp/4/6/92) id AA01549; Wed, 20 Mar 96 15:16:20 GMT Date: Wed, 20 Mar 96 15:16:20 GMT From: goujard@Aria.u-strasbg.fr (Mister G.) Message-Id: <9603201516.AA01549@Aria.u-strasbg.fr> To: ipng@sunroof.eng.sun.com Subject: (IPng 1564) Routing with Solaris 2.5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'm working on IPv6, trying to learn more about the transition from IPv4. In our case we would like our SunSparc to act as a router for another machine. This SunSparc runs Solaris 2.5 and the appropriate tools for IPv6. >> Is it possible to route IPv6 incoming from the other machine ??? The other machine runs NetBSD 1.1 with the INRIA implementation of IPv6. Would it be better to use this machine as a router ??? French student waiting for a response ..... Thanks D. Goujard ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 20 07:55:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04877; Wed, 20 Mar 96 07:55:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04871; Wed, 20 Mar 96 07:55:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05375; Wed, 20 Mar 1996 07:53:27 -0800 Received: by mercury.Sun.COM (Sun.COM) id HAA06902; Wed, 20 Mar 1996 07:53:25 -0800 Received: from mailhub.advtech.uswest.com (mh16.advtech.uswest.com [130.13.16.7]) by uswat.advtech.uswest.com (8.7.5/8.7.3) with ESMTP id IAA00669 for ; Wed, 20 Mar 1996 08:53:24 -0700 (MST) Received: from yakima.advtech.uswest.com (yakima.advtech.uswest.com [130.13.21.147]) by mailhub.advtech.uswest.com (8.7.5/8.7.3) with SMTP id IAA27410; Wed, 20 Mar 1996 08:53:23 -0700 (MST) Received: by yakima.advtech.uswest.com (advtech.uswest.com) id AA04545 (4.1/at-generic.8Nov93); Wed, 20 Mar 96 08:53:22 MST From: Brian Field Message-Id: <9603201553.AA04545@yakima.advtech.uswest.com> Subject: (IPng 1565) flows & priority values To: ipng@sunroof.eng.sun.com Date: Wed, 20 Mar 1996 08:53:21 -0700 (MST) Cc: bfield@advtech.uswest.com (Brian Field) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've read through RFC 1883 (IPv6 Specification) and have a question regarding flows and priority values. In section 6 (Flow Labels), paragraph five begins by stating that: "All packets belonging to the same flow must be sent with the same source address, destination address, priority, and flow label." Later, in section 7 (Priority), the first paragraph states that: "The 4-bit priority field in the IPv6 header enables a source to identify the desired delivery priority of its packets, relative to other packets from the same source." Does the Priority section state imply that, within a flow, packets can have different priority values? If so, then doesn't this contradict what is written in the Flow section? If a flow can only label its packets with a single value, then what is the justification for this constraint? Is the first node on the path responsible for verifying that this constraint is true for all packets in the flow? Thanks, Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 22 13:20:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06865; Fri, 22 Mar 96 13:20:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06859; Fri, 22 Mar 96 13:19:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11283; Fri, 22 Mar 1996 13:17:16 -0800 Received: by mercury.Sun.COM (Sun.COM) id NAA24879; Fri, 22 Mar 1996 13:16:21 -0800 Received: (wessorh@localhost) by ar.com (8.6.11/8.6.5) id NAA08866 for ipng@sunroof.Eng.Sun.COM; Fri, 22 Mar 1996 13:15:50 -0800 Date: Fri, 22 Mar 1996 13:15:50 -0800 From: "Rick H. Wesson" Message-Id: <199603222115.NAA08866@ar.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1566) IPv6 Regestries X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know what the requirements will be to become a regestery? Will IANA decide who becomes a registery? If so what will they use to decide who is and is not allowed to become one. Thanks, -Rick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 22 15:19:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06924; Fri, 22 Mar 96 15:19:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06918; Fri, 22 Mar 96 15:18:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08256; Fri, 22 Mar 1996 15:16:20 -0800 Received: by mercury.Sun.COM (Sun.COM) id PAA27720; Fri, 22 Mar 1996 15:14:49 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA19443; Fri, 22 Mar 1996 15:14:12 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Mar 1996 15:17:15 -0800 To: "Rick H. Wesson" From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1567) Re: IPv6 Regestries Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rick, >Does anyone know what the requirements will be to >become a regestery? Will IANA decide who becomes a >registery? If so what will they use to decide who >is and is not allowed to become one. The IANA is responsible for who is a registry. Suggest you contact them (iana@isi.edu) about their criteria. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Mar 22 17:11:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07125; Fri, 22 Mar 96 17:11:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06573; Fri, 22 Mar 96 04:08:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04143; Fri, 22 Mar 1996 04:06:49 -0800 Received: by mercury.Sun.COM (Sun.COM) id EAA04651; Fri, 22 Mar 1996 04:06:48 -0800 Received: from catullus.agw.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Fri, 22 Mar 1996 11:59:15 +0000 Received: from isdgate.agw.bt.co.uk (isdgate.agw.bt.co.uk [147.150.41.229]) by catullus.agw.bt.co.uk (8.6.12/8.6.11) with SMTP id KAA08343; Fri, 22 Mar 1996 10:09:59 GMT Received: by isdgate.agw.bt.co.uk with Microsoft Mail id <31527D7F@isdgate.agw.bt.co.uk>; Fri, 22 Mar 96 10:14:23 GMT From: "Jenkins, Paul" To: bt-ietf-addr , bt-ipng , ipng Subject: (IPng 1568) Re: Proposed v6 Addressing, open ended routing tables Date: Fri, 22 Mar 96 09:58:00 GMT Message-Id: <31527D7F@isdgate.agw.bt.co.uk> Encoding: 160 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael? wrote on 11 March ---------- > From: ssilverman > To: bt-ietf-addr; bt-ipng; ipng; ssilverman > Subject: Re: (IPng 1533) Proposed v6 Addressing, open ended routing tables > Date: 11 March 1996 16:20 > > One serious problem that I see with saying, "There are 250 > privileged entities, and everyone else is second class", is that > you have to tell when someone is no longer in first class. > > What happens if three years from now sprint is no longer one of > the main routers? What would have happened if this had been done > two years ago, and now ATT wants to get into the business? What > happens when one of the now regional ISP's wants to go national? > > Any thing like this, that limits -- rather strictly -- the > ability of the net to adapt, that restricts what the people who > make up the net can do, gets a no vote from me. > > (However, I think that 2 bytes worth is a different story. But > then, doesn't that make the routing tables too large?) > > Here's another idea: As long as the V6 address assignment is > done in a way that renumbering is trivial and automatic, then > the only thing that a backbone router needs to know is what > outgoing interface(s) to use for a given prefix. If we say that > N bits (be it 5 bits for the registry, or 8 or 16 bits for a > TLISP number) are sufficent, then that is enough for a router to > decide what outgoing port to use, and it is sufficient to reach > a router for that (registry, ISP, etc). > > At that point, that entity knows how big the next field is, and > has a complete table for routing that field. > > In other words, no one has, or needs, the complete table. The > main routers for sprint know how to route to all the large > groups that sprint routes to (meaning local ISP's that get > serviced through sprint), those local ISP's know how to reach > all their currently logged on customers, etc. > > As I'm not sure this is clear enough, let's try that again. > 1. A top level, registry router, will have 31 entries for > (registry ID, list of output interfaces to use) for each of the > other 31 registries. They will also have an entry for each of > the N-bits of ISP's that they serve. > > So, if one registry were to register 4 bytes of villiage ID's, > then that registry would have to maintain routers that could > deal with billions of possible addresses. The rest of the > internet would only have one address for "how to reach one of > their routers". This implies ALL inter registry traffic is routed through one of 32 router points on the internet! Is this reasonable?? > > 2. Something on the "backbone", such as a sprint router, would > have 32 entries for all of the registries. It would also have > details on everything at the sprint level -- all of the local > ISP's that get served through sprint, all of the sprint internal > routings, etc. But it has no details, nor does it care to care, > about the details of the routings at MCI nor registry #21. > > 3. It's entirely possible that, given 56 bits to identify the > combination of , that > there's enough bits in there for a third level. That would be > more than 16 bits for each. > > In other words, a given registry might have 16 bits set aside > for identifying the next lower layer that it knows how to reach. > That's only 64K entries, max, that it needs to have. Lets say > that this is the village registry. > > It could decide to break the 56 bits that it has into 8 bits of > country ID. (256 entries at the top, plus the other 31 registries, > or a total of 289 total entries in the routing table.) Within > each country, there would be an agency that decided how to break > that down -- some smaller countries would have nothing but > zero's in the remaining 48 bits. Others might use 16 bits of > zero for padding, and the remaining 32 bits would be broken up > into 6 bits of state id, and then at the state level would be > routers that use the remaining 26 bits for whatever was wanted > at that level. > > Now, this manages to keep the routing tables small. How well > does it actually route packets? > > Lets say that I've got a node in california, and I'm two hops > direct from a node in las vegas. I don't talk direct to that > node. I send it to my higher up (the county level router), from > there to the california level router, from there to the las > vegas level router, from there to the reno router, and then to > the casino, which then sends it to the slot machine. (just > kidding). But if the addresses had been allocated by different registries, unless both registries were located in the US then this communication would require international links. Whilst the US may not suffer from such problems, what if the communications were between Manchester and Blackburn? It seems to me that this solution goes too far in reducing the routeing tables and creates great demands on international links. > > The fact that I have a neighbor node across town in las vegas is > ignored as the destination is not a neighboring site. Hmm. > > Well, this idea keeps routing tables small, at the expense of > greater traffic, especially at the registry level (if I'm in the > fido registry, and someone else is in the telephone registry, > then we'll talk by going all the way to the top). The only > solution to that that I see is to have a mechanism to > automatically build source route tunnels. Maybe when a TCP > connection is opened, there might be some way to say, "This is > going to be a heavy volume connection -- find a faster > connection", followed by some way to query routers (which I > can't see without major network flooding). > > So how does this compare with the "use 8 bits for 250 top level > routers/areas"? Well, I'm looking at 32 top level registries, and > from there, each of them has as many "areas" as they can handle. > Other than that, about the only difference is that I'm explicitly > not saying anything about how many sublayers of subrouters may be > enountered before the destination. > > Michael > > p.s. An initial idea/proposal for those router questions. > As the neighbor discovery/router advertisements will contain > things like prefix bits, you can find out when a neighbor is > in a different routing area than your main router. So, if > someone were to send a "anyone have a better route to foo" > message upstream past you, you could send it, not only upstream > to your router, but also across that other connection. > So, it would be something like, > 1. A node with a non-local neighbor can tell it's router(s) this fact, > 2. "is there a better way?" would go upstream to the routers, > 3. When the router sees one of these with a prefix that seems to > match part or all of one of the non local prefixes it was sent, > then that router will construct a loose source route message > that first goes to the site "nearby", then across the gateway, > and then to the all routers address, asking if any of them have > a faster way to X than through the top. > > This doesn't flood, it only goes where there are cross boundary > connections, and then only if the neighbor is in the destination > area. Comments? > The discovery mechanism implies that the routers are part of the same routing domain. If not then the discovery procedure will not create an adjacency through which routing information can be exchanged. The autonomy of routing domains will be important when there is wider use of policy based routeing to control the rources used by others. If they systems are part of the same domain, why would they use addresses allocated from different address allocation authorities? I do not think this is a practical way forward. Paul Jenkins 0171 250 6598 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 24 05:18:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08005; Sun, 24 Mar 96 05:18:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07999; Sun, 24 Mar 96 05:18:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24304; Sun, 24 Mar 1996 05:16:10 -0800 Received: by mercury.Sun.COM (Sun.COM) id FAA28832; Sun, 24 Mar 1996 05:16:10 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA22401; Sun, 24 Mar 1996 14:16:09 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA20475; Sun, 24 Mar 1996 14:16:04 +0100 Message-Id: <9603241316.AA20475@dxcoms.cern.ch> Subject: (IPng 1569) Re: IPv6 Regestries To: wessorh@ar.com (Rick H. Wesson) Date: Sun, 24 Mar 1996 14:16:04 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199603222115.NAA08866@ar.com> from "Rick H. Wesson" at Mar 22, 96 01:15:50 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 Rick, Read RFC 1881 for the official story. Brian Carpenter >--------- Text sent by Rick H. Wesson follows: > > > > Does anyone know what the requirements will be to > become a regestery? Will IANA decide who becomes a > registery? If so what will they use to decide who > is and is not allowed to become one. > > Thanks, > > -Rick > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 24 06:03:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08053; Sun, 24 Mar 96 06:03:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08047; Sun, 24 Mar 96 06:03:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25003; Sun, 24 Mar 1996 06:01:27 -0800 Received: by mercury.Sun.COM (Sun.COM) id GAA00266; Sun, 24 Mar 1996 06:01:28 -0800 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1570) Re: IPv6 Regestries To: wessorh@ar.com (Rick H. Wesson) Date: Sun, 24 Mar 1996 14:00:56 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199603222115.NAA08866@ar.com> from "Rick H. Wesson" at Mar 22, 96 01:15:50 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone know what the requirements will be to > become a regestery? Will IANA decide who becomes a > registery? If so what will they use to decide who > is and is not allowed to become one. and can they justify it in court ... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 24 18:43:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08240; Sun, 24 Mar 96 18:43:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08234; Sun, 24 Mar 96 18:42:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16490; Sun, 24 Mar 1996 18:40:50 -0800 Received: by mercury.Sun.COM (Sun.COM) id SAA21226; Sun, 24 Mar 1996 18:40:50 -0800 Received: (wessorh@localhost) by ar.com (8.6.11/8.6.5) id SAA12661; Sun, 24 Mar 1996 18:40:32 -0800 Date: Sun, 24 Mar 1996 18:40:32 -0800 (PST) From: "Rick H. Wesson" X-Sender: wessorh@ibd To: Brian Carpenter CERN-CN Cc: ipng@sunroof.eng.sun.com, iab@isi.edu, iana@isi.edu, iesg@cnri.reston.va.us Subject: (IPng 1571) Re: IPv6 Regestries In-Reply-To: <9603241316.AA20475@dxcoms.cern.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 1881 does not declare the procedure for application to become an IPv6 Regional or SubRegional Registery. Could anyone please state the procedure? Thanks, -Rick On Sun, 24 Mar 1996, Brian Carpenter CERN-CN wrote: > Rick, > > Read RFC 1881 for the official story. > > Brian Carpenter > > > >--------- Text sent by Rick H. Wesson follows: > > > > > > > > Does anyone know what the requirements will be to > > become a regestery? Will IANA decide who becomes a > > registery? If so what will they use to decide who > > is and is not allowed to become one. > > > > Thanks, > > > > -Rick > > ------------------------------------------------------------------------------ > > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > > IPng Home Page: http://playground.sun.com/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Mar 27 18:36:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10205; Wed, 27 Mar 96 18:36:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10199; Wed, 27 Mar 96 18:35:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00342; Wed, 27 Mar 1996 18:33:58 -0800 Received: by mercury.Sun.COM (Sun.COM) id SAA12784; Wed, 27 Mar 1996 18:33:58 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA28377; Wed, 27 Mar 1996 18:33:18 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 1996 18:36:31 -0800 To: mankin@isi.edu, sob@harvard.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1572) Request to Advance "A Method for the Transmission of IPv6 Packets over Token Ring Networks" Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : Path MTU Discovery for IP version 6 Author(s) : J. McCann, S. Deering Filename : draft-ietf-ipngwg-pmtuv6-01.txt Pages : 16 Date : 02/21/1996 The working group last call on this document ended on Thursday March 21, 1996. No comments were received during the working group last call. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 28 08:38:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10662; Thu, 28 Mar 96 08:38:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10656; Thu, 28 Mar 96 08:37:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22968; Thu, 28 Mar 1996 08:35:50 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA21677; Thu, 28 Mar 1996 08:35:48 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G105) id AA22700; Thu, 28 Mar 96 09:35:39 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA09743; Thu, 28 Mar 96 09:35:38 MST; for ipng@sunroof.eng.sun.com Message-Id: <9603281635.AA09743@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Thu, 28 Mar 1996 09:35:38 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Keith Sklower , ipng@sunroof.eng.sun.com Subject: (IPng 1573) Re: "adopting" getaddrinfo() Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, In your Internet draft (which has unfortunately expired) you also describe the getinfobysockaddr() function. This is a handy function that can be called from a protocol-independent function for logging purposes, and I think this function should also go into the sockets API along with the Posix.1g getaddrinfo(). (Posix.1g does not define anything like this getinfobysockaddr(), unfortunately.) But I just noticed that the first argument is a "struct sockaddr *" but there's no accompanying length field. This is fine with the newer sockaddr's that have their own length field, but the IPv6 API will not require this. Also as this function is defined it is the only sockets function (I think) that takes a pointer to a socket address structure without a corresponding length field. Shouldn't a new argument be added to specify the length? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Mar 28 08:58:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10689; Thu, 28 Mar 96 08:58:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10683; Thu, 28 Mar 96 08:58:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26214; Thu, 28 Mar 1996 08:56:17 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA28511; Thu, 28 Mar 1996 08:56:17 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA16179; Thu, 28 Mar 1996 08:55:37 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Mar 1996 08:58:50 -0800 To: mankin@isi.edu, sob@harvard.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1574) Request to Advance "Path MTU Discovery for IP version 6" Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us, hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The subject of the enclosed message should have been: "Request to Advance "Path MTU Discovery for IP version 6" Bob >X-Sender: hinden@mailhost.ipsilon.com >Mime-Version: 1.0 >Date: Wed, 27 Mar 1996 18:36:31 -0800 >To: mankin@isi.edu, sob@harvard.edu >From: hinden@Ipsilon.COM (Bob Hinden) >Subject: (IPng 1572) Request to Advance "A Method for the Transmission of >IPv6 Packets over Token Ring > Networks" >Cc: ipng@sunroof.Eng.Sun.COM, scoya@cnri.reston.va.us >Sender: owner-ipng@sunroof.Eng.Sun.COM >Precedence: bulk > > >The chairs of the IP Next Generation working group, on behalf of the >working group, request that the following document be published as a RFC >with Proposed Standard status: > > Title : Path MTU Discovery for IP version 6 > Author(s) : J. McCann, S. Deering > Filename : draft-ietf-ipngwg-pmtuv6-01.txt > Pages : 16 > Date : 02/21/1996 > >The working group last call on this document ended on Thursday March 21, >1996. No comments were received during the working group last call. > >Bob Hinden / Steve Deering > > > >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Mar 30 10:02:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12095; Sat, 30 Mar 96 10:02:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12089; Sat, 30 Mar 96 10:02:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25447; Sat, 30 Mar 1996 10:00:36 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA28130; Sat, 30 Mar 1996 10:00:37 -0800 Received: from [205.226.7.88] ([205.226.7.88]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA25549; Sat, 30 Mar 1996 10:00:24 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 30 Mar 1996 10:03:46 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1575) WG Last Call: "An IPv6 Provider-Based Unicast Address Format" Cc: hinden@Ipsilon.COM, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an ipng working group last call for comments on advancing the following document to Proposed Standard: Title : An IPv6 Provider-Based Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel Filename : draft-ietf-ipngwg-unicast-addr-fmt-03.txt Pages : 8 Date : 02/24/1996 Note: A new version of this document ( -04) will appear shortly which fixes some typographical errors. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end one weeks from today, on Friday April 5, 1996. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Mar 31 00:21:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12226; Sun, 31 Mar 96 00:21:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12220; Sun, 31 Mar 96 00:20:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21723; Sun, 31 Mar 1996 00:18:54 -0800 Received: by mercury.Sun.COM (Sun.COM) id AAA23542; Sun, 31 Mar 1996 00:18:40 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA21230; Sun, 31 Mar 1996 10:18:33 +0200 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA02550; Sun, 31 Mar 1996 10:18:27 +0200 Message-Id: <9603310818.AA02550@dxcoms.cern.ch> Subject: (IPng 1576) Re: WG Last Call: "An IPv6 Provider-Based Unicast Address Format" To: hinden@ipsilon.com (Bob Hinden) Date: Sun, 31 Mar 1996 10:18:27 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, hinden@ipsilon.com, deering@parc.xerox.com In-Reply-To: from "Bob Hinden" at Mar 30, 96 10:03:46 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 > This is an ipng working group last call for comments on advancing the > following document to Proposed Standard: > > Title : An IPv6 Provider-Based Unicast Address Format > Author(s) : Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel > Filename : draft-ietf-ipngwg-unicast-addr-fmt-03.txt I support this version for advancement Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com