From owner-ipng Fri Dec 1 01:10:58 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06110; Fri, 1 Dec 95 01:10:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06104; Fri, 1 Dec 95 01:10:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20037; Fri, 1 Dec 1995 01:11:16 -0800 Received: from ncc.ripe.net by mercury.Sun.COM (Sun.COM) id BAA13253; Fri, 1 Dec 1995 01:11:10 -0800 Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA26244 (5.65a/NCC-2.30); Fri, 1 Dec 1995 10:10:15 +0100 Message-Id: <9512010910.AA26244@ncc.ripe.net> To: rcoltun@fore.com (Robert Coltun) Cc: ipng@sunroof2.eng.sun.com, ospf@gated.cornell.edu From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 883) Re: OSPF Version 2 For IP Version 6 In-Reply-To: Your message of "Fri, 01 Dec 1995 00:55:48 EST." <9512010555.AA20561@marlin-atm.fore.com> Date: Fri, 01 Dec 1995 10:10:06 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Dec 95 00:55:48 EST Robert Coltun wrote: > Enclosed is OSPF Version 2 For IP Version 6 draft to be discussed > next week. As allways comments would be appreciated. I'm off to the airfield in one hour. I know of several people who are already travelling. Don't you think this draft is slightly late? Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 1 09:37:23 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06208; Fri, 1 Dec 95 09:37:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06041; Thu, 30 Nov 95 23:20:59 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14523; Thu, 30 Nov 1995 23:21:31 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id XAA02236; Thu, 30 Nov 1995 23:21:32 -0800 Received: from ruiner (ppp-pm01-dy-15.opr.oakland.edu [141.210.14.176]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id BAA19295; Fri, 1 Dec 1995 01:21:26 -0600 Received: by ruiner with Microsoft Mail id <01BABF93.B200BB00@ruiner>; Fri, 1 Dec 1995 02:21:17 -0500 Message-Id: <01BABF93.B200BB00@ruiner> From: Brad Wilson To: "'Ted Rohling'" Cc: "'ipng@sunroof2.eng.sun.com'" Subject: (IPng 884) Re: ICMPv6 Echo reply Date: Thu, 30 Nov 1995 18:35:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> OK---so is the "too big" messages counted as a ping response or as a "too >> big" message? If my ICMP request packets are too big for the network then I >> guess I just have to forget it and take it down a bit? A too big message is a too big message. You should not presume that it means anything else. -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetDisclaimer() { return CString("All I say is fact :-p"); } }; ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 4 13:29:55 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00282; Mon, 4 Dec 95 13:29:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00276; Mon, 4 Dec 95 13:29:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21209; Mon, 4 Dec 1995 13:30:04 -0800 Received: from mailrelay.ipsilon.com by mercury.Sun.COM (Sun.COM) id NAA04009; Mon, 4 Dec 1995 13:30:04 -0800 Received: from [206.103.69.204] (drop199.internetMCI.ietf.org [206.103.69.199]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id NAA20580; Mon, 4 Dec 1995 13:42:48 -0800 X-Sender: hinden@tester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Dec 1995 13:30:15 -0800 To: iesg@cnri.reston.va.us From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 885) Comments on "An IPv6 Provider-Based Unicast Address Format" Cc: ipng@sunroof.eng.sun.com, hinden@ipsilon.com, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have been informed by the IPng area directors that IESG did not approve "An IPv6 Provider-Based Unicast Address Format" for Proposed Standard. The IPng w.g. chairs disagree with the IESG comments and believe that this document should be advanced to Proposed Standard. The following comments were forwarded to us from the IPng area directors. Our response to the issues raised is interspersed in their comments. Our conclusion is at the end of this message. >>From kasten@mailserv-D.ftp.com Tue Nov 21 15:35:13 1995 >Date: Tue, 21 Nov 95 15:32:51 EST >To: sob@newdev.harvard.edu >Subject: Re: IPv6 addressing plan >From: kasten@ftp.com (Frank Kastenholz) >Reply-To: kasten@ftp.com >Sender: kasten@mailserv-D.ftp.com >Repository: mailserv-D.ftp.com, [message accepted at Tue Nov 21 15:32:45 1995] >Originating-Client: d-cell.ftp.com >Content-Length: 1442 > > > > Can those of you who had specifc comments on the IPv6 addressing > > plan please send them to me asap? I'd like to get the messsages > > back to the WG chairs soon. > >scott, here's what i sent with my discuss vote. > >if i remember, the real big issue was why we went on and specified >all the glop in the middle -- why not just specify that subscribers >should be able to get the low 64(?) bits for themselves, and let the >high 64 bits be an issue strictly for iana (it takes a prefix and >registry number for itself, allocates all of what's left (except the >low 64) to the registry, which takes some of the bits for itself and >allocates the rest to the provider... It is very important to specify the "glop in the middle". The most important reason is to insure that different providers utilize the address space efficiently. With no "standard" for doing this allocation it is likely that the address space will be used very inefficiently. The hierarchy in the address needs to be specified and can not be just left to "someone else" to do the right thing. This document is also consistent with "An Architecture for IPv6 Unicast Address Allocation" which the IESG approved for publication in September. It should be noted that the IANA has reviewed the document and that Jon Postel is one of the editors of the document. >===================================================================== > >why does this have to be a standard? why not a bcp? This issue was discussed previously by the working group. The working group concluded that it should be a standard because the document specifies fields sizes and values. Also, given that IPv6 is not widely deployed at this time, the specification for how to format provider based address can hardly be called "current practice". There was also the feeling that having this document a standard was an important prerequisite for deploying IPv6. >why do we have to specify anything beyond the registry portion -- >or can't we trust registries (etc) to properly subdivide >the bits. The motivation is that the registries need to have specific guidance as what to do. There needs to be a framework for them to operate in. Also as noted above, it is important that the registries use the addresses efficiently. >recurse this down -- why do we have to tell providers >that they must provde 64 bits to their subscribers? There are several reasons for this. The first is that we want to insure that subscribers have enough address space to use 48-bit MAC layer address for auto-configuration and still have enough address space left (16-bits) to create a local address hierarchy. Another reason is to insure that renumbering can work by requiring that all providers leave at least 64-bits of space for subscribers so the subscribers can switch to another provider and not have to change their local address hierarchy. Another reason is to give the subscribers enough address space to greatly reduce the need to renumber due to the growth of the subscriber. This was, of course, one of the reason to make IPv6 have bigger addresses in the first place. >this really >screws up, say, a simple dialup ppp provider where each subscriber >is one person with one machine and there needs to be only 1 bit >of address space, doesn't it? It does not screw up a simple dialup PPP provider at all. A dialup provider which obtains a provider identifier can give each dialup customer 64 bits of local address space (like any other provider customer). The fact that the customer might only use one address does not create any problems for the provider and, of course, allows the customer to grow. It is also possible for a dialup provider to only get a subscriber identifier and use the local part of the address to both create its own routing hierarchy and give a smaller number of bits to each customer. Again this does not create any problems for the provider. >as long as we are into writing excessive specifications, what is a >registry? Registries are defined in "An Architecture for IPv6 Unicast Address Allocation" which the IESG approved for publication as an Informational RFC in September. >aren't we falling into _exactly_ the same trap that people fell into 15 >years ago when they said 'we only need 8 bits of network number' The problems in IPv4 with the classfull addresses was that the routers and the hosts knew about the boundaries in the addresses. That is not true with IPv6 addresses. The boundaries are an administrative structure that can be changed without changing any software in hosts and routers if that should ever become necessary. It should be also noted that this document only specifies the use of a small percentage of the overall IPv6 address space. As we learn more from experience with this approach we can design other allocation schemes. >Frank Kastenholz > > > >>From Harald.T.Alvestrand@uninett.no Wed Nov 22 06:01:58 1995 >From: Harald.T.Alvestrand@uninett.no >X-Mailer: exmh version 1.6.2 7/18/95 >To: Scott Bradner >Subject: Re: IPv6 addressing plan >In-reply-to: Your message of "Tue, 21 Nov 1995 11:31:59 EST." ><199511211631.LAA19769@newdev.harvard.edu> >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Date: Wed, 22 Nov 1995 12:02:23 +0100 >Sender: Harald.T.Alvestrand@uninett.no > >My comments: > >- There are no RES bits between Registry and Provider. > I would prefer to make these one field, and let the IANA decide > how many bits to use for each Registry's prefix. The IANA has reviewed this document and found the current scheme satisfactory. While the number of users/subscribers/providers in the internet is growing exponentially, the number of continents, geographical regions, and countries is not growing at the same rate. It was felt that the size of the registry field was adequate. There is also a line of thought that the registry field is unnecessary (because it is not used for routing) and the same thing could be accomplished by allocating blocks of provider addresses to individual registries (in much the same manner as IP network addresses are assigned to providers in CIDR). The inclusion of the registry field in some sense represents a consensus between two points of view in the working group. Also, because registry is not used for routing it should be kept as small as possible. > Another part of the document already does this (subregistries); > we might as well be consistent. The motivation was that not every registry will need to have national registries. They can be used were appropriate. Hence the current treatment in the document. >- There is no language saying who decides if the RES fields must be > used; is this done Internet-wide by the IESG, IANA or ISOC, or is > it done per registry/provider? In this case, are they really Reserved? The intent was that the IANA was responsible for the RES fields. If this is not clear in the document it should be fixed. >- I think this should be a BCP. Please see previous comments on same topic. >That's all....I said "no objection" to the document as it was, but >if we are going to recycle, we might as well get this handled. > > Harald The IPng w.g. chairs believe that the comments received reflect a misunderstanding of the motivations for the design choices. We would like the IESG to reconsider this document based on these comments. Bob Hinden / Steve Deering IPng Working Group Chairs ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 5 13:46:57 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00936; Tue, 5 Dec 95 13:46:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00930; Tue, 5 Dec 95 13:46:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17271; Tue, 5 Dec 1995 13:47:11 -0800 Received: from mailrelay.ipsilon.com by mercury.Sun.COM (Sun.COM) id NAA03110; Tue, 5 Dec 1995 13:47:11 -0800 Received: from [206.103.69.197] (drop195.internetMCI.ietf.org [206.103.69.195]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id NAA24406; Tue, 5 Dec 1995 13:59:25 -0800 X-Sender: hinden@tester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Dec 1995 13:46:49 -0800 To: sob@harvard.edu, mankin@isi.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 886) Request for Advancement of IPng IPv6overEthernet Document Cc: hinden@ipsilon.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Allison and Scott, 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 Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-ethernet-ntwrks-01.txt Pages : 4 Date : 10/10/1995 No comments on this document were received during the Working Group Last Call which ended on November 27, 1995. The decision to move this document forward was also confirmed at the IPng working group meeting held today at the Dallas IETF meeting. Bob Hinden / Steve Deering IPng Working Group Chairs ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 5 13:51:18 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00956; Tue, 5 Dec 95 13:51:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00947; Tue, 5 Dec 95 13:51:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17920; Tue, 5 Dec 1995 13:51:26 -0800 Received: from mailrelay.ipsilon.com by mercury.Sun.COM (Sun.COM) id NAA04364; Tue, 5 Dec 1995 13:51:23 -0800 Received: from [206.103.69.197] (drop195.internetMCI.ietf.org [206.103.69.195]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id NAA24403; Tue, 5 Dec 1995 13:59:21 -0800 X-Sender: hinden@tester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Dec 1995 13:46:46 -0800 To: sob@harvard.edu, mankin@isi.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 887) Request for Advancement of IPng Neighbor Discovery Document Cc: hinden@ipsilon.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Allison and Scott, 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 : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : T. Narten, E. Nordmark, W. Simpson Filename : draft-ietf-ipngwg-discovery-03.txt Pages : 86 Date : 11/17/1995 No comments on this document were received during the Working Group Last Call which ended on December 3, 1995. The decision to move this document forward was also confirmed at the IPng working group meeting held today at the Dallas IETF meeting. Bob Hinden / Steve Deering IPng Working Group Chairs ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 5 15:53:57 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01185; Tue, 5 Dec 95 15:53:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01179; Tue, 5 Dec 95 15:53:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06095; Tue, 5 Dec 1995 15:54:08 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id PAA01260; Tue, 5 Dec 1995 15:54:00 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id AAA06611 for ; Wed, 6 Dec 1995 00:53:58 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id AAA16794 for ; Wed, 6 Dec 1995 00:53:57 +0100 Message-Id: <199512052353.AAA16794@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: (IPng 888) multihomed model Date: Wed, 06 Dec 1995 00:53:56 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe one of the issues for multihomed is the choice of the model as described in RFC 1122 Requirements of Internet Hosts, 3.3.4 Local Multihoming, page 59... Francis.Dupont@inria.fr PS: here is the text: There are two key requirement issues related to multihoming: (A) A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. (B) A host MAY restrict itself to sending (non-source- routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams. DISCUSSION: Internet host implementors have used two different conceptual models for multihoming, briefly summarized in the following discussion. This document takes no stand on which model is preferred; each seems to have a place. This ambivalence is reflected in the issues (A) and (B) being optional. o Strong ES Model The Strong ES (End System, i.e., host) model emphasizes the host/gateway (ES/IS) distinction, and would therefore substitute MUST for MAY in issues (A) and (B) above. It tends to model a multihomed host as a set of logical hosts within the same physical host. With respect to (A), proponents of the Strong ES model note that automatic Internet routing mechanisms could not route a datagram to a physical interface that did not correspond to the destination address. Under the Strong ES model, the route computation for an outgoing datagram is the mapping: route(src IP addr, dest IP addr, TOS) -> gateway Here the source address is included as a parameter in order to select a gateway that is directly reachable on the corresponding physical interface. Note that this model logically requires that in general there be at least one default gateway, and preferably multiple defaults, for each IP source address. o Weak ES Model This view de-emphasizes the ES/IS distinction, and would therefore substitute MUST NOT for MAY in issues (A) and (B). This model may be the more natural one for hosts that wiretap gateway routing protocols, and is necessary for hosts that have embedded gateway functionality. The Weak ES Model may cause the Redirect mechanism to fail. If a datagram is sent out a physical interface that does not correspond to the destination address, the first-hop gateway will not realize when it needs to send a Redirect. On the other hand, if the host has embedded gateway functionality, then it has routing information without listening to Redirects. In the Weak ES model, the route computation for an outgoing datagram is the mapping: route(dest IP addr, TOS) -> gateway, interface ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 5 16:06:43 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01200; Tue, 5 Dec 95 16:06:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01194; Tue, 5 Dec 95 16:06:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08662; Tue, 5 Dec 1995 16:06:50 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id QAA04647; Tue, 5 Dec 1995 16:06:51 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id TAA12655; Tue, 5 Dec 1995 19:05:41 -0500 (EST) Date: Tue, 5 Dec 1995 19:05:41 -0500 (EST) From: Scott Bradner Message-Id: <199512060005.TAA12655@newdev.harvard.edu> To: hinden@ipsilon.com, mankin@isi.edu, sob@harvard.edu Subject: (IPng 889) Re: Request for Advancement of IPng IPv6overEthernet Document Cc: deering@parc.xerox.com, ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Can you please issue a last call for this? thanks Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 6 13:38:28 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01665; Wed, 6 Dec 95 13:38:28 PST Received: from snail.Sun.COM by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01649; Wed, 6 Dec 95 13:30:53 PST Received: from mercury.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA14343; Wed, 6 Dec 95 13:31:19 PST Received: from lillen.Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id NAA09321; Wed, 6 Dec 1995 13:31:17 -0800 Received: by lillen.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id UAA00320; Tue, 5 Dec 1995 20:59:27 -0800 Date: Tue, 5 Dec 1995 20:59:27 -0800 From: nordmark@lillen (Erik Nordmark) Message-Id: <199512060459.UAA00320@lillen.Eng.Sun.COM> To: mccann@zk3.dec.com, deering@parc.xerox.com Subject: (IPng 890) Comments on draft-ietf-ipngwg-pmtuv6-00.txt Cc: ipng@sunroof.Eng, nordmark@Eng Reply-To: nordmark@Eng Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The specification needs to include this from the IPv6 base secification: "In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next- Hop MTU less than 576. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 576, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 528 octets (576 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used." If path MTU discovery includes the flow ID in the path specification it would seem that for consistency we should have flow specific redirects in IPv6. Or is it the case that the router to router path can depend on the flow id but the first hop router can not depend on the flow id? Editorial suggestions and nits: It might make sense to add a section "comparison with IPv4" listing what was specified at the WG meeting to aid readers and implementors that are familiar with IPv4 path mtu discovery. It might make sense to add the definitions of path MTU and link MTU up front (for readers that are not familiar with IPv4 path mtu discovery). Section 3 has a reference to [IPv6] but the references section list the document as [IPv6-SPEC]. The last paragraph in section 3: Would it make sense to clarify it by saying "or the result of having multiple paths with different PMTU to the destination"? Section 4.2: There are references to "subnet routes" which should probably be replaced by "prefix routes". Also, it might make sense to use the neighbor discovery terminology of "destination cache" etc. Section 4.5: Since NFS and Sun RPC operate over both TCP and UDP it would make sense to add "over UDP" to the second paragraph. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 8 10:00:54 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03143; Fri, 8 Dec 95 10:00:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03137; Fri, 8 Dec 95 10:00:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03692; Fri, 8 Dec 1995 10:01:02 -0800 Received: from ftp.com by mercury.Sun.COM (Sun.COM) id KAA16620; Fri, 8 Dec 1995 10:01:03 -0800 Received: from ftp.com by ftp.com ; Fri, 8 Dec 1995 13:01:01 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 8 Dec 1995 13:01:01 -0500 Received: from mccoy (drop004.internetMCI.ietf.org) by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12310; Fri, 8 Dec 95 12:57:52 EST Message-Id: Priority: Normal To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 891) IPv6 list Date: Fri, 08 Dec 95 13:05:31 EST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks -- The address for the ipv6 mib list was correct -- ip6mib@research.ftp.com= with the usual '-request' address to join/leave. The archive is at ftp://research= .ftp.com/pub/ip6mib/archive and is pretty short. The discussion that we had shortly after the San Jose meeting had more to do with the representa= tion of network addresses rather than packet in/out counts so I guess we could start a discussion with Dmitry sending his mib to the list. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 10 14:32:53 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04261; Sun, 10 Dec 95 14:32:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04255; Sun, 10 Dec 95 14:32:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26148; Sun, 10 Dec 1995 14:32:56 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id OAA16622; Sun, 10 Dec 1995 14:32:57 -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 OAA17618; Sun, 10 Dec 1995 14:32:48 -0800 X-Sender: hinden@tester.ipsilon.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Dec 1995 14:33:36 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 892) WG last call: IPv6 over FDDI 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 : A Method for the Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-fddi-ntwrks-01.txt Pages : 6 Date : 11/06/1995 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two weeks from today, on Saturday December 22. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 11 13:06:06 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04925; Mon, 11 Dec 95 13:06:06 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04919; Mon, 11 Dec 95 13:05:51 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA10738; Mon, 11 Dec 1995 13:05:53 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10984; Mon, 11 Dec 1995 13:06:07 -0800 Date: Mon, 11 Dec 1995 13:06:07 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512112106.NAA10984@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 893) Re: WG last call: IPv6 over FDDI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Filename : draft-ietf-ipngwg-fddi-ntwrks-01.txt I talked to Matt at the IETF about some concerns I had with the completeness and robustness of the "interaction with bridges" proposal in this document. Until these issues are addressed the document should not go to proposed standard. The issues are: - The proposal does not specify what MTU to use for multicast packets. (An FDDI node could be sending a multicast packet with receivers on the Ethernet side without ever having received a packet from the Ethernet side of the bridge.) - The proposal only specifies how the MTU is determined when Neighbor Discovery packets for node X are received from node X. Thus it does not handle the case of a redirect message where node Y passes on X's link layer address. - The proposal does not specify the MTU used for Neighbor Discovery packets - presumably this has to be the lower MTU to ensure that the ND messages can always cross the bridge. The discussion with Matt resulted in a more robust idea for handling bridges that would address my concern: - The routers have to be configured to send out MTU options specifying the lower MTU. This will ensure that the default operation (including multicast) will be to use a working MTU. - Receipt of the specified the frame priority field value in a ND packet can make a node increase its MTU for sending to originator of the ND packet. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 12 13:24:14 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05611; Tue, 12 Dec 95 13:24:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05605; Tue, 12 Dec 95 13:23:59 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11278; Tue, 12 Dec 1995 13:24:15 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id NAA03504; Tue, 12 Dec 1995 13:24:14 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HYQ3KAL2I8002PNK@FNAL.FNAL.GOV>; Tue, 12 Dec 1995 15:24:07 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA06126; Tue, 12 Dec 95 15:22:29 CST Date: Tue, 12 Dec 1995 15:22:29 -0600 From: Matt Crawford Subject: (IPng 894) Re: WG last call: IPv6 over FDDI In-Reply-To: Your message of Sun, 10 Dec 95 14:33:36 PST. To: hinden@Ipsilon.COM (Bob Hinden) Cc: ipng@sunroof.eng.sun.com Message-Id: <9512122122.AA06126@munin.fnal.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mimeprimaryboundary Content-Description: Final(?) draft of IPV6-over-FDDI Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain Bob, et al. I just sent the following version of IPv6-over-FDDI to the internet-drafts editor. Matt Crawford --mimeprimaryboundary Content-Type: message/external-body; access-type="anon-ftp"; site="munin.fnal.gov"; directory="pub"; name="draft-ietf-ipngwg-fddi-ntwrks-02.txt" Content-Description: draft-ietf-ipngwg-fddi-ntwrks-02.txt Content-Type: text/plain --mimeprimaryboundary-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 13 05:23:19 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05849; Wed, 13 Dec 95 05:23:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05843; Wed, 13 Dec 95 05:23:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13443; Wed, 13 Dec 1995 05:23:18 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id FAA03042; Wed, 13 Dec 1995 05:23:18 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08642; 13 Dec 95 7:39 EST To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: IESG Secretary Subject: (IPng 895) Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Date: Wed, 13 Dec 95 07:39:17 -0500 Message-Id: <9512130739.aa08642@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 Ethernet 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 December 26, 1995. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 13 06:08:16 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05911; Wed, 13 Dec 95 06:08:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05905; Wed, 13 Dec 95 06:08:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15047; Wed, 13 Dec 1995 06:08:17 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id GAA08207; Wed, 13 Dec 1995 06:08:17 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08818; 13 Dec 95 7:45 EST To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: IESG Secretary Subject: (IPng 896) Last Call: Neighbor Discovery for IP Version 6 (IPv6) to Proposed Standard Date: Wed, 13 Dec 95 07:45:44 -0500 Message-Id: <9512130745.aa08818@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 "Neighbor Discovery for IP Version 6 (IPv6)" 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 December 26, 1995. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 13 15:44:07 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06358; Wed, 13 Dec 95 15:44:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06352; Wed, 13 Dec 95 15:43:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13675; Wed, 13 Dec 1995 15:44:09 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id PAA18255; Wed, 13 Dec 1995 15:44:06 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id SAA18372; Wed, 13 Dec 1995 18:43:51 -0500 Message-Id: <199512132343.SAA18372@borg.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Dec 1995 18:42:43 -0500 To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 897) IPv6 over Token Ring Cc: twarwick@madge.com, adraper@madge.com, i802@msg.ti.com, Ray.Samora@proteon.com, John.Messenger@proteon.com, ead@unh.edu, rvslager@vnet.ibm.com, preiss@vnet.ibm.com, George_lin@3mail.3com.com, fxl@3com.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gentle Readers: Here's the latest draft of the IPv6 over Token Ring spec. Major changes from the previous version include new and improved multicast address mapping and updated text on MTU. I've not submitted this to the I-D editor to give it a day or so to percolate on the list. Absent objections, though, I'll do so at the end of the week. [The CC's in this message are those folks from the 802.5 committee that have helped with the draft. If it matters to you, take care to whom you send responses.] Internet Engineering Task Force Stephen Thomas INTERNET DRAFT AT&T Tridom December 13, 1995 A Method for the Transmission of IPv6 Packets over Token Ring Networks Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Introduction This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Token Ring networks [802.5]. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on a Token Ring. The memo concludes with a description of the mapping of IPv6 multicast addresses to Token Ring functional addresses. IPv6 Encapsulation IPv6 packets are transmitted in LLC/SNAP frames, using long-format (48 bit) addresses. The data field contains the IPv6 header and payload. The following figure shows a complete 802.5 frame containing an IPv6 datagram. Thomas Expires June 1996 [Page 1] INTERNET-DRAFT IPv6 over Token Ring December 13, 1995 +-------+-------+-------+-------+ | SD | AC | FC | | +-----------------------+ | | Destination Address | | +-----------------------+ | | Source | +-------+ Address +-------+ | | DSAP | +-------+-------+-------+-------+ | SSAP | CTL | OUI | +-------+-------+-------+-------+ | OUI | EtherType | | +-------+---------------+ | | | ~ IPv6 header and payload... ~ | | +-------------------------------+ | FCS | +-------+-------+---------------+ | ED | FS | +-------+-------+ In the presence of source route bridges, a routing information field (RIF) may appear immediately after the source address. A RIF is present in frames when the most significant bit of the source address is set to one. Token Ring Header Fields SD - Starting Delimiter AC - Access Control FC - Frame Control Destination Address - 48-bit IEEE address of destination station Source Address - 48-bit IEEE address of source station DSAP - Destination Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA) SSAP - Source Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA) Thomas Expires June 1996 [Page 2] INTERNET-DRAFT IPv6 over Token Ring December 13, 1995 CTL - Control Field (for Unnumbered Information, shall always contain the value 0x03) OUI - Organizationally Unique Identifier (for EtherType encoding, shall always contain the value 0x000000) EtherType - Protocol type of encapsulated payload (for IPv6, shall always contain the value 0x86DD) FCS - Frame Check Sequence ED - Ending Delimiter FS - Frame Status Maximum Transmission Unit IEEE 802.5 networks have a maximum frame size based on the maximum time a node may hold the token. This time depends on many factors including the data signaling rate and the number of nodes on the ring. Because the maximum frame size varies, implementations must rely on static configuration or router advertisements [DISC] to determine actual MTU sizes. Common default values include approximately 2000, 4000, and 8000 octets. In an environment using source route bridging, the process of discovering the MAC-level path to a neighbor can yield the MTU for the path to that neighbor. The information is contained in the largest frame (LF) subfield of the routing information field. This field limits the size of the information field of frames to that destination, and that information field includes both the LLC [802.2] header and the IPv6 datagram. Since, for IPv6, the LLC header is always 8 octets in length, the IPv6 MTU can be found by subtracting 8 from the maximum frame size defined by the LF subfield. If an implementation uses this information to determine MTU sizes, it must maintain separate MTU values for each neighbor. A detailed list of the LF values and the resulting maximum frame size can be found in [802.1D]. To illustrate the calculation of IPv6 MTU, the following table lists several common values. LF (base) LF (extension) MAC MTU IP MTU 000 000 516 508 001 000 1470 1462 010 000 2052 2044 011 000 4399 4391 Thomas Expires June 1996 [Page 3] INTERNET-DRAFT IPv6 over Token Ring December 13, 1995 100 000 8130 8122 101 000 11407 11399 110 000 17749 17741 111 000 41600 41592 Stateless Autoconfiguration and Link-local Addresses The address token [CONF] for a Token Ring interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order. A different MAC address set manually or by software should not be used as the address token. An IPv6 address prefix used for stateless autoconfiguration of a Token Ring interface must be 80 bits in length. The IPv6 Link-local address [AARCH] for a Token Ring interface is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80::. +-------+-------+-------+-------+ | FE 80 00 00 | +-------+-------+-------+-------+ | 00 00 00 00 | +-------+-------+-------+-------+ | 00 00 | | +-------+-------+ | | Token Ring Address | +-------+-------+-------+-------+ Address Mapping - Unicast The procedure for mapping IPv6 addresses into Token Ring link layer addresses is described in [DISC]. The Source/Target Link Layer Address option has the following form when the link layer is Token Ring. +-------+-------+-------+-------+ | Type |Length | | +-------+-------+ | | Token Ring Address | +-------+-------+-------+-------+ Option Fields: Type 1 for Source Link Layer Address 2 for Target Link Layer Address Thomas Expires June 1996 [Page 4] INTERNET-DRAFT IPv6 over Token Ring December 13, 1995 Length 1 (in units of 8 octets) Token Ring Address The 48-bit IEEE 802 address, in canonical bit order. Address Mapping - Multicast All IPv6 packets with multicast destination addresses are transmitted to Token Ring functional addresses. The following table shows the specific mapping between the IPv6 addresses and Token Ring functional addresses (in canonical form). Note that protocols other than IPv6 may use these same functional addresses, so all Token Ring frames destined to these functional addresses are not guaranteed to be IPv6 datagrams. MAC Func Addr (canonical) IPv6 Multicast Addresses 03 00 80 00 00 00 all nodes (FF0X::1) and solicited node (FF02::1:XXXX:XXXX) addresses 03 00 40 00 00 00 all routers addresses (FF0X::2) 03 00 00 80 00 00 any other multicast address with three least significant bits = 000 03 00 00 40 00 00 any other multicast address with three least significant bits = 001 03 00 00 20 00 00 any other multicast address with three least significant bits = 010 03 00 00 10 00 00 any other multicast address with three least significant bits = 011 03 00 00 08 00 00 any other multicast address with three least significant bits = 100 03 00 00 04 00 00 any other multicast address with three least significant bits = 101 03 00 00 02 00 00 any other multicast address with three least significant bits = 110 03 00 00 01 00 00 any other multicast address with three least significant bits = 111 Thomas Expires June 1996 [Page 5] INTERNET-DRAFT IPv6 over Token Ring December 13, 1995 Security Considerations Security considerations are not addressed in this memo. References [802.1D] IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges. ANSI/IEEE Std 802.1D, 1993 Edition. [802.2] IEEE Standards for Local Area Networks: Logical Link Control. ANSI/IEEE Std 802.2-1985. [802.5] IEEE Standards for Local Area Networks: Token Ring Access Method and Physical Layer Specifications. IEEE Std 802.5-1989. [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. Currently draft-ietf-ipngwg-addr-arch-03.txt. [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. Currently draft-ietf-addrconf-ipv6-03.txt. [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery for IP Version 6 (IPv6). Currently draft-ietf-ipngwg- discovery-01.txt. [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. Currently draft-ietf-ipngwg-ipv6-spec-02.txt. Author's Address Stephen Thomas AT&T Tridom Phone: (770) 514-3522 840 Franklin Court Fax: (770) 514-3491 Marietta, GA 30067 USA Email: stephen.thomas@tridom.com Thomas Expires June 1996 [Page 6] ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 13 16:24:23 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06414; Wed, 13 Dec 95 16:24:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06408; Wed, 13 Dec 95 16:24:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20025; Wed, 13 Dec 1995 16:24:26 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id QAA28075; Wed, 13 Dec 1995 16:24:24 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA29467; Wed, 13 Dec 1995 19:15:51 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA03846; Wed, 13 Dec 1995 19:15:50 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id AAA13125; Thu, 14 Dec 1995 00:27:16 GMT Message-Id: <199512140027.AAA13125@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Stephen Thomas Cc: ipng@sunroof.eng.sun.com Subject: (IPng 898) Re: IPv6 over Token Ring In-Reply-To: Your message of "Wed, 13 Dec 1995 18:42:43 EST." <199512132343.SAA18372@borg.mindspring.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Thu, 14 Dec 1995 00:27:15 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In <199512132343.SAA18372@borg.mindspring.com> , you wrote: 03 00 80 00 00 00 all nodes (FF0X::1) and solicited node (FF02::1:XXXX:XXXX) addresses What is the rationale for including the solicated node multicasts in this bucket rather than spreading them out over the other 8 functional addresses? 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/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 13 18:03:56 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06482; Wed, 13 Dec 95 18:03:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06476; Wed, 13 Dec 95 18:03:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03089; Wed, 13 Dec 1995 18:03:59 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id SAA18995; Wed, 13 Dec 1995 18:04:00 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15326(5)>; Wed, 13 Dec 1995 18:03:35 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 13 Dec 1995 18:03:26 -0800 To: ipng@sunroof.eng.sun.com Cc: deering@parc.xerox.com Subject: (IPng 899) IPv6 and ICMPv6 specs Date: Wed, 13 Dec 1995 18:03:11 PST From: Steve Deering Message-Id: <95Dec13.180326pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I mentioned at the first ipngwg meeting in Dallas that there were a number of previously agreed-upon changes that were incorporated into the base IPv6 spec and the ICMPv6 spec that were submitted to the RFC Editor. Since it may take a couple weeks for the RFCs to appear, and a number of you are trying to get implementations ready for the upcoming UNH testing, I have made the submitted manuscripts available for anonymous FTP from: ftp://parcftp.xerox.com/pub/ipng/submitted-ipv6-rfc ftp://parcftp.xerox.com/pub/ipng/submitted-icmpv6-rfc When the official RFCs appear, I will delete these copies, and you should do the same and fetch the real RFCs, which will contain at least one difference from these copies: they will have official RFC numbers! The RFCs will not contain the traditional "Changes from the Previous Draft" appendices, since it is inappropriate for an RFC to reference an Internet Draft. Therefore, I am including the list of changes since the last published draft of each, below. Please pay special attention to the Routing Header and Fragment Header sections of the IPv6 spec, which underwent major revision. Steve ----------- Changes from draft-ietf-ipngwg-ipv6-spec-02.txt, June 19, 1995: o Revised abstract. o In the Terminology section, added a Note about hybrid host/routers, i.e., nodes configured to forward packets received from some, but not all, interfaces. o Explicitly specified that extension headers and options must be processed strictly in the order they appear a packet. o In the description of the two high-order bits of Option Types, explicitly stated that the sending of an ICMP Parameter Problem message in response to an unrecognized 10... Option Type occurs regardless of whether or not the containing packet was destined to a multicast address. This is a clarification, not a change. o In the description of the third-highest-order bit of Option Types, made it clear that the entire Option Data field of options that can change en-route must be treated as zero octets when computing a packet authenticator (i.e., when using an Authentication header). o In the description of the Jumbo Payload option, made it clearer that the Jumbo Payload Length includes the length of the Hop-by-Hop Options header. o Changed the Routing header to enable unknown types of routing headers to be ignored by final destination nodes. This caused a major revision of the Routing header section. Also added an example showing how the header fields change on each segment of a route. o Description of fragmentation rewritten, and changed to remove the Fragment Next Header field from the set of fields that must be checked for equality in all fragments making up the same original packet. Also, specified reassembly error handling, including reassembly time-out. o Added requirement that all nodes be able to accept fragmented packets that, after reassembly and discard of the Fragment header, are as large as 1500 octets. o Deleted note about IPv4's minimum MTU and and minimum reassembly buffer size. o In the Flow Labels section, added the priority field to the list of fields that must remain the same for all packets in the same flow. o In the "Formatting Guidelines for Options" appendix, corrected two instances of "Hdr Ext Len=1" to "Hdr Ext Len=3". o Deleted "Changes from Previous Draft" appendix. o Supplied RFC numbers for the ipsec references, and added a reference to the ipsec architecture document (RFC-1825). o Fixed a few typos. ------------- Changes from draft-ietf-ipngwg-icmp-02.txt, June 1995: o Added text about ICMP error messages for which the upper-layer protocol cannot be identified, due to truncation to fit the 576-octet limit for error message packets. o Deleted description of pseudo-header, replacing it with a reference to the description in the IPv6 spec. o Corrected example of usage of the pointer in the Parameter Problem message (changed "48" to "40"). o Added the second exception to the "no ICMP error messages in response to multicasts" rule, which is "unrecognied option" Parameter Problem messages in response to options whose high-order bits are 10. o Changed name of "Group Membership Termination" message to "Group Membership Reduction". ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 13 18:16:23 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06499; Wed, 13 Dec 95 18:16:23 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06493; Wed, 13 Dec 95 18:16:08 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA05475; Wed, 13 Dec 1995 18:16:06 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA17669; Wed, 13 Dec 1995 18:16:20 -0800 Date: Wed, 13 Dec 1995 18:16:20 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512140216.SAA17669@bobo.eng.sun.com> To: sthomas@mindspring.com Subject: (IPng 900) Re: IPv6 over Token Ring Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maximum Transmission Unit > > IEEE 802.5 networks have a maximum frame size based on the maximum > time a node may hold the token. This time depends on many factors > including the data signaling rate and the number of nodes on the > ring. Because the maximum frame size varies, implementations must > rely on static configuration or router advertisements [DISC] to > determine actual MTU sizes. Common default values include > approximately 2000, 4000, and 8000 octets. In order to aid interoperability on a link with no routers I think you should specify a default value (that can be overridden by an MTU option in a router advertisement). Is it safe to make the default the smallest used MTU? Also, is there a hard upper bound imposed by 802.5 for the MTU? If so it should be specified. > In an environment using source route bridging, the process of > discovering the MAC-level path to a neighbor can yield the MTU for > the path to that neighbor. The information is contained in the > largest frame (LF) subfield of the routing information field. This > field limits the size of the information field of frames to that > destination, and that information field includes both the LLC > [802.2] header and the IPv6 datagram. Since, for IPv6, the LLC > header is always 8 octets in length, the IPv6 MTU can be found by > subtracting 8 from the maximum frame size defined by the LF > subfield. If an implementation uses this information to determine > MTU sizes, it must maintain separate MTU values for each neighbor. I don't understand the details of token ring source routing. Would this source route bridging feature be used for multicast packets as well as unicast packets? If not it would make sense to state that multicast never uses this feature. Independent of that I think you need to specify - the precedence of MTU information from different sources; a default value, information learned from router advertisements, and information from the LF field. - which of the MTU sources that can increase and which can decrease the MTU. > Stateless Autoconfiguration and Link-local Addresses > > The address token [CONF] for a Token Ring interface is the > interface's built-in 48-bit IEEE 802 address, in canonical bit > order. A different MAC address set manually or by software should > not be used as the address token. I think the IEEE 802 specifications say that addresses are assigned to stations and not to interfaces. I don't want the above statement to preclude an IPv6 implementation that assigns IEEE addresses to each station (and not to each interface). > [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. > Currently draft-ietf-addrconf-ipv6-03.txt. > > [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery > for IP Version 6 (IPv6). Currently draft-ietf-ipngwg- > discovery-01.txt. The revision numbers on the above (and possibly other) drafts are old. ND is -03. Addrconf is -06. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 14 10:40:03 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06944; Thu, 14 Dec 95 10:40:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06938; Thu, 14 Dec 95 10:39:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12018; Thu, 14 Dec 1995 10:39:59 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id KAA12789; Thu, 14 Dec 1995 10:40:01 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12863; 14 Dec 95 9:55 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 901) I-D ACTION:draft-ietf-ipngwg-fddi-ntwrks-02.txt Date: Thu, 14 Dec 95 09:55:50 -0500 Message-Id: <9512140955.aa12863@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. Title : A Method for the Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-fddi-ntwrks-02.txt Pages : 6 Date : 12/13/1995 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-fddi-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 (192.12.192.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-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: <19951213152328.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-fddi-ntwrks-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951213152328.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/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 14 11:51:09 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07091; Thu, 14 Dec 95 11:51:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07085; Thu, 14 Dec 95 11:50:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24458; Thu, 14 Dec 1995 11:51:09 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id LAA05046; Thu, 14 Dec 1995 11:51:09 -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 LAA29804; Thu, 14 Dec 1995 11:51:08 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Dec 1995 11:52:00 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 902) Continuation of WG last call: IPv6 over FDDI Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new draft for IPv6 over FDDI is now in the Internet Draft directories. The new draft reflects the comments received to date on the last call. The new draft is: Title : A Method for the Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-fddi-ntwrks-02.txt Pages : 6 Date : 12/13/1995 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. The last call period for this document ends on Saturday December 23 (the original last call announcement specified the 12/22, which was an error). Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 14 12:07:48 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07153; Thu, 14 Dec 95 12:07:48 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07147; Thu, 14 Dec 95 12:07:33 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA19452; Thu, 14 Dec 1995 12:07:30 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18069; Thu, 14 Dec 1995 12:07:45 -0800 Date: Thu, 14 Dec 1995 12:07:45 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512142007.MAA18069@bobo.eng.sun.com> To: iesg@cnri.reston.va.us Subject: (IPng 903) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to see to move to proposed comments if it can address this minor comment. The specification reads as if IEEE addresses are assigned to interfaces and the last time I read the IEEE 802 specifications they were referring to "stations". I do not want to preclude an IPv6 implementation that assigns IEEE addresses to each station (and not to each interface). For example, every Sun workstation shipped to date has one Ethernet address assigned to the box which is used for all interfaces. The particular text is: "Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token." The above text implies that each interface has a built-in IEEE 802 address. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 14 12:16:27 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07188; Thu, 14 Dec 95 12:16:27 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07182; Thu, 14 Dec 95 12:16:12 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA19690; Thu, 14 Dec 1995 12:16:09 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18075; Thu, 14 Dec 1995 12:16:24 -0800 Date: Thu, 14 Dec 1995 12:16:24 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512142016.MAA18075@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 904) Re: Continuation of WG last call: IPv6 over FDDI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The comment I just made on the "IPv6 over Ethernet" specification also applies to the FDDI spec (included below). Also, I the control-L page breaks seem to have been replaced by "=0C" for both drafts. Erik ----- Begin Included Message ----- >From owner-ipng@sunroof Thu Dec 14 12:12 PST 1995 Date: Thu, 14 Dec 1995 12:07:45 -0800 From: nordmark@caribe-86 (Erik Nordmark) To: iesg@cnri.reston.va.us Subject: (IPng 903) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 I'd like to see to move to proposed comments if it can address this minor comment. The specification reads as if IEEE addresses are assigned to interfaces and the last time I read the IEEE 802 specifications they were referring to "stations". I do not want to preclude an IPv6 implementation that assigns IEEE addresses to each station (and not to each interface). For example, every Sun workstation shipped to date has one Ethernet address assigned to the box which is used for all interfaces. The particular text is: "Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token." The above text implies that each interface has a built-in IEEE 802 address. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 14 12:21:23 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07201; Thu, 14 Dec 95 12:21:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07195; Thu, 14 Dec 95 12:21:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29156; Thu, 14 Dec 1995 12:21:21 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id MAA13297; Thu, 14 Dec 1995 12:21:21 -0800 Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA14600; Thu, 14 Dec 95 15:20:15 EST Received: from karma.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA19781; Thu, 14 Dec 95 15:21:13 EST Date: Thu, 14 Dec 95 15:21:13 EST Message-Id: <9512142021.AA19781@pobox.BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA24697; Thu, 14 Dec 95 15:20:45 EST From: Mike Davis To: nordmark@caribe-86.eng.sun.com Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com In-Reply-To: <199512142007.MAA18069@bobo.eng.sun.com> (nordmark@caribe-86.Eng.Sun.COM) Subject: (IPng 905) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: nordmark@caribe-86.Eng.Sun.COM (Erik Nordmark) The particular text is: "Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token." The above text implies that each interface has a built-in IEEE 802 address. I don't take it that way. How would you change it? --mad -- Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 druid@world.std.com madavis@fas.harvard.edu (transient) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 14 12:55:42 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07274; Thu, 14 Dec 95 12:55:42 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07268; Thu, 14 Dec 95 12:55:28 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA20646; Thu, 14 Dec 1995 12:55:24 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18125; Thu, 14 Dec 1995 12:55:39 -0800 Date: Thu, 14 Dec 1995 12:55:39 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512142055.MAA18125@bobo.eng.sun.com> To: mdavis@BayNetworks.com Subject: (IPng 906) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The address token [CONF] for an Ethernet interface is the interface's > built-in 48-bit IEEE 802 address, in canonical bit order and with the > octets in the same order in which they would appear in the header of > an ethernet frame. (The individual/group bit is in the first octet > and the OUI is in the first three octets.) A different MAC address > set manually or by software should not be used as the address token." > > The above text implies that each interface has a built-in IEEE 802 address. > > I don't take it that way. How would you change it? A minimalist change would be to change "built-in" to "factory-assigned". This would remove any false perception that IEEE 802 address have to be built into NICs. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 14 13:00:03 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07294; Thu, 14 Dec 95 13:00:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07242; Thu, 14 Dec 95 12:50:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03704; Thu, 14 Dec 1995 12:50:42 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id MAA19890; Thu, 14 Dec 1995 12:50:43 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA14751 for ipng@sunroof.eng.sun.com; Thu, 14 Dec 1995 12:50:42 -0800 Date: Thu, 14 Dec 1995 12:50:42 -0800 From: Ran Atkinson Message-Id: <199512142050.MAA14751@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 907) Re: Ipv6 over IEEE 802 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % The particular text is: % "Stateless Autoconfiguration and Link-Local Addresses % % The address token [CONF] for an Ethernet interface is the interface's % built-in 48-bit IEEE 802 address, in canonical bit order and with the % octets in the same order in which they would appear in the header of % an ethernet frame. (The individual/group bit is in the first octet % and the OUI is in the first three octets.) A different MAC address % set manually or by software should not be used as the address token." > The above text implies that each interface has a built-in IEEE 802 address. I think Erik's concern is legitimate. How about replacing: ...is the interface's built-in 48-bit IEEE 802 address, in... with this new text ...is the built-in 48-bit IEEE 802 address associated with that interface (NB: all interfaces on a system MAY share the same IEEE 802 address), in... Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 15 16:06:26 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08438; Fri, 15 Dec 95 16:06:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08432; Fri, 15 Dec 95 16:06:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22421; Fri, 15 Dec 1995 16:06:26 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id QAA07526; Fri, 15 Dec 1995 16:06:27 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id TAA18686; Fri, 15 Dec 1995 19:06:16 -0500 Message-Id: <199512160006.TAA18686@borg.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Dec 1995 19:00:46 -0500 To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) From: Stephen Thomas Subject: (IPng 908) Re: IPv6 over Token Ring Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:16 PM 12/13/95 -0800, Erik Nordmark wrote: > >> Maximum Transmission Unit >In order to aid interoperability on a link with no routers I think you >should specify a default value (that can be overridden by an MTU option >in a router advertisement). Is it safe to make the default >the smallest used MTU? Good idea, but I'm actually tempted to make the default MTU 1500 to deal with any bridged Ethernets in the picture. >Also, is there a hard upper bound imposed by 802.5 for the MTU? >If so it should be specified. Actually, I think the biggest LF value is specified as >X where X is some constant. The ultimate limit, though is the 2-byte 802.2 frame length field. I'll add that to the text as well. >I don't understand the details of token ring source routing. >Would this source route bridging feature be >used for multicast packets as well as unicast packets? >If not it would make sense to state that multicast never uses this feature. Source routing is not used for multicast. The spec should probably state to use the default MTU for multicast, perhaps unless a router overrides. >Independent of that I think you need to specify > - the precedence of MTU information from different sources; a default > value, information > learned from router advertisements, and information from the LF field. > - which of the MTU sources that can increase and which can decrease > the MTU. Yep. Will do. >> Stateless Autoconfiguration and Link-local Addresses >I think the IEEE 802 specifications say that addresses are assigned to >stations and not to interfaces. I don't want the above statement to >preclude an IPv6 implementation that assigns IEEE addresses to each >station (and not to each interface). Also a good point. >> [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. >> Currently draft-ietf-addrconf-ipv6-03.txt. >> >> [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery >> for IP Version 6 (IPv6). Currently draft-ietf-ipngwg- >> discovery-01.txt. > >The revision numbers on the above (and possibly other) drafts >are old. ND is -03. Addrconf is -06. Isn't addrconf up to -07 now? ;^) I'll update to the latest as of the time I submit to I-D editor. Many yhanks for the comments and suggestions. --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 15 16:09:20 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08451; Fri, 15 Dec 95 16:09:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08445; Fri, 15 Dec 95 16:09:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22701; Fri, 15 Dec 1995 16:09:19 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id QAA08212; Fri, 15 Dec 1995 16:09:20 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id TAA18554; Fri, 15 Dec 1995 19:05:45 -0500 Message-Id: <199512160005.TAA18554@borg.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Dec 1995 19:00:20 -0500 To: Matt Thomas From: Stephen Thomas Subject: (IPng 909) Re: IPv6 over Token Ring Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:27 AM 12/14/95 +0000, Matt Thomas wrote: >In <199512132343.SAA18372@borg.mindspring.com> , you wrote: > > 03 00 80 00 00 00 all nodes (FF0X::1) and solicited > node (FF02::1:XXXX:XXXX) addresses > >What is the rationale for including the solicated node multicasts in >this bucket rather than spreading them out over the other 8 >functional addresses? The thinking goes something like: If solicted node addresses were spread across the regular 8 functional addresses, then there would be a non- trivial probability that a poor node that only wanted to listen for NSs would also get hit with a high volume, multicast multimedia stream. Our intention is to isolate those IPv6 multicast addresses to which a node MUST listen to and stick them on their own functional address. That way, a minimum implementation doesn't have to worry about other IPv6 multicast traffic overloading it. Of course, the presumption here is that we (IETF, vendors, ...) aren't going to create a bunch more IPv6 multicast addresses that become "required listening" for minimal systems. If that assumption fails, then the nodes will likely end up having to software filter a multicast stream despite our best efforts. Despite this posibility, we figured it was worth a shot. Are there dissenting opinions? --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 15 16:26:34 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08483; Fri, 15 Dec 95 16:26:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08477; Fri, 15 Dec 95 16:26:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24756; Fri, 15 Dec 1995 16:26:30 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id QAA11707; Fri, 15 Dec 1995 16:26:31 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HYUGTE6EF4001DZY@FNAL.FNAL.GOV>; Fri, 15 Dec 1995 18:26:27 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA19321; Fri, 15 Dec 95 18:24:49 CST Date: Fri, 15 Dec 1995 18:24:49 -0600 From: Matt Crawford Subject: (IPng 910) Re: IPv6 over Token Ring In-Reply-To: Your message of Fri, 15 Dec 95 19:00:20 EST. <199512160005.TAA18554@borg.mindspring.com> To: Stephen Thomas Cc: Matt Thomas , ipng@sunroof.eng.sun.com Message-Id: <9512160024.AA19321@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ is that we (IETF, vendors, ...) aren't going to create a bunch more > IPv6 multicast addresses that become "required listening" for minimal > systems. [...] > Despite this posibility, we figured it was worth a shot. Are there > dissenting opinions? I do not dissent. I wonder if we can retrofit some mapping like this onto IPv4 multicast over token ring. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 16 09:00:53 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08835; Sat, 16 Dec 95 09:00:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08829; Sat, 16 Dec 95 09:00:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27500; Sat, 16 Dec 1995 09:00:52 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id JAA14779; Sat, 16 Dec 1995 09:00:54 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA03543; Sat, 16 Dec 1995 11:56:03 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00932; Sat, 16 Dec 1995 11:56:02 -0500 Message-Id: <9512161656.AA00932@wasted.zk3.dec.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 911) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of "Thu, 14 Dec 95 12:16:24 PST." <199512142016.MAA18075@bobo.eng.sun.com> Date: Sat, 16 Dec 95 11:56:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Have we determined if we need to make both ether and fddi (and others) make it so there is an identification of physical interface ID be part of the token (meaning the token is bigger). I am seeing this as a problem in DHCPv6 where the relay-agent gets messages from 3 different links and sees duplicate tokens. Then what I would need to do is slap an interface ID for each incoming link. The reason is that to a remote server the addresses will appear to be duplicated for each node via the Interface token. We can all build this into other protocols or can it be fixed with an IPv6 over foo strategy? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 16 12:08:41 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08866; Sat, 16 Dec 95 12:08:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08860; Sat, 16 Dec 95 12:08:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02683; Sat, 16 Dec 1995 12:08:41 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id MAA29897; Sat, 16 Dec 1995 12:08:41 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3471; Sat, 16 Dec 95 15:08:17 EST Received: by RTP (XAGENTA 4.0) id 4935; Sat, 16 Dec 1995 15:08:12 -0500 Received: from rsal3p4.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15678; Sat, 16 Dec 1995 15:08:29 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by hygro (8.6.11/8.6.9) with SMTP id PAA00202; Sat, 16 Dec 1995 15:07:59 -0500 Message-Id: <199512162007.PAA00202@hygro> X-Authentication-Warning: hygro.raleigh.ibm.com: Host localhost.raleigh.ibm.com didn't use HELO protocol To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 912) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of "Sat, 16 Dec 1995 11:56:02 EST." <9512161656.AA00932@wasted.zk3.dec.com> Date: Sat, 16 Dec 1995 15:07:53 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >Have we determined if we need to make both ether and fddi (and others) >make it so there is an identification of physical interface ID be part >of the token (meaning the token is bigger). Maybe I'm missing something here, but I'm not 100% convinced there is a problem here. If I understand the issue correctly, you are saying that it is not good enough to use the link-layer address for an interface token. Link-layer addresses may be unique for a link-type, but aren't unique across different link types. Thus, an ethernet and token ring interface might happen to use the same link-layer address (and consequently generate the same interface token). This could confuse the DHCP server. One solution is to concatentate a special identifier (different for each link-type) to the link-layer address when forming the interface token. I think the above problem can be addressed without creating a special identifier. If a DHCP server gets DHCP requests from hosts on links other than the link to which the DHCP server is attached, those requests must come via a relay agent. When relaying a packet, the relay agent must set the gateway address field in the DHCP packet to the address of the interface on which the relay agent received the original request. Thus, the gateway address field of the DHCP packet identifies the link on which the host resides, providing the necessary information to properly deal with duplicate interface tokens on different link types. DHCP packets from hosts on different link types will go through different relay agents (or more precisely, will be received on different interfaces if the relay agent is multihomed). >I am seeing this as a >problem in DHCPv6 where the relay-agent gets messages from 3 different >links and sees duplicate tokens The relay agent had better know which interface (i.e., link) the DHCP packets come in on, so it shouldn't be confused by this case. This is already an issue DHCPv4; when a DHCP server sends a response back to a multihomed relay agent, the relay agent uses the gateway address field (or whatever its called in DHCPv4) to figure out which interface the packet should be sent out on. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 17 17:08:31 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09239; Sun, 17 Dec 95 17:08:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09233; Sun, 17 Dec 95 17:08:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17768; Sun, 17 Dec 1995 17:08:24 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id RAA03819; Sun, 17 Dec 1995 17:08:25 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04277; Sun, 17 Dec 95 20:07:24 EST Received: from dima.wellfleet.com (BNE_CS3_Port1) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA14855; Sun, 17 Dec 95 20:08:17 EST Message-Id: <30D4BF90.528F@baynetworks.com> Date: Sun, 17 Dec 1995 20:10:40 -0500 From: Dimitry Haskin Organization: Bay Networks, Inc. X-Mailer: Mozilla 2.0b3 (Win95; I) Mime-Version: 1.0 To: iesg@cnri.reston.va.us Cc: ipng@sunroof.eng.sun.com Subject: (IPng 913) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I object to moving draft-ietf-ipngwg-ethernet-ntwrks-01.txt and draft-ietf-ipngwg-fddi-ntwrks-02.txt to proposed standard in their current form. My objection is that the proposed method of composing an interface's link-local address does not provide for the link-local address uniqueness across all interfaces of a single node. It is often the case that the same MAC address, which is used for the link-local address token, is used by multiple interfaces thus resulting in the same link-local address for all such interfaces. I don't think it is acceptable since it violates one of the requirements of the IPv6 addressing architecture: "An IPv6 unicast address refers to a single interface". I'm far from being an architectural purist but this particular violation results in the unnecessary design and implementation hardships. One of the important assumptions of IPv6 architecture is that a good deal of the IPv4 code base can be re-used with a trivial provision for longer addresses. The assumption that an node's interface can be uniquely identified with an unicast address is built in an array of IPv4 products -- from implementation-internal database organizations to MIB tables to configuration and monitoring tools. As an implementor, I encounter more and more places where yet another kluge needs to be provided to just accommodate the link-local address imposed exception to the rule. This is really unfortunate since all that can be avoided by adopting an extremely simple rule that, regardless of media type, the link local address contain the corresponding interface id in the agreed upon bits of the address (e.g. in the least significant 16 bits). Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 04:39:55 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09420; Mon, 18 Dec 95 04:39:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09414; Mon, 18 Dec 95 04:39:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09626; Mon, 18 Dec 1995 04:39:53 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id EAA22684; Mon, 18 Dec 1995 04:39:50 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id NAA20308; Mon, 18 Dec 1995 13:37:15 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id NAA04398; Mon, 18 Dec 1995 13:37:14 +0100 Message-Id: <199512181237.NAA04398@givry.inria.fr> From: Francis Dupont To: Dimitry Haskin Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 914) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of Sun, 17 Dec 1995 20:10:40 EST. <30D4BF90.528F@baynetworks.com> Date: Mon, 18 Dec 1995 13:37:06 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Dimitry Haskin, even with a weak model for multihomed hosts things are far simpler with a different token for each interface and a 16 bit field at the end of the token is the simplest way to avoid this kind of problems. Media drafts must be updated ASAP and re-proposed! Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 06:22:27 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09472; Mon, 18 Dec 95 06:22:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09466; Mon, 18 Dec 95 06:22:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13000; Mon, 18 Dec 1995 06:22:22 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id GAA03186; Mon, 18 Dec 1995 06:22:23 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA11281; Mon, 18 Dec 1995 09:16:21 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25656; Mon, 18 Dec 1995 09:16:16 -0500 Message-Id: <9512181416.AA25656@wasted.zk3.dec.com> To: "Thomas Narten" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 915) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of "Sat, 16 Dec 95 15:07:53 EST." <199512162007.PAA00202@hygro> Date: Mon, 18 Dec 95 09:16:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, First lets not make this just a DHCP problem it can also be a web or service location protocol or any gateway problem too. >Have we determined if we need to make both ether and fddi (and others) >make it so there is an identification of physical interface ID be part >of the token (meaning the token is bigger). >Maybe I'm missing something here, but I'm not 100% convinced there is >a problem here. If I understand the issue correctly, you are saying >that it is not good enough to use the link-layer address for an >interface token. Link-layer addresses may be unique for a link-type, >but aren't unique across different link types. Thus, an ethernet and >token ring interface might happen to use the same link-layer address >(and consequently generate the same interface token). This could >confuse the DHCP server. One solution is to concatentate a special >identifier (different for each link-type) to the link-layer address >when forming the interface token. >I think the above problem can be addressed without creating a special >identifier. If a DHCP server gets DHCP requests from hosts on links >other than the link to which the DHCP server is attached, those >requests must come via a relay agent. When relaying a packet, the >relay agent must set the gateway address field in the DHCP packet to >the address of the interface on which the relay agent received the >original request. Thus, the gateway address field of the DHCP packet >identifies the link on which the host resides, providing the necessary >information to properly deal with duplicate interface tokens on >different link types. DHCP packets from hosts on different link types >will go through different relay agents (or more precisely, will be >received on different interfaces if the relay agent is multihomed). Your close and in your scenario of a perfect world where the gateway address is unqiue for each client on a link your answer is correct. But...... Link 1 Link 2 Link 3 \ | / \ | / \ | / Server Ether 1 Server Ether 2 Server Ether 2 | | | -------------------------------------- | | | Server Box (e.g. DHCPv6 | | (Relay-Agent) | -------------------------------------- | Ether 4 to Other Networks (e.g. Interface to other networks like the Interface used by a Relay-Agent to send client packets to remote DHCPv6 server) The unperfect world will use the above scenario and there will only be one interface used to send all incoming packets to remote servers. Today in in DHCPv4 they use a Hardware Type to differentiate these multiple links. This will not work as an address can be duplicated across links and have the same hardware type (many DHCPv4 implementations use the ARP hardware type). What I will do in DHCPv6 if we don't fix this is add an interface-identifier in a packet to a remote server for the interface the DHCPv6 client packet came in on. A remote server (which it knows it is via the protocol see the spec) will have to also record this interface identifier from the Relay-Agent. But I believe this problem will exists for other than DHCPv6 anytime their is a reliance on messages from multiple links and at the same time a reliance on the link-layer address. There has been some talk of using up some of the bits of the token to differentiate links? My question I guess to others than Thomas, is are we going to pursue this discussion further. Or we will just keep fixing it as the problem arises in IETF Protocols and in other IPv6 implementation scenarios. >>I am seeing this as a >>problem in DHCPv6 where the relay-agent gets messages from 3 different >>links and sees duplicate tokens >The relay agent had better know which interface (i.e., link) the DHCP >packets come in on, so it shouldn't be confused by this case. This is >already an issue DHCPv4; when a DHCP server sends a response back to a >multihomed relay agent, the relay agent uses the gateway address field >(or whatever its called in DHCPv4) to figure out which interface the >packet should be sent out on. I know and will fix that problem in DHCPv6. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 07:04:29 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09512; Mon, 18 Dec 95 07:04:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09506; Mon, 18 Dec 95 07:04:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15720; Mon, 18 Dec 1995 07:04:22 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id HAA10000; Mon, 18 Dec 1995 07:04:23 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HYY41WXK34001WLL@FNAL.FNAL.GOV>; Mon, 18 Dec 1995 09:03:52 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA26775; Mon, 18 Dec 95 09:02:13 CST Date: Mon, 18 Dec 1995 09:02:13 -0600 From: Matt Crawford Subject: (IPng 916) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of Sat, 16 Dec 95 11:56:02 EST. <9512161656.AA00932@wasted.zk3.dec.com> To: bound@zk3.dec.com, Thomas Narten Cc: nordmark@caribe-86.eng.sun.com (Erik Nordmark), ipng@sunroof.eng.sun.com Message-Id: <9512181502.AA26775@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09560; Mon, 18 Dec 95 07:24:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09554; Mon, 18 Dec 95 07:24:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17346; Mon, 18 Dec 1995 07:24:41 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id HAA14191; Mon, 18 Dec 1995 07:24:42 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA23506; Mon, 18 Dec 1995 10:09:39 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32647; Mon, 18 Dec 1995 10:09:32 -0500 Message-Id: <9512181509.AA32647@wasted.zk3.dec.com> To: Dimitry Haskin Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 917) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Sun, 17 Dec 95 20:10:40 EST." <30D4BF90.528F@baynetworks.com> Date: Mon, 18 Dec 95 10:09:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IESG, I fully support Dimitry Haskins objection (attached) and think this issue needs to be revisted. This problem will plague us also because any application or protocol that is at the hub of multiple links and forwarding that data to next hop nodes will have to add an identifier or some such mechanism to differentiate the link-local address or link-layer identifier if used for the next hop if it is used as an identifier (not as an address to return a response to). But we do need to be careful how we solve this problem if using up prefix bits. Dimitry proposed a solution which should have received more discussion IMHO. thanks /jim Return-Path: daemon Received: from alpha.zk3.dec.com by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28355; Sun, 17 Dec 1995 20:27:02 -0500 Received: from mail1.digital.com by alpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA07976; Sun, 17 Dec 1995 20:27:00 -0500 Received: from mercury.Sun.COM by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA17504; Sun, 17 Dec 1995 17:23:35 -0800 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id RAA03862; Sun, 17 Dec 1995 17:09:24 -0800 Received: from sunroof.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA18232; Sun, 17 Dec 1995 17:09:16 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09239; Sun, 17 Dec 95 17:08:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09233; Sun, 17 Dec 95 17:08:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17768; Sun, 17 Dec 1995 17:08:24 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id RAA03819; Sun, 17 Dec 1995 17:08:25 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04277; Sun, 17 Dec 95 20:07:24 EST Received: from dima.wellfleet.com (BNE_CS3_Port1) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA14855; Sun, 17 Dec 95 20:08:17 EST Message-Id: <30D4BF90.528F@baynetworks.com> Date: Sun, 17 Dec 1995 20:10:40 -0500 From: Dimitry Haskin Organization: Bay Networks, Inc. X-Mailer: Mozilla 2.0b3 (Win95; I) Mime-Version: 1.0 To: iesg@cnri.reston.va.us Cc: ipng@sunroof.eng.sun.com Subject: (IPng 913) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I object to moving draft-ietf-ipngwg-ethernet-ntwrks-01.txt and draft-ietf-ipngwg-fddi-ntwrks-02.txt to proposed standard in their current form. My objection is that the proposed method of composing an interface's link-local address does not provide for the link-local address uniqueness across all interfaces of a single node. It is often the case that the same MAC address, which is used for the link-local address token, is used by multiple interfaces thus resulting in the same link-local address for all such interfaces. I don't think it is acceptable since it violates one of the requirements of the IPv6 addressing architecture: "An IPv6 unicast address refers to a single interface". I'm far from being an architectural purist but this particular violation results in the unnecessary design and implementation hardships. One of the important assumptions of IPv6 architecture is that a good deal of the IPv4 code base can be re-used with a trivial provision for longer addresses. The assumption that an node's interface can be uniquely identified with an unicast address is built in an array of IPv4 products -- from implementation-internal database organizations to MIB tables to configuration and monitoring tools. As an implementor, I encounter more and more places where yet another kluge needs to be provided to just accommodate the link-local address imposed exception to the rule. This is really unfortunate since all that can be avoided by adopting an extremely simple rule that, regardless of media type, the link local address contain the corresponding interface id in the agreed upon bits of the address (e.g. in the least significant 16 bits). Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html 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/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 08:07:41 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09597; Mon, 18 Dec 95 08:07:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09591; Mon, 18 Dec 95 08:07:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21284; Mon, 18 Dec 1995 08:07:37 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA23422; Mon, 18 Dec 1995 08:07:37 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5479; Mon, 18 Dec 95 11:07:11 EST Received: by RTP (XAGENTA 4.0) id 6095; Mon, 18 Dec 1995 11:07:03 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17391; Mon, 18 Dec 1995 11:07:22 -0500 Message-Id: <9512181607.AA17391@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 918) draft-ietf-ipngwg-fddi-ntwrks-02.txt Date: Mon, 18 Dec 1995 11:07:22 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For purposes of this document, information received from DHCP is > considered ``manually configured''. I don't really disagree with this statement, but I don't think it belongs in the IP-over-foo specs on a case-by-case basis. I think it would be more appropriate to state it once (perhaps in the DHCP spec) so that its interpretation is consistent across all link-types. Is there WG consensus that DHCP-learned info is considered "manually configured" from the perspective of all of our documents? Also, is their WG consensus that manually configured info that is obtained in an implementation-specific manner (e.g., read from a config file?) has precedence over DHCP-learned information? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 09:08:16 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09642; Mon, 18 Dec 95 09:08:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09636; Mon, 18 Dec 95 09:08:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28538; Mon, 18 Dec 1995 09:08:13 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id JAA08276; Mon, 18 Dec 1995 09:08:14 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA16094; Mon, 18 Dec 1995 11:49:43 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15028; Mon, 18 Dec 1995 11:49:41 -0500 Message-Id: <9512181649.AA15028@wasted.zk3.dec.com> To: "Thomas Narten" Cc: Matt Crawford , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 919) Re: draft-ietf-ipngwg-fddi-ntwrks-02.txt In-Reply-To: Your message of "Mon, 18 Dec 95 11:07:22 -0400." <9512181607.AA17391@cichlid.raleigh.ibm.com> Date: Mon, 18 Dec 95 11:49:41 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> For purposes of this document, information received from DHCP is >> considered ``manually configured''. >I don't really disagree with this statement, but I don't think it >belongs in the IP-over-foo specs on a case-by-case basis. I think it >would be more appropriate to state it once (perhaps in the DHCP spec) >so that its interpretation is consistent across all link-types. I think stating clearly what you mean would be helpful. I think I know what you mean but I don't want to guess. Can you state and example? >Is there WG consensus that DHCP-learned info is considered "manually >configured" from the perspective of all of our documents? Also, is >their WG consensus that manually configured info that is obtained in an >implementation-specific manner (e.g., read from a config file?) has >precedence over DHCP-learned information? Again an example would be great. Then I will respond yeah or nay as one persons input. thanks /jim Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html 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/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 09:29:39 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09665; Mon, 18 Dec 95 09:29:39 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09659; Mon, 18 Dec 95 09:29:24 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA07664; Mon, 18 Dec 1995 09:29:14 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02599; Mon, 18 Dec 1995 09:29:31 -0800 Date: Mon, 18 Dec 1995 09:29:31 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512181729.JAA02599@bobo.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 920) Re: Continuation of WG last call: IPv6 over FDDI Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Have we determined if we need to make both ether and fddi (and others) > make it so there is an identification of physical interface ID be part > of the token (meaning the token is bigger). Is your concern about how to "route" the DHCP packets back to the host or are you concerned with how the DHCP server identifies the host in its "database" of configuration information? I think Tomas address the former issue. The latter issue seems like it could use some work. We have one class of interfaces that have globally unique interface tokens (IEEE 802 based and perhaps other interfaces). These should never cause any duplicate tokens unless some NIC cards get produced with identical addresses. Perhaps the DHCP server can be made to detect duplicates for IEEE 802 tokens should they ever appear. But another class of interface tokens are not globally unique. For example, Appletalk/Localtalk tokens would presumably fall in this category. It is not clear to me how tokens will be created for PPP links. I don't know how you could possibly use tokens that are not globally unique (or at least unique across the domain that your DHCP server handles). Note that adding some form of local interface ID to the token doesn't make it more globally unique. For example, if you two localtalk nodes with link-layer address 17 in different parts of your organization (on different localtalk links) both of these would presumably have a single interface i.e. the interface ID would be the same. Thus the would still be duplicate. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 10:30:04 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09776; Mon, 18 Dec 95 10:30:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09770; Mon, 18 Dec 95 10:29:53 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10904; Mon, 18 Dec 1995 10:30:00 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id KAA03447; Mon, 18 Dec 1995 10:29:59 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9082; Mon, 18 Dec 95 13:29:33 EST Received: by RTP (XAGENTA 4.0) id 6133; Mon, 18 Dec 1995 13:29:11 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19143; Mon, 18 Dec 1995 13:29:28 -0500 Message-Id: <9512181829.AA19143@cichlid.raleigh.ibm.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 921) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of "Mon, 18 Dec 1995 09:29:31 PST." <199512181729.JAA02599@bobo.eng.sun.com> Date: Mon, 18 Dec 1995 13:29:28 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: >Is your concern about how to "route" the DHCP packets >back to the host or are you concerned with how the DHCP server identifies >the host in its "database" of configuration information? >I think Tomas address the former issue. >The latter issue seems like it could use some work. I'm actually concerned about both issues, and the 'gateway field' addresses both of them. There are two reasons why the relay agent needs to put the proper address in the gateway field of relayed DHCP packets: 1) When the server responds, it sends the packet back to the relay agent. The relay agent extracts the 'gateway field' and uses it to identify the interface the packet should be sent out (i.e., the link where the client resides). 2) When a DCHP server receives a client request via a relay agent, the server has to figure out what address to return. In order to return a proper address, the server needs to know what subnet the client is on (i.e., what prefix to use). That knowledge can't come from the client itself (it may be an out-of-the-box machine); it comes from the 'gateway field' the relay agent added. The server uses that field to figure out which subnet the client is so that it can generate an appropriate address. I'm arguing that proper setting of the 'gateway field' is both necessary and sufficient. >But another class of interface tokens are not globally unique. >For example, Appletalk/Localtalk tokens would presumably fall in >this category. But they can be unique per-link, and the DHCP server can deal with addresses that are unique per-link, provided it knows which link the host is on. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 11:48:38 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09913; Mon, 18 Dec 95 11:48:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09907; Mon, 18 Dec 95 11:48:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24170; Mon, 18 Dec 1995 11:48:31 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA04235; Mon, 18 Dec 1995 11:48:30 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21872; Mon, 18 Dec 95 14:47:31 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA18733; Mon, 18 Dec 95 14:48:28 EST Date: Mon, 18 Dec 95 14:48:28 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512181948.AA18733@pobox.BayNetworks.com> To: crawdad@FNAL.FNAL.GOV Subject: (IPng 922) Re: Continuation of WG last call: IPv6 over FDDI Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Matt Crawford > > According to my notes, someone volunteered to put together the case > for using the bits between the 10 bit link-local prefix and the > interface token. However, I didn't record who that was. Perhaps the > minute-taker did? > It was Robert Elz who volunteered to write a draft proving that uniqueness of the link-local address accross node's interfaces is a good thing. But as I see it, no such a prove is necessary -- it IS already a requirement of the IPv6 addressing architecture. The burden of prove should be on those hwo opposes it. Those who think that allowing duplicate link-local addresses across node's interfaces is a swell idea should make a convincing case for it and push for the modification of the addressing spec. So far I haven't heard any reasonable arguments for it. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 14:07:22 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10053; Mon, 18 Dec 95 14:07:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10047; Mon, 18 Dec 95 14:07:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14996; Mon, 18 Dec 1995 14:07:20 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id OAA10445; Mon, 18 Dec 1995 14:07:20 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA08226; Mon, 18 Dec 1995 17:03:09 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25226; Mon, 18 Dec 1995 17:03:08 -0500 Message-Id: <9512182203.AA25226@wasted.zk3.dec.com> To: dhcp-v6@bucknell.edu, ipng@sunroof.eng.sun.com, addrconf@cisco.com Cc: perk@watson.ibm.com Subject: (IPng 923) Authorship of DHCPv6 Date: Mon, 18 Dec 95 17:03:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk **** DO NOT RESPOND TO THIS MAIL OR START A DISCUSSION ***** OK to respond to me directly of course I am sending this to DHCPv6 and IPng, and addrconf just don't want it to be a thread. Charlie Perkins will now be co-author with me on DHCPv6. Charlie and I talked and worked this out at the Dallas IETF. So if you send me private DHCPv6 mail as many like to do please now copy Charlie I put his address in the cc: above. As always mail to the DHCPv6 list is preferred. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 14:35:59 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10100; Mon, 18 Dec 95 14:35:59 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10094; Mon, 18 Dec 95 14:35:44 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA18049; Mon, 18 Dec 1995 14:35:32 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02732; Mon, 18 Dec 1995 14:35:48 -0800 Date: Mon, 18 Dec 1995 14:35:48 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512182235.OAA02732@bobo.eng.sun.com> To: dhaskin@BayNetworks.com Subject: (IPng 924) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com, iesg@cnri.reston.va.us Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [...] > address for all such interfaces. I don't think it is acceptable since it > violates one of the requirements of the IPv6 addressing architecture: > "An IPv6 unicast address refers to a single interface". Your argument is too simplistic. IPv6 addresses come with different uniqness (as weel as routability) scope. For instance, a link-local address is only guaranteeed to be unique on one link. Therefor, the same link-local address might very well be assigned to multiple interfaces on multiple nodes. Thus your quote from the addressing archtecture should not be construed to mean that the all link-local and site-local addresses must be globally unique; that was not the intent of the addressing architecture spec as far as I can tell. But being an implementor myself (aren't we all?) I would be tempted by an implementation simplicity argument PROVIDED that it can be done at a reasonable cost. The benfits of tagging the link-local addresses with an interface ID is that the node can use IP addresses in most cases to identify interfaces. (I say "in most cases" because the architecture allows for unnumbered point-point interfaces.) However, there is a cost with providing this feature. Nodes have to ensure some form of stability for their link-local addresses. For instance, a reboot of a router (perhaps after installing new interface cards) should not change the link-local addresses assigned to its interfaces. Protocols like Neighbor Discovery (see section 6.2.8 "Link-local address change" in draft-ietf-ipngwg-discovery-03.txt) assume that the link-local address of a router doesn't change silently. How "expensive" would it be for an implementation to provide stable link-local address once you include the interface ID in the address? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 15:33:32 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10187; Mon, 18 Dec 95 15:33:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10180; Mon, 18 Dec 95 15:31:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26870; Mon, 18 Dec 1995 15:30:34 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id PAA02142; Mon, 18 Dec 1995 15:30:29 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16212(9)>; Mon, 18 Dec 1995 15:30:15 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 18 Dec 1995 15:30:06 -0800 To: Dimitry Haskin Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 925) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: dhaskin's message of Sun, 17 Dec 95 17:10:40 -0800. <30D4BF90.528F@baynetworks.com> Date: Mon, 18 Dec 1995 15:30:01 PST From: Steve Deering Message-Id: <95Dec18.153006pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, Whether or not I agree with your opinion that IPv6 link-local addresses ought to be unique across all interfaces of a multi-interface node, I disagree with your line of argument. > It is often > the case that the same MAC address, which is used for the link-local address > token, is used by multiple interfaces thus resulting in the same link-local > address for all such interfaces. I don't think it is acceptable since it > violates one of the requirements of the IPv6 addressing architecture: > "An IPv6 unicast address refers to a single interface". The IPv6 addressing architecture requires that a unicast address identify a single interface *within the scope of that address*. For link-local addresses, the scope is a single link, i.e., uniqueness is required only across the set of interfaces attached to the same link. The whole point of link-local addresses is that they are *not* required to be unique beyond the link -- the same link-local address may be assigned to more than one interface, as long as those interfaces are attached to different links. One of the common ways in which re-use of the same link-local address on different links may occur is the example you gave, where a multi-interface node fabricates a link-local address for each of its interfaces using a single node-wide MAC address -- that is perfectly "legal", as long as each interface is attached to a different link. > The assumption that an node's interface can be uniquely > identified with an unicast address is built in an array of IPv4 products -- > from implementation-internal database organizations to MIB tables to > configuration and monitoring tools. This assumption has already proven to be false in the IPv4 world, and ought to be re-examined for IPv6. "Unnumbered" or "not-separately-numbered" interfaces have become common in IPv4, and are permitted in IPv6 (for routers). Tunnels are also widely used and, though they serve the role of links, their endpoints are seldom given distinct addresses. The set of Frame Relay VCs terminating in a single node, and serving as multiple point-to-point links, often share a single unicast addresses for all the link endpoints that terminate at the same node. > As an implementor, I encounter more > and more places where yet another kluge needs to be provided to just > accommodate the link-local address imposed exception to the rule. I'm surprised that you, as an implementor, have not yet encountered all the other exceptions to the rule. I think you should seriously consider alternative methods of identifying different interfaces within a single node, such as using interface names (e.g., BSD-style names like "le0" and "sl1"), or interface indices ("0", "1", ...), that will work to locally identify not just "normal" interfaces, but also unnumbered interfaces, tunnel endpoints, etc. I get the impression that you are hoping to use IPv6 link-local addresses as unique interface identifiers within a multi-interface node, even though that is not what they were designed for. That is, they could serve as a *solution* to a local (intra-node) naming problem that *already exists* in IPv4 and IPv6 (i.e., this a not a problem *created* by link-local addresses, as you have claimed, but rather one that might be *solved* by them). I was prepared to accept your proposal for adding an "interface index" field to link-local addresses, but when the subject was brought up in the Dallas meeting, a number of complications and loose-ends were identified -- i.e., it was clear that this is *not* just a no-brainer change. That's why I, in my WG chair role, asked for a written proposal (something more than a "wouldn't it be nice if" email message) that deals with those outstanding issues, upon which we can seek WG consensus, and then if necessary, revise the IPv6-over-foo specs. In summary, I believe your stated reasons for why the IPv6-over-Ethernet and IPv6-over-FDDI specs should not advance to Proposed Standard are incorrect. Those specs do not violate the requirements of IPv6 unicast addresses, nor do they introduce a new intra-node naming problem that is not present in IPv4. You are really asking for an additional capability that, at least superficially, looks like a good idea, but in my opinion needs further specification and analysis. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 16:20:58 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10271; Mon, 18 Dec 95 16:20:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10265; Mon, 18 Dec 95 16:20:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03660; Mon, 18 Dec 1995 16:20:48 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id QAA12970; Mon, 18 Dec 1995 16:20:45 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA01276; Mon, 18 Dec 95 19:19:43 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA01723; Mon, 18 Dec 95 19:20:40 EST Date: Mon, 18 Dec 95 19:20:40 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512190020.AA01723@pobox.BayNetworks.com> To: nordmark@caribe-86.eng.sun.com Subject: (IPng 926) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com, iesg@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Mon, 18 Dec 1995 14:35:48 -0800 > From: nordmark@caribe-86.Eng.Sun.COM (Erik Nordmark) > > > [...] > > address for all such interfaces. I don't think it is acceptable since it > > violates one of the requirements of the IPv6 addressing architecture: > > "An IPv6 unicast address refers to a single interface". > > Your argument is too simplistic. > > IPv6 addresses come with different uniqness (as weel as routability) scope. > For instance, a link-local address is only guaranteeed to be unique on > one link. Therefor, the same link-local address might very well be assigned > to multiple interfaces on multiple nodes. > > Thus your quote from the addressing archtecture should not be construed > to mean that the all link-local and site-local addresses must be globally > unique; that was not the intent of the addressing architecture spec as far > as I can tell. > My interpretation was that an unicast address is unique within node scope. Steve indicated that it was not the intend for link-local addresses. So I stand corrected. > But being an implementor myself (aren't we all?) I would be tempted by > an implementation simplicity argument PROVIDED that it can be done > at a reasonable cost. > > The benfits of tagging the link-local addresses with an interface ID > is that the node can use IP addresses in most cases to identify > interfaces. (I say "in most cases" because the architecture allows for > unnumbered point-point interfaces.) > > However, there is a cost with providing this feature. Nodes have to > ensure some form of stability for their link-local addresses. For instance, > a reboot of a router (perhaps after installing new interface cards) should > not change the link-local addresses assigned to its interfaces. > Protocols like Neighbor Discovery (see section 6.2.8 "Link-local address > change" in draft-ietf-ipngwg-discovery-03.txt) assume that the > link-local address of a router doesn't change silently. > Tell me that Neighbor Discovery provides a way to detect a silent address change (by a timeout, NUD, or whatever). Please.. > How "expensive" would it be for an implementation to provide stable > link-local address once you include the interface ID in the address? The interface id is quite stable in our implementation. Can't speak for others. > > Erik Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 21:26:50 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10542; Mon, 18 Dec 95 21:26:50 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10536; Mon, 18 Dec 95 21:26:35 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA26965; Mon, 18 Dec 1995 21:26:24 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA02961; Mon, 18 Dec 1995 21:26:40 -0800 Date: Mon, 18 Dec 1995 21:26:40 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512190526.VAA02961@bobo.eng.sun.com> To: narten@VNET.IBM.COM Subject: (IPng 927) Re: Continuation of WG last call: IPv6 over FDDI Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thomas Narten writes: > I'm actually concerned about both issues, and the 'gateway field' > addresses both of them. There are two reasons why the relay agent > needs to put the proper address in the gateway field of relayed DHCP > packets: > > 1) When the server responds, it sends the packet back to the relay > agent. The relay agent extracts the 'gateway field' and uses it to > identify the interface the packet should be sent out (i.e., the link > where the client resides). > > 2) When a DCHP server receives a client request via a relay agent, the > server has to figure out what address to return. In order to return a > proper address, the server needs to know what subnet the client is on > (i.e., what prefix to use). That knowledge can't come from the client > itself (it may be an out-of-the-box machine); it comes from the > 'gateway field' the relay agent added. The server uses that field to > figure out which subnet the client is so that it can generate an > appropriate address. #2 is fine as long as all the DHCP server does is to return an IP address. However, if the server has been configured to return other information (e.g. if my desktop machine wants to have a different DNS domainname "foo.sun.com" compared to other machines that all use "eng.sun.com") and I want this information to be associated with the client independent of which relay agent happened to serve it, and potentially also independent of which Ethernet my machine happens to connect to. Thus essentially I'd like a unique identifier for "Erik's workstation" that is not tied to where in the local topology that the host connects. Then the DHCP server can return the configuration information specific to my machine. An Ethernet address could serve as such an identifier. Adding relay server tagging to the identifier might break things if "Ethernet address A on link X" is considered to be a different node than "Ethernet address A on link Y". Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 21:41:41 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10559; Mon, 18 Dec 95 21:41:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10553; Mon, 18 Dec 95 21:41:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29259; Mon, 18 Dec 1995 21:41:36 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id VAA28469; Mon, 18 Dec 1995 21:41:38 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA30263; Tue, 19 Dec 1995 00:39:09 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20919; Tue, 19 Dec 1995 00:39:07 -0500 Message-Id: <9512190539.AA20919@wasted.zk3.dec.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 928) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of "Mon, 18 Dec 95 09:29:31 PST." <199512181729.JAA02599@bobo.eng.sun.com> Date: Tue, 19 Dec 95 00:39:07 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >> Have we determined if we need to make both ether and fddi (and others) >> make it so there is an identification of physical interface ID be part >> of the token (meaning the token is bigger). >Is your concern about how to "route" the DHCP packets >back to the host or are you concerned with how the DHCP server identifies >the host in its "database" of configuration information? Actually both. >I think Tomas address the former issue. >The latter issue seems like it could use some work. Yes Thomas and I took it offline. I can use the interface for the first issue as the IP address for the gateway. My concern was that if I send the packet to the server from a non client interface at the relay-agent with the address in the gateway-address field that the gateway address is not routable from the server for some reason. But that is not a DHCP problem and a bad network setup problem. I have seen this in real life and Thomas is right. So the idea will work. >We have one class of interfaces that have globally unique interface >tokens (IEEE 802 based and perhaps other interfaces). These should >never cause any duplicate tokens unless some NIC cards get produced >with identical addresses. Perhaps the DHCP server can be made to >detect duplicates for IEEE 802 tokens should they ever appear. I like this idea. WARNING SOMEONE IS BOGUS. >But another class of interface tokens are not globally unique. >For example, Appletalk/Localtalk tokens would presumably fall in >this category. It is not clear to me how tokens will be created >for PPP links. I don't know how you could possibly use tokens that >are not globally unique (or at least unique across the domain that >your DHCP server handles). This was not my impression. I hate to design for non-unique tokens if I don't have too. I was under the impression that the token could be duplicated too. >Note that adding some form of local interface ID to the token doesn't make >it more globally unique. For example, if you two localtalk nodes >with link-layer address 17 in different parts of your organization >(on different localtalk links) both of these would presumably have >a single interface i.e. the interface ID would be the same. Thus >the would still be duplicate. Yes and it also does not help with the database either if the client uses a different relay-agent next time around. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Dec 18 22:19:15 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10635; Mon, 18 Dec 95 22:19:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10629; Mon, 18 Dec 95 22:19:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01414; Mon, 18 Dec 1995 22:19:13 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id WAA01759; Mon, 18 Dec 1995 22:19:14 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA13988; Tue, 19 Dec 1995 01:14:04 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25261; Tue, 19 Dec 1995 01:14:04 -0500 Message-Id: <9512190614.AA25261@wasted.zk3.dec.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 929) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of "Mon, 18 Dec 95 21:26:40 PST." <199512190526.VAA02961@bobo.eng.sun.com> Date: Tue, 19 Dec 95 01:14:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >#2 is fine as long as all the DHCP server does is to return an IP address. >However, if the server has been configured to return other information >(e.g. if my desktop machine wants to have a different DNS domainname >"foo.sun.com" compared to other machines that all use "eng.sun.com") >and I want this information to be associated with the client independent >of which relay agent happened to serve it, and potentially also >independent of which Ethernet my machine happens to connect to. >Thus essentially I'd like a unique identifier for "Erik's workstation" >that is not tied to where in the local topology that the >host connects. Then the DHCP server can return the configuration >information specific to my machine. This is really a key point for us to remember in this discussion. >An Ethernet address could serve as such an identifier. >Adding relay server tagging to the identifier might break things >if "Ethernet address A on link X" is considered to be a different >node than "Ethernet address A on link Y". This is pretty easy to do for the check in the code to parse the binding there would be different checks at the server when handling clients requests. I think we need to put this differentiation in the spec? I agree that "Eriks Workstation" should be unique for configuration data other than address parts. Have folks run into this implementing DHCPv4? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 19 05:31:02 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10804; Tue, 19 Dec 95 05:31:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10798; Tue, 19 Dec 95 05:30:51 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18511; Tue, 19 Dec 1995 05:30:59 -0800 Received: from coral.bucknell.edu by venus.Sun.COM (Sun.COM) id FAA05632; Tue, 19 Dec 1995 05:30:59 -0800 Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA13445; Tue, 19 Dec 1995 08:30:53 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Dec 1995 08:31:08 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 930) Re: Continuation of WG last call: IPv6 over FDDI Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I understand this conversation, we're trying to sort out several issues: * How to uniquely identify a DHCPv6 client to a DHCPv6 server * How to deliver messages from a DHCPv6 server to a DHCPv6 client using only the client's link-local address * How to identify a DHCPv6 client to a DHCPv6 server for the purpose of selecting specific configuration parameters (which may be selected on the basis of the link to which the client is attached, the "class" to which the client belongs, or "hand-crafted" for the specific client) I believe DHCPv6 has all of the pieces in place to resolve these issues (or, at least we've agreed in the WG that the pieces should be included in DHCPv6). Here is the scenario for client-server communication: * The client identifies itself with an 'interface id', 'vendor class' and 'user class'; the client selects these to uniquely identify itself to the server * The client multicasts a message intended to reach a DHCPv6 server * The relay agent inserts the interface on which it received the client message into 'relay agent address' before forwarding to the server (if the relay agent is multihomed but cannot identify the interface on which it received the message from the client, it is broken, um, non-compliant) * The server uses 'relay agent address' to identify the link (not as an identifier) to which the client is attached * The server constructs a response based on the link and the unique identifiers; this response can have parameters for that specific client * The server records this information keyed as (link prefix, client id), which uniquely identify the client independent of which relay agent and server handle the client request * The server returns the message to 'relay agent address'; the relay agent forwards the message to the client's link-local address out the interface to which 'relay agent address' is attached - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 19 08:44:30 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10903; Tue, 19 Dec 95 08:44:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10897; Tue, 19 Dec 95 08:44:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03850; Tue, 19 Dec 1995 08:44:26 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id IAA11574; Tue, 19 Dec 1995 08:44:26 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA17070; Tue, 19 Dec 1995 11:35:04 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32219; Tue, 19 Dec 1995 11:34:58 -0500 Message-Id: <9512191634.AA32219@wasted.zk3.dec.com> To: Harald.T.Alvestrand@uninett.no Cc: bound@zk3.dec.com, Dimitry Haskin , iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 931) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Tue, 19 Dec 95 10:50:27 +0100." <199512190950.DAA22798@dale.uninett.no> Date: Tue, 19 Dec 95 11:34:57 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald, >Just to be sure I know what you are talking about: >From your comments, it seems that you're saying that the IEEE 802 >concept "station" is mapped in the draft to the IPv6 concept >"Interface", and/or that 802 "media" is mapped to the IPv6 concept >"link", and that these mappings actually can't be made in some cases. Yes. >Check questions, to see if I understand: >- Is it the case that there exist multiport Ethernet cards, or CPUs > with multiple Ethernet cards, on which all of the interfaces use the > same MAC address? Right now (today) an IPv6 address on a "link" can only be assigned to one interface (station). If one would want to assign a multiport Ethernet to "one" IPv6 address then it would have to make sure that to the upper-layers (defined in IPv6 base spec) the multiport Ethernet is presented as a single virtual interface. That virtual interface should only have one interface-token (e.g. MAC address). >- Is it also the case that in some combination of circumstances, more than > one of the interfaces can be connected to what IPv6 (but not 802.3) > considers a single "link", giving duplicate addresses on that link? Yes and that is why IPv6 ND and Addr Conf have specified the need for Duplicate Address Detection on a link. >- Or is it the case that in some combination of circumstances, link-local > addresses are used outside the link, giving rise to a need for link-local > addresses that are unique within a larger scope? Never should be the case. This is not permitted. >as for a solution to the problem: >You seem to suggest moving the MAC address to the 48 highest bits of the >64-bit "link-local" field, and using the lower 16 bits for an "index". >Would the purpose be equally well served by allowing a station to place >any value it wants to into the high 16 bits of the lower 64 bits of a >link-local address, and recommending the value zero for single-interface >"stations"? I did not propose any solution but Dimitry has and I think it does not matter whether its the high-order bits or low-order bits. I recall his solution is in the context of your assumption of the solution. >Thanks for your help in understanding the problem! The problem arises in a multihome situation on a single node supporting multiple links (802.3 media) where the interfaces (802.3 stations) exist on different links for the same node. In this case it is "perceived" that the interface-token (MAC address) may be duplicated on each link. IPv6 ND/Addr conf Duplicate Address Detection does not verify that the link-local address (or any address (site, global)) is not duplicated across links. It has been mentioned in the IPng WG that some implementations will use the CPU # (as an example) to assign the link-layer address (identifier for 802.3 station) for all interfaces (stations) across multiple links. Hence, there is no way to differentitate the link-local address across the multihome links on a single node. By using Dimitrys suggestion it is possible to discriminate the link-layer address and interface-token via the 16bits (high or low) of the lower 64bits of a link-local address. Neighbor Discovery (ND) in a mutlihomed node the link-local address would not be duplicated and implementors avoid having to carry interface-IDs in however they maintain ND cache or tables or whatever they want to call it in their implementations. It also removes having to have a priori knowledge of interfaces at the application layer should the link-local address be used to communicate on a link (not off link). There are other options that have been alluded to in WG discussions: 1. Make it mandatory that each interface have a unique interface-token identifier (e.g. MAC address). The problem is that there are cases where this is still not unique. But it would help is what some have suggested. But this will affect existing implementations link-layer code and so far we have tried to avoid that in IPv6. Like the fact the the Minimum MTU guranteed is 576 instead of 1500 (or 1492). IMHO bag it rewrite your link layers but this is a minority view and not popular so most of the time consensus is that the link layer in existing implementations is sacred. 2. Link-Local address only have context and meaning on a link to perform Neighbor Discovery and have no meaning to any other aspects of IPv6 processing. This would mean we loose a great benefit for IPv6. For example the implementation I am working with for IPv6 builds a link-local address when the UNIX kernel restarts, comes online, reboots, or whatever now as part of the start-up scripts. If no router exists to provide stateless addr conf and no DHCPv6 server exists to give me an address (stateful) I can still communicate with other nodes on the link. We do this now with telnet, ftp, ping, or tftp. Its really nice and a real evolution from IPv4. If we make link-local addresses only usable for ND and Addrconf on a link we will loose this great benefit for users of IPv6. I don't think this is a good idea and would be one who would object greatly. I think Dimitrys proposal is cheap, does not break anything in IPv6, and can be implemented quite easily. Dimitry has been asked to write up a proposal. I think that is really not necessary. Its a fix to the IPv6 over Foo specs to add the interface ID as you have outlined. One interface-token logic check I think is ATM. I think ATM will use up all 64bits but that media will not have duplicates. I have searched pretty hard and have not found any media type that would need greater than 64bits. This is important because it will affect implementations use of interface-tokens and link-local addresses in the IPv6 code path. But then again somone thought once 32bits would be enough address space forever. Hope this is useful, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 19 11:11:36 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11059; Tue, 19 Dec 95 11:11:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11053; Tue, 19 Dec 95 11:11:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27950; Tue, 19 Dec 1995 11:11:26 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA07584; Tue, 19 Dec 1995 11:11:26 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA18279; Tue, 19 Dec 95 14:10:26 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA07700; Tue, 19 Dec 95 14:11:23 EST Date: Tue, 19 Dec 95 14:11:23 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512191911.AA07700@pobox.BayNetworks.com> To: deering@parc.xerox.com Subject: (IPng 932) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > Whether or not I agree with your opinion that IPv6 link-local addresses ought > to be unique across all interfaces of a multi-interface node, I disagree with > your line of argument. > > > It is often > > the case that the same MAC address, which is used for the link-local address > > token, is used by multiple interfaces thus resulting in the same link-local > > address for all such interfaces. I don't think it is acceptable since it > > violates one of the requirements of the IPv6 addressing architecture: > > "An IPv6 unicast address refers to a single interface". > > The IPv6 addressing architecture requires that a unicast address identify > a single interface *within the scope of that address*. For link-local > addresses, the scope is a single link, i.e., uniqueness is required only > across the set of interfaces attached to the same link. The whole point of > link-local addresses is that they are *not* required to be unique beyond the > link -- the same link-local address may be assigned to more than one > interface, as long as those interfaces are attached to different links. > One of the common ways in which re-use of the same link-local address on > different links may occur is the example you gave, where a multi-interface > node fabricates a link-local address for each of its interfaces using a > single node-wide MAC address -- that is perfectly "legal", as long as each > interface is attached to a different link. Yet another fine example of vagueness of an architectural document. I think my interpretation comes naturally from the reading of section 2.1 of the IPv6 addressing architecture (For those who didn't read the document, I've attached this section in entirety to this message). I think it is also logical to treat a router as a link between all its interfaces. > > > The assumption that an node's interface can be uniquely > > identified with an unicast address is built in an array of IPv4 products -- > > from implementation-internal database organizations to MIB tables to > > configuration and monitoring tools. > > This assumption has already proven to be false in the IPv4 world, and ought > to be re-examined for IPv6. "Unnumbered" or "not-separately-numbered" > interfaces have become common in IPv4, and are permitted in IPv6 (for > routers). Tunnels are also widely used and, though they serve the role of > links, their endpoints are seldom given distinct addresses. The set of > Frame Relay VCs terminating in a single node, and serving as multiple > point-to-point links, often share a single unicast addresses for > all the link endpoints that terminate at the same node. > (Disclaimer: I'm not speaking for all possible IPv4 implementations -- bad or good.) My point is that, if you have an IPv4 address assigned to an interface, it unambiguously identifies this interface withing a single box. Your Frame Relay example is not an exception since a VC bundle is treated by IP as a single physical interface to a multicast media (same as Ethernet). "Unnumbered" interfaces don't have an address so it is an ugly special case introduced into IPv4 for the address conservation purpose. It is a kluge which handles a subset of IP stack with a number of yet unsolved or purely resolved problems. IMHO, unnumbered interfaces should have not be included into IPv6 architecture. I don't see any need for them there -- IPv6 can afford to number an interface, even if it is a local-scope only address. > > As an implementor, I encounter more > > and more places where yet another kluge needs to be provided to just > > accommodate the link-local address imposed exception to the rule. > > I'm surprised that you, as an implementor, have not yet encountered all > the other exceptions to the rule. > Actually "unnumbered" interfaces is the only special case in respect of interface addressing that we've had to handle differently in IPv4. I hope this case can be completely ignored in IPv6 (partly due to the possibility of using the link-local addresses). > I think you should seriously consider alternative methods of identifying > different interfaces within a single node, such as using interface names > (e.g., BSD-style names like "le0" and "sl1"), or interface indices > ("0", "1", ...), that will work to locally identify not just "normal" > interfaces, but also unnumbered interfaces, tunnel endpoints, etc. We have interface indices, but IPv6 addresses is what is used in IPv6 packets and it would be simpler if an interface address could be uniquely mapped to such an id. > > I get the impression that you are hoping to use IPv6 link-local addresses > as unique interface identifiers within a multi-interface node, even though > that is not what they were designed for. That is, they could serve as a > *solution* to a local (intra-node) naming problem that *already exists* in > IPv4 and IPv6 (i.e., this a not a problem *created* by link-local addresses, > as you have claimed, but rather one that might be *solved* by them). Fine. But again short of unnumbered interfaces (where no address is provided), which IMO should be removed from IPv6 architecture, the link-local address is so far the only case (at least as I can tell) where an address may identify multiple interfaces of a single node. > prepared to accept your proposal for adding an "interface index" field to > link-local addresses, but when the subject was brought up in the Dallas > meeting, a number of complications and loose-ends were identified -- i.e., > it was clear that this is *not* just a no-brainer change. That's why I, > in my WG chair role, asked for a written proposal (something more than a > "wouldn't it be nice if" email message) that deals with those outstanding > issues, upon which we can seek WG consensus, and then if necessary, revise > the IPv6-over-foo specs. > > In summary, I believe your stated reasons for why the IPv6-over-Ethernet and > IPv6-over-FDDI specs should not advance to Proposed Standard are incorrect. > Those specs do not violate the requirements of IPv6 unicast addresses, nor > do they introduce a new intra-node naming problem that is not present in > IPv4. I stand corrected on the former but still don't quite agree on the latter. > You are really asking for an additional capability that, at least > superficially, looks like a good idea, but in my opinion needs further > specification and analysis. > > Steve > Dimitry P.S. As promised from draft-ietf-ipngwg-addr-arch-03.txt: 2.1 Addressing Model IPv6 Addresses of all types are assigned to interfaces, not nodes. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node. An IPv6 unicast address refers to a single interface. A single interface may be assigned multiple IPv6 addresses of any type (unicast, anycast, and multicast). There are two exceptions to this model. These are: 1) A single address may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as one interface when presenting it to the internet layer. This is useful for load-sharing over multiple physical interfaces. 2) Routers may have unnumbered interfaces (i.e., no IPv6 address assigned to the interface) on point-to-point links to eliminate the necessity to manually configure and advertise the addresses. Addresses are not needed for point-to-point interfaces on routers if those interfaces are not to be used as the origins or destinations of any IPv6 datagrams. IPv6 continues the IPv4 model that a subnet is associated with one link. Multiple subnets may be assigned to the same link. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 19 13:12:01 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11245; Tue, 19 Dec 95 13:12:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11239; Tue, 19 Dec 95 13:11:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15666; Tue, 19 Dec 1995 13:11:52 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id NAA10867; Tue, 19 Dec 1995 13:11:52 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21911; Tue, 19 Dec 95 16:10:53 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA14155; Tue, 19 Dec 95 16:11:46 EST Date: Tue, 19 Dec 95 16:11:46 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512192111.AA14155@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 933) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > I was prepared to accept your proposal for adding an "interface index" field to > link-local addresses, but when the subject was brought up in the Dallas > meeting, a number of complications and loose-ends were identified -- i.e., > it was clear that this is *not* just a no-brainer change. That's why I, > in my WG chair role, asked for a written proposal (something more than a > "wouldn't it be nice if" email message) that deals with those outstanding > issues, upon which we can seek WG consensus, and then if necessary, revise > the IPv6-over-foo specs. Can someone please to articulate what are the outstanding issues which need to be addressed? Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 19 13:49:42 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11294; Tue, 19 Dec 95 13:49:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11288; Tue, 19 Dec 95 13:49:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21264; Tue, 19 Dec 1995 13:49:35 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id NAA20241; Tue, 19 Dec 1995 13:49:35 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA23338; Tue, 19 Dec 95 16:48:36 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA15712; Tue, 19 Dec 95 16:49:33 EST Date: Tue, 19 Dec 95 16:49:33 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512192149.AA15712@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 934) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Begin Included Message ----- From wling Tue Dec 19 11:32:46 1995 Date: Tue, 19 Dec 95 11:32:41 EST From: wling (Wenken Ling) To: dhaskin@BayNetworks.com Subject: Re: (IPng 926) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Cc: ipng@sunroof.Eng.Sun.COM Content-Length: 1518 >> However, there is a cost with providing this feature. Nodes have to >> ensure some form of stability for their link-local addresses. For instance, >> a reboot of a router (perhaps after installing new interface cards) should >> not change the link-local addresses assigned to its interfaces. >> Protocols like Neighbor Discovery (see section 6.2.8 "Link-local address >> change" in draft-ietf-ipngwg-discovery-03.txt) assume that the >> link-local address of a router doesn't change silently. >> > >Tell me that Neighbor Discovery provides a way to detect a silent address >change (by a timeout, NUD, or whatever). Please.. Section 6.2.8 "Link-local Address Change" states that a link-local address change in a router SHOULD (not MUST) be accompanied by multicasts of RA from the old address with the Router Lifetime field set to zero and a few RAs with the new link-local address. As I understand it, this is basically an optimization since it propagates the new link-local address to link-layer address mapping faster than if you were to just wait for a timeout to trigger the next RA which would include the new mapping. Not doing this will make convergence slower but things still work (this scenario just collapses into the case of a router failing and being "silently" replaced with another working router). NUD provides a way to detect a silent address change - if my address changes I will no longer respond to a unicast NS to the old address with a NA with the solicited bit set. -Wenken ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 19 18:17:25 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11476; Tue, 19 Dec 95 18:17:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11470; Tue, 19 Dec 95 18:17:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25063; Tue, 19 Dec 1995 18:17:19 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id SAA17897; Tue, 19 Dec 1995 18:17:18 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27185 Wed, 20 Dec 1995 13:13:53 +1100 (from kre@munnari.OZ.AU) To: Matt Crawford Cc: bound@zk3.dec.com, Thomas Narten , nordmark@caribe-86.eng.sun.com (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 935) Re: Continuation of WG last call: IPv6 over FDDI In-Reply-To: Your message of "Mon, 18 Dec 1995 09:02:13 MDT." <9512181502.AA26775@munin.fnal.gov> Date: Wed, 20 Dec 1995 13:14:06 +1100 Message-Id: <5231.819425646@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 18 Dec 1995 09:02:13 -0600 From: Matt Crawford Message-ID: <9512181502.AA26775@munin.fnal.gov> According to my notes, someone volunteered to put together the case for using the bits between the 10 bit link-local prefix and the interface token. However, I didn't record who that was. Perhaps the minute-taker did? That was me - that is, I was the sucker (not minute taker). Further, as soon as I have finished writing it you (Matt) are getting to help debug the obvious fatal flaws before it gets sent to the WG and I-D directory... kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 01:53:13 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11698; Wed, 20 Dec 95 01:53:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11692; Wed, 20 Dec 95 01:53:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18745; Wed, 20 Dec 1995 01:53:10 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id BAA06354; Wed, 20 Dec 1995 01:53:09 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12180 Wed, 20 Dec 1995 20:49:09 +1100 (from kre@munnari.OZ.AU) To: Steve Deering Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 936) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Mon, 18 Dec 1995 15:30:01 PST." <95Dec18.153006pst.75270@digit.parc.xerox.com> Date: Wed, 20 Dec 1995 20:49:22 +1100 Message-Id: <5375.819452962@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 18 Dec 1995 15:30:01 PST From: Steve Deering Message-ID: <95Dec18.153006pst.75270@digit.parc.xerox.com> This assumption has already proven to be false in the IPv4 world, and ought to be re-examined for IPv6. "Unnumbered" or "not-separately-numbered" interfaces have become common in IPv4, and are permitted in IPv6 (for routers). This makes no sense, when taken at its most literal. We certainly don't want to start requiring all links to have global addresses, that, as you say, has been shown to be unnecessary, and to consume unnecessary amounts of global address space. However, when considering link local addresses, there is no reason at all to ever have a link without link local addresses. The same address space is reused for every link, so nothing is consumed, further, the existance of the addresses can cause some problems (though certainly not all) to be easier to overcome - eg: a node can easily test whether the remote peer (and link between) on an "unnumbered" link is active, and its IP layer is working, by pinging its link local address - without relying on knowledge of any other addresses the node may have. Further, mechanisms could be employed to allow a node to discover other global addresses that may be available at aneighbour node, using link local addresses for the initial communications. Further, your statement directly contradicts the latest addrconf draft (draft-ietf-addrconf-ipv6-auto-07.txt) which states (on page 7): All interfaces have a link-local unicast address. No ambiguity about that "all interfaces", which must include an interface set up to handle a tunnel link, or any other link that may be unnumbered from the point of global addressing. There is no reason at all to change addrconf in this regard. I think you should seriously consider alternative methods of identifying different interfaces within a single node, such as using interface names (e.g., BSD-style names like "le0" and "sl1"), or interface indices ("0", "1", ...), that will work to locally identify not just "normal" interfaces, but also unnumbered interfaces, tunnel endpoints, etc. The nice thing about using link local addresses for interface identification is that the same addressing structure can be used as for all other IP identification, no need for a special case labels like "le0", further, doing this in initial IPv6 implementations would mean there would be a reasonable chance that the various systems would all use the same addressing mechanism for this purpose, rather than everyone inventing their own - which is of little importance to IPv6 itself, but will make it much more uniform when deployed, and so easier for the users. That's why I, in my WG chair role, asked for a written proposal I am in the process of doing this. Personally I don't see that it requires any specs be delayed currently, the changes will be minor enough (everywhere) if accepted that they can easily be folded into the existing specs (that will mean replacement rfcs for those that have reached that stage - but need not result in delaying their progress from proposed to draft status). The one weird thing about the draft I am writing is that it is absolutely not intended to ever be published as an rfc. It is meant for discussion, then for small parts of it to perhaps be integrated into other drafts (or rfcs), this draft itself will die. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 05:56:59 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11783; Wed, 20 Dec 95 05:56:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11777; Wed, 20 Dec 95 05:56:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27708; Wed, 20 Dec 1995 05:56:49 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id FAA28306; Wed, 20 Dec 1995 05:56:48 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5505; Wed, 20 Dec 95 08:56:22 EST Received: by RTP (XAGENTA 4.0) id 6793; Wed, 20 Dec 1995 08:56:17 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15764; Wed, 20 Dec 1995 08:56:35 -0500 Message-Id: <9512201356.AA15764@cichlid.raleigh.ibm.com> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 937) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Tue, 19 Dec 1995 16:11:46 EST." <9512192111.AA14155@pobox.BayNetworks.com> Date: Wed, 20 Dec 1995 08:56:35 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk dhaskin@BayNetworks.com (Dimitry Haskin) writes: >Can someone please to articulate what are the outstanding issues which need >to be addressed? Off the top of my head: 1) If an interface's link-layer address isn't mapped into a link-local address the same way on all interfaces (on different machines), two nodes with the same link-layer address might select different link-local addresses, and the two nodes would not detect the case when two interfaces happen to have the same link-layer addresses on a link. Currently, if DAD fails on a link-local address, the interface is disabled, preventing two interfaces with the same link-layer address from being used simultaneously. 2) Is this a proposal to change the "interface token" or just a proposal to use (unused) additional bits in the link-local prefix to hold an "interface id"? If the former, how many bits will be needed? Is the cost (in terms of a reduced prefix size) worth the benefits (uniqueness of unicast addresses within a node)? Also, I think it would be undesirable (from DHCP's perspective) to have the interface token be based on something a node computes at startup that may change over time. A change in the hardware configuration (e.g., removing an interface) would change the logical interface number and interface token, which would likely confuse a DHCP server. ND would likely have a problem as well (more below). If the proposal is the latter, i.e., consume bits in the link-local prefix only, DAD will have to be performed on every address. We would effectively have two interface tokens, one used for generating link-local addresses, another for generating all other addresses. Right now, DAD permits a node to test only its link-local address for uniqueness. The assumption is that all nodes use the same set of prefixes, so the interface token being unique insures address uniqueness. Note also that DAD must be run on the link-local address *first*, so that all nodes test the same address first. If two nodes tested different addresses at the same time, both would conclude the addresses were unique (which they are). But it would be incorrect to then not test the other addresses constructed from the same token. The end result is that DAD would need to be run on every address generated via stateless autoconfiguration. If DAD fails, do we disable the interface or just not configure the address? Probably the latter. But this makes it possible for two interfaces using the same link-layer address to be in use simultaneously (e.g., two interfaces could both attempt to configure address X & Y, and one interface ends up using X, the other one using Y. Duplicate IP addresses aren't in use, but duplicate link-layer address are.) 3) Don't we need to apply the same extension to site-local addresses? In theory, a router connecting two autonomous sites might have end up using the same site-local prefix on two interfaces. Deja vu. Since the site-local prefix doesn't really have unused bits in it, however, we'd have to steal bits from the interface token space. Also, wling (Wenken Ling) writes: > >Tell me that Neighbor Discovery provides a way to detect a silent address > >change (by a timeout, NUD, or whatever). Please.. > > > Section 6.2.8 "Link-local Address Change" states that a link-local address > change in a router SHOULD (not MUST) be accompanied by multicasts of RA The SHOULD should probably be a MUST. > from the old address with the Router Lifetime field set to zero and a few > RAs with the new link-local address. As I understand it, this is basically an > optimization since it propagates the new link-local address to link-layer > address mapping faster than if you were to just wait for a timeout to trigger > the next RA which would include the new mapping. Not doing this will > make convergence slower but things still work (this scenario just collapses > into the case of a router failing and being "silently" replaced with another > working router). > NUD provides a way to detect a silent address change - if my address changes > I will no longer respond to a unicast NS to the old address with a NA with > the solicited bit set. Things are slightly more complicated than the above paragraph suggests. The reason routers are required to use link-local addresses in ND is that those addresses are expected to rarely (if ever) change. Currently, if a router sends a redirect for destination XXX to a host, the host ignores the redirect if it comes from a source address different than the first-hop address it is using when forwarding traffic to XXX. If a host never learns that a router's link-local address has changed, it will ignore redirect info from that router. Because hosts don't time out redirects, a router MUST tell the host that its address has changed; the host won't automatically time it out. So the above is required for correctness (in this particular case) and is not just an optimization. [Note that should the first-hop stop working, NUD will time-out the entry and choose a new router, but that would only happen if the router stopped working.] Note also that if a router reboots with a different link-local address, it is unlikely to have remembered the previous link-local address it was using, and it won't be able to send out RAs saying that the old link-local address is no longer valid. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 07:56:04 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11902; Wed, 20 Dec 95 07:56:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11896; Wed, 20 Dec 95 07:55:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06576; Wed, 20 Dec 1995 07:55:53 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id HAA17266; Wed, 20 Dec 1995 07:55:54 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HZ0YFZP2EO00312W@FNAL.FNAL.GOV>; Wed, 20 Dec 1995 09:55:48 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA04906; Wed, 20 Dec 95 09:54:08 CST Date: Wed, 20 Dec 1995 09:54:08 -0600 From: Matt Crawford Subject: (IPng 938) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of Wed, 20 Dec 95 08:56:35 -0400. <9512201356.AA15764@cichlid.raleigh.ibm.com> To: Thomas Narten Cc: dhaskin@BayNetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com Message-Id: <9512201554.AA04906@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ 2) Is this a proposal to change the "interface token" or just a > proposal to use (unused) additional bits in the link-local prefix to > hold an "interface id"? The link-local prefix *is* 10 bits. Period. There's no argument about that, is there? Whether and how we use the remaining 118-N is under discussion. > If the former, how many bits will be needed? Is the cost (in terms of > a reduced prefix size) See above. > If the proposal is the latter, i.e., consume bits in the link-local > prefix only, See above. > DAD will have to be performed on every address. [...] Right now, > DAD permits a node to test only its link-local address for > uniqueness. Or every node would have to do DAD (doodad, ha ha) and respond to DAD on the address formed with all zeroes in the in-between bits. Or, link-local addresses are excluded from the addrconf dictum that only one address formed from a given token needs to be checked with DAD. Or (my own suggestion of earlier this week), for each prefix length only one address formed from a given token needs to be checked, and the implementor is reminded that the link-local address is 10 bits long, not 80. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 08:38:59 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11951; Wed, 20 Dec 95 08:38:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11945; Wed, 20 Dec 95 08:38:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10995; Wed, 20 Dec 1995 08:36:28 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA26738; Wed, 20 Dec 1995 08:36:28 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9437; Wed, 20 Dec 95 11:36:01 EST Received: by RTP (XAGENTA 4.0) id 6862; Wed, 20 Dec 1995 11:35:57 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA02693; Wed, 20 Dec 1995 11:36:11 -0500 Message-Id: <9512201636.AA02693@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: dhaskin@BayNetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com Subject: (IPng 939) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Wed, 20 Dec 1995 09:54:08 CST." <9512201554.AA04906@munin.fnal.gov> Date: Wed, 20 Dec 1995 11:36:11 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: >> 2) Is this a proposal to change the "interface token" or just a >> proposal to use (unused) additional bits in the link-local prefix to >> hold an "interface id"? >The link-local prefix *is* 10 bits. Period. There's no argument >about that, is there? Whether and how we use the remaining 118-N is >under discussion. Strictly speaking, of course the above is true. I'm looking at the issue from a slightly different angle. We can view the proposed change as applying only to link-local addresses, in which case we have not really changed the size/formation of the interface token. However, we now conceptually have two tokens, one used for link-local address generation, the other for all other addresses. This has implications for DAD at the very least. Or one can look at it as a change in the interface token (i.e., the interface identifier is logically part of the token), in which case the interface token will still be unique for all address formations, but we've effectively reduced the maximum size a prefix can be (not so good). I think Dimitry's specific proposal is to change link-local address formation only, so we effectively get two tokens. >> If the former, how many bits will be needed? Is the cost (in terms of >> a reduced prefix size) >See above. If the proposal effectively makes the interface identifier part of the token, we've just made the maximum allowable prefix smaller. >> DAD will have to be performed on every address. [...] Right now, >> DAD permits a node to test only its link-local address for >> uniqueness. >Or every node would have to do DAD (doodad, ha ha) and respond to DAD >on the address formed with all zeroes in the in-between bits. Ugh. I think Erik's original point applies here. The benefits of tagging a link-local address with a logical interface identifier must be balanced against all the costs of doing so. >Or (my own suggestion of earlier this week), for each prefix length >only one address formed from a given token needs to be checked, and >the implementor is reminded that the link-local address is 10 bits >long, not 80. I don't think this is sufficient. Consider two interfaces that have the same token. They both want to configure addresses X1 and X2, but node 1 runs DAD on X1 first while node 2 runs DAD on X2. Result: they both conclude the address is unique. If they then skip DAD on the remaining address, oops. Addrconf requires that DAD be performed on the link-local address first to avoid this problem. >Or (my own suggestion of earlier this week), for each prefix length ^^^^^^^^^^^^^^^^^^^^^^ Also, although this doesn't bear on your point, all prefixes contained in RAs (on the same link) have the same length. We've defined the interface token to have a fixed length, and addrconf makes it an error to pad a short prefix with zeros to make it long enough to combine with a token. We wanted to avoid the case of getting two seemingly different prefix announcements, that were in fact the same, i.e., the longer prefix just had more zeros in it. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 12:21:54 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12198; Wed, 20 Dec 95 12:21:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12192; Wed, 20 Dec 95 12:21:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14169; Wed, 20 Dec 1995 12:21:50 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id MAA04368; Wed, 20 Dec 1995 12:21:49 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA25040; Wed, 20 Dec 1995 15:16:32 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03678; Wed, 20 Dec 1995 15:16:27 -0500 Message-Id: <9512202016.AA03678@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 940) DISCUSSION: Use of multiple Addresses on Interfaces Date: Wed, 20 Dec 95 15:16:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Have to open a discussion in IPng that came up on the DHCPv6 WG list. We were in discussion why a client would ever know it needs more addresses for an interface than a server provides them in a response to a DHCPv6 DISCOVER addresses and other network paramenters. Folks went back and forth la la la..... But we need to do a logic check on IPng architecturally what the perceived rules are as we have not stated them for a specific case. I do not believe when we clearly articulated at the IETF IPng Interim meeting Oct 93 at Cambridge MA the rule that interfaces can support multiple addresses, we did not intend any "rule-set" of how or why those addresses can be used. Nothing prevents us giving NFS 1::2, WEB Server 1::3, and DBMS-1 1::14, and DBMD-2 1::37. It is an implementation manner. This is the architectural issue raised on DHCPv6. More discussion below. If a DHCPv6 client knows as an END-SYSTEM that is fully loaded with configuration to act as a Network Server that it wants to use different addresses for the END-SYSTEMS: NFS Server, WEB Server, Secure Connected Servers, and NON-Secure Services (e.g. secure telnet and non-secure telnet server) why would this not be allowed in IPv6? Today nothing prevents this in any spec. The other problem is that what really is the issue is "port space". Doing the above is avoiding using a different port for WEB Server #1 and WEB Server #2. Or if a user is USING security for one telnet server (confidential data available at login) and on the other telnet server the user IS NOT USING security one way to implement this on the same interface is to have two IPv6 addresses for the interface. In the cases above after the DHCPv6 client starts and has received the addresses that the server is to give the client, the client later during the course of its existence learns it needs to have these other addresses discussed above. So it requests those addresses. Some say there needs to be manual interaction between lets say Dept A and where the DHCPv6 server is located to make sure the server "knows" what addresses are needed. I think this is bogus. Some say we are assigning addresses to services if we permit this model. I say so what? What are addresses used for? I veiw it as this is the address where you can get to this application. It may or may not be a service. Service is a broad term (too broad for me). I see nothing wrong with an END-SYSTEM using DHCPv6 to request addresses for application functions that need different addresses. In addition I do not believe REQUIRING DHCPv6 servers to have a priori all knowledge of all addresses a client needs leaving a client END-SYSTEM with an administrative out-of-band problem is reasonable in the market. My assumption is that departments in private industry will want autonomy to dynamically request addresses for application functions the client needs from a DHCPv6 Server without any paperwork, phone calls, or meetings to discuss what is really pretty simple. Anyway for this list those are my biases clearly. But the important question in doing this does it break any intent of IPv6. I think the answer is no. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 13:36:54 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12543; Wed, 20 Dec 95 13:36:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12537; Wed, 20 Dec 95 13:36:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23620; Wed, 20 Dec 1995 13:36:44 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA22343; Wed, 20 Dec 1995 13:36:44 -0800 Subject: (IPng 941) Re: DISCUSSION: Use of multiple Addresses on Interfaces To: ipng@sunroof.eng.sun.com Date: Wed, 20 Dec 1995 16:37:07 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9512201637.aa07206@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > Nothing prevents us giving NFS 1::2, WEB Server 1::3, and > DBMS-1 1::14, and DBMD-2 1::37. It is an implementation manner. This > is the architectural issue raised on DHCPv6. More discussion below. I don't believe anything PREVENTS us from giving services different addresses. Whether or not it is a good idea, or brain-damage, is, IMHO, irrelevant w.r.t. your question. > If a DHCPv6 client knows as an END-SYSTEM that is fully loaded with > configuration to act as a Network Server that it wants to use different > addresses for the END-SYSTEMS: NFS Server, WEB Server, Secure Connected > Servers, and NON-Secure Services (e.g. secure telnet and non-secure > telnet server) why would this not be allowed in IPv6? Today nothing > prevents this in any spec. Nothing really does prevent this in any spec. Again, the question of whether it's a good idea pops into my head, but it is, again, not explicitly forbidden in any spec I'm aware of. > Anyway for this list those are my biases clearly. But the important > question in doing this does it break any intent of IPv6. I think the > answer is no. The only "intent" of IPv6 it breaks is (again, IMHO) the need to use address space better. IMHO, addresses per service are VERY WASTEFUL. Then again, with DHCP, perhaps the 48-bits per subnet (because of stateless addrconf) can be used more fruitfully. If that were the case, then I have less of a problem with it. No subnet I'm aware of will have 2^48 nodes (even a big ATM cloud), so a smartly implemented DHCPv6 server that pays attention to what link-addresses are out there can probably use the remaining 2^48 - ~200 numbers to do all the address-per-service assigning it needs to. PLEASE NOTE: I don't follow DHCP or DHCPv6. The bottom line is that there is nothing (AFAIK) in the spec that forbids assigning multiple addresses per interface solely for the purpose of different services. The other part of the bottom line is that IN MY OPINION, addresses per service is a bad idea. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 14:32:25 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12612; Wed, 20 Dec 95 14:32:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12606; Wed, 20 Dec 95 14:32:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01026; Wed, 20 Dec 1995 14:32:21 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id OAA06304; Wed, 20 Dec 1995 14:32:19 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA27159; Wed, 20 Dec 1995 17:29:01 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15962; Wed, 20 Dec 1995 17:29:01 -0500 Message-Id: <9512202229.AA15962@wasted.zk3.dec.com> To: Dan McDonald Cc: ipng@sunroof.eng.sun.com Subject: (IPng 942) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Wed, 20 Dec 95 16:37:07 EST." <9512201637.aa07206@cs.nrl.navy.mil> Date: Wed, 20 Dec 95 17:29:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, >PLEASE NOTE: I don't follow DHCP or DHCPv6. The bottom line is that there >is nothing (AFAIK) in the spec that forbids assigning multiple addresses per >interface solely for the purpose of different services. The other part of >the bottom line is that IN MY OPINION, addresses per service is a bad idea. I agree with you technically. But as an engineer I am also concerned about the use of technology being deployed and how users will use it. I think I am beginning now to ask myself a new question? Why are we permitting multiple addresses per interface in IPv6? What reason was in our minds when we said we wanted this at Cambridge MA? We never discussed that question other than fault tolerance/mutlihoming. I don't think we have to now IMHO. We have given users the capability to do with it what they want. Let me put it another way does anyone want to put more restrictions in our specifications for multiple addresses per interface or addresses in general? Users should be able to tell address configuration I want an address? We have decided that IPv6 will let users ask for multiple addresses on an interface. Its up to those users what they want to do with those addresses and they should be able to request them. I don't think in any standard we can say your not allowed to request them for this reason or that reason. Steve Deering/Bob Hinden would you comment or give guidance on this discussion ----> thanks???? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 14:53:10 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12630; Wed, 20 Dec 95 14:53:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12624; Wed, 20 Dec 95 14:52:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03732; Wed, 20 Dec 1995 14:53:01 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id OAA11485; Wed, 20 Dec 1995 14:53:00 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HZ1CZHKPYO0038LX@FNAL.FNAL.GOV>; Wed, 20 Dec 1995 16:52:23 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA06559; Wed, 20 Dec 95 16:50:41 CST Date: Wed, 20 Dec 1995 16:50:41 -0600 From: Matt Crawford Subject: (IPng 943) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of Wed, 20 Dec 95 11:36:11 -0400. <9512201636.AA02693@cichlid.raleigh.ibm.com> To: Thomas Narten Cc: dhaskin@BayNetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com Message-Id: <9512202250.AA06559@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ >Or (my own suggestion of earlier this week), [blah blah blah] > > I don't think this is sufficient. Consider two interfaces that have > the same token. They both want to configure addresses X1 and X2, but > node 1 runs DAD on X1 first while node 2 runs DAD on X2. Result: they > both conclude the address is unique. If they then skip DAD on the > remaining address, oops. You got me there. So we're reduced to two choices. No, three. 1. Test every address with DAD. 2. Always test and respond to the link-local address which has all zeros in the in-between bits. (Ugly, nasty.) 3. Forget about ever using the bits between the link-local prefix and the address token. > Also, although this doesn't bear on your point, all prefixes contained > in RAs (on the same link) have the same length. No, but the subset which may be autonomously configured by the hosts must all have the same length, 128-N. But those are the ones we're concerned with here. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 14:57:34 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12642; Wed, 20 Dec 95 14:57:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12636; Wed, 20 Dec 95 14:57:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04435; Wed, 20 Dec 1995 14:57:23 -0800 Received: from research.att.com by mercury.Sun.COM (Sun.COM) id OAA12605; Wed, 20 Dec 1995 14:57:23 -0800 From: smb@research.att.com Message-Id: <199512202257.OAA12605@mercury.Sun.COM> Received: from research by ns; Wed Dec 20 17:56:06 EST 1995 Received: by gryphon; Wed Dec 20 17:56:17 EST 1995 To: bound@zk3.dec.com Cc: Dan McDonald , ipng@sunroof.eng.sun.com Subject: (IPng 944) Re: DISCUSSION: Use of multiple Addresses on Interfaces Date: Wed, 20 Dec 95 17:56:17 EST Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think I am beginning now to ask myself a new question? Why are we permitting multiple addresses per interface in IPv6? What reason was in our minds when we said we wanted this at Cambridge MA? We never discussed that question other than fault tolerance/mutlihoming. I don't think we have to now IMHO. We have given users the capability to do with it what they want. Well, I set forth my reasons; see RFC 1681. And while I wasn't at the Cambridge meeting, I did raise the issue at the Big 10 meeting, notably in the suggestion that the incorporation of the link address into the IPv6 address leave room on the right for such extra addresses. This was intended to follow our aggregation principles; the router would need just one entry for all such addresses. Let me put it another way does anyone want to put more restrictions in our specifications for multiple addresses per interface or addresses in general? Users should be able to tell address configuration I want an address? We have decided that IPv6 will let users ask for multiple addresses on an interface. Its up to those users what they want to do with those addresses and they should be able to request them. I don't think in any standard we can say your not allowed to request them for this reason or that reason. In fact, using multiple addresses is becoming common today, to permit www.foo.com and www.bar.com to coexist on a single machine. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 16:12:43 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12732; Wed, 20 Dec 95 16:12:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12726; Wed, 20 Dec 95 16:12:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14731; Wed, 20 Dec 1995 16:12:36 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id QAA29639; Wed, 20 Dec 1995 16:12:36 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15383(1)>; Wed, 20 Dec 1995 16:12:27 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 20 Dec 1995 16:10:13 -0800 To: Robert Elz Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 945) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: kre's message of Wed, 20 Dec 95 01:49:22 -0800. <5375.819452962@munnari.OZ.AU> Date: Wed, 20 Dec 1995 16:10:06 PST From: Steve Deering Message-Id: <95Dec20.161013pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, I think you are mixing up two separate parts of my response to Dimitry, no doubt due to my insufficiently clear writing. Dimitry made two claims: (1) He claimed that the IPv6 addressing architecture document requires that the link-local addresses of each interface of a multi-interface node must each be different. I responded that that is incorrect (though I accept his point that the addressing document could be clearer -- that's almost always true). Two interfaces may have the same link-local address if they are attached to different links. This is true whether those two interfaces are plugged into a single node or into two different nodes. (2) He claimed that the possibility of duplicate link-local addresses within a node created a naming problem (the lack of a distinct address for each interface of a node) that does not exist in IPv4. I responded with several examples of where, in IPv4, a node may have multiple interfaces but not have a unique unicast address for each of those interfaces. With that restatement of what I was trying to say, let me respond to your points. > This assumption has already proven to be false in the IPv4 world, and > ought to be re-examined for IPv6. "Unnumbered" or "not-separately- > numbered" interfaces have become common in IPv4, and are permitted > in IPv6 (for routers). > > This makes no sense, when taken at its most literal. > ...when considering link local addresses, there is > no reason at all to ever have a link without link local > addresses. The sentences you quoted from me, above, were not talking about link-local addresses, so it is incorrect to read them as implying that it is possible to have an interface without a link-local address. I agree that every interface must have a link-local address. I argue that more than one interface can legally have the *same* link-local address, as long as they attach to different links. The "assumption" I was referring to was the assumption that a multi- interface node has a unique unicast address for each of its interfaces. It has become false in the IPv4 world, and is not necessarily true in the IPv6 world (unless we decide to *make* it true in the IPv6 world by specifying that each interface of a multi-interface node must have a *different* link-local address -- but that would be loading an additional requirement on link-local addresses that is not necessary for their intended purpose). > ...The same address space is reused for every link, > so nothing is consumed, further, the existance of the addresses > can cause some problems (though certainly not all) to be > easier to overcome - eg: a node can easily test whether the > remote peer (and link between) on an "unnumbered" link is > active, and its IP layer is working, by pinging its link local > address - without relying on knowledge of any other addresses > the node may have. Further, mechanisms could be employed > to allow a node to discover other global addresses that may > be available at aneighbour node, using link local addresses > for the initial communications. Yes, yes, yes. I agree with all that. > Further, your statement directly contradicts the latest > addrconf draft (draft-ietf-addrconf-ipv6-auto-07.txt) > which states (on page 7): > > All interfaces have a link-local unicast address. I did not make a statement that contradicts that sentence. Yes, all interfaces have a link-local address. That does not imply that all interfaces have *different* link-local addresses. > No ambiguity about that "all interfaces", which must include > an interface set up to handle a tunnel link, or any other > link that may be unnumbered from the point of global addressing. Agreed. > I think you should seriously consider alternative methods of identifying > different interfaces within a single node, such as using interface names > (e.g., BSD-style names like "le0" and "sl1"), or interface indices > ("0", "1", ...), that will work to locally identify not just "normal" > interfaces, but also unnumbered interfaces, tunnel endpoints, etc. > > The nice thing about using link local addresses for interface > identification is that the same addressing structure can be > used as for all other IP identification, no need for a special > case labels like "le0", further, doing this in initial IPv6 > implementations would mean there would be a reasonable chance > that the various systems would all use the same addressing > mechanism for this purpose, rather than everyone inventing their > own - which is of little importance to IPv6 itself, but will > make it much more uniform when deployed, and so easier for the > users. Maybe so. But note that you would be giving up some desirable properties if you changed from "le0" style names to interface indices wrapped in IPv6 address clothing. For example, an Ethernet interface named "ether0" is unlikely to change if you add a PPP interface to the same node, but an Ethernet interface named "interface 0" might well become "interface 1" when a PPP interface is added to the node (the PPP interface becoming "interface 0", because when the node boots, it initializes its serial interfaces before its Ethernets, or whatever). That's likely to make management more complicated, not less. My point is, the definition of link-local addresses requires uniqueness only across the set of interfaces attached to a *link*, not the set of interfaces attached to a *node*. If you want link-local addresses to be unique across all the interfaces of a node, please recognize that this is an *additional* requirement imposed on link-local addresses, one that is *not* necessary for their correct operation. We might decide to impose this additional requirement on link-local addresses to help with the intra-node interface naming problem, but we could just as well solve that problem other ways, e.g., by using local interface names or indices, or even (if you *really* insist on using interface names that look syntactically like addresses) by defining a new "node-local" class of IPv6 addresses (that would basically be a new constant prefix plus an interface index number). > The one weird thing about the draft I am writing is that it > is absolutely not intended to ever be published as an rfc. > It is meant for discussion, then for small parts of it to > perhaps be integrated into other drafts (or rfcs), this draft > itself will die. Correct. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 16:35:48 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12749; Wed, 20 Dec 95 16:35:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12743; Wed, 20 Dec 95 16:35:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17743; Wed, 20 Dec 1995 16:35:38 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id QAA04492; Wed, 20 Dec 1995 16:35:39 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA16114; Wed, 20 Dec 95 19:34:37 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA07276; Wed, 20 Dec 95 19:35:34 EST Date: Wed, 20 Dec 95 19:35:34 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512210035.AA07276@pobox.BayNetworks.com> To: dhaskin@BayNetworks.com, narten@VNET.IBM.COM Subject: (IPng 946) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >1) If an interface's link-layer address isn't mapped into a link-local >address the same way on all interfaces (on different machines), two >nodes with the same link-layer address might select different >link-local addresses, and the two nodes would not detect the case when >two interfaces happen to have the same link-layer addresses on a >link. Currently, if DAD fails on a link-local address, the interface >is disabled, preventing two interfaces with the same link-layer >address from being used simultaneously. Regardless of media type, Interface Id has to be in the fixed location of the link-local address . So the duplicate MAC address detection can be trivially made. But I agree that it requires a small change in the autoconfiguration spec wrt the DAD with link-local addresses. . >2) Is this a proposal to change the "interface token" or just a >proposal to use (unused) additional bits in the link-local prefix to >hold an "interface id"? The latter. .... >If the proposal is the latter, i.e., consume bits in the link-local >prefix only, DAD will have to be performed on every address. We would >effectively have two interface tokens, one used for generating >link-local addresses, another for generating all other addresses. >Right now, DAD permits a node to test only its link-local address for >uniqueness. The assumption is that all nodes use the same set of >prefixes, so the interface token being unique insures address >uniqueness. Note also that DAD must be run on the link-local address >*first*, so that all nodes test the same address first. If two nodes >tested different addresses at the same time, both would conclude the >addresses were unique (which they are). But it would be incorrect to >then not test the other addresses constructed from the same token. >The end result is that DAD would need to be run on every address >generated via stateless autoconfiguration. When DAD is run on the link-local address the Interface id portion of the address is to be assumed to be all zero when addresses are compared. Short of this DAD procedure should not change. >If DAD fails, do we disable the interface or just not configure the >address? Probably the latter. But this makes it possible for two >interfaces using the same link-layer address to be in use >simultaneously (e.g., two interfaces could both attempt to configure >address X & Y, and one interface ends up using X, the other one using >Y. Duplicate IP addresses aren't in use, but duplicate link-layer >address are.) See above. >3) Don't we need to apply the same extension to site-local addresses? I don't think so. >In theory, a router connecting two autonomous sites might have end up >using the same site-local prefix on two interfaces. Deja vu. Since the >site-local prefix doesn't really have unused bits in it, however, we'd >have to steal bits from the interface token space. I don't think this should be allowed to happen. Furthermore, since an interface token may not be unique across node's interfaces, if the stateless autoconfiguration is used, it can be problematic to allow more than one interface of the same node to be connected to the same subnet of any type of unicast address. At least before this done one needs to assure that such interfaces would come up with different tokens. Also, wling (Wenken Ling) writes: > >Tell me that Neighbor Discovery provides a way to detect a silent address > >change (by a timeout, NUD, or whatever). Please.. > > > Section 6.2.8 "Link-local Address Change" states that a link-local address > change in a router SHOULD (not MUST) be accompanied by multicasts of RA The SHOULD should probably be a MUST. > from the old address with the Router Lifetime field set to zero and a few > RAs with the new link-local address. As I understand it, this is basically an > optimization since it propagates the new link-local address to link-layer > address mapping faster than if you were to just wait for a timeout to trigger > the next RA which would include the new mapping. Not doing this will > make convergence slower but things still work (this scenario just collapses > into the case of a router failing and being "silently" replaced with another > working router). > NUD provides a way to detect a silent address change - if my address changes > I will no longer respond to a unicast NS to the old address with a NA with > the solicited bit set. >Things are slightly more complicated than the above paragraph >suggests. The reason routers are required to use link-local addresses >in ND is that those addresses are expected to rarely (if ever) >change. Currently, if a router sends a redirect for destination XXX to >a host, the host ignores the redirect if it comes from a source >address different than the first-hop address it is using when >forwarding traffic to XXX. If a host never learns that a router's >link-local address has changed, it will ignore redirect info from that >router. Because hosts don't time out redirects, a router MUST tell the >host that its address has changed; the host won't automatically time >it out. So the above is required for correctness (in this particular >case) and is not just an optimization. [Note that should the first-hop >stop working, NUD will time-out the entry and choose a new router, but >that would only happen if the router stopped working.] >Note also that if a router reboots with a different link-local >address, it is unlikely to have remembered the previous link-local >address it was using, and it won't be able to send out RAs saying that >the old link-local address is no longer valid. Now we have a problem! But not because of the interface id in the link-local address. As matter of fact, in the IP implementations I'm familiar with, the internal index (locators) of an existing physical interface doesn't change even when other interfaces are added or deleted. To do it differently would require to re-configure existing interfaces every time some other interface is deleted. But it is quite normal to replace a port module. In this respect interface indexes are far more stable than link layer addresses. So how does ND handle a link-local address change due to a MAC address change? Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 17:54:25 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12821; Wed, 20 Dec 95 17:54:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12815; Wed, 20 Dec 95 17:54:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26705; Wed, 20 Dec 1995 17:54:19 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id RAA19118; Wed, 20 Dec 1995 17:54:19 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15448(8)>; Wed, 20 Dec 1995 17:54:11 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 20 Dec 1995 17:53:50 -0800 To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 947) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: dhaskin's message of Tue, 19 Dec 95 11:11:23 -0800. <9512191911.AA07700@pobox.BayNetworks.com> Date: Wed, 20 Dec 1995 17:53:37 PST From: Steve Deering Message-Id: <95Dec20.175350pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I have remove the IESG mailing list from the cc line of this reply, to save them from having to wade through even more of this level of discussion. If we reach some new consensus, we'll post a summary to the iesg folks. -Steve] Dimitry, > Yet another fine example of vagueness of an architectural document. Apparently so! Thanks for helping to identify those points of vagueness; we'll try to fix them at the first opportunity to rev the RFC. > I think my interpretation comes naturally from the reading of section 2.1 > of the IPv6 addressing architecture (For those who didn't read the > document, I've attached this section in entirety to this message). The problem is that section 2.1 doesn't refer to address scope at all, i.e., to link-local and site-local addresses. So naturally you assumed that it applies to all addresses, when in fact the authors simply forgot about the scoped unicast addresses when they wrote that section. So, for example, the following sentence from that section: An IPv6 unicast address refers to a single interface. really ought to say: An IPv6 unicast address refers to a single interface within the scope of that address. Also, the following statement overlooks the existance of link-local addresses: 2) Routers may have unnumbered interfaces (i.e., no IPv6 address assigned to the interface) on point-to-point links to eliminate the necessity to manually configure and advertise the addresses. Every interface will at least have a link-local address. (Of course, those do not have to be manually configured or advertised in the routing system.) > I think it is also logical to treat a router as a link between all its > interfaces. That may be a useful abstraction in your implementation, but your imagined internal link is not an instance of a "link" as defined for IPv6. In any case, your internal "logical link" does not make the interfaces attached to one "real" link become attached to a different "real" link. The scope of a link-local address is the set of interfaces that attach to the same link. It does not include interfaces that attach to other links. > My point is that, if you have an IPv4 address assigned to an interface, > it unambiguously identifies this interface withing a single box. Your > Frame Relay example is not an exception since a VC bundle is treated > by IP as a single physical interface to a multicast media (same as Ethernet). That's not what I heard at the ipngwg meeting at the Digital reasearch lab in Cambridge. At that meeting, I tried the tack you are trying: I suggested that every interface should have a unique address and I was shot down by those who treat the set of Frame Relay VCs that converge on a single FR interface as multiple point-to-point links, and they didn't want the administrative burden of having a separate IP address for each of those links. I suspect also that certain routing protocols would *require* that you treat an FR relay as a set of p-to-p links, rather than as an interface to a multi-access link, at least in those cases where you don't have a full mesh of VCs -- do all IP routing protocols work over media where not every router can reach every other router? > "Unnumbered" interfaces don't have an address so it is an ugly special case > introduced into IPv4 for the address conservation purpose. It may be ugly, but it is a true example from IPv4 which disproves your claim that in IPv4 all interfaces have unique IP addresses. > Actually "unnumbered" interfaces is the only special case in respect of > interface addressing that we've had to handle differently in IPv4. So, you *did* have to deal with non-uniquely numbered interfaces in IPv4, contrary to the claim in your original message. Also, you forgot about tunnels. Those are links too, whose endpoints are typically not given unique addresses. > Fine. But again short of unnumbered interfaces (where no address is > provided), which IMO should be removed from IPv6 architecture, the > link-local address is so far the only case (at least as I can tell) > where an address may identify multiple interfaces of a single node. Certainly, we could eliminate the notion of unnumbered interfaces and require that all links (tunnels included) be assigned at least a link- local address. That's a separate issue from whether or not those link- local adresses must be unique across all the interfaces of a single node. I disagree with your contention that link-local addresses are the only case of sharing a unicast address across multiple interfaces, but even if it were true, so what? Link-local addresses (and site-local addresses) are something new in IPv6, something different from global unicast addresses, so you should not be surprised that they have different properties than global unicast addresses. In particular, they have the property that the same address can be reused in different topological regions (either different links or different sites) -- if that were not the case, we would require global uniqueness for link-local addresses, which is a much more difficult property to guarantee than simple link uniqueness. A node that attaches to multiple such topological regions then needs to be able to cope with the fact that the same address may be valid in each of those regions, identifying different interfaces, possibly different interfaces on the node itself. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 18:08:14 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12838; Wed, 20 Dec 95 18:08:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12832; Wed, 20 Dec 95 18:08:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28064; Wed, 20 Dec 1995 18:08:07 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id SAA21907; Wed, 20 Dec 1995 18:08:07 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07001 Thu, 21 Dec 1995 13:07:27 +1100 (from kre@munnari.OZ.AU) To: Steve Deering Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 948) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Wed, 20 Dec 1995 16:10:06 PST." <95Dec20.161013pst.75270@digit.parc.xerox.com> Date: Thu, 21 Dec 1995 13:07:40 +1100 Message-Id: <5521.819511660@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 20 Dec 1995 16:10:06 PST From: Steve Deering Message-ID: <95Dec20.161013pst.75270@digit.parc.xerox.com> I think you are mixing up two separate parts of my response to Dimitry, Perhaps. The sentences you quoted from me, above, were not talking about link-local addresses, That was not clear. I agree that every interface must have a link-local address. Fine, though I note that Ran sent a recent message, in reply to mine, arguing against exactly that, so it seems this has not been made clear enough. I argue that more than one interface can legally have the *same* link-local address, as long as they attach to different links. Yes. Further, nothing in the draft I am creating in any way changes that (to attempt to do so would be folly, there are too many ways that this could happen to attempt to prevent them all). The "assumption" I was referring to was the assumption that a multi- interface node has a unique unicast address for each of its interfaces. OK, that wasn't clear either. It has become false in the IPv4 world, and is not necessarily true in the IPv6 world (unless we decide to *make* it true in the IPv6 world by specifying that each interface of a multi-interface node must have a *different* link-local address -- but that would be loading an additional requirement on link-local addresses that is not necessary for their intended purpose). Yes, I understood that comment. The current question seems, to me, to be whether there is anything to be gained by permitting (I was not proposing requiring) nodes to cause their link local addresses to be unique within themselves. [...] That does not imply that all interfaces have *different* link-local addresses. No, there is certainly nothing in the current specs that requires that, or for that matter even permits it in some cases. Currently, the link-local address is required to come from a "manufacturer assigned" MAC address for most media (all that currently have specs, I am waiting to see how PPP is proposing to handle this, and appletalk). If a node has multiple (say ethernet) interfaces, and only one manufacturer assigned MAC address to use as its token, then it is currently *required* to have duplicate link local addresses. What I'd like to do is delete that requirement. I don't think that having nodes invent tokens (probably by some form of arithmetic on a token they start with) is sensible, but making use of some of those 80 zeroes sees like it might be a viable solution. For example, an Ethernet interface named "ether0" is unlikely to change if you add a PPP interface to the same node, but an Ethernet interface named "interface 0" might well become "interface1" when a PPP interface is added to the node (the PPP interface becoming "interface 0", because when the node boots, it initializes its serial interfaces before its Ethernets, or whatever). That's likely to make management more complicated, not less. Well, maybe. I don't actually see that the problem changes. Sure, adding a ppp interface isn't likely to change the name of an existing ethernet interface using the form (as in le0, ppp0, etc), but adding a new ethernet, or ppp interface is just as likely to change the numbers of others. With some boxes I have to deal with I am still yet to fathom how the part is assigned (I'm sure there's an algorithm, but it has defeated me). I figure out which interface is 0, 1, (etc), by connecting them all to cables, configuring some random (IPv4) address on each, then running tcpdump to see what other traffic is out there, so I know which cable each interface is connected to. Then I find that cable, and see which interface I am physically plugged into, and from that associate the hardware with the number. Every time a new interface is added the procedure gets repeated, as the numbers (to me at least) don't appear stable. If I knew the algorithm I could probably avoid a lot of this, by knowing which slot I should stick the first ethernet interface in so it will always be '0', no matter what else is added, but I don't... With the extra field, this can be avoided to some extent. Note that there will be no requirement for the numbers to be 0 1 2 3 (etc). Manufacturers could choose to place some hardware specific encoding in the field, so that as long as the hardware remains attached to the same physical location, the interface designation would remain stable, regardless of what else is added elsewhere. This is what will actually be recommended. Combining that possibility with the attractiveness (to me) of having a single IPv6 related addressing/identifying mechanism, causes me to believe in this as a simple (almost cost free) addition to make. My point is, the definition of link-local addresses requires uniqueness only across the set of interfaces attached to a *link*, not the set of interfaces attached to a *node*. Understood. If you want link-local addresses to be unique across all the interfaces of a node, please recognize that this is an *additional* requirement imposed on link-local addresses, one that is *not* necessary for their correct operation. Understood (by me, always) We might decide to impose this additional requirement on link-local addresses to help with the intra-node interface naming problem, but we could just as well solve that problem other ways, e.g., by using local interface names or indices, or even (if you *really* insist on using interface names that look syntactically like addresses) by defining a new "node-local" class of IPv6 addresses (that would basically be a new constant prefix plus an interface index number). Yes, any of those are possible. However it seems to me that a trifling change to link local addresses (which are defined to exist already) can cause them to have the "right" properties, where required. At this stage, it really might be better to wait for the draft to appear. That will probably take a couple of weeks (sorry about that, its the time of year, and I really do need someone else to read it and find the places where my sentences that go on for pages, etc, and really need fixing, exist, and how they should be modified, plus any fatal obvious technical flaws fixed before it appears in public). As I said last time, I don't think it will be necessary to delay the IPv6 over foo specs from IESG approval (even assuming the IESG plan on working much in the nest week or so to approve them...). The changes to those specs will, even if this is accepted, by miniscule, just basically saying "here is this field defined in addrconf, use it the addrconf way". The substance of the changes will be in addrconf, where link local addresses are described in detail - which also is the only place it makes sense, in every IPv6 over foo the same words would need to be repeated otherwise. Even addrconf, can go ahead as it is, the changes there will also not affect almost anything that exists, and be a minor addition comparatively, if accepted. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 20:32:13 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12966; Wed, 20 Dec 95 20:32:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12960; Wed, 20 Dec 95 20:32:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07423; Wed, 20 Dec 1995 20:32:06 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id UAA08798; Wed, 20 Dec 1995 20:32:08 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA15466; Wed, 20 Dec 1995 23:23:56 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25206; Wed, 20 Dec 1995 23:23:55 -0500 Message-Id: <9512210423.AA25206@wasted.zk3.dec.com> To: Steve Deering Cc: Robert Elz , iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 949) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Wed, 20 Dec 95 16:10:06 PST." <95Dec20.161013pst.75270@digit.parc.xerox.com> Date: Wed, 20 Dec 95 23:23:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >My point is, the definition of link-local addresses requires uniqueness only >across the set of interfaces attached to a *link*, not the set of interfaces >attached to a *node*. If you want link-local addresses to be unique across >all the interfaces of a node, please recognize that this is an *additional* >requirement imposed on link-local addresses, one that is *not* necessary for >their correct operation. We might decide to impose this additional >requirement on link-local addresses to help with the intra-node interface >naming problem, but we could just as well solve that problem other ways, >e.g., by using local interface names or indices, or even (if you *really* >insist on using interface names that look syntactically like addresses) by >defining a new "node-local" class of IPv6 addresses (that would basically >be a new constant prefix plus an interface index number). >From my perspective I am "only" concerned about the intra-node interface naming problem. I would prefer a solution where we can use unused bits in the token part of the link-local address. Do you have a problem if we do this in such a manner? This is what I am assuming Kre is writing up working with Matt Crawford? If we don't fix it now via a specification of sorts then as implementors we will fix it for ourselves. I prefer fixing it with a spec. /jim > The one weird thing about the draft I am writing is that it > is absolutely not intended to ever be published as an rfc. > It is meant for discussion, then for small parts of it to > perhaps be integrated into other drafts (or rfcs), this draft > itself will die. Correct. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html 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/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 21:22:15 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13001; Wed, 20 Dec 95 21:22:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12995; Wed, 20 Dec 95 21:22:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10017; Wed, 20 Dec 1995 21:22:08 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id VAA15010; Wed, 20 Dec 1995 21:22:10 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA21359; Thu, 21 Dec 1995 00:19:49 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26399; Thu, 21 Dec 1995 00:19:48 -0500 Message-Id: <9512210519.AA26399@wasted.zk3.dec.com> To: smb@research.att.com Cc: bound@zk3.dec.com, Dan McDonald , ipng@sunroof.eng.sun.com Subject: (IPng 950) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Wed, 20 Dec 95 17:56:17 EST." <199512202257.XAA07258@ns1.digital.fr> Date: Thu, 21 Dec 95 00:19:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, I just rejogged my memory banks and pulled RFC 1681 "On Many Addresses Per Host". We are dealing with it now and I think your RFC still stands and is correct. For the WG the discussion is very good in the RFC. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 20 22:48:34 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13080; Wed, 20 Dec 95 22:48:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13074; Wed, 20 Dec 95 22:48:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13065; Wed, 20 Dec 1995 22:48:29 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id WAA21346; Wed, 20 Dec 1995 22:48:28 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19008 Thu, 21 Dec 1995 17:44:57 +1100 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: Steve Deering , iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 951) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Wed, 20 Dec 1995 23:23:55 CDT." <9512210423.AA25206@wasted.zk3.dec.com> Date: Thu, 21 Dec 1995 17:45:10 +1100 Message-Id: <5781.819528310@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 20 Dec 95 23:23:55 -0500 From: bound@zk3.dec.com Message-ID: <9512210423.AA25206@wasted.zk3.dec.com> From my perspective I am "only" concerned about the intra-node interface naming problem. I would prefer a solution where we can use unused bits in the token part of the link-local address. I don't think I understand this. What "unused bits in the token part?" I wouyld have thought the "token part" was fully occupied by the token (further, the token is media dependant, and as has been said here before, in order to assure the within-node uniqueness that is desired, the extra bits need to be somewhere that tokens are unlikely to overlap. My current (half written) doc has them in the 2nd 16 bit chunk of the linkl-local addr (ie: FE80/16 in the first 16 bits, being the FE80/10 prefix, and 6 spare bits for expansion), then the interface identifier, in 16 bits, and then 96 more bits to contain the token in a media dependant manner). This is what I am assuming Kre is writing up Until I understand what you mean, I really don't know... working with Matt Crawford? I'm writing it, I (unilaterally) nominated Matt as one of the first proof readers... (ie: don't blame Matt if it doesn't appear soon enough, or you don't like it) kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 00:36:29 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13200; Thu, 21 Dec 95 00:36:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13194; Thu, 21 Dec 95 00:36:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17322; Thu, 21 Dec 1995 00:36:23 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id AAA29992; Thu, 21 Dec 1995 00:36:22 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA11341; Thu, 21 Dec 1995 09:36:20 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA09667; Thu, 21 Dec 1995 09:36:19 +0100 Message-Id: <9512210836.AA09667@dxcoms.cern.ch> Subject: (IPng 952) Re: DISCUSSION: Use of multiple Addresses on Interfaces To: ipng@sunroof.eng.sun.com Date: Thu, 21 Dec 1995 09:36:19 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199512202257.OAA12605@mercury.Sun.COM> from "smb@research.att.com" at Dec 20, 95 05:56:17 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > In fact, using multiple addresses is becoming common today, to permit > www.foo.com and www.bar.com to coexist on a single machine. True, but this (and to some extent RFC 1681) begs the question of whether this is a Good Thing architecturally. This example actually overloads both the DNS and the IP addressing scheme to compensate for the absence of either URNs, or a "real" directory service, and of a selector field in IP addresses. And as pragmatists, I guess we have to live with that. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 01:27:30 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13249; Thu, 21 Dec 95 01:27:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13243; Thu, 21 Dec 95 01:27:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19147; Thu, 21 Dec 1995 01:27:22 -0800 Received: from sophia.inria.fr by mercury.Sun.COM (Sun.COM) id BAA05135; Thu, 21 Dec 1995 01:27:19 -0800 Received: from [138.96.136.21] by sophia.inria.fr (8.6.12/8.6.12) with SMTP id KAA12970; Thu, 21 Dec 1995 10:24:29 +0100 Date: Thu, 21 Dec 1995 10:24:29 +0100 X-Authentication-Warning: sophia.inria.fr: Host maccdc1.inria.fr claimed to be [138.96.136.21] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Brian Carpenter CERN-CN" From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 953) Re: DISCUSSION: Use of multiple Addresses on Interfaces Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:36 AM 21/12/95, Brian Carpenter CERN-CN wrote: >Steve, > >> In fact, using multiple addresses is becoming common today, to permit >> www.foo.com and www.bar.com to coexist on a single machine. > >True, but this (and to some extent RFC 1681) begs the question >of whether this is a Good Thing architecturally. Well, I would call this a fact of life. I contend that this sort of "aliasing" is already supported by the neighbor discovery equivalent of "proxy arp". The relation with address configuration mechanism is however very far from clear: * whoever decides that server.foobar.net should host www.bar.com makes is going to perform quite a lot of configuration. At the very least, one may expect that they will configure a data base and register the name "www.bar.com" in a configuration file. * this kind of arrangement only aims at showing up an independent name in the DNS. A key point will be to guarantee consistency between the DNS and the actual network. Why not just read the addresses in the DNS, then do the proxy thing ? To sum up, aren't we going overboard with our desire to automatize configuration? The market need for client machines is obvious: don't assume any parametrization whatsoever. But for servers ? Can't we assume that they know at least the set of "alternate DNS names" that they will use ? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 03:55:13 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13333; Thu, 21 Dec 95 03:55:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13327; Thu, 21 Dec 95 03:55:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24244; Thu, 21 Dec 1995 03:55:06 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id DAA16098; Thu, 21 Dec 1995 03:55:06 -0800 Received: from uvite56.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA23687; Thu, 21 Dec 1995 06:55:00 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Dec 1995 06:55:19 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 954) Re: DISCUSSION: Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me ask a related question, that bears more directly on DHCPv6... Are there situations in which a client, having acquired or verified one or more global addresses for all of its interfaces at system boot time (e.g., through DHCPv6), would, at some later time, want to acquire more addresses for some or all of its interfaces. The reason I ask is that providing for these situationss will require explicit consideration in the design of the DHCPv6 protocol and server behavior. - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 04:53:11 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13379; Thu, 21 Dec 95 04:53:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13373; Thu, 21 Dec 95 04:53:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26122; Thu, 21 Dec 1995 04:53:06 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id EAA21405; Thu, 21 Dec 1995 04:53:06 -0800 Received: from uvite56.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA27179; Thu, 21 Dec 1995 07:53:00 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Dec 1995 07:53:20 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 955) Re: DISCUSSION: Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:30 PM 12/21/95, Robert Elz wrote: > Are there situations in which a client, having acquired or verified one or > more global addresses for all of its interfaces at system boot time (e.g., > through DHCPv6), would, at some later time, want to acquire more addresses > for some or all of its interfaces. > >I think there can be, though whether DHCP needs to be able >to supply those addresses, or whether the client does, as >Christian suggested, discovers the extra addresses by looking >itself up in the DNS, is less important. The reason to ask about DHCPv6 specifically is that we will need to understand the problem thoroughly and take some care in designing the DHCPv6 protocol and server behavior if one client can request several addresses through multiple, independent transactions. None of this is Rocket Science; we just need to make sure we think hard about the details (none of which were considered in the DHCPv4 model)... - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 06:25:27 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13425; Thu, 21 Dec 95 06:25:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13419; Thu, 21 Dec 95 06:25:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29893; Thu, 21 Dec 1995 06:25:16 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id GAA01440; Thu, 21 Dec 1995 06:25:17 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HZ29K0Q0KW003GPQ@FNAL.FNAL.GOV>; Thu, 21 Dec 1995 08:25:11 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA08773; Thu, 21 Dec 95 08:23:32 CST Date: Thu, 21 Dec 1995 08:23:31 -0600 From: Matt Crawford Subject: (IPng 956) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of Thu, 21 Dec 95 13:07:40 +1100. <5521.819511660@munnari.OZ.AU> To: Robert Elz Cc: Steve Deering , iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Message-Id: <9512211423.AA08773@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ With the extra field, this can be avoided to some extent. Note > that there will be no requirement for the numbers to be 0 1 2 3 > (etc). Manufacturers could choose to place some hardware > specific encoding in the field, ... I presume you meant implementors, but no matter. I hope you're considering the extra field to consist of *all* the bits bewteen the link-local prefix and the address token. (That's 70 bits in the case of ethernet and fddi.) Why? Because any other choice is a pointless restriction. I still haven't made up my mind whether I want the extra field to be used or not. In the tiniest possible nutshell, the argument is: Pro: help for some implementors. Con: extra hair on duplicate address detection. Tie: philosophical arguments go both ways, and aren't very strong. > As I said last time, I don't think it will be necessary to delay > the IPv6 over foo specs from IESG approval. [...] The changes to > those specs will, even if this is accepted, by miniscule, [...] > Even addrconf, can go ahead as it is, the changes there will also > not affect almost anything that exists Along with a miniscule change to the addr-arch document, which explicitly shows zeros in the bits under discussion. I would point out also that the set of solicited-node multicast groups a node must join is unaffected by this discussion for media whose address token is 32 bits or more. Any author of IP-over-foo document for foo having a token of less than 32 bits might want to specify some must-be-zero bits in the link-local address to achieve the same effect. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 06:34:16 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13447; Thu, 21 Dec 95 06:34:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13435; Thu, 21 Dec 95 06:34:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00342; Thu, 21 Dec 1995 06:34:06 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA02554; Thu, 21 Dec 1995 06:34:05 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7391; Thu, 21 Dec 95 09:33:37 EST Received: by RTP (XAGENTA 4.0) id 6996; Thu, 21 Dec 1995 09:33:32 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19129; Thu, 21 Dec 1995 09:33:53 -0500 Message-Id: <9512211433.AA19129@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 957) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Wed, 20 Dec 1995 15:16:27 EST." <9512202016.AA03678@wasted.zk3.dec.com> Date: Thu, 21 Dec 1995 09:33:53 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >I do not believe when we clearly articulated at the IETF IPng Interim meeting >Oct 93 at Cambridge MA the rule that interfaces can support multiple >addresses, we did not intend any "rule-set" of how or why those addresses can >be used. Nothing prevents us giving NFS 1::2, WEB Server 1::3, and >DBMS-1 1::14, and DBMD-2 1::37. It is an implementation manner. This >is the architectural issue raised on DHCPv6. More discussion below. Whether the architecture clearly forbids it (it doesn't), whether it is a good idea (debatable), and whether (and how) DHCP and/or other protocols should *encourage* such behavior are all different questions. To me, the relevant question for DHCP is: what is the model for supporting multiple addresses per server? I don't think anyone is suggesting the DHCP forbid the practice (it can't). But there are at least two models: - the knowledge about how many (extra) addresses a client wants (e.g., it wants an extra one for NFS as opposed to something else) is configured at the server. The client doesn't tell the server (via DHCP) to allocate an extra address for NFS, but relies on the server learning of the need through communication external to DHCP (e.g., talking to the person administering the DHCP server). - the knowledge about how many (extra) addresses a client wants is known only the client, and the DHCP protocol provides a mechanism to clients allowing them to obtain additional addresses. The second model will certainly introduce complexity to DHCP, and I tend to think that servers playing games with addresses per service require enough extra configuration anyway that the second model probably doesn't provide a signficant benefit over the first. Also, I'm also under the impression that you find the first model unacceptable because of bureacratic/administrative hassles involved in having end-users coordinate with the person administering the DHCP server in a timely manner. I'm not sure that this is a problem that DHCP should (or can) solve! >If a DHCPv6 client knows as an END-SYSTEM that is fully loaded with >configuration to act as a Network Server that it wants to use different >addresses for the END-SYSTEMS: NFS Server, WEB Server, Secure Connected >Servers, and NON-Secure Services (e.g. secure telnet and non-secure >telnet server) why would this not be allowed in IPv6? Today nothing >prevents this in any spec. What is the problem that needs solving? You've given a solution to an undefined problem. Without understanding the problem, there is no way to determine if there are alternate (possibly better) solutions. For example, what is motivation for giving the NFS server a different address from the web server? What problem does that solve? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 06:34:27 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13448; Thu, 21 Dec 95 06:34:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13441; Thu, 21 Dec 95 06:34:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00373; Thu, 21 Dec 1995 06:34:13 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id GAA02540; Thu, 21 Dec 1995 06:34:03 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA21153; Thu, 21 Dec 1995 09:17:06 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA08503; Thu, 21 Dec 1995 09:17:01 -0500 Message-Id: <9512211417.AA08503@wasted.zk3.dec.com> To: Robert Elz Cc: bound@zk3.dec.com, Steve Deering , iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 958) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Thu, 21 Dec 95 17:45:10 +1100." <5781.819528310@munnari.OZ.AU> Date: Thu, 21 Dec 95 09:17:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I don't think I understand this. What "unused bits in the >token part?" I wouyld have thought the "token part" was >fully occupied by the token (further, the token is media >dependant, and as has been said here before, in order to >assure the within-node uniqueness that is desired, the >extra bits need to be somewhere that tokens are unlikely to >overlap. My current (half written) doc has them in the >2nd 16 bit chunk of the linkl-local addr (ie: FE80/16 in >the first 16 bits, being the FE80/10 prefix, and 6 spare >bits for expansion), then the interface identifier, in 16 >bits, and then 96 more bits to contain the token in a >media dependant manner). Sorry for terseness. interface-token is 64bits. for any broadcast media we really only need 48 bits. i looked at the 16 bits left as extra bits. OK I see you are going to leave the token alone. this is good won't step on other prefixes that use the token to build a non-link-local address. we could have just made the token "become" what the identifier adds to it and it would have been media independent+ID but your approach seems smarter for the long term. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 06:40:41 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13479; Thu, 21 Dec 95 06:40:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13473; Thu, 21 Dec 95 06:40:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00770; Thu, 21 Dec 1995 06:40:36 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA03900; Thu, 21 Dec 1995 06:40:36 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7538; Thu, 21 Dec 95 09:40:08 EST Received: by RTP (XAGENTA 4.0) id 7006; Thu, 21 Dec 1995 09:40:04 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17389; Thu, 21 Dec 1995 09:40:23 -0500 Message-Id: <9512211440.AA17389@cichlid.raleigh.ibm.com> To: huitema@pax.inria.fr (Christian Huitema) Cc: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com Subject: (IPng 959) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Thu, 21 Dec 1995 10:24:29 +0100." Date: Thu, 21 Dec 1995 09:40:23 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema writes: >Well, I would call this a fact of life. I contend that this sort of >"aliasing" is already supported by the neighbor discovery equivalent of >"proxy arp". Strictly speaking, proxy arp isn't used for the 'address per server model.' My understanding is that individual servers get their own (unicast) address, but the address is still unique [within its appropriate scope of course :-)]. So ND behaves as normal. Erik and I have not (yet) identified a clear need for the proxy mechanism, except for maybe mobility, but that remains to be seen. >To sum up, aren't we going overboard with our desire to automatize >configuration? The market need for client machines is obvious: don't >assume any parametrization whatsoever. But for servers ? Can't we assume >that they know at least the set of "alternate DNS names" that they will use >? I strongly agree with this. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 06:52:42 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13501; Thu, 21 Dec 95 06:52:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13495; Thu, 21 Dec 95 06:52:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01437; Thu, 21 Dec 1995 06:52:36 -0800 Received: from comet.connix.com by mercury.Sun.COM (Sun.COM) id GAA05810; Thu, 21 Dec 1995 06:52:36 -0800 Received: from connix.com (localhost [127.0.0.1]) by comet.connix.com (8.6.5/8.6.5) with ESMTP id JAA18286; Thu, 21 Dec 1995 09:52:29 -0500 Message-Id: <199512211452.JAA18286@comet.connix.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 960) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Thu, 21 Dec 1995 09:36:19 +0100." <9512210836.AA09667@dxcoms.cern.ch> Date: Thu, 21 Dec 1995 09:52:23 -0500 From: Gary R Wright Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Brian Carpenter CERN-CN" writes: > > In fact, using multiple addresses is becoming common today, to permit > > www.foo.com and www.bar.com to coexist on a single machine. > > True, but this (and to some extent RFC 1681) begs the question > of whether this is a Good Thing architecturally. This example > actually overloads both the DNS and the IP addressing scheme to > compensate for the absence of either URNs, or a "real" directory > service, and of a selector field in IP addresses. And as pragmatists, > I guess we have to live with that. I think the primary reason people do this is because a port number can't be associated with a domain name. There is no problem at all running multiple WWW servers on different ports, but no one wants to specify a WWW server as http://www.something.com:2345/ I haven't thought about the implications, but it would have been nice if an A record in the DNS allowed a port to be specified along with the address. That would simplify lots of things like WWW servers at multiple ports, IRC servers, MUDS, and any other Internet server that resides at multiple ports and would like to be referenced by a simple domain name. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 07:48:53 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13576; Thu, 21 Dec 95 07:48:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13570; Thu, 21 Dec 95 07:48:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05934; Thu, 21 Dec 1995 07:48:47 -0800 Received: from nsco.network.com by mercury.Sun.COM (Sun.COM) id HAA16094; Thu, 21 Dec 1995 07:48:47 -0800 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA20482; Thu, 21 Dec 95 09:50:34 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA16612; Thu, 21 Dec 95 09:49:50 CST Date: Thu, 21 Dec 95 09:49:50 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9512211549.AA16612@anubis.network.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 961) Re: DISCUSSION: Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's my impression that at least one common reason for wanting multiple addresses on an interface is so that the addresses can later be split across two machines (or, sometimes, one needs to merge two machines into one). In the Future Glorious World that IPv6 and DHCPv6 etc are going to usher in, all this stuff will be learned dynamically, so the needs to preserve a given service at a given address will be substantially reduced. Or, as someone else pointed out, IP could move ahead into the 1970s and get real directory/service advertisement protocols. Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 08:24:57 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13637; Thu, 21 Dec 95 08:24:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13631; Thu, 21 Dec 95 08:24:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09281; Thu, 21 Dec 1995 08:24:47 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id IAA24175; Thu, 21 Dec 1995 08:24:47 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HZ2DQ3756O003II9@FNAL.FNAL.GOV>; Thu, 21 Dec 1995 10:24:37 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA09243; Thu, 21 Dec 95 10:22:57 CST Date: Thu, 21 Dec 1995 10:22:57 -0600 From: Matt Crawford Subject: (IPng 962) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of Thu, 21 Dec 95 09:17:01 EST. <9512211417.AA08503@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Message-Id: <9512211622.AA09243@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Sorry for terseness. interface-token is 64bits. 64??? Where do you get that? Or is that your proposed redefinition? Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 09:11:59 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13696; Thu, 21 Dec 95 09:11:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13690; Thu, 21 Dec 95 09:11:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14453; Thu, 21 Dec 1995 09:11:48 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA05858; Thu, 21 Dec 1995 09:11:49 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA03136; Thu, 21 Dec 1995 09:11:49 -0800 Date: Thu, 21 Dec 1995 09:11:49 -0800 From: Ran Atkinson Message-Id: <199512211711.JAA03136@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 963) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: <9512202229.AA15962@wasted.zk3.dec.com> References: <9512201637.aa07206@cs.nrl.navy.mil> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9512202229.AA15962@wasted.zk3.dec.com> you write: >I think I am beginning now to ask myself a new question? Why are we >permitting multiple addresses per interface in IPv6? I'm not sure why the decision was reached, but I can provide an example where it is necessary. On a multi-level secure node (one that, for example, has mechanisms that are trusted to separate unclassified data/users from secret data/users), it is often desirable to have multiple addresses per interface. A typical example is that each vertical sensitivity level (unclassified, secret, top secret) would get its own IP address even though they are all on the same interface. It is imporant that we continue to permit multiple addresses on a single interface with IPv6. Btw, I don't see this example as an issue for DHCP because DHCP is not usually used in security-conscious environments because DHCP is currently one of the best cracker tools around to break into IP nodes (no meaningful authentication exists in DHCP and because of the design, it seems non-trivial to add authentication to DHCP without a major version change). I tend to agree with Dan that an IP address per service might not be a really good example of why multiple addresses are needed. >Let me put it another way does anyone want to put more restrictions in >our specifications for multiple addresses per interface or addresses in >general? No, for the reasons above, though it might not hurt to add non-restrictive informational text suggesting that address conservation is A Good Thing and that users will normally not want or need to have more than one address per interface. Maybe this is appropriate for a BCP ? Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 09:42:40 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13752; Thu, 21 Dec 95 09:42:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13746; Thu, 21 Dec 95 09:42:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19144; Thu, 21 Dec 1995 09:42:33 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id JAA14115; Thu, 21 Dec 1995 09:42:33 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA31527; Thu, 21 Dec 1995 12:39:05 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30400; Thu, 21 Dec 1995 12:39:04 -0500 Message-Id: <9512211739.AA30400@wasted.zk3.dec.com> To: "Thomas Narten" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 964) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Thu, 21 Dec 95 09:33:53 -0400." <9512211433.AA19129@cichlid.raleigh.ibm.com> Date: Thu, 21 Dec 95 12:39:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >Whether the architecture clearly forbids it (it doesn't), whether it >is a good idea (debatable), and whether (and how) DHCP and/or other >protocols should *encourage* such behavior are all different >questions. Well this thread is only in mind does the architecture forbid it and I think the answer is NO. DHCP will get done in DHCP WG. What users do with the technology they buy we have no control over. >To me, the relevant question for DHCP is: what is the model for >supporting multiple addresses per server? I don't think anyone is >suggesting the DHCP forbid the practice (it can't). But there are at >least two models: > - the knowledge about how many (extra) addresses a client wants > (e.g., it wants an extra one for NFS as opposed to something else) > is configured at the server. The client doesn't tell the server > (via DHCP) to allocate an extra address for NFS, but relies on the > server learning of the need through communication external to DHCP > (e.g., talking to the person administering the DHCP server). > > - the knowledge about how many (extra) addresses a client wants is > known only the client, and the DHCP protocol provides a mechanism > to clients allowing them to obtain additional addresses. >The second model will certainly introduce complexity to DHCP, and I >tend to think that servers playing games with addresses per service >require enough extra configuration anyway that the second model >probably doesn't provide a signficant benefit over the first. Lets take this back to DHCP WG. Its not complex at all. But that discussion will happen on DHCP WG. >Also, I'm also under the impression that you find the first model >unacceptable because of bureacratic/administrative hassles involved in >having end-users coordinate with the person administering the DHCP >server in a timely manner. I'm not sure that this is a problem that >DHCP should (or can) solve! No its not even relative to the discussion. I pointed it out that it should not be the case. >>If a DHCPv6 client knows as an END-SYSTEM that is fully loaded with >>configuration to act as a Network Server that it wants to use different >>addresses for the END-SYSTEMS: NFS Server, WEB Server, Secure Connected >>Servers, and NON-Secure Services (e.g. secure telnet and non-secure >>telnet server) why would this not be allowed in IPv6? Today nothing >>prevents this in any spec. >What is the problem that needs solving? You've given a solution to an >undefined problem. Without understanding the problem, there is no way >to determine if there are alternate (possibly better) solutions. THe bottom line is there is nothing in IPv6 that prevents users from doing anything with addresess they deem necessary. I think we can now go back to DHCP List. >For example, what is motivation for giving the NFS server a different >address from the web server? What problem does that solve? I don't have to have different ports for one thing. Customers can just simply do it and they want too. Again nothing in IPv6 prevents it which was Ralphs concern when he asked me to bring it here. Back to DHCP WG. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 09:48:44 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13786; Thu, 21 Dec 95 09:48:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13780; Thu, 21 Dec 95 09:47:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19949; Thu, 21 Dec 1995 09:47:02 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id JAA15513; Thu, 21 Dec 1995 09:46:56 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA29207; Thu, 21 Dec 95 12:45:57 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA08159; Thu, 21 Dec 95 12:46:53 EST Date: Thu, 21 Dec 95 12:46:53 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512211746.AA08159@pobox.BayNetworks.com> To: deering@parc.xerox.com Subject: (IPng 965) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com, dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > > My point is that, if you have an IPv4 address assigned to an interface, > > it unambiguously identifies this interface withing a single box. Your > > Frame Relay example is not an exception since a VC bundle is treated > > by IP as a single physical interface to a multicast media (same as Ethernet). > > That's not what I heard at the ipngwg meeting at the Digital reasearch lab > in Cambridge. At that meeting, I tried the tack you are trying: I suggested > that every interface should have a unique address and I was shot down by > those who treat the set of Frame Relay VCs that converge on a single FR > interface as multiple point-to-point links, and they didn't want the > administrative burden of having a separate IP address for each of those > links. I suspect also that certain routing protocols would *require* that > you treat an FR relay as a set of p-to-p links, rather than as an interface > to a multi-access link, at least in those cases where you don't have a > full mesh of VCs -- do all IP routing protocols work over media where > not every router can reach every other router? > I can't speak for all possible implementations. It is possible that there is an unknown to me IP-over-FR implementation that assigns a single IP address to a group of VCs with each VC treated as a separate IP interface. But Bay has a complete field tried IP-over-FR implementation that has managed without such a crock. The Ethernet analogy might not be 100% accurate (e.g. it may not be appropriate to send redirects or do a third party route advertisement if you don't have a full mesh of VCs) but for purpose of our discussion it is good enough. And so far we have not encounter a routing protocol that would require as to re-think our approach. > > "Unnumbered" interfaces don't have an address so it is an ugly special case > > introduced into IPv4 for the address conservation purpose. > > It may be ugly, but it is a true example from IPv4 which disproves your > claim that in IPv4 all interfaces have unique IP addresses. > > > Actually "unnumbered" interfaces is the only special case in respect of > > interface addressing that we've had to handle differently in IPv4. > > So, you *did* have to deal with non-uniquely numbered interfaces in IPv4, > contrary to the claim in your original message. You are insisting on using the "unnumbered" as a case in your point. But it really is not. The "unnumbered" interfaces don't realy handle many cases that you want to be supported with link-local addresses, e.g: you can't send a packet to an unnumbered interface, but, I guess, you would like a link-local address to be used as a packet destination; if two systems wish to run a routing protocol over an unnumbered p-to-p link they need to anchor this protocol to a valid interface addresses on such system, i.e. addresses are borrowed from numbered interfaces with an array of nasty problems resulting from this unavoidable approach. I guess, you would want to do this way when link-local addresses are involved. > > Also, you forgot about tunnels. Those are links too, whose endpoints are > typically not given unique addresses. > Sorry, I did not mean to conveniently ignore this case. Basically, in our implementation, it is very similar to the IP-over-FR case. I.e., if a single address is used for multiple tunnels, it is treated as a single interface to a multi-access link. The IPv6 automatic tunneling is an example. > > Certainly, we could eliminate the notion of unnumbered interfaces and > require that all links (tunnels included) be assigned at least a link- > local address. That's a separate issue from whether or not those link- > local adresses must be unique across all the interfaces of a single node. > > I disagree with your contention that link-local addresses are the only > case of sharing a unicast address across multiple interfaces, but even > if it were true, so what? Link-local addresses (and site-local addresses) > are something new in IPv6, something different from global unicast addresses, > so you should not be surprised that they have different properties than > global unicast addresses. I'm not surprised. But if we can give them a property that don't deprive link-local addresses of their intended purpose but greatly simplify the implementation effort, it will be for a better. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 10:15:27 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13868; Thu, 21 Dec 95 10:15:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13862; Thu, 21 Dec 95 10:15:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24606; Thu, 21 Dec 1995 10:15:20 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id KAA24052; Thu, 21 Dec 1995 10:15:21 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA29407; Thu, 21 Dec 1995 13:06:01 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32090; Thu, 21 Dec 1995 13:06:01 -0500 Message-Id: <9512211806.AA32090@wasted.zk3.dec.com> To: Matt Crawford Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 966) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Thu, 21 Dec 95 10:22:57 CST." <9512211622.AA09243@munin.fnal.gov> Date: Thu, 21 Dec 95 13:06:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, >> Sorry for terseness. interface-token is 64bits. >64??? Where do you get that? Or is that your proposed redefinition? Assumption from addr conf discussions ? Not correct? thanks /jiM ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 11:30:02 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13954; Thu, 21 Dec 95 11:30:02 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13948; Thu, 21 Dec 95 11:29:46 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA17748; Thu, 21 Dec 1995 11:29:30 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09254; Thu, 21 Dec 1995 11:29:48 -0800 Date: Thu, 21 Dec 1995 11:29:48 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199512211929.LAA09254@bobo.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 967) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The problem arises in a multihome situation on a single node supporting > multiple links (802.3 media) where the interfaces (802.3 stations) exist > on different links for the same node. In this case it is "perceived" > that the interface-token (MAC address) may be duplicated on each link. > IPv6 ND/Addr conf Duplicate Address Detection does not verify that the > link-local address (or any address (site, global)) is not duplicated across > links. It has been mentioned in the IPng WG that some implementations > will use the CPU # (as an example) to assign the link-layer address > (identifier for 802.3 station) for all interfaces (stations) across > multiple links. Hence, there is no way to differentitate the link-local > address across the multihome links on a single node. By using Dimitrys > suggestion it is possible to discriminate the link-layer address and > interface-token via the 16bits (high or low) of the lower 64bits of a > link-local address. Neighbor Discovery (ND) in a mutlihomed node > the link-local address would not be duplicated and implementors avoid having ^^^^^^^^^^^^ > to carry interface-IDs in however they maintain ND cache or tables or > whatever they want to call it in their implementations. It also removes ^^^^^^^^^^^^ > having to have a priori knowledge of interfaces at the application layer > should the link-local address be used to communicate on a link (not off > link). The above two marked sentences tell me that you (and probably other) believe that interface tokens solve all the hard problems related to link-local address on multihomed hosts. They do not. An example: H2 is a multihomed node with two interfaces (if0 and if1) connection it to link0 and link1,respectively. The links are of the same type and this link type does not have globally unique link-layer addresses. For instance, it could be appletalk/localtalk. On each link there is a single-homed host: H0 on link0 and H1 on link1. Let's call there interfaces if0. The link-layer addresses on H2 is A2 (happens to be the same for both if0 and if1). With the interface-ID idea H2 would have a different link-local address for if0 and if1 (we can call them A2-0 and A2-1). Independent of any interface-ID, when H2 needs to represent H0 and H1 it needs to know what interface to send packet out on. In particular, if H0 and H1 happens to have the same (e.g. localtalk) link-layer address it would be impossible to distinguish between them unless the remote addresses are associated with some identifier for the interface. (NOTE: the interface-ID proposal puts IDs on the multihomed hosts own addresses. It can not effect the addresses of other nodes.) The above example applies whether to both IP/ND data structures and to applications. If the addresses do not include a prefix that can be used to determine which interface to use you need an adjunct interface identifier anywhere you have an address. Thus a multihomed host using telnet might need to specify the interface on the command line: telnet if1 This is the only possibility (independent of any interface-IDs) if the link-layer addresses are not globally unique (or a least unique across all links connected to the multihomed node). As Dan McDonald has pointed out, if the link-layer addresses are unique across all connected links, it is possible to have ND try to find the destination by sending Neighbor Solicitations out all interfaces. This could remove the need to specify the interface name to e.g. telnet with this particular (albeit common - Ethernet) type link. But Dan's idea has nothing to do with interface_IDs either. So what are interface-IDs useful for? Only when a multihomed node wants to use a link-local address to uniquely identify one of its OWN interfaces. This could be very useful in many cases so I'm not saying that we shouldn't add interface-IDs to the link-local addresses. All I'm saying is that we need to make sure we understand what problems interface-IDs solve and which they do not solve. They are not the holy grail that will make the handling of link-local addresses on multihomed nodes trivial. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 16:01:25 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14114; Thu, 21 Dec 95 16:01:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14108; Thu, 21 Dec 95 16:01:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10237; Thu, 21 Dec 1995 16:01:17 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id QAA26871; Thu, 21 Dec 1995 16:01:18 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14816(1)>; Thu, 21 Dec 1995 16:01:10 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 21 Dec 1995 16:00:57 -0800 To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 968) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: dhaskin's message of Thu, 21 Dec 95 09:46:53 -0800. <9512211746.AA08159@pobox.BayNetworks.com> Date: Thu, 21 Dec 1995 16:00:55 PST From: Steve Deering Message-Id: <95Dec21.160057pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, > > ... Link-local addresses (and site-local addresses) are something new > > in IPv6, something different from global unicast addresses, so you > > should not be surprised that they have different properties than > > global unicast addresses. > > I'm not surprised. But if we can give them a property that don't > deprive link-local addresses of their intended purpose but greatly > simplify the implementation effort, it will be for a better. Fine. Let's wait till we see kre's write-up to see how much complication is added in one place to provide simplification in another. In case it's not clear, I am *not* necessarily opposed to adding an interface index to link-local addresses. That is, I disagreed with some of your arguments, but I do not necessarily disagree with your goal. If it turns out that adding an interface index to link-local addresses indeed has a negligible cost (e.g., it doesn't require us to perfom n times more DADs), and it really helps implementations, then great, let's do it. But it is not yet clear that that is the case, hence the request for a write-up and a full discussion of the pros and cons (which we are currently engaged in). I think Erik's point is also important: we must not assume that making link-local addresses unique within a node solves more problems than it really does. For instance, it does not eliminate the need for some method for applications to learn what interface a packet arrived on, independent of the addresses in the packet, and to specify what interface a packet should go out on, independent of the addresses in the packet. Here's another example to ponder (maybe this is a sub-example of what Erik was talking about). Consider multihomed nodes with PPP links only, and assume that the link-local addresses for PPP interfaces are generated by having one end use token value 1 and the other end use token value 2 (with some protocol to determine which end gets which of the two tokens). This would be a perfectly reasonable way of generating link-local addresses for PPP links -- we certainly don't want to require that nodes having only PPP links also acquire an IEEE 802 address or some other likely-to-be- globally-unique token. Assume also that nodes add interface indexes to their link-local addresses, to guarantee uniqueness within the node. The following illustration shows three nodes, A, B, and C, joined by PPP links x and y. The end of each link is labeled with its assigned link-local address, in the form LL/i/t, where LL is the link-local prefix, i is the local interface index, and t is the link-unique token for the interface. ------- ------- ------- | | link x | | link y | | ------| A |----------------| B |----------------| C |------ LL/0/1| |LL/1/2 LL/0/1| |LL/1/2 LL/0/1| |LL/1/2 ------- ------- ------- The assigned link-local addresses have the necessary property that each end of a link has a different address, and the additional property desired by Dimitry and others that each of a node's interfaces has a different link-local address. But note that, for node B, the address LL/1/2 has two possible meanings: either node B's only interface on link y, or node A's interface on link x, and without qualifying any reference to that address with some interface identifier, it is ambiguous. Now, you might suggest that B should choose its interface indexes so as to avoid the ambiguity, but that would mean waiting to learn what A and C had chosen, but A and C might have to wait to learn what their further- out neigbors had chosen, who in turn would have to wait... Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 17:10:16 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14208; Thu, 21 Dec 95 17:10:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14202; Thu, 21 Dec 95 17:10:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18355; Thu, 21 Dec 1995 17:10:09 -0800 Received: from vangogh.CS.Berkeley.EDU by mercury.Sun.COM (Sun.COM) id RAA11109; Thu, 21 Dec 1995 17:10:10 -0800 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id RAA09341 for ipng@sunroof.Eng.Sun.COM; Thu, 21 Dec 1995 17:08:56 -0800 (PST) Date: Thu, 21 Dec 1995 17:08:56 -0800 (PST) From: Keith Sklower Message-Id: <199512220108.RAA09341@vangogh.CS.Berkeley.EDU> To: ipng@sunroof.eng.sun.com Subject: (IPng 969) Re: (IPng968) - need for uniq ID's/PPP and identifying interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I wanted to comment on two separable issues that Steve disccused in his most recent note: First - in the context of multihomed nodes with PPP links only - Steve generously wishes to spare nodes the requirement of obtaining "an IEEE 802 address or some other likely-to-be-globally-unique token". I wanted to point out that if the multihomed node is running the PPP multilink protocol as a service provider over ISDN, it will want such a unique identifier *anyway*. Secondly - on this issue of link-local addresses - while I agree that it is necessary to inform an application on which interface a packet arrived, it not as as clear to me that the appropriate way to do this is with an IPv6 address. The 4.4-based BSDish systems have something called a sockaddr_dl which serves the purpose of identifying both the receiving interface for a packet, and also the link-layer address to which it was sent. I have to admit being overwhelmed by the discussion; can somebody remind me (private mail will be fine if you don't want to add to the clutter on the list), what other purposes the link-local address serves, other than as an API construction for identifying receiving and transmitting interfaces? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Dec 21 19:42:46 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14315; Thu, 21 Dec 95 19:42:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14309; Thu, 21 Dec 95 19:42:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00142; Thu, 21 Dec 1995 19:42:38 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id SAA23645; Thu, 21 Dec 1995 18:33:53 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15569(3)>; Thu, 21 Dec 1995 18:33:46 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 21 Dec 1995 18:33:35 -0800 To: Keith Sklower Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 970) Re: (IPng968) - need for uniq ID's/PPP and identifying interfaces In-Reply-To: sklower's message of Thu, 21 Dec 95 17:08:56 -0800. <199512220108.RAA09341@vangogh.CS.Berkeley.EDU> Date: Thu, 21 Dec 1995 18:33:24 PST From: Steve Deering Message-Id: <95Dec21.183335pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > First - in the context of multihomed nodes with PPP links only - > Steve generously wishes to spare nodes the requirement of obtaining > "an IEEE 802 address or some other likely-to-be-globally-unique token". > I wanted to point out that if the multihomed node is running the > PPP multilink protocol as a service provider over ISDN, it will want such a > unique identifier *anyway*. The fact that some PPP endpoints will have or need global identifiers does not imply that all of them will have them. When I used the term "PPP", I really meant any point-to-point link, including a length of wire strung between a serial port on one node and a serial port on another, or a permanent circuit leased from an carrier, or a point-to-point wireless IR link between two adjacent portables -- no phone number, ISDN number, ethernet address, or anything. > Secondly - on this issue of link-local addresses - while I agree that > it is necessary to inform an application on which interface a packet arrived, > it not as as clear to me that the appropriate way to do this is with an > IPv6 address. The 4.4-based BSDish systems have something called > a sockaddr_dl which serves the purpose of identifying both the > receiving interface for a packet, and also the link-layer address > to which it was sent. Sounds good to me. > I have to admit being overwhelmed by the discussion; can somebody > remind me (private mail will be fine if you don't want to add to > the clutter on the list), what other purposes the link-local address > serves, other than as an API construction for identifying receiving > and transmitting interfaces? That was not the purpose for which they were invented. They were intended to provide unique addresses for nodes attached to isolated links, such as a standalone Ethernet (with no routers attached, or on which all attached routers are down when a host starts up) or an ad-hoc link formed when a few laptops are connected (by wires or wirelessly) across a conference room table. In that scenario, there is no need for globally-unique Internet addresses, nor is there likely to be any means of automatically generating them (i.e., no routers to advertise global prefixes and no DHCP servers). Link-local addresses were also intended to be used when bootstrapping up to global addresses, for example, to serve as the source address of a DHCP request packet that is trying to obtain a global address, to which the DHCP response can be sent (either by a neighboring DHCP server or by a neighboring DHCP relay agent). And finally, if all the site-local or global prefixes assigned to a link time out, link-local address provide the ability for nodes on the link to still communicate with each other. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 22 01:56:53 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14650; Fri, 22 Dec 95 01:56:53 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14644; Fri, 22 Dec 95 01:56:42 PST Received: from everglade ([129.144.201.16]) by caribe.eng.sun.com (5.x/SMI-SVR4) id AA00656; Fri, 22 Dec 1995 01:56:24 -0800 Date: Fri, 22 Dec 1995 01:58:49 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 971) Re: (IPng968) - need for uniq ID's/PPP and identifying interfaces To: ipng@sunroof Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Secondly - on this issue of link-local addresses - while I agree that > it is necessary to inform an application on which interface a packet arrived, > it not as as clear to me that the appropriate way to do this is with an > IPv6 address. The 4.4-based BSDish systems have something called > a sockaddr_dl which serves the purpose of identifying both the > receiving interface for a packet, and also the link-layer address > to which it was sent. Actually, I think that the use of an IP address to identify the receiving interface and specify the outgoing interface, as discussed in the latest revision of the API spec, is a rather clean design. And it fits well with the architecture. After all, what facility does the Internet architecture provide to identify interfaces? IP addresses! So why not just use them to identify the receiving and outgoing interface? In the rare case where interfaces have no addresses that are unique within the scope of the node, the system could assign its own unique "node local" addresses that are used only for identifying interfaces within the machine. I see a couple of problems with using the interface name (e.g. "le0") to identify an interface to an application: 1) It introduces a new name space for the application to deal with. 2) Interface names tend to be rather cryptic, and on most systems, administrators can't change them to something more reasonable. If the API identifies the receiving interface with an IP address, on the other hand, the application has lots of functions for dealing with IP addresses. It can, for example, map that address into a human-readable string by calling the address-to-name translation function. Similarly, an application can use the name-to-address translation function to map the name of an interface into its address for use in specifying the outgoing interface. Presumably, one reason for providing a way in the API to specify an outgoing interface is so that users can specify the outgoing interface at the command line. The interface name on my laptop machine is named "pcelx1". I would rather be able to type: % telnet server via myhost-ethernet than % telent server via pcelx1 Also, I don't think we have to mix the functions of returning the receiving IP interface information with delivering the source and destination datalink addresses. The sockaddr_dl is probably the right way to do the latter, but need not necessarly be used for the former. It might be nice to allow the application to ask for receiving interface information, and datalink addresses, independently. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 22 07:19:21 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14829; Fri, 22 Dec 95 07:19:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14823; Fri, 22 Dec 95 07:19:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27888; Fri, 22 Dec 1995 07:18:50 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id HAA04859; Fri, 22 Dec 1995 07:18:45 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA16267; Fri, 22 Dec 95 10:17:45 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA16965; Fri, 22 Dec 95 10:18:38 EST Date: Fri, 22 Dec 95 10:18:38 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512221518.AA16965@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com, Bob.Gilligan@Eng Subject: (IPng 972) Re: - need for uniq ID's/PPP and identifying interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Actually, I think that the use of an IP address to identify the > receiving interface and specify the outgoing interface, as discussed > in the latest revision of the API spec, is a rather clean design. And > it fits well with the architecture. After all, what facility does the > Internet architecture provide to identify interfaces? IP addresses! > So why not just use them to identify the receiving and outgoing > interface? In the rare case where interfaces have no addresses that > are unique within the scope of the node, the system could assign its > own unique "node local" addresses that are used only for identifying > interfaces within the machine. > And some of us are tring to preclude such a rare case so no new address type needs to be invented. > I see a couple of problems with using the interface name (e.g. "le0") > to identify an interface to an application: 1) It introduces a new > name space for the application to deal with. 2) Interface names tend > to be rather cryptic, and on most systems, administrators can't change > them to something more reasonable. > > If the API identifies the receiving interface with an IP address, on > the other hand, the application has lots of functions for dealing with > IP addresses. It can, for example, map that address into a > human-readable string by calling the address-to-name translation > function. Similarly, an application can use the name-to-address > translation function to map the name of an interface into its address > for use in specifying the outgoing interface. > I'd like to add that it is very useful (necessary?) to have a vendor independent format for interface locators, and addresses are quite natural for it. It would be much easier to develop a generic network management and monitoring tool if the standart locator format existed. Public IPv6 MIB probably will be the first beneficiary. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 22 08:03:34 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14856; Fri, 22 Dec 95 08:03:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14850; Fri, 22 Dec 95 08:03:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01535; Fri, 22 Dec 1995 08:03:26 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA12543; Fri, 22 Dec 1995 08:03:26 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3523; Fri, 22 Dec 95 11:02:57 EST Received: by RTP (XAGENTA 4.0) id 7292; Fri, 22 Dec 1995 11:02:54 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19083; Fri, 22 Dec 1995 11:03:16 -0500 Message-Id: <9512221603.AA19083@cichlid.raleigh.ibm.com> To: Bob Gilligan Cc: ipng@sunroof.eng.sun.com Subject: (IPng 973) Re: (IPng968) - need for uniq ID's/PPP and identifying interfaces In-Reply-To: Your message of "Fri, 22 Dec 1995 01:58:49 PST." Date: Fri, 22 Dec 1995 11:03:16 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Gilligan writes: >Actually, I think that the use of an IP address to identify the >receiving interface and specify the outgoing interface, as discussed >in the latest revision of the API spec, is a rather clean design. >[...] In the rare case where interfaces have no addresses that >are unique within the scope of the node, the system could assign its >own unique "node local" addresses that are used only for identifying >interfaces within the machine. If IP addresses are to be used for uniquely identifying interfaces on a node, I suspect there will be an assumption made (by applications) that the interface address/identifier can be used as a source (or destination) of a packet. If a "node local" address were created that had no scope beyond the current node, interesting behavior might result in those cases where node local addresses had to be created (as opposed to using a proper link-local or other scope address). So without some careful thought, I'm not sure "node local" addresses would be such a good idea. If *all* interface identifiers were node-local, and had no scope beyond the node, we'd probably be OK. But now we've simply said there has to be a way to name interfaces, and we've come around full circle. Oh, and how do you name interfaces that don't have addresses assigned to them yet, e.g., while bootstrapping? It seems like we'll still need a way of naming interfaces independent of using IP addresses. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 22 08:14:07 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14869; Fri, 22 Dec 95 08:14:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14862; Fri, 22 Dec 95 08:13:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02365; Fri, 22 Dec 1995 08:13:54 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id IAA14491; Fri, 22 Dec 1995 08:13:54 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17316; Fri, 22 Dec 95 11:12:55 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA19553; Fri, 22 Dec 95 11:13:52 EST Date: Fri, 22 Dec 95 11:13:52 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512221613.AA19553@pobox.BayNetworks.com> To: deering@parc.xerox.com Subject: (IPng 974) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > I think Erik's point is also important: we must not assume that making > link-local addresses unique within a node solves more problems than it > really does. For instance, it does not eliminate the need for some method > for applications to learn what interface a packet arrived on, independent > of the addresses in the packet, and to specify what interface a packet > should go out on, independent of the addresses in the packet. > Absolutely. > Here's another example to ponder (maybe this is a sub-example of what Erik > was talking about). [Rest omitted]. And yet another example which applies to any type of addresses including globally unique addresses: a node can have a neighbor with an address X on one of his physical links and a tunnel (e.g. IPv6-in-IPv4 tunnel) to the same address X. It would appear as the same neighbor address X on two different links. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 22 08:24:51 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14885; Fri, 22 Dec 95 08:24:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14879; Fri, 22 Dec 95 08:24:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03323; Fri, 22 Dec 1995 08:24:43 -0800 Received: from iol.unh.edu by mercury.Sun.COM (Sun.COM) id IAA16872; Fri, 22 Dec 1995 08:24:44 -0800 Received: by iol.unh.edu (4.1/SMI-4.1) id AA08192; Fri, 22 Dec 95 11:21:04 EST From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9512221621.AA08192@iol.unh.edu> Subject: (IPng 975) testing fragmentation and reassembly To: ipng@sunroof.eng.sun.com (ipng) Date: Fri, 22 Dec 1995 11:21:03 -0500 (EST) Cc: ipv6imp@munnari.oz.au (ipv6imp), qv@sun4.iol X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We, here at UNH were discussing testing of fragmentaion and reassembly and this question came up : Is it legal to have a next header value of zero in the fragmentation header of fragment packets other than the first fragment packet ( where it is illegal ) ? The reason this question arose is due to the following statement in the basic spec : > The following conditions are not expected to occur, but are not > considered errors if they do: > ...... > The Next Header values in the Fragment headers of different > fragments of the same original packet may differ. Only the value > from the Offset zero fragment packet is used for reassembly. while another paragraph in the base spec states the following : > If, as a result of processing a header, a node is required to proceed > to the next header but the Next Header value in the current header is > unrecognized by the node, it should discard the packet and send an > ICMP Parameter Problem message to the source of the packet, with an > ICMP Code value of 2 ("unrecognized Next Header type encountered") > and the ICMP Pointer field containing the offset of the unrecognized > value within the original packet. The same action should be taken if > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > a node encounters a Next Header value of zero in any header other > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > than an IPv6 header. > ~~~~~~~~~~~~~~~~~~~~ Note : This question is purely from a testing perspective. Different implementation might interpret this differently and ( some might just leave the Next Header value as zero ). So should a receiving node generate the above ICMP message ? Comments ? Quaizar ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-4488 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 22 13:43:21 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15069; Fri, 22 Dec 95 13:43:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15063; Fri, 22 Dec 95 13:43:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14608; Fri, 22 Dec 1995 13:43:07 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id NAA06589; Fri, 22 Dec 1995 13:43:07 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25736; Fri, 22 Dec 95 16:41:25 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA03226; Fri, 22 Dec 95 16:42:18 EST Date: Fri, 22 Dec 95 16:42:18 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9512222142.AA03226@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com, ietf-ppp@MERIT.EDU Subject: (IPng 976) "IP Version 6 over PPP" draft Cc: dhaskin@BayNetworks.com, eallen@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm attaching the initial draft of IPv6-over-PPP that I know some of you can't wait to see. So here it is. I've also submitted this draft to the draft editor. I will not be reading my mail next week - so don't feel that your feedback is ignored if you don't get a prompt reply. Thanks, Dimitry P.S. I'm not on the PPP mailing list but Ed Allen is. ------------------------------------ cut ----------------------------------- Internet Engineering Task Force Internet Draft Dimitry Haskin Expires July 1996 Ed Allen Bay Networks, Inc. January 1996 IP Version 6 over PPP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Expires July 1996 [Page 1] Internet Draft IP Version 6 over PPP January 1996 Table of Contents 1. Introduction .......................................... 2 1.1. Specification of Requirements ...................... 3 2. Sending IPv6 Datagrams ................................ 3 3. A PPP Network Control Protocol for IPv6 ............... 4 4. IPV6CP Configuration Options .......................... 5 4.1. Interface-Token ................................... 8 4.2. IPv6-Compression-Protocol 5. Stateless Autoconfiguration and Link-Local Addresses .. 9 A. IPV6CP Recommended Options ............................. 10 Security Considerations ....................................... 10 References .................................................... 10 Acknowledgments ............................................... 10 Authors' Addresses ............................................ 11 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer Expires July 1996 [Page 2] Internet Draft IP Version 6 over PPP January 1996 protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. In this document, the NCP for establishing and configuring the IPv6 over PPP is referred as the IPv6 Control Protocol (IPV6CP). The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (power failure at the other end, carrier drop, etc.). 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to inter-operate with another implementation which does include the option. 2. Sending IPv6 Datagrams Before any IPv6 packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the IPv6 Control Protocol must reach the Opened state. Exactly one IPv6 packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0xxx (Internet Protocol Version 6). Expires July 199 [Page 3] Internet Draft IP Version 6 over PPP January 1996 The maximum length of an IPv6 packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. PPP links supporting IPv6 must allow at least 576 octets in the information field of a data link layer frame. 3. A PPP Network Control Protocol for IPv6 The IPv6 Control Protocol (IPV6CP) is responsible for configuring, enabling, and disabling the IPv6 protocol modules on both ends of the point-to-point link. IPV6CP uses the same packet exchange mechanism as the Link Control Protocol (LCP). IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPV6CP packets received before this phase is reached should be silently discarded. The IPv6 Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one IPV6CP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8xxx (IPv6 Control Protocol). Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects. Timeouts IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types IPV6CP has a distinct set of Configuration Options, which are defined below. Expires July 1996 [Page 4] Internet Draft IP Version 6 over PPP January 1996 4. IPV6CP Configuration Options IPV6CP Configuration Options allow negotiation of desirable IPv6 parameters. IPV6CP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed. Up-to-date values of the IPV6CP Option Type field are specified in the most recent "Assigned Numbers" RFC [5]. Current values are assigned as follows: 1 Interface-Token 2 IPv6-Compression-Protocol 4.1. Interface-Token Description This Configuration Option provides a way to negotiate a unique 64-bit interface token to be used for the address autoconfiguration [3] at the local end of the link (see section 5). The interface token MUST be unique within the PPP link; i.e. upon completion of the negotiation different Interface-Token values are to be selected for the ends of the PPP link. Before this Configuration Option is requested, an implementation must choose its tentative Interface-Token. It is recommended that a non-zero value be chosen in the most random manner possible in order to guarantee with very high probability that an implementation will arrive at a unique token value. A good way to choose a unique random number is to start with a unique seed. Suggested sources of uniqueness include machine serial numbers, other network hardware addresses, time-of-day clocks, etc. Note that it may not be sufficient to use a link-layer address alone as the seed, since it will not always be unique. Thus it is suggested that the seed should be calculated from a variety of sources that are likely to be different even on identical systems and as many sources as possible be used simultaneously. Good sources of uniqueness or randomness are required for the Interface-Token negotiation to succeed. If a good source of randomness cannot be found, it is recommended that a zero value be used for the Interface-Token transmitted in the Expires July 1996 [Page 5] Internet Draft IP Version 6 over PPP January 1996 Configure-Request. Note that if at least one of the PPP peers is able to generate a unique random number, the token negotiation will succeed. When a Configure-Request is received with the Interface-Token Configuration Option and the receiving peer implements this option, the received Interface-Token is compared with the Interface-Token of the last Configure-Request sent to the peer. Depending on the result of the comparison an implementation MUST respond in one of the following ways: If the two Interface-Tokens are different, the Interface-Token MUST be acknowledged, i.e. Configure-Ack is sent with the requested Interface-Token, meaning that the responding peer agrees with the Interface-Token requested. If the two Interface-Tokens are equal and are not zero, a Configure-Nak MUST be sent specifying a different non-zero Interface-Token value suggested for use by the remote peer. If the two Interface-Tokens are equal to zero, the Interface-Tokens negotiation MUST be terminated by transmitting the Configure-Reject with the Interface-Token value set to zero. In this case, a unique Interface-Token can not be negotiated. If a Configure-Request is received with the Interface-Token Configuration Option and the receiving peer does not implement this option, Configure-Rej is sent. A new Configure-Request SHOULD NOT be sent to the peer until normal processing would cause it to be sent (that is, until a Configure- Nak is received or the Restart timer runs out). A new Configure-Request MUST NOT contain the Interface-Token option if a valid Interface-Token Configure-Reject is received. Reception of a Configure-Nak with a suggested Interface-Token different from that of the last Configure-Nak sent to the peer indicates a unique Interface-Token. In this case a new Configure- Request MUST be sent with the token value suggested in the last Configure-Nak from the peer. But if the received Interface-Token is equal to the one sent in the last Configure-Nak, a new Interface-Token MUST be chosen. In this case, a new Configure- Request SHOULD be sent with the new tentative Interface-Token. Expires July 1996 [Page 6] Internet Draft IP Version 6 over PPP January 1996 This sequence (transmit Configure-Request, receive Configure- Request, transmit Configure-Nak, receive Configure-Nak) might occur a few times, but it is extremely unlikely to occur repeatedly. More likely, the Interface-Tokens chosen at either end will quickly diverge, terminating the sequence. If negotiation about the Interface-Token is required, and the peer did not provide the option in its Configure-Request, the option SHOULD be appended to a Configure-Nak. The tentative value of the Interface-Token given must be acceptable as the remote Interface-Token; i.e. should be different from the token value selected for the local end of the PPP link. The next Configure- Request from the peer may include this option. If the next Configure-Request does not include this option the peer MUST NOT send another Configure-Nak with this option included. It should assume that the peer's implementation does not support this option. By default, an implementation SHOULD attempt to negotiate the Interface-Token for its end of the PPP connection. A summary of the Interface-Token Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Interface-Token +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface-Token (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface-Token (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 10 Interface-Token The 64-bit Interface-Token which is very likely to be unique to one end of the link or zero if a good sources of uniqueness can not be found. Expires July 1996 [Page 7] Internet Draft IP Version 6 over PPP January 1996 Default No Interface-Token is selected. 4.2. IPv6-Compression-Protocol Description This Configuration Option provides a way to negotiate the use of a specific compression protocol. The IPv6-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired. By default, compression is not enabled. A summary of the IPv6-Compression-Protocol Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IPv6-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Type 2 Length >= 4 IPv6-Compression-Protocol The IPv6-Compression-Protocol field is two octets and indicates the compression protocol desired. Values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. Up-to-date values of the IPv6-Compression-Protocol field are specified in the most recent "Assigned Numbers" RFC [5]. Expires July 1996 [Page 8] Internet Draft IP Version 6 over PPP January 1996 Current values are assigned as follows: Value (in hex) Protocol 004f IPv6 Header Compression Data The Data field is zero or more octets and contains additional data as determined by the particular compression protocol. Default No compression protocol enabled. 5. Stateless Autoconfiguration and Link-Local Addresses The interface token, which is used for forming IPv6 addresses of a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP connection setup (see section 4.1). If no valid interface token has been successfully negotiated, procedures for recovering from such a case are unspecified. One approach is to manually configure all IPv6 addresses of the interface. Link-local addresses of PPP interfaces have the following format: | 10 bits | 16 bits | 38 bits | 64 bits | +----------+--------------+----------------+----------------------+ |1111111010| Interface ID | 0 | Interface Token | +----------+--------------+----------------+----------------------+ The most significant 10 bits of the address is the Link-Local prefix FE80::. Other address fields are as followed: Interface ID - [Robert Elz will provide the text for the "Interface ID" description]. Interface Token - the 64-bit link-unique interface token. 38 zero bits pad out the address between the Interface ID and the Interface Token fields. Expires July 1996 [Page 9] Internet Draft IP Version 6 over PPP January 1996 A. IPV6CP Recommended Options The following Configurations Options are recommended: Interface-Token IPv6-Compression-Protocol Security Considerations Security issues are not discussed in this memo. References [1] W. Simpson, "The Point-to-Point Protocol", RFC 1661, July 1994. [2] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", Internet Draft. [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", Internet Draft [3] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", Internet Draft [4] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Internet Draft [5] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, October 1994. Acknowledgments [TBA] Expires July 1996 [Page 10] Internet Draft IP Version 6 over PPP January 1996 Authors' Addresses Dimitry Haskin Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 email: dhaskin@baynetworks.com Ed Allen Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 email: eallen@baynetworks.com Expires July 1996 [Page 10] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Dec 22 17:31:14 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15149; Fri, 22 Dec 95 17:31:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15143; Fri, 22 Dec 95 17:31:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07225; Fri, 22 Dec 1995 17:31:05 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id RAA10468; Fri, 22 Dec 1995 17:31:07 -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 RAA04254; Fri, 22 Dec 1995 17:31:09 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Dec 1995 17:32:07 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 977) Happy Holidays Cc: hinden@Ipsilon.COM, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We would like to wish everyone a Happy Holiday and Happy New Year. The IPng working group has made great progress in the past year getting the IPv6 protocols finalized and into the standards process. Next year we should see many implementations and the start of IPv6 deployment! Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Dec 23 13:32:16 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15446; Sat, 23 Dec 95 13:32:16 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15440; Sat, 23 Dec 95 13:32:05 PST Received: from everglade ([129.144.201.16]) by caribe.eng.sun.com (5.x/SMI-SVR4) id AA17971; Sat, 23 Dec 1995 13:31:44 -0800 Date: Sat, 23 Dec 1995 13:34:15 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 978) Re: (IPng968) - need for uniq ID's/PPP and identifying interfaces To: 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 > From: "Thomas Narten" > . . . > Bob Gilligan writes: > > >Actually, I think that the use of an IP address to identify the > >receiving interface and specify the outgoing interface, as discussed > >in the latest revision of the API spec, is a rather clean design. > >[...] In the rare case where interfaces have no addresses that > >are unique within the scope of the node, the system could assign its > >own unique "node local" addresses that are used only for identifying > >interfaces within the machine. > > If IP addresses are to be used for uniquely identifying interfaces on > a node, I suspect there will be an assumption made (by applications) > that the interface address/identifier can be used as a source (or > destination) of a packet. If a "node local" address were created that > had no scope beyond the current node, interesting behavior might > result in those cases where node local addresses had to be created (as > opposed to using a proper link-local or other scope address). So > without some careful thought, I'm not sure "node local" addresses > would be such a good idea. . . . I don't see the notion of "node local" addresses as such a foreign concept. After all, we have had the loopback address (127.0.0.1) in IPv4 for quite some time, and applications have learned to deal with the fact that they can not use that as a source address. In the current revision of the API spec, the receiving interface identifier is clearly separated from the source IP address of the received packet. And applications have to explicitly ask to get the receiving interface information, so I don't think they are going to be confused. > . . . If *all* interface identifiers were > node-local, and had no scope beyond the node, we'd probably be OK. But > now we've simply said there has to be a way to name interfaces, and > we've come around full circle. I don't think this is necessarily full-circle. The key point is is that applications would be using IP addresses to uniquely identify interfaces within a node, rather than strings that are cryptic, variable-length, and harder for applications and users to deal with. > Oh, and how do you name interfaces that don't have addresses assigned > to them yet, e.g., while bootstrapping? It seems like we'll still need > a way of naming interfaces independent of using IP addresses. Clearly system administrators need some handle on physical interfaces. But presenting that namespace to applications via the API does not necessarily follow. Administrators need to identify interfaces in terms of what slot the NIC is plugged in to, what driver is being used, etc, while applications don't need to know those details. It makes sense for the "ifconfig" program to deal in terms of interface names (strings like "pcelx1"), but it is cleaner to keep the API in terms of IP addresses. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Dec 24 13:02:39 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15761; Sun, 24 Dec 95 13:02:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15755; Sun, 24 Dec 95 13:02:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05312; Sun, 24 Dec 1995 13:02:29 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id NAA19589; Sun, 24 Dec 1995 13:02:30 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14978(1)>; Sun, 24 Dec 1995 13:02:24 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 24 Dec 1995 13:02:12 -0800 To: Bob Gilligan Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 979) Re: (IPng968) - need for uniq ID's/PPP and identifying interfaces In-Reply-To: Bob.Gilligan's message of Sat, 23 Dec 95 13:34:15 -0800. Date: Sun, 24 Dec 1995 13:01:57 PST From: Steve Deering Message-Id: <95Dec24.130212pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ...The key point is is > that applications would be using IP addresses to uniquely identify > interfaces within a node, rather than strings that are cryptic, > variable-length, and harder for applications and users to deal with. Bob, I'm surprised by your contention that 16-byte-long IPv6 addresses would be more convenient for applications or users to deal with than a character string or a small integer index, for local identification of interfaces. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 26 01:14:26 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16157; Tue, 26 Dec 95 01:14:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16151; Tue, 26 Dec 95 01:14:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09578; Tue, 26 Dec 1995 01:14:14 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id BAA24001; Tue, 26 Dec 1995 01:14:14 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA18642; Tue, 26 Dec 1995 04:08:00 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18698; Tue, 26 Dec 1995 04:07:58 -0500 Message-Id: <9512260907.AA18698@wasted.zk3.dec.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 980) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Thu, 21 Dec 95 11:29:48 PST." <199512211929.LAA09254@bobo.eng.sun.com> Date: Tue, 26 Dec 95 04:07:57 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk %> The problem arises in a multihome situation on a single node supporting %> multiple links (802.3 media) where the interfaces (802.3 stations) exist %> on different links for the same node. In this case it is "perceived" %> that the interface-token (MAC address) may be duplicated on each link. %> IPv6 ND/Addr conf Duplicate Address Detection does not verify that the %> link-local address (or any address (site, global)) is not duplicated across %> links. It has been mentioned in the IPng WG that some implementations %> will use the CPU # (as an example) to assign the link-layer address %> (identifier for 802.3 station) for all interfaces (stations) across %> multiple links. Hence, there is no way to differentitate the link-local %> address across the multihome links on a single node. By using Dimitrys %> suggestion it is possible to discriminate the link-layer address and %> interface-token via the 16bits (high or low) of the lower 64bits of a %> link-local address. Neighbor Discovery (ND) in a mutlihomed node %> the link-local address would not be duplicated and implementors avoid having %> to carry interface-IDs in however they maintain ND cache or tables or %> whatever they want to call it in their implementations. It also removes %> having to have a priori knowledge of interfaces at the application layer %> should the link-local address be used to communicate on a link (not off %> link). >The above two marked sentences tell me that you (and probably other) >believe that interface tokens solve all the hard problems related >to link-local address on multihomed hosts. They do not. Not my belief? It only solves the problems I stated above of which no one or me ever stated in this discussion. Sounds like you should have come to our Multihome discussion at Dallas as the cases we discussed instead of an "addrconf" meeting clearly articulated this discussion does not solve the multihome problem. >An example: > H2 is a multihomed node with two interfaces (if0 and if1) > connection it to link0 and link1,respectively. > The links are of the same type and this link type does not > have globally unique link-layer addresses. For instance, it > could be appletalk/localtalk. Well I think this should have been outlawed as illegal and always have but lets go on. > On each link there is a single-homed host: H0 on link0 and H1 > on link1. Let's call there interfaces if0. Why would anyone call their interfaces the same name or mneumonic? Or did you mean the singular "interface" for both H0 and H1 which is if0? > The link-layer addresses on H2 is A2 (happens to be the same > for both if0 and if1). With the interface-ID idea > H2 would have a different link-local address for if0 and > if1 (we can call them A2-0 and A2-1). OK. > Independent of any interface-ID, when H2 needs to represent > H0 and H1 it needs to know what interface to send packet out > on. In particular, if H0 and H1 happens to have the same > (e.g. localtalk) link-layer address it would be impossible > to distinguish between them unless the remote addresses > are associated with some identifier for the interface. > (NOTE: the interface-ID proposal puts IDs on the multihomed > hosts own addresses. It can not effect the addresses of other > nodes.) Agree with your last sentences. I am only concerned about differentitation of link-local addresses on the "same" node. >The above example applies whether to both IP/ND data structures and >to applications. If the addresses do not include a prefix >that can be used to determine which interface to use you need >an adjunct interface identifier anywhere you have an address. >Thus a multihomed host using telnet might need to specify the >interface on the command line: > telnet if1 If its telnet FE80::????link-layer-addr then at the transport or if one likes the network layer, when the FE80 prefix is seen the node "knows" the link-local address which interface is being used. >This is the only possibility (independent of any interface-IDs) if >the link-layer addresses are not globally unique (or a least unique >across all links connected to the multihomed node). >As Dan McDonald has pointed out, if the link-layer addresses are >unique across all connected links, it is possible to have ND try to >find the destination by sending Neighbor Solicitations out all >interfaces. This could remove the need to specify the interface name to >e.g. telnet with this particular (albeit common - Ethernet) type link. >But Dan's idea has nothing to do with interface_IDs either. But it makes the idea work for link-local addresses. >So what are interface-IDs useful for? >Only when a multihomed node wants to use a link-local address to >uniquely identify one of its OWN interfaces. EXACTLY! You just stated why I want them in yet another manner. Thank You. >This could be very useful in many cases so I'm not saying that we >shouldn't add interface-IDs to the link-local addresses. >All I'm saying is that we need to make sure we understand what >problems interface-IDs solve and which they do not solve. >They are not the holy grail that will make the handling of >link-local addresses on multihomed nodes trivial. Absolutely. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 26 01:21:55 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16172; Tue, 26 Dec 95 01:21:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16166; Tue, 26 Dec 95 01:21:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09673; Tue, 26 Dec 1995 01:21:44 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id BAA24367; Tue, 26 Dec 1995 01:21:44 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA02342; Tue, 26 Dec 1995 04:18:14 -0500 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18986; Tue, 26 Dec 1995 04:18:00 -0500 Message-Id: <9512260918.AA18986@wasted.zk3.dec.com> To: Steve Deering Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com Subject: (IPng 981) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Thu, 21 Dec 95 16:00:55 PST." <95Dec21.160057pst.75270@digit.parc.xerox.com> Date: Tue, 26 Dec 95 04:18:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >I think Erik's point is also important: we must not assume that making >link-local addresses unique within a node solves more problems than it >really does. For instance, it does not eliminate the need for some method >for applications to learn what interface a packet arrived on, independent >of the addresses in the packet, and to specify what interface a packet >should go out on, independent of the addresses in the packet. In the case of link-local on that specific node it can. I already responded to Erik's mail. Also as an aside comment no one ever said it did solve the complex multihome problems. >Here's another example to ponder (maybe this is a sub-example of what Erik >was talking about). Consider multihomed nodes with PPP links only, and >assume that the link-local addresses for PPP interfaces are generated by >having one end use token value 1 and the other end use token value 2 >(with some protocol to determine which end gets which of the two tokens). >This would be a perfectly reasonable way of generating link-local addresses >for PPP links -- we certainly don't want to require that nodes having only >PPP links also acquire an IEEE 802 address or some other likely-to-be- >globally-unique token. Assume also that nodes add interface indexes to >their link-local addresses, to guarantee uniqueness within the node. >The following illustration shows three nodes, A, B, and C, joined by >PPP links x and y. The end of each link is labeled with its assigned >link-local address, in the form LL/i/t, where LL is the link-local prefix, >i is the local interface index, and t is the link-unique token for the >interface. ------- ------- ------- | | link x | | link y | | ------| A |----------------| B |----------------| C |------ LL/0/1| |LL/1/2 LL/0/1| |LL/1/2 LL/0/1| |LL/1/2 ------- ------- ------- >The assigned link-local addresses have the necessary property that each >end of a link has a different address, and the additional property desired >by Dimitry and others that each of a node's interfaces has a different >link-local address. But note that, for node B, the address LL/1/2 has >two possible meanings: either node B's only interface on link y, or >node A's interface on link x, and without qualifying any reference to >that address with some interface identifier, it is ambiguous. >Now, you might suggest that B should choose its interface indexes so as >to avoid the ambiguity, but that would mean waiting to learn what A and >C had chosen, but A and C might have to wait to learn what their further- >out neigbors had chosen, who in turn would have to wait... The only issue at hand for me in your example is Node B. It can know which interface is being used link X by LL/0/1 or link Y LL/1/2 inside the network code path as long as LL is denoted by FE80 prefix and then the rest of the address. So a telnet to a link-local address that is properly configured in fact has the interface for that "single-node" known by its address. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 26 13:23:17 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16365; Tue, 26 Dec 95 13:23:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16359; Tue, 26 Dec 95 13:23:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27611; Tue, 26 Dec 1995 13:22:59 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA01688; Tue, 26 Dec 1995 13:23:00 -0800 Subject: (IPng 982) NUD, TCP, etc (from IPv6imp list) To: ipng@sunroof.eng.sun.com Date: Tue, 26 Dec 1995 16:23:24 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9512261623.aa01929@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Currently, 4.4-Lite's TCP pretty much ignores errors until TCP itself has done enough retransmissions, etc. to determine the problem. Observe: =====================(Cut up to and including here.)====================== /* * Notify a tcp user of an asynchronous error; * store error as soft error, but wake up user * (for now, won't do anything until can select for soft error). */ void tcp_notify(inp, error) struct inpcb *inp; int error; { register struct tcpcb *tp = (struct tcpcb *)inp->inp_ppcb; register struct socket *so = inp->inp_socket; /* * Ignore some errors if we are hooked up. * If connection hasn't completed, has retransmitted several times, * and receives a second error, give up now. This is better * than waiting a long time to establish a connection that * can never complete. */ if (tp->t_state == TCPS_ESTABLISHED && (error == EHOSTUNREACH || error == ENETUNREACH || error == EHOSTDOWN)) { return; } else if (tp->t_state < TCPS_ESTABLISHED && tp->t_rxtshift > 3 && tp->t_softerror) so->so_error = error; else tp->t_softerror = error; wakeup((caddr_t) &so->so_timeo); sorwakeup(so); sowwakeup(so); } =====================(Cut up to and including here.)====================== I though one of the goals of NUD was to keep TCP connections from hanging too long because of neighbor unreachability. The way I tickle tcp_notify for NUD failures is with EHOSTDOWN (i.e. ICMPv6 Address Unreachable messages eventually cause EHOSTDOWN to get percolated up to the socket). Do you think I should put if EHOSTDOWN, immediately wakeup the socket with failure? Should I only do it if I'm not yet established? It would be nice to hear from those who are more experienced with TCP. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Dec 26 13:27:17 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16385; Tue, 26 Dec 95 13:27:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16379; Tue, 26 Dec 95 13:27:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27780; Tue, 26 Dec 1995 13:27:00 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA02097; Tue, 26 Dec 1995 13:27:01 -0800 Subject: (IPng 983) Followup note To: IPng Mailing list Date: Tue, 26 Dec 1995 16:27:26 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9512261627.aa01965@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a small followup note: With NUD, v6 telnets take the same amount of time to time out as v4 telnets, but the v6 telnet gives a more informative ("Host is down") message after the timeout. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 27 07:11:44 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16670; Wed, 27 Dec 95 07:11:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16664; Wed, 27 Dec 95 07:11:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24232; Wed, 27 Dec 1995 07:11:25 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id HAA26381; Wed, 27 Dec 1995 07:11:25 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10709; 27 Dec 95 9:51 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 984) I-D ACTION:draft-ietf-ipngwg-pppext-ipv6cp-00.txt Date: Wed, 27 Dec 95 09:51:07 -0500 Message-Id: <9512270951.aa10709@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-pppext-ipv6cp-00.txt Pages : 10 Date : 12/26/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. 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-pppext-ipv6cp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-00.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 (192.12.192.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-pppext-ipv6cp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951226140556.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pppext-ipv6cp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951226140556.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/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Dec 27 11:17:56 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16798; Wed, 27 Dec 95 11:17:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16792; Wed, 27 Dec 95 11:17:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04996; Wed, 27 Dec 1995 11:17:37 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id LAA26448; Wed, 27 Dec 1995 11:17:39 -0800 Received: from otlaser.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA25870; Wed, 27 Dec 1995 14:05:47 -0500 Received: by tlaser.zk3.dec.com; (5.65v3.2/1.1.8.2/06Mar95-1016AM) id AA27289; Wed, 27 Dec 1995 14:05:38 -0500 Date: Wed, 27 Dec 1995 14:05:38 -0500 From: Jack McCann USG Message-Id: <9512271905.AA27289@tlaser.zk3.dec.com> To: nordmark@Eng Subject: (IPng 985) Re: Comments on draft-ietf-ipngwg-pmtuv6-00.txt Cc: deering@parc.xerox.com, huitema@pax.inria.fr, ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thanks for your comments on the pmtuv6 spec. >Date: Tue, 5 Dec 1995 20:59:27 -0800 >From: nordmark@lillen.eng.sun.com (Erik Nordmark) >Message-Id: <199512060459.UAA00320@lillen.Eng.Sun.COM> >To: mccann@zk3.dec.com, deering@parc.xerox.com >Subject: (IPng 890) Comments on draft-ietf-ipngwg-pmtuv6-00.txt >Cc: ipng@sunroof.eng.sun.com, nordmark@eng.sun.com > >The specification needs to include this from the IPv6 base >secification: >"In response to an IPv6 packet that is sent to an IPv4 destination (i.e., >a packet that undergoes translation from IPv6 to IPv4), the originating >IPv6 node may receive an ICMP Packet Too Big message reporting a Next- >Hop MTU less than 576. In that case, the IPv6 node is not required to >reduce the size of subsequent packets to less than 576, but must include >a Fragment header in those packets so that the IPv6-to-IPv4 translating >router can obtain a suitable Identification value to use in resulting >IPv4 fragments. Note that this means the payload may have to be reduced >to 528 octets (576 minus 40 for the IPv6 header and 8 for the Fragment >header), and smaller still if additional extension headers are used." I did not include this because it was already in the IPv6 base spec, and I do not want to have the same thing specified in two places. I can include it in the pmtuv6 spec, but: 1. As Christian Huitema pointed out: >I thought that we had given up the idea of translation, precisely because >this kind of problems becomes rapidly untractable... Perhaps this does not belong in either the base spec or the pmtu spec, but rather belongs in a translation spec (if such a thing comes to exist). 2. I don't want to repeat it if it's staying in the base spec. Steve, Bob: want to move this? >If path MTU discovery includes the flow ID in the path specification >it would seem that for consistency we should have flow specific >redirects in IPv6. Or is it the case that the router to router path >can depend on the flow id but the first hop router can not depend >on the flow id? It seems reasonable that one first hop router may be preferable over another first hop router for a given flow, and that a router may redirect based on flow. ND is not explicit on this subject, but it does not seem to preclude it either. We can get the flow from the 'Redirected Header' option in the ICMP redirect (provided we have not overflowed 560 octets before we try to add the option). >Editorial suggestions and nits: > >It might make sense to add a section "comparison with IPv4" >listing what was specified at the WG meeting to aid readers and >implementors that are familiar with IPv4 path mtu discovery. > >It might make sense to add the definitions of path MTU and link MTU >up front (for readers that are not familiar with IPv4 path mtu discovery). > >Section 3 has a reference to [IPv6] but the references section >list the document as [IPv6-SPEC]. > >The last paragraph in section 3: > Would it make sense to clarify it by saying "or the result of > having multiple paths with different PMTU to the destination"? > >Section 4.2: > There are references to "subnet routes" which should probably be > replaced by "prefix routes". Also, it might make sense to > use the neighbor discovery terminology of "destination cache" > etc. > >Section 4.5: > Since NFS and Sun RPC operate over both TCP and UDP it would make > sense to add "over UDP" to the second paragraph. OK, except for the part about changing to ND terminology for implementation suggestions, I'll have to think about that. > > Erik > - Jack ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com