From owner-ipng Tue Jan 2 09:16:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18796; Tue, 2 Jan 96 09:16:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09427; Mon, 18 Dec 95 04:55:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10108; Mon, 18 Dec 1995 04:55:47 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id EAA23921; Mon, 18 Dec 1995 04:55:47 -0800 Received: from ppp-pm01-dy-5.opr.oakland.edu (ppp-pm01-dy-5.opr.oakland.edu [141.210.14.166]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id GAA02401 for ; Mon, 18 Dec 1995 06:55:46 -0600 Received: by ppp-pm01-dy-5.opr.oakland.edu with Microsoft Mail id <01BACD1E.1392A300@ppp-pm01-dy-5.opr.oakland.edu>; Mon, 18 Dec 1995 07:54:36 -0500 Message-Id: <01BACD1E.1392A300@ppp-pm01-dy-5.opr.oakland.edu> From: Brad Wilson To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 986) Re: Last Call: A Method for the Transmission of IPv6 Date: Mon, 18 Dec 1995 07:46:30 -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 >> 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 This seems like a reasonable suggestion, especially given the fact that at least one major vendor (Sun) gives a single MAC address to all its Ethernet interfaces. -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Tue Jan 2 09:24:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18842; Tue, 2 Jan 96 09:24:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09702; Mon, 18 Dec 95 09:58:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05878; Mon, 18 Dec 1995 09:58:27 -0800 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id JAA23561; Mon, 18 Dec 1995 09:58:28 -0800 Received: from rja-ss20.cisco.com.noname (rja-ss20.cisco.com [171.69.58.102]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id JAA27325 for ; Mon, 18 Dec 1995 09:58:28 -0800 Received: by rja-ss20.cisco.com.noname (4.1/SMI-4.1) id AA09783; Mon, 18 Dec 95 09:59:11 PST Date: Mon, 18 Dec 95 09:59:11 PST From: rja@rja-ss20.cisco.com (Randall Atkinson) Message-Id: <9512181759.AA09783@rja-ss20.cisco.com.noname> To: ipng@sunroof.eng.sun.com Subject: (IPng 987) Re: draft-ietf-ipngwg-fddi-ntwrks-02.txt In-Reply-To: <9512181607.AA17391@cichlid.raleigh.ibm.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> For purposes of this document, information received from DHCP is >> considered ``manually configured''. In article <9512181607.AA17391@cichlid.raleigh.ibm.com> Thomas Narten wrote: > >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 actually like the current wording. It helps make things more clear to the reader IMHO. >Is there WG consensus that DHCP-learned info is considered "manually >configured" from the perspective of all of our documents? No. Your broader usage of "manually configured" conflicts with RFC-1825-1827, which are already Proposed Standard RFCs relating to IPv6. >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? On this, IMHO, we ought not be specifying things at a micro-level of detail... 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 Tue Jan 2 10:20:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18923; Tue, 2 Jan 96 10:20:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10774; Tue, 19 Dec 95 03:48:07 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14691; Tue, 19 Dec 1995 03:48:15 -0800 Received: from domen.uninett.no by venus.Sun.COM (Sun.COM) id DAA27363; Tue, 19 Dec 1995 03:48:15 -0800 Received: from troms6.or.uninett.no by domen.uninett.no with SMTP (PP) id <11021-0@domen.uninett.no>; Tue, 19 Dec 1995 12:47:15 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id DAA22798; Tue, 19 Dec 1995 03:50:28 -0600 Message-Id: <199512190950.DAA22798@dale.uninett.no> From: Harald.T.Alvestrand@uninett.no To: bound@zk3.dec.com Cc: Dimitry Haskin , iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Subject: (IPng 988) 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 10:09:32 EST." <9512181509.AA32647@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <22794.819366626.1@dale.uninett.no> Date: Tue, 19 Dec 1995 10:50:27 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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. 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? - 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? - 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? 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"? Thanks for your help in understanding the problem! Harald A ------------------------------------------------------------------------------ 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 Jan 2 10:28:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18952; Tue, 2 Jan 96 10:28:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10873; Tue, 19 Dec 95 08:32:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02540; Tue, 19 Dec 1995 08:32:50 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id IAA07667; Tue, 19 Dec 1995 08:32:51 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13670; Tue, 19 Dec 95 11:31:48 EST Received: from naxos.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA00281; Tue, 19 Dec 95 11:32:41 EST Date: Tue, 19 Dec 95 11:32:41 EST From: wling@BayNetworks.com (Wenken Ling) Message-Id: <9512191632.AA00281@pobox.BayNetworks.com> To: dhaskin@BayNetworks.com Subject: (IPng 989) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> 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 ------------------------------------------------------------------------------ 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 Jan 2 10:42:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18980; Tue, 2 Jan 96 10:42:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11856; Wed, 20 Dec 95 07:35:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04806; Wed, 20 Dec 1995 07:35:17 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id HAA13608; Wed, 20 Dec 1995 07:35:14 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id RAA00698; Wed, 20 Dec 1995 17:33:44 +0200 Date: Wed, 20 Dec 1995 17:33:44 +0200 From: Juha Heinanen Message-Id: <199512201533.RAA00698@lohi.dat.tele.fi> To: ipng@sunroof.eng.sun.com Cc: yakov@cisco.com, roll@stupi.se, hinden@ipsilon.com, deering@parc.xerox.com, postel@isi.edu Subject: (IPng 990) questions and concerns regarding unicast-addr-fmt-02 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i read unicast-addr-fmt-02 draft and have a couple of questions/concerns? - when can we expect the rfc to be published? - are the registries already in place (i'm especially interested in europe)? - how can it be possible that in the future providerid can grow to the right and the subscriberid to the left? shouldn't it be one or the other? if a particular provider would like to grow the subscriberid already now to the left, is it possible? a provider that operates in several countries may namely find the three octet subscriber field too short to implement a multilayer hierarchy. for example, the provider might want to assign 8 bits for the country code and then if the provider has several hundred points of presense per country, then there may not be enough bits left to identify a subscriber in a pop. - why is the subscriberid not allowed to grow to the right? in summary, i'm worried that there is not enough bits for a large international provider in the proposed scheme if the use of (one of) the reserved bytes for subscriberid is not allowed right from the start. -- juha ps. i'm not on the ipng list, so i would appreciate a cc to me. ------------------------------------------------------------------------------ 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 Jan 2 10:47:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19009; Tue, 2 Jan 96 10:47:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12100; Wed, 20 Dec 95 10:25:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26496; Wed, 20 Dec 1995 10:25:09 -0800 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id KAA25979; Wed, 20 Dec 1995 10:25:10 -0800 Received: from rja-ss20.cisco.com.noname (rja-ss20.cisco.com [171.69.58.102]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id KAA17756; Wed, 20 Dec 1995 10:25:09 -0800 Received: by rja-ss20.cisco.com.noname (4.1/SMI-4.1) id AA26870; Wed, 20 Dec 95 10:25:52 PST Date: Wed, 20 Dec 95 10:25:52 PST From: rja@rja-ss20.cisco.com (Randall Atkinson) Message-Id: <9512201825.AA26870@rja-ss20.cisco.com.noname> To: kre@munnari.oz.au Subject: (IPng 991) Re: Abolishing unnumbered interfaces In-Reply-To: <5375.819452962@munnari.OZ.AU> References: <95Dec18.153006pst.75270@digit.parc.xerox.com> Organization: cisco Systems, Inc., 170 W. Tasman Drive, San Jose, CA Cc: ipng@sunroof.eng.sun.com 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). In article <5375.819452962@munnari.OZ.AU> kre wrote: > This makes no sense, when taken at its most literal. (see below) > 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. I'm glad we're agreed on this at least. > 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. Consider Frame Relay or ATM or X.25 where there can be N logical interfaces on a single physical interface. How would you implement your proposal on such a router ? What is the benefit of doing this as compared with using an unnumbered interface ? Further, please educate me on what _exactly_ it buys me to have a link-local on an interface in the situations where IPv4 routers currently have unnumbered interfaces ? Please consider a single point-to-point serial interface connecting 2 routers as part of your answer. It requires some (possibly modest, but non-zero) amount of cycles for me to number an interface. It also increases my implementation effort because the code to handle unnumbered interfaces _already_ exists and works fine. I can't currently see the benefit to abolishing unnumbered interfaces on routers, but am willing to be educated if there is some good reason for this. >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. We can certainly discuss changing the AddrConf document still, so the existing AddrConf text is not by itself a reason to change the other draft. IMHO, the AddrConf document should be aligned with Steve Deering's current text making unnumbered interfaces explicitly permitted for routers. > 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. I'll probably have to have my internal interface identifier ANYWAY, so my rough cut estimate is that the link-local is pure expense with no benefit for interfaces that are currently (IPv4) unnumbered. I'd like to reuse as much of the existing software as possible. If there is some benefit to changing things (as there was with replacing ARP with an ICMP-based Neighbor Discovery), then I'm willing and happy to write new stuff. For now, I need to be educated on how abolishing unnumbered router interfaces is a benefit to me. Regards, Ran rja@cisco.com PS: Here is my new address/phone information... Voice: +1 (408) 526-6566 Fax: +1 (408) 526-4952 Geographic: cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA ------------------------------------------------------------------------------ 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 Jan 2 10:51:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19024; Tue, 2 Jan 96 10:51:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12147; Wed, 20 Dec 95 11:45:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08740; Wed, 20 Dec 1995 11:45:40 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id LAA25095; Wed, 20 Dec 1995 11:45:39 -0800 Received: from ppp-pm01-dy-13.opr.oakland.edu (ppp-pm01-dy-13.opr.oakland.edu [141.210.14.174]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id NAA16812 for ; Wed, 20 Dec 1995 13:45:34 -0600 Received: by ppp-pm01-dy-13.opr.oakland.edu with Microsoft Mail id <01BACEE9.9ACC6BE0@ppp-pm01-dy-13.opr.oakland.edu>; Wed, 20 Dec 1995 14:44:02 -0500 Message-Id: <01BACEE9.9ACC6BE0@ppp-pm01-dy-13.opr.oakland.edu> From: Brad Wilson To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 992) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Date: Wed, 20 Dec 1995 14:36:32 -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 >> 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" Except that link local addresses are not guaranteed to be unique, even inside a single host. A unique "tag" of some kind is needed. -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Tue Jan 2 11:07:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19146; Tue, 2 Jan 96 11:07:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13353; Thu, 21 Dec 95 04:30:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25299; Thu, 21 Dec 1995 04:30:54 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id EAA19336; Thu, 21 Dec 1995 04:30:53 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00981 Thu, 21 Dec 1995 23:30:45 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: droms@bucknell.edu (Ralph Droms) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 993) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Thu, 21 Dec 1995 06:55:19 CDT." Date: Thu, 21 Dec 1995 23:30:58 +1100 Message-Id: <6180.819549058@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 21 Dec 1995 06:55:19 -0500 From: droms@bucknell.edu (Ralph Droms) Message-ID: 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. I'm not sure the DNS approach would work though - the client can discover that way that it is supposed to own a particular address, but cannot determine just where the address should be applied. It is not clear to me that there is another sane way for it to discover that information currently. I think I now understand the previous confusion, it was not clear (on the dhcp v6 list) just what kinds of "multiple addresses" people were considering, there clearly seem to be two distinct types, ones where the client knows it needs a new address, for some extra service (there is no point arguing about whether this is "good" or not, it happens, and will continue to happen). For those, clearly the client should be initiating some kind of transaction to obtain the address. And then there are the addresses that result from wider configuration at the site (or larger) level - on that link there (perhaps all links) every node that gets an address should be given one from each of these N prefixes. Again, there is no point arguing about whether this is a need or not, clearly it is going to happen (whether due to renumbering, multi-homing, or something else). For these addreses, the client should just be asking for "addresses for this link", the server should return however many are appropriate. Note there is no way that a (non manually configured) client can figure out how many addresses it will receive this way. Even if it were to sonnp the wire, and see that every other client out there is receiving 4 addresses every time they ask, this particular client may have been configured (by the DHCP administrator) to receive more or less of them for some reason. Eg: if 4 addresses are being handed out to old nodes, but one of those is being (on its way to be) deprecated, new nodes appearing on the link may be given only the 3 addresses that will remain, they have no pre-existing need to continue using an address that is being phased out of the older nodes (but which they still need until it has gone completely). I believe that both kinds of "multiple addresses" need to be handled in the DHCP protocol (for V6). Being able to request an "extra address" sometime after requesting an earlier set would also be useful. Eg: with the current URL fiasco of addressing (or something similar in the future), a node might want to start serving a new URL. For that it needs an address. Ideally we don't want nodes to configure those addresses, and I am not sure the DNS trick will work, the address has to come from somewhere, if stateful autoconfig is in use (ie: DHCP), then it seems natural to go back to DHCP and ask for a nw address. The server may then return a group of addresses as at any other time of course. 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 Tue Jan 2 11:10:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19226; Tue, 2 Jan 96 11:10:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13408; Thu, 21 Dec 95 05:59:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28621; Thu, 21 Dec 1995 05:59:43 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id FAA28226; Thu, 21 Dec 1995 05:59:43 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id PAA02059; Thu, 21 Dec 1995 15:58:03 +0200 Date: Thu, 21 Dec 1995 15:58:03 +0200 From: Juha Heinanen Message-Id: <199512211358.PAA02059@lohi.dat.tele.fi> To: ipng@sunroof.eng.sun.com Cc: postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, yakov@cisco.com Subject: (IPng 994) more on provider based unicast address format Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i didn't get any reply to my questions yesterday, so i have had time to think the address format issue a little bit longer. the draft format is: 010|registry|provider|x|subscriber|y|intra-sub provider or subscriber can extend to x and intra-sub can extend to y. the draft doesn't say, if i get a subscriber code zz, can the registry later allocate for someone else zzx, ie, will my subscriber prefix 010registryxx uniquely identify me. i think it should. one way to solve this is to start the provider code with 0 if it is two bytes and with 1 if it extends to x. then if i get a two byte provider code, i can use x as part of the subscriber field. is this the intend? also, the draft says that y can only be used to extend intra-sub, not subscriber. what i would like to do is to internally split the subscriber into hi-order and low-order parts and if the low-order part begins with 0, then y will extend to intra-sub and it it begins with 1, then y is part of subscriber. comments? in any case, i don't think the current draft is ready to be promoted to an rfc, since it leaves too many things unclear. on the other hand, i consider the addressing issue to be a very important and urgent one. do we really need to wait until the next meeting before getting it resolved? please cc your answer to me. -- juha ------------------------------------------------------------------------------ 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 Jan 2 11:26:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19299; Tue, 2 Jan 96 11:26:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14044; Thu, 21 Dec 95 13:40:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21453; Thu, 21 Dec 1995 13:40:31 -0800 Received: from reef.bucknell.edu by mercury.Sun.COM (Sun.COM) id NAA23252; Thu, 21 Dec 1995 13:40:30 -0800 Received: by reef.bucknell.edu (5.65/IDA-1.2.8) id AA05335; Thu, 21 Dec 1995 16:40:29 -0500 Date: Thu, 21 Dec 1995 16:40:29 -0500 From: Ralph Droms Message-Id: <9512212140.AA05335@reef.bucknell.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 995) Re: DISCUSSION; Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew Molitor wrote: > Or, as someone else pointed out, IP could move ahead into the 1970s >and get real directory/service advertisement protocols. Hear, hear. DHCP was originally conceived as a bare-bones bootstrap mechanism to get enough configuration into a node so it could successfully communicate with other, more sophisticated directory and service advertisement mechanisms. IMHO, the additional layers of function being proposed for DHCPv6 - on-demand requests for additional addresses, names of nodes where application-layer can be found, protocol stack parameter management, asynchronous renumbering - should be provided by other mechanisms such as DNS, SVRLOC and SNMP. Trying to add all of these additional features into DHCP, which is, after all, a pretty crufty example of damage to a layered model (I don't mean that in a derogatory way; DHCP *has* to break any layered models just to get its job done), is the wrong way to go. - 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 Jan 2 11:32:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19345; Tue, 2 Jan 96 11:32:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14097; Thu, 21 Dec 95 15:55:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09440; Thu, 21 Dec 1995 15:55:20 -0800 Received: from newsgate.dircon.co.uk by mercury.Sun.COM (Sun.COM) id PAA25133; Thu, 21 Dec 1995 15:55:18 -0800 Received: (from cymru@localhost) by newsgate.dircon.co.uk (8.6.12/8.6.9) with UUCP id XAA29549 for ipng@sunroof.Eng.Sun.COM; Thu, 21 Dec 1995 23:32:19 GMT Received: from lxorguk.ukuu.org.uk (Ulxorguk@localhost) by snowcrash.cymru.net (8.7.1/8.7.1) with UUCP id XAA30553 for sunroof.Eng.Sun.COM!ipng; Thu, 21 Dec 1995 23:02:00 GMT Received: by lightning.swansea.linux.org.uk (Smail3.1.29.1 #1) id m0tSt3g-0005FWC; Thu, 21 Dec 95 22:01 GMT Message-Id: From: anarchy@lxorguk.ukuu.org.uk (Alan Cox) Subject: (IPng 996) Re: DISCUSSION: Use of multiple Addresses on Interfaces To: amolitor@anubis.network.com (Andrew Molitor) Date: Thu, 21 Dec 1995 22:01:52 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9512211549.AA16612@anubis.network.com> from "Andrew Molitor" at Dec 21, 95 09:49:50 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Or, as someone else pointed out, IP could move ahead into the 1970s > and get real directory/service advertisement protocols. ISP's are using multiple addresses for things like hot swapping on web servers. Each box has 3 organisations pages on it and can flip in about 2 seconds to take on one of the other boxes if it fails just by adding an extra local address and reloading its http daemon. Do that with a distributable directory service - remembering the DNS is also hot swapped this way. Alan ------------------------------------------------------------------------------ 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 Jan 2 11:38:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19376; Tue, 2 Jan 96 11:38:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19370; Tue, 2 Jan 96 11:38:07 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28087; Tue, 2 Jan 1996 11:37:50 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id LAA24106; Tue, 2 Jan 1996 11:37:49 -0800 Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi.dat.tele.fi (8.6.12/8.6.12) with SMTP id VAA11140; Tue, 2 Jan 1996 21:36:04 +0200 Message-Id: <30E98944.9FD@lohi.dat.tele.fi> Date: Tue, 02 Jan 1996 21:36:36 +0200 From: Juha Heinanen Organization: Telecom Finland Inc. X-Mailer: Mozilla 2.0b4 (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Cc: postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, yakov@cisco.com Subject: (IPng 997) rsend of my message concerning provider based unicast address format Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i have been wondering whyu noone had reacted to my questions regarding the provider based unicast address draft. one explanation can be that for some reason, it was not distributed to the list. i'll therefore resend the message below and also correct one typo in it. -- juha --------------------- i didn't get any reply to my questions yesterday, so i have had time to think the address format issue a little bit longer. the draft format is: 010|registry|provider|x|subscriber|y|intra-sub provider or subscriber can extend to x and intra-sub can extend to y. the draft doesn't say, if i get a *provider* code zz, can the registry later allocate for someone else zzx, ie, will my *provider* prefix 010registryxx uniquely identify me. i think it should. one way to solve this is to start the provider code with 0 if it is two bytes and with 1 if it extends to x. then if i get a two byte provider code, i can use x as part of the subscriber field. is this the intend? also, the draft says that y can only be used to extend intra-sub, not subscriber. what i would like to do is to internally split the subscriber into hi-order and low-order parts and if the low-order part begins with 0, then y will extend to intra-sub and it it begins with 1, then y is part of subscriber. comments? in any case, i don't think the current draft is ready to be promoted to an rfc, since it leaves too many things unclear. on the other hand, i consider the addressing issue to be a very important and urgent one. do we really need to wait until the next meeting before getting it resolved? please cc your answer to me. -- juha ------------------------------------------------------------------------------ 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 Jan 2 11:52:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19415; Tue, 2 Jan 96 11:52:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15109; Fri, 22 Dec 95 15:53:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28592; Fri, 22 Dec 1995 15:53:29 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id PAA29324; Fri, 22 Dec 1995 15:53:30 -0800 Received: from ppp-pm01-dy-2.opr.oakland.edu (ppp-pm01-dy-2.opr.oakland.edu [141.210.14.163]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id RAA06124; Fri, 22 Dec 1995 17:53:26 -0600 Received: by ppp-pm01-dy-2.opr.oakland.edu with Microsoft Mail id <01BAD09E.BE07C3A0@ppp-pm01-dy-2.opr.oakland.edu>; Fri, 22 Dec 1995 18:53:11 -0500 Message-Id: <01BAD09E.BE07C3A0@ppp-pm01-dy-2.opr.oakland.edu> From: Brad Wilson To: "ietf-ppp@MERIT.EDU" , "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 998) RE: "IP Version 6 over PPP" draft Date: Fri, 22 Dec 1995 18:52:17 -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 Two questions ... excuse my ignorance. :-) >> 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). Does other media differentiate between IP and IPv6 packets with different packet types? The last I knew (admittedly, I haven't been watching the non-PPP stuff too closely) the packet type for both was the same. >> 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). Shouldn't this be MUST? Do any other media allow manually configured addresses in IPv6? I thought the whole point was autoconfig. :-) Is there a time when manual configuration is desired? -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Tue Jan 2 12:02:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19481; Tue, 2 Jan 96 12:02:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19474; Tue, 2 Jan 96 12:02:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01559; Tue, 2 Jan 1996 12:01:52 -0800 Received: from trane.uninett.no by mercury.Sun.COM (Sun.COM) id MAA02164; Tue, 2 Jan 1996 12:01:52 -0800 Received: (from sthaug@localhost) by trane.uninett.no id VAA04445 (8.6.12/IDA-1.6); Tue, 2 Jan 1996 21:01:45 +0100 Date: Tue, 2 Jan 1996 21:01:44 +0100 (MET) From: Steinar Haug 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 999) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: <199512190950.DAA22798@dale.uninett.no> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 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. > > 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? The default for Suns with multiple Ethernet interfaces is that all the interfaces have the same Ethernet address. Can be changed with ifconfig. If you run DECnet IV it's a requirement that all Ethernet interfaces have the same Ethernet address. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ------------------------------------------------------------------------------ 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 Jan 2 12:03:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19494; Tue, 2 Jan 96 12:03:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19488; Tue, 2 Jan 96 12:03:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01686; Tue, 2 Jan 1996 12:02:47 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id MAA02466; Tue, 2 Jan 1996 12:02:47 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id PAA11012; Tue, 2 Jan 1996 15:01:11 -0500 (EST) Date: Tue, 2 Jan 1996 15:01:11 -0500 (EST) From: Scott Bradner Message-Id: <199601022001.PAA11012@newdev.harvard.edu> To: bradw@netnet.net, ietf-ppp@MERIT.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 1000) Re: "IP Version 6 over PPP" draft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there a time when manual configuration is desired? when you are in a IPv4 environment without IPv6 routers it gets a bit hard to get the node up without manual config. one case ... 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 Tue Jan 2 12:16:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19541; Tue, 2 Jan 96 12:16:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19535; Tue, 2 Jan 96 12:16:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03428; Tue, 2 Jan 1996 12:16:26 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id MAA06717; Tue, 2 Jan 1996 12:16:21 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id PAA11078; Tue, 2 Jan 1996 15:12:11 -0500 (EST) Date: Tue, 2 Jan 1996 15:12:11 -0500 (EST) From: Scott Bradner Message-Id: <199601022012.PAA11078@newdev.harvard.edu> To: Harald.T.Alvestrand@uninett.no, sthaug@nethelp.no Subject: (IPng 1001) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Cc: bound@zk3.dec.com, dhaskin@baynetworks.com, iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you run DECnet IV it's a requirement that all Ethernet interfaces have the same Ethernet address. including on a router - a 10 port router with decnet enabled on all ports will have 10 ports with the same Ethernet address (one calculated from the DECnet area & node numbers) 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 Tue Jan 2 12:35:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19585; Tue, 2 Jan 96 12:35:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19579; Tue, 2 Jan 96 12:35:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05613; Tue, 2 Jan 1996 12:35:22 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id MAA11580; Tue, 2 Jan 1996 12:35:20 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HZJDYMPQB4005ZTR@FNAL.FNAL.GOV>; Tue, 02 Jan 1996 14:34:59 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA04846; Tue, 2 Jan 96 14:33:11 CST Date: Tue, 02 Jan 1996 14:33:11 -0600 From: Matt Crawford Subject: (IPng 1002) Re: "IP Version 6 over PPP" draft In-Reply-To: Your message of Fri, 22 Dec 95 18:52:17 EST. <01BAD09E.BE07C3A0@ppp-pm01-dy-2.opr.oakland.edu> To: Brad Wilson Cc: "ietf-ppp@MERIT.EDU" , "ipng@sunroof.Eng.Sun.COM" Message-Id: <9601022033.AA04846@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{ Does other media differentiate between IP and IPv6 packets with different > packet types? The last I knew (admittedly, I haven't been watching the > non-PPP stuff too closely) the packet type for both was the same. Sadly, yes. It was believed that many network stack implementations would not allow packet demultiplexing on the 4 bit IP Version field, so a different ethertype (86DD hex instead of 0800 hex) is used on ethernet-like media. > Shouldn't this be MUST? Do any other media allow manually configured > addresses in IPv6? Allow -- yes. _________________________________________________________ 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 Tue Jan 2 12:58:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19620; Tue, 2 Jan 96 12:58:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19614; Tue, 2 Jan 96 12:57:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07777; Tue, 2 Jan 1996 12:57:34 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id MAA16711; Tue, 2 Jan 1996 12:57:34 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA06387; Tue, 2 Jan 1996 15:48:26 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA06154; Tue, 2 Jan 1996 15:48:22 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id UAA07738; Tue, 2 Jan 1996 20:49:34 GMT Message-Id: <199601022049.UAA07738@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Steinar Haug Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 1003) Re: Last Call: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard In-Reply-To: Your message of "Tue, 02 Jan 1996 21:01:44 +0100." X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 02 Jan 1996 20:49:32 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you run DECnet IV it's a requirement that all Ethernet interfaces have > the same Ethernet address. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no Incorrect. If you run DECnet Phase IV, then it's true that all interfaces that DECnet is running over will have the same address; this does not equate to all interfaces. However this has absolutey zero bearing on this discussion since you will be using the hardware address (either from the board or the system) and not the DECnet AA-00-04-00-xx-yy address for your link local token. This is explicitly mentioned in the IPv6 over FDDI and IPv6 over Ethernet drafts: A different MAC address set manually or by software should not be used as the address token. 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 Tue Jan 2 13:33:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19679; Tue, 2 Jan 96 13:33:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17226; Thu, 28 Dec 95 09:50:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20587; Thu, 28 Dec 1995 09:50:42 -0800 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id JAA27034; Thu, 28 Dec 1995 09:50:43 -0800 Received: from rja-ss20.cisco.com.noname (rja-ss20.cisco.com [171.69.58.102]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id JAA26360; Thu, 28 Dec 1995 09:50:42 -0800 Received: by rja-ss20.cisco.com.noname (4.1/SMI-4.1) id AA09575; Thu, 28 Dec 95 09:51:22 PST Date: Thu, 28 Dec 95 09:51:22 PST From: rja@rja-ss20.cisco.com (Randall Atkinson) Message-Id: <9512281751.AA09575@rja-ss20.cisco.com.noname> To: mccann@zk3.dec.com Subject: (IPng 1004) Re: Comments on draft-ietf-ipngwg-pmtuv6-00.txt In-Reply-To: <9512271905.AA27289@tlaser.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to see a consistent set of terminology among the various IPng drafts. It would be unfortunate to use a different term in the PMTU spec from the term in the ND specs from the term in the base spec if the item is really the same in all cases. If there are meaningful differences, then perhaps different terms should be used and the differences in semantics among the terms should be highlighted in the drafts for clarity. In general, I like the increased precision of some of the IPng specs (e.g. making "node", "host", and "router" clearly defined :-). 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 Wed Jan 3 12:33:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21508; Wed, 3 Jan 96 12:33:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21502; Wed, 3 Jan 96 12:33:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27141; Wed, 3 Jan 1996 12:33:28 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id MAA29405; Wed, 3 Jan 1996 12:33:26 -0800 From: bound@zk3.dec.com Received: from gwwasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA02740; Wed, 3 Jan 1996 15:25:41 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06021; Wed, 3 Jan 1996 15:25:35 -0500 Message-Id: <9601032025.AA06021@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: karels@bsdi.com Subject: (IPng 1005) IPv6 BSD API Spec What to Do ?? Date: Wed, 03 Jan 96 15:25:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We had tried to determine if we could get a set of Industry implementors to parse out the issue in the attached mail. But it appears that we should send this to the IPng List for some discussion. The issue and problems are stated in the attached mail message. Can we discuss here or do we need to create and API mail list elsewhere? If so lets discuss. thanks /jim ------- Forwarded Message Return-Path: bound Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13759; Wed, 20 Dec 1995 16:58:23 -0500 Message-Id: <9512202158.AA13759@wasted.zk3.dec.com> To: Bob.Gilligan@eng.sun.com, set@thumper.bellcore.com, jgm+@cmu.edu, sklower@vangogh.cs.berkeley.edu, thomas@netrix.lkg.dec.com, rstevens@noao.edu, mccann@zk3.dec.com, paul@vix.com, nordmark@jurassic-248.eng.sun.com, solensky@ftp.com, robs@join.com, Francis.Dupont@inria.fr, grehan@ipsilon.com, henrysa@microsoft.com, danmcd@cs.nrl.navy.mil, peter@sics.se, billmd@hpinpcb.cup.hp.com, marc@mentat.com, tim@mentat.com Cc: bound@zk3.dec.com, deering@parc.xerox.com, hinden@ipsilon.com, pvm@home.net, brian@dxcoms.cern.ch, sob@hsdndev.harvard.edu, mankin@isi.edu Subject: IPv6 API What to Do Date: Wed, 20 Dec 95 16:58:23 -0500 From: bound X-Mts: smtp We have some issues in the community with the IPv6 API. Its gotten to the point where Keith Sklower and Matt Thomas are going to issue another API spec possibly having more BSD 4.4 focus and Paul Vixie is adamant that the names for our DNS APIs are completely bogus. Paul will not use them in the IPv6 public domain version of DNS AAAA or other parts like Dyn Update, IXFR, or Notify and that is significant. Also Keith Sklower wants getconninfo() as part of the API (note it is pretty much blessed by IEEE POSIX .12 now). Bob Gilligan and I talked and the last thing we need in IPv6 is a splinter of APIs for IPv6 as this could affect the rate at which IPv6 can get implemented. Rather than take this to the ipng list right away maybe we can find some compromise off-line amongst ourselves. Most are on or are going to be on vacation at least until January 10th. So I don't think we can complete discussion for some time but I wanted to get this mail out while its fresh in my head. The list for this discussion is as follows (do we need others?): Co-Authors of Present Spec: Bob Gilligan Sue Thomson Jim Bound Interested API Thinkers/Implementors: Richard Stevens John Meyers Matt Thomas Keith Sklower Jack Mccann Erik Nordmark Paul Vixie Frank Solensky Rob Stevens Francis Dupont Peter Grehan Henry Sanders Dan McDonald Bill Medlin Peter Sjodin Marc Hasson Tim Hartrick Folks I think need to be cc'd too in the IETF who have not had objections but need to be aware of these issues: Steve Deering Bob Hinden Paul Mockapetris Brian Carpenter Scott Bradner Allison Mankin Issues I have heard about (other names may be associated with topics but I am doing my best so don't beat me up): 1. The names of the DNS APIs. Paul V. will you give us your view and why you don't like what we have specified and what you propose. 2. Alignment issues and structure of the sock_addr as defined for source routes, multihome interfaces, and flow-ids. ALL. This gets into sock_addr array vs BSD 4.4 msg_control use too. 3. getconninfo(). Can we come up with a compromise? Keith S. and Matt T. 4. Adding new socket semantics to socket function where needed and using BSD 4.4 semantics when needed Richard S., Matt T. John M., and Keith S. Such as having accept2() for new applications. 5. Magic Cookies! Have we said enough? Jack M. 6. Getting all options at once via vector returning all options that were on at the network layer. Matt T. 7. Forcing a MUST to make DNS APIs thread safe having the resolver return a pointer location. Jack M. 8. Other parameters we may want returned from DNS APIs. John M., Richard S., Paul V., and Frank S. 9. BSD 4.3 vs BSD 4.4 ALL 10. Use of sin6_port or can we just have the structure elements be sin_port as the structure qualifier differentiates v6 or v4. WOuld it making porting applications for ISVs easier? Jack M. 11. Are all OK on multicast the way we have it specified? ALL 12. Should security be a separate API spec? Dan M. 13. Do we need to add more features to enhance portability? ALL 14. Other issues for our discussion!!!!!!!!!!! Lets make the list or anything else that needs discussion. Without an API I don't believe we can get IPv6 deployed. Mutliple APIs by such strong folks like the Bob, Sue, and I and then one from strong folks with respect like Matt, Paul, and Keith will confuse vendors, ISVs, and the research community. This is not good lets figure it out. thanks /jim ------- End of Forwarded 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 Wed Jan 3 12:57:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21541; Wed, 3 Jan 96 12:57:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21535; Wed, 3 Jan 96 12:57:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29803; Wed, 3 Jan 1996 12:56:51 -0800 Received: from aland.bbn.com by mercury.Sun.COM (Sun.COM) id MAA05237; Wed, 3 Jan 1996 12:56:51 -0800 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id MAA27911; Wed, 3 Jan 1996 12:53:20 -0800 (PST) Message-Id: <199601032053.MAA27911@aland.bbn.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, karels@bsdi.com Subject: (IPng 1006) Re: IPv6 BSD API Spec What to Do ?? In-Reply-To: Your message of Wed, 03 Jan 96 15:25:35 -0500. <9601032025.AA06021@fwasted.zk3.dec.com> Date: Wed, 03 Jan 96 12:53:20 -0800 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim: I'd certainly like to kibbitz on the topic. At the same time, I'd like to see us avoid a POSIX type situation (where it has been what, 5 years, to standardize sockets...!?). If keeping me (and some others) out of the room would help, do it. Craig ------------------------------------------------------------------------------ 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 Jan 3 17:52:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21889; Wed, 3 Jan 96 17:52:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21786; Wed, 3 Jan 96 16:50:07 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02180; Wed, 3 Jan 1996 16:49:53 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id QAA01516; Wed, 3 Jan 1996 16:49:54 -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 QAA13722 for ; Wed, 3 Jan 1996 16:50:05 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 1996 16:51:11 -0800 To: ipng@sunroof.eng.sun.com From: "Joyce K. Reynolds" (by way of hinden@ipsilon.com (Bob Hinden)) Subject: (IPng 1007) RFC1883 on IPv6 Specification Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 1883: Title: Internet Protocol, Version 6 (IPv6) Specification Author: S. Deering & R. Hinden Date: December 1995 Mailbox: deering@parc.xerox.com, hinden@ipsilon.com Pages: 37 Characters: 82,089 Updates/Obsoletes: none URL: ftp://ds.internic.net/rfc/rfc1883.txt This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. This document is the product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <960103144212.RFC@ISI.EDU> [This attachment must be fetched by mail. Open the stationery below and send the resulting message to get the attachment.] Attachment converted: Macintosh HD:Get RFC1883 on IPv6 Specificati (EuSn/CSOm) (00007347) Content-Type: Message/External-body; name="rfc1883.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" [This attachment must be fetched by ftp. Open the document below to ask your ftp client to fetch it.] Attachment converted: Macintosh HD:Get rfc1883.txt (AURL/Arch) (00007348) Content-Type: text/plain Content-ID: <960103144212.RFC@ISI.EDU> ------------------------------------------------------------------------------ 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 Jan 3 17:54:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21901; Wed, 3 Jan 96 17:54:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21819; Wed, 3 Jan 96 17:14:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05194; Wed, 3 Jan 1996 17:14:05 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id RAA06182; Wed, 3 Jan 1996 17:14:06 -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 RAA14229 for ; Wed, 3 Jan 1996 17:14:17 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 1996 17:15:23 -0800 To: ipng@sunroof.eng.sun.com From: "Joyce K. Reynolds" (by way of hinden@ipsilon.com (Bob Hinden)) Subject: (IPng 1008) RFC1885 on ICMPv6 (ICMP for IPv6) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 1885: Title: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Author: A. Conta, S. Deering Date: December 1995 Mailbox: conta@zk3.dec.com, deering@parc.xerox.com Pages: 20 Characters: 32,214 Updates/Obsoletes: none URL: ftp://ds.internic.net/rfc/rfc1885.txt This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document. This document is the product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <960103145014.RFC@ISI.EDU> [This attachment must be fetched by mail. Open the stationery below and send the resulting message to get the attachment.] Attachment converted: Macintosh HD:Get RFC1885 on ICMPv6 (ICMP for (EuSn/CSOm) (00007358) Content-Type: Message/External-body; name="rfc1885.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" [This attachment must be fetched by ftp. Open the document below to ask your ftp client to fetch it.] Attachment converted: Macintosh HD:Get rfc1885.txt (AURL/Arch) (00007359) Content-Type: text/plain Content-ID: <960103145014.RFC@ISI.EDU> ------------------------------------------------------------------------------ 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 Jan 3 17:55:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21913; Wed, 3 Jan 96 17:55:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21791; Wed, 3 Jan 96 16:50:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02186; Wed, 3 Jan 1996 16:49:57 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id QAA01525; Wed, 3 Jan 1996 16:49:58 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA13727 for ; Wed, 3 Jan 1996 16:50:09 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 1996 16:51:15 -0800 To: ipng@sunroof.eng.sun.com From: "Joyce K. Reynolds" (by way of hinden@ipsilon.com (Bob Hinden)) Subject: (IPng 1009) RFC1884 on IPv6 Addressing Architecture Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 1884: Title: IP Version 6 Addressing Architecture Author: R. Hinden & S. Deering, Editors Date: December 1995 Mailbox: hinden@ipsilon.com, deering@parc.xerox.com Pages: 18 Characters: 37,860 Updates/Obsoletes: none URL: ftp://ds.internic.net/rfc/rfc1884.txt This specification defines the addressing architecture of the IP Version 6 protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 nodes required addresses. This document is the product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <960103144800.RFC@ISI.EDU> [This attachment must be fetched by mail. Open the stationery below and send the resulting message to get the attachment.] Attachment converted: Macintosh HD:Get RFC1884 on IPv6 Addressing (EuSn/CSOm) (0000734C) Content-Type: Message/External-body; name="rfc1884.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" [This attachment must be fetched by ftp. Open the document below to ask your ftp client to fetch it.] Attachment converted: Macintosh HD:Get rfc1884.txt (AURL/Arch) (0000734D) Content-Type: text/plain Content-ID: <960103144800.RFC@ISI.EDU> ------------------------------------------------------------------------------ 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 Jan 3 17:59:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21942; Wed, 3 Jan 96 17:59:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21936; Wed, 3 Jan 96 17:59:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11104; Wed, 3 Jan 1996 17:59:02 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id RAA15259; Wed, 3 Jan 1996 17:59:03 -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 RAA14981 for ; Wed, 3 Jan 1996 17:59:15 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 1996 18:00:21 -0800 To: ipng@sunroof.eng.sun.com From: "Joyce K. Reynolds" (by way of hinden@ipsilon.com (Bob Hinden)) Subject: (IPng 1010) RFC1886 on IPv6 DNS Extensions Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 1886: Title: DNS Extensions to support IP version 6 Author: S. Thomson & C. Huitema Date: December 1995 Mailbox: set@thumper.bellcore.com, Christian.Huitema@MIRSA.INRIA.FR Pages: 5 Characters: 6,424 Updates/Obsoletes: none URL: ftp://ds.internic.net/rfc/rfc1886.txt This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This document is the product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <960103145412.RFC@ISI.EDU> [This attachment must be fetched by mail. Open the stationery below and send the resulting message to get the attachment.] Attachment converted: Macintosh HD:Get RFC1886 on IPv6 DNS Extensi (EuSn/CSOm) (0000735B) Content-Type: Message/External-body; name="rfc1886.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" [This attachment must be fetched by ftp. Open the document below to ask your ftp client to fetch it.] Attachment converted: Macintosh HD:Get rfc1886.txt (AURL/Arch) (0000735C) Content-Type: text/plain Content-ID: <960103145412.RFC@ISI.EDU> ------------------------------------------------------------------------------ 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 Jan 3 18:29:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22016; Wed, 3 Jan 96 18:29:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22010; Wed, 3 Jan 96 18:28:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13544; Wed, 3 Jan 1996 18:28:37 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id SAA20554; Wed, 3 Jan 1996 18:28:39 -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 SAA15718 for ; Wed, 3 Jan 1996 18:28:50 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 1996 18:29:56 -0800 To: ipng@sunroof.eng.sun.com From: "Joyce K. Reynolds" (by way of hinden@ipsilon.com (Bob Hinden)) Subject: (IPng 1011) RFC1887 on IPv6 Unicast Address Allocation Architecture Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 1887: Title: An Architecture for IPv6 Unicast Address Allocation Author: Y. Rekhter & T. Li, Editors Date: December 1995 Mailbox: yakov@cisco.com, tli@cisco.com Pages: 26 Characters: 66,066 Updates/Obsoletes: none URL: ftp://ds.internic.net/rfc/rfc1887.txt This document provides an architecture for allocating IPv6 unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in RFC 1884. This document does not go into the details of an addressing plan. This document is the product of the IPNG Working Group of the IETF. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <960103145732.RFC@ISI.EDU> [This attachment must be fetched by mail. Open the stationery below and send the resulting message to get the attachment.] Attachment converted: Macintosh HD:Get RFC1887 on IPv6 Unicast Add (EuSn/CSOm) (0000735E) Content-Type: Message/External-body; name="rfc1887.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" [This attachment must be fetched by ftp. Open the document below to ask your ftp client to fetch it.] Attachment converted: Macintosh HD:Get rfc1887.txt (AURL/Arch) (0000735F) Content-Type: text/plain Content-ID: <960103145732.RFC@ISI.EDU> ------------------------------------------------------------------------------ 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 Jan 3 19:48:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22074; Wed, 3 Jan 96 19:48:52 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22068; Wed, 3 Jan 96 19:48:36 PST Received: from kandinsky.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA11688; Wed, 3 Jan 1996 19:47:56 -0800 Received: by kandinsky.eng.sun.com (5.x/SMI-SVR4) id AA29295; Wed, 3 Jan 1996 19:53:24 -0800 Date: Wed, 3 Jan 1996 19:53:24 -0800 From: gilligan@caribe.eng.sun.com (Bob Gilligan) Message-Id: <9601040353.AA29295@kandinsky.eng.sun.com> To: ipng@sunroof Subject: (IPng 1012) Re: (IPng968) - need for uniq ID's/PPP and identifying interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To follow up on a thread from before the holidays... > > Date: Sun, 24 Dec 1995 13:01:57 PST > From: "Steve Deering" > > > ...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. I the context of an application's interface to the system, I think a 16-byte IPv6 address is easier to deal with than an interface name string or index number. This is because the place where an interface identifier would be carried -- in the address argument to recvfrom() or sendto() call -- already must carry one 16-bute IPv6 address. Extending that to carry two is straightforward and simple. In the context of a user's interface with the application, I think that a hostname is simpler for the user to deal with than an than either an interface name string, or interface index number. And we have a library function that will transform a hostname into an IPv6 address that can be used in the application/system interface! 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 Jan 4 09:39:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22383; Thu, 4 Jan 96 09:39:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22377; Thu, 4 Jan 96 09:39:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01805; Thu, 4 Jan 1996 09:39:07 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id JAA08280; Thu, 4 Jan 1996 09:39:08 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA00358; Thu, 4 Jan 96 12:38:13 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA27139; Thu, 4 Jan 96 12:39:03 EST Date: Thu, 4 Jan 96 12:39:03 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601041739.AA27139@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1013) Max size of interface token Cc: dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, None of the IPv6 specs clearly specify the maximum size of the interface token used for forming Ipv6 addresses. It seems that it is left up to the individual IPv6-over-Foo specs. Furthermore, the autoconfiguration draft implies that it is ok to have an interface token of 118 bits in length: "If the interface token is more than 118 bits in length, autoconfiguration fails and manual configuration is required". The problem is that the maximum size of the interface token determines the length of what is left for different address allocation schemes. E.g., the suggested Provider-Based address can have up to 64-bits of the register/provider specific portion of the address. This leaves 64 bits for the subscriber-specific component. If the size of an interface token is 48-bits, the remaining 16 bits can be used for the subscriber subneting to provide hierarchical routing within a subscriber. But if the size of an interface token is 64 bits as suggested by the IPv6-over-ATM and IPv6-over-PPP drafts no address hierarchy within a subscriber is possible if autoconfiguration is used to form addresses. This is cleary very undesirable. The botom line is that we need to specify a reasonable maximum size of the interface token so different address assignment proposals are aware of the size of the portion of the address reserved for the token. For simplicity, I would go as far as specifying an exact fixed size of the interface token (e.g. 48 bits); medias that need fewer bits for their token can always pad it out with zero bits. If we decide that 48 bits is not enough, the Provider-Based address format needs to be revisited to allow for some subscriber hierarcy. Regards, 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 Jan 4 10:23:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22442; Thu, 4 Jan 96 10:23:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22436; Thu, 4 Jan 96 10:23:46 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08706; Thu, 4 Jan 1996 10:23:29 -0800 Received: from southstation.mvp.com by Sun.COM (sun-barr.Sun.COM) id AA10111; Thu, 4 Jan 96 10:23:30 PST Received: (from george@localhost) by southstation.mvp.com (8.6.11/8.6.6) id KAA04011; Thu, 4 Jan 1996 10:03:51 -0800 Date: Thu, 4 Jan 1996 10:03:51 -0800 From: George Mitchell Message-Id: <199601041803.KAA04011@southstation.mvp.com> To: dhaskin@BayNetworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 1014) Re: Max size of interface token Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > None of the IPv6 specs clearly specify the maximum size of the interface > token used for forming Ipv6 addresses. In fact, RFC1884 contains a surprising number of unspecified values "m", "n", and "s" for a document which purports to be a Proposed Standard. When do the blanks get filled in? As a complete outsider to this process, I apologize if this message seems to be an unwarranted intrusion. -- George Mitchell (george@mvp.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 Jan 4 12:47:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22557; Thu, 4 Jan 96 12:47:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22551; Thu, 4 Jan 96 12:46:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01460; Thu, 4 Jan 1996 12:46:40 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id MAA07650; Thu, 4 Jan 1996 12:46:41 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20440; 4 Jan 96 15:43 EST To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: IESG Secretary Subject: (IPng 1015) Document Action: IPv6 Testing Address Allocation to Experimental Date: Thu, 04 Jan 96 15:43:07 -0500 Message-Id: <9601041543.aa20440@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has reviewed the Internet-Draft "IPv6 Testing Address Allocation" and recommends that it be published by the RFC Editor as an Experimental RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ 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 Jan 5 11:42:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23245; Fri, 5 Jan 96 11:42:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23239; Fri, 5 Jan 96 11:42:10 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13679; Fri, 5 Jan 1996 11:41:53 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id LAA21386; Fri, 5 Jan 1996 11:41:53 -0800 Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA26467; Fri, 5 Jan 1996 14:41:52 -0500 Received: from [134.82.18.89] (droms.bucknell.edu) by charcoal (5.x/SMI-SVR4) id AA04870; Fri, 5 Jan 1996 14:41:46 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Jan 1996 14:41:52 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 1016) Re: DISCUSSION: Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:34 AM 1/3/96, Christian Huitema wrote: >I don't know whether this is better achieved by carrying multiple addresses >within one DHCP message, or by using some "more addresses" bit mechanism to >chain multiple DHCP packet. I would rather leave this to the DHCP working >group... Agreed - the DHC WG can work out how to cary multiple address in one "transaction" (whether that transaction consists of one or more than one message). I'm still not clear on whether we can expect a client to initiate multiple DHCP transactions; i.e., will a DHCP client ask for one address or addresses at boot time, and then come back and ask for additional addresses in a separate transaction at a later time? - 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 Fri Jan 5 17:26:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23503; Fri, 5 Jan 96 17:26:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23497; Fri, 5 Jan 96 17:26:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27492; Fri, 5 Jan 1996 17:26:16 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id RAA11633; Fri, 5 Jan 1996 17:26:15 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA28956; Fri, 5 Jan 96 17:25:37 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA01445; Fri, 5 Jan 1996 17:26:04 -0800 Date: Fri, 5 Jan 1996 17:26:04 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601060126.AA01445@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1017) NUD and the OVERRIDE bit. X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I need a ruling. The following sentence appears in the current ND document in section 7.2.4 "Sending Solicited Neighbor Advertisements". "If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service , the Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to one." It seems to me that if a neighbor solicitation prompting the advertise- ment has a unicast destination address, the responding host should not set the Override bit unless the link address being used by the remote node needs to be changed for some reason. If the solicitation has a multicast destination then obviously the Override bit in the responding advertisement should be zero. This could make NUD quite a bit more efficient since the link address in- formation in the cache would only be updated as needed instead of every thirty seconds or so. I understand that the sentence above only says "SHOULD", however this is a case where a remote node can impose a performance penalty on my node by not implementating a fairly straight forward optimization. It would be nice if this optimization were actualy in the text. Does this optimization break some of the fundamental assumptions of the ND/NUD protocol? tim@mentat.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 Jan 5 22:04:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23608; Fri, 5 Jan 96 22:04:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23602; Fri, 5 Jan 96 22:04:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11131; Fri, 5 Jan 1996 22:03:48 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id WAA05385; Fri, 5 Jan 1996 22:03:49 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03769 Sat, 6 Jan 1996 17:03:38 +1100 (from kre@munnari.OZ.AU) To: droms@bucknell.edu (Ralph Droms) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1018) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Fri, 05 Jan 1996 14:41:52 CDT." Date: Sat, 06 Jan 1996 17:03:53 +1100 Message-Id: <1612.820908233@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 5 Jan 1996 14:41:52 -0500 From: droms@bucknell.edu (Ralph Droms) Message-ID: I'm still not clear on whether we can expect a client to initiate multiple DHCP transactions; i.e., will a DHCP client ask for one address or addresses at boot time, and then come back and ask for additional addresses in a separate transaction at a later time? This could obviously be done either way. However, to do it the "multiple transactions" method will need quite a bit more protocol baggage I'd think. I can see at least two possible methods - one would be for the server to tell the client how many addresses it should be requesting (probably in every response), and for the client to indicate in the request how many addresses it has currently received, so the server can return the next - this still retains the basically stateless nature of the protocol at the server end (though the server needs to usually retain the ordering of addresses - though even that could proabbly be finessed by the client). The other way would be for the client to indicate how many addresses it has received in the request, and for the server to either return the next address, or indicate "no more" in the response. This would make the client slightly simpler, at the expense of having the server perhaps a little more complex. As far as the basic protocol goes, having the server simply say "here are all your addresses" (for the interface) is clearly much simpler, regardless of how much extra parsing code is needed in the client to pick apart the variable length address field. Where this one gets complex is in making sure that the protocol can correctly handle being able to return all the addresses when there are so many that they won't all fit in one packet. Based just upon current practice, that is clearly going to happen. Its stupid things have turned out this way, but there are WWW servers with hundreds of addresses, even without extra overheads, a hundred 16 byte addresses is more than will fit in the minimum required reassembled packet, and much more than might fit without fragmentation over some media (do we want DHCP servers to have to do PMTU discovery to their clients?) 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 Sat Jan 6 03:37:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23726; Sat, 6 Jan 96 03:37:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23720; Sat, 6 Jan 96 03:36:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18256; Sat, 6 Jan 1996 03:36:28 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id DAA17533; Sat, 6 Jan 1996 03:36:27 -0800 Received: from charcoal-gw.eg.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA27685; Sat, 6 Jan 1996 06:36:26 -0500 Received: from [134.82.7.156] (uvite53.bucknell.edu) by charcoal (5.x/SMI-SVR4) id AA08602; Sat, 6 Jan 1996 06:36:20 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 6 Jan 1996 06:36:25 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 1019) Re: DISCUSSION: Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:03 PM 1/6/96, Robert Elz wrote: > Date: Fri, 5 Jan 1996 14:41:52 -0500 > From: droms@bucknell.edu (Ralph Droms) > > I'm still not clear on whether we can expect a client to initiate multiple > DHCP transactions; i.e., will a DHCP client ask for one address or > addresses at boot time, and then come back and ask for additional addresses > in a separate transaction at a later time? > >This could obviously be done either way. There's a subtlety to the question that I'm just not doing a very good job of explaining... Will there be cases in which neither the client nor the server know at boot time how many addresses the client will want? Here's a scenario - client boots and server hands out n addresses (assume, e.g., that the netadmin has configured the server to deliver n (n >= 1) addresses to that class of client. Now, some time later, application X starts up and decides it needs its own address on an interface. Neither the client nor the server knew, a priori, that the application would ask for another address, so the client will have to go back to the server to ask for another address. The difference here is in the prior knowledge. If either the client or the server know how many addresses the client should receive at boot time, we can wrap the whole thing up in one DHCP 'transaction' (consisting of one or many DHCP message exchanges). What I'd like to get an opinion on is: a) Is the scenario I described in the previous paragraph one that we should be thinking about, b) Do we need to accommodate this scenario through DHCP or is it time to consider some more elaborate structure for address management of which DHCP is simply one delivery mechanism? BTW, in my opinion, accommodating the scenario in which the client may go back for additional addresses adds a fair amount of baggage to the protocol and a lot of overhead to the server (all of this can be discussed on the DHCPv6 mailing list). It will require also some careful thinking about the semantics of multiple allocations (which we might want to discuss here, to make sure DHCPv6 meets the needs of the IPv6 community as a whole). - 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 Sat Jan 6 05:02:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23780; Sat, 6 Jan 96 05:02:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23774; Sat, 6 Jan 96 05:02:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19299; Sat, 6 Jan 1996 05:02:23 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id FAA20070; Sat, 6 Jan 1996 05:02:22 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26104 Sun, 7 Jan 1996 00:02:16 +1100 (from kre@munnari.OZ.AU) To: droms@bucknell.edu (Ralph Droms) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1020) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Sat, 06 Jan 1996 06:36:25 CDT." Date: Sun, 07 Jan 1996 00:02:30 +1100 Message-Id: <1911.820933350@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 6 Jan 1996 06:36:25 -0500 From: droms@bucknell.edu (Ralph Droms) Message-ID: Will there be cases in which neither the client nor the server know at boot time how many addresses the client will want? Ah yes, of course. Sometime in the past I had noted that too, but of course, forgot before I opened my mouth/keyboard... a) Is the scenario I described in the previous paragraph one that we should be thinking about, Yes. b) Do we need to accommodate this scenario through DHCP I think so. I would expect this can be done by having the client send a "this is an additional request" type counter/flag to the server, each time after the first, so the server knows this is a request for additional addressing, and not a repeat of the earlier request (or any other previous request for more addresses). When the new request is made, the client clearly knows this is new. Its actually probably a little more interesting to consider just how this can be handled with stateless address autoconf. If the client has only one "token" it can configure only one (set of) addresses by itself, if DHCP address allocation isn't being used, the only current way to handle this may be manual config of the client, which is not something that should be encouraged, let alone mandated. I'd prefer having the client in charge of its addresses in the DNS, rather than having the DNS tell the clients what addresses to use as well, so doing DNS lookups is also probably not the solution. 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 Sat Jan 6 09:40:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23821; Sat, 6 Jan 96 09:40:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23815; Sat, 6 Jan 96 09:40:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24370; Sat, 6 Jan 1996 09:39:44 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id JAA00980; Sat, 6 Jan 1996 09:39:45 -0800 Subject: (IPng 1021) A few announcements To: IPng Mailing list , ipv6imp@munnari.oz.au Date: Sat, 6 Jan 1996 12:39:58 -0500 (EST) From: Dan McDonald Cc: danmcd@cs.nrl.navy.mil, phan@cs.nrl.navy.mil, cmetz@cs.nrl.navy.mil, kchin@cs.nrl.navy.mil, hale@itd.nrl.navy.mil X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9601061240.aa24768@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks in IPng-land. This note is an announcement of a few things. 1. NRL TEST NETWORK IS UP After a few last minute feature hacks and subsequent bug fixes, the NRL IPv6 team of Dan McDonald, Bao Phan, Craig Metz, and Ken Chin is pleased to announce the NRL IPv6 test network. The topology is as follows: -----+---------------+------------------+---------------+---- 90-net | | | | beech.cs noname.cs nameless.cs | mallorn.cs (ROUTER) mallorn.itd | | -------------------------+------------------------------+---- 92-net | sweetgum.itd We have two subnets, the "90" and the "92". They are numbered as follows w.r.t. IPv6 90 92 == == v4-compat ::132.250.90.0/120 ::132.250.92.0/120 global-test 5f00:3000:84fa:5a00::0/80 5f00:3000:84fa:5a00:1::0/80 The machine "mallorn" is a crude IPv6 router. To optimally set your routers I'd suggest adding routes of 5f00:3000:84fa:5a00::0/79 (Notice how I aggregated them!), ::132.250.90.0/120 and ::132.250.92.0/120 to tunnel v4 to mallorn.{cs,itd}.nrl.navy.mil. Mallorn's routing tables include the appropriate on-link routes, and a default route set to internet95.ipsilon.com, which means even v4-compatibles travel from any of my hosts as native IPv6 until they hit mallorn. Peter, if you don't want mallorn's default route pointing to you, tell me, and I'll change it. Yes, I can send net-unreachables, but I figured it'd be more fun this way. The IPv6 addresses are as follows (append ".nrl.navy.mil" to their names): host v4-compat global-test ---- --------- ----------- beech.cs ::132.250.90.16 5f00:3000:84fa:5a00::20:afd8:3d42 noname.cs ::132.250.90.19 5f00:3000:84fa:5a00::800:2008:471b nameless.cs ::132.250.90.20 5f00:3000:84fa:5a00::800:200f:fde7 mallorn.cs ::132.250.90.70 5f00:3000:84fa:5a00::20:af0c:5f58 mallorn.itd ::132.250.92.6 5f00:3000:84fa:5a00:1:20:afda:3189 sweetgum.itd ::132.250.92.65 5f00:3000:84fa:5a00:1:800:2008:1d68 Oh, BTW, yes those are addresses generated by addrconf and stateless configuration. I figure the interface addresses won't be changing soon, and since I don't have prefix timeouts working yet, I can safely advertise them. All nodes will respond to IPv6 pings. Sweetgum also has been opened up a bit so people can telnet, finger, chargen, and echo over TCP and UDP where appropriate (i.e. no UDP telnets :-). Sweegum's guest account is: login: guest Password: NRL-GUEST and when logging in it will generate three forms of netstat (-i, -r, and -a) with some pauses for reading them. If anyone has v6-security working, contact me, and we can set up an inetd with security turned on somewhere. The bad news is that this network will be up over the weekend and through next week for sure. After that I can make no guarantees. That brings us to the second announcement. 2. DAN IS LEAVING NRL Because of many reasons, next week at NRL will be my last week. After that, the IPv6 work here will _probably_ fold, I cannot say for sure. I will be resurfacing at the end of this month or early February at my new place of employment. That brings me to the third announcement. 3. NRL SOURCE CODE AVAILABILITY Another release of the NRL code will be coming. Most of the changes from the one that is circulating now are v6-related, along with possibly some PF_KEY refinements. Getting will be just like getting the current version. Pardon my indirect approach, but that's just how things are. :-P I will most likely be involved with the community in some aspect at my new job. Hopefully I will continue with IPng. This has been a great learning experience, something not every kid fresh out of school (which I was when this was still SIPP) gets a chance to do. I hope to continue to do my small part to push this beast along, and get it out there. Thanks! Daniel L. McDonald ------------------------------------------------------------------------------ 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 Jan 7 21:13:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24085; Sun, 7 Jan 96 21:13:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24079; Sun, 7 Jan 96 21:13:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17203; Sun, 7 Jan 1996 21:12:51 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id VAA23026; Sun, 7 Jan 1996 21:12:52 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA22216; Sun, 7 Jan 1996 23:57:18 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07306; Sun, 7 Jan 1996 23:56:44 -0500 Message-Id: <9601080456.AA07306@fwasted.zk3.dec.com> To: Robert Elz Cc: droms@bucknell.edu (Ralph Droms), ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1022) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Sun, 07 Jan 96 00:02:30 +1100." <1911.820933350@munnari.OZ.AU> Date: Sun, 07 Jan 96 23:56:44 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we have the requirement at this time. I think we don't want to over engineer this requirement or this discussion. I think from the discussion we need to support a DHCPv6 request for additional addresses from a client for an interface. This was in the very first spec I built and was reviewed at Danvers MA for discussion. It was very complex to design at the server and at the client. We have a requirement now per the DHCPv6 WG mail list to provide multiple addresses from a server to a client. Now we need to discuss what are the requirements when supporting additional addresses for the client for an interface. If there are no objections I would like to now move this discussion back to DHCPv6 list? Thank You IPng. I take consensus to be that Steve Bellovins RFC 1681 holds as a model. Most don't like the pragmatic truth it states, but this may be like Ethernet does not work in Theory but works in Reality. Charlie Perkins and I will design into DHCPv6 the requirements we hear and run it by the DHCPv6 list once we understand the requirements? I am not sure what they are right now for the complete picture? 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 Sun Jan 7 21:17:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24097; Sun, 7 Jan 96 21:17:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24091; Sun, 7 Jan 96 21:17:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17326; Sun, 7 Jan 1996 21:17:27 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id VAA23387; Sun, 7 Jan 1996 21:17:30 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA32245; Mon, 8 Jan 1996 00:10:52 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07776; Mon, 8 Jan 1996 00:10:51 -0500 Message-Id: <9601080510.AA07776@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1023) ND Asst for Security Issue for DHCPv6? Date: Mon, 08 Jan 96 00:10:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Have to come to our IPng list again. See attached and then my question after. ======================================================= %> - authentication and relay agents. Do we need a new mechanism to %> solve this? Does the problem need solving? %I think that any authentication stuff needs to be done as another %option (that is, extension :-) which we can design later. This %approach seemed to be acceptable at the last working group meeting. This is a harder problem and I have sent a proposed solution out to the list I hope to get responses too. What I don't want to do is require non-END-SYSTEMS which are not Hosts acting as relay-agents to have to implement IPSEC. THis is tricky but can be designed in the prototocol. The discussion as I recall it at the WG was that the relay-agent must change the packet of the client which breakes the IPSEC model to the remote server. Serveral soultions were discussed: 1. Have End-to-End client-relay-agent then relay-agent-remote-server. Folks initially did not like this as it causes a security association twice. It also can require IPSEC on routers for IPv6 and this is not good or was intended in IPv6. 2. The client must get the relay-agents address to put into the packet and then resend the client message to the relay-agent. This will work but is a real hack and extra packet on the network. 3. Encapsulate the client packet in IPv6 to the remote server. This will work but causes a tunnel strategy as the norm as IPSEC eventually will be widely implemented and used at least for authentication. ======================================================================== Because DHCPv6 is an implementation of Stateful Address Autoconfiguration can we have as an option to ND when the Managed bit "M" or other config "O" is on that as another option a set of fields identifying the gateway and server addresses for DHCPv6? I don't want to discuss the manual configuration case as that is a "punt" for ND and Addr conf anyway per the IPv6 October Wash D.C. interim meeting. 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 Jan 8 05:50:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24236; Mon, 8 Jan 96 05:50:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24230; Mon, 8 Jan 96 05:49:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03300; Mon, 8 Jan 1996 05:49:34 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id FAA29718; Mon, 8 Jan 1996 05:49:25 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18698; Mon, 8 Jan 1996 14:49:12 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA17312; Mon, 8 Jan 1996 14:49:11 +0100 Message-Id: <9601081349.AA17312@dxcoms.cern.ch> Subject: (IPng 1024) Re: Max size of interface token To: dhaskin@baynetworks.com (Dimitry Haskin) Date: Mon, 8 Jan 1996 14:49:11 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9601041739.AA27139@pobox.BayNetworks.com> from "Dimitry Haskin" at Jan 4, 96 12:39:03 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 Dimitry, As I recall the reason there are 64 subscriber specific bits preceded by 8 reserved bits in the draft unicast format is exactly in case 48 bit tokens prove to be insufficient. You have to realise that ATM "hardware" addresses can be 20 bytes long. Squeezing them into 48 or 64 bits is going to be an effort. Setting a recommended maximum token size at 48 bits and an absolute maximum at 64 bits would seem reasonable to me. 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 Mon Jan 8 06:27:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24253; Mon, 8 Jan 96 06:27:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24247; Mon, 8 Jan 96 06:26:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04669; Mon, 8 Jan 1996 06:26:27 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA03794; Mon, 8 Jan 1996 06:26:26 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3163; Mon, 08 Jan 96 09:25:44 EST Received: by RTP (XAGENTA 4.0) id 9229; Mon, 8 Jan 1996 09:25:45 -0500 Received: from rsalh1p15.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20362; Mon, 8 Jan 1996 09:26:09 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id JAA00250; Mon, 8 Jan 1996 09:24:09 -0500 Message-Id: <199601081424.JAA00250@hygro.raleigh.ibm.com> To: Robert Elz Cc: droms@bucknell.edu (Ralph Droms), ipng@sunroof.eng.sun.com Subject: (IPng 1025) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Sun, 07 Jan 1996 00:02:30 +1100." <1911.820933350@munnari.OZ.AU> Date: Mon, 08 Jan 1996 09:24:09 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > Will there be cases in which neither the client nor the > server know at boot time how many addresses the client will > want? >Ah yes, of course. Sometime in the past I had noted that too, >but of course, forgot before I opened my mouth/keyboard... > a) Is the scenario I described in the previous paragraph > one that we should be thinking about, >Yes. > b) Do we need to accommodate this scenario through DHCP >I think so. It would really help me to see a concrete example of why this is necessary and/or useful. Addresses identify interfaces; they do not identify endpoints (i.e., application services). If anything, the current trend is to move to DNS names rather than identifiers to deal with the pain associated with having to change addresses. Do we really want to encourage behavior that complicates renumbering? I have read RFC 1681. I don't consider that as a mandate for doing this. Quoting from 1681: > For the ideas outlined below, I do not claim that multiple addresses > per host is the only or even necessarily the best way to accomplish > the goal. I do claim that my ideas are at the very least plausible, > and that I expect that many of them will be tried. For many of the possible uses suggested there, I concur with the author that there are better alternative solutions. For many of the examples cited, I think that using multiple addresses will be rather difficult to implement when the details are considered. Thus, I would really like to see a more convincing argument that we should *encourage* such behavior and that the base DHCP architecture requires such behavior. In the specific case of DHCP, allowing clients to request "extra" addresses will significantly complicate the protocol and administration model. Again, what is the benefit to the end user (i.e., the system administrator)? 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 Jan 8 06:35:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24265; Mon, 8 Jan 96 06:35:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24259; Mon, 8 Jan 96 06:35:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05111; Mon, 8 Jan 1996 06:35:15 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA05012; Mon, 8 Jan 1996 06:35:15 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3328; Mon, 08 Jan 96 09:34:32 EST Received: by RTP (XAGENTA 4.0) id 9235; Mon, 8 Jan 1996 09:34:33 -0500 Received: from rsalh1p15.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20943; Mon, 8 Jan 1996 09:35:03 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id JAA00263; Mon, 8 Jan 1996 09:33:00 -0500 Message-Id: <199601081433.JAA00263@hygro.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1026) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Mon, 08 Jan 1996 00:10:51 EST." <9601080510.AA07776@fwasted.zk3.dec.com> Date: Mon, 08 Jan 1996 09:33:00 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >Because DHCPv6 is an implementation of Stateful Address >Autoconfiguration can we have as an option to ND when the Managed bit >"M" or other config "O" is on that as another option a set of fields >identifying the gateway and server addresses for DHCPv6? I've thought about this for a while, but I'm not sure it really buys as much as first appears. Relay agents *really* mess up the IPSec model. In addition, address scoping issues get in the way. The client will only (in general) have a link-local unicast address. If the server is on a remote link, getting the host's packet to the server introduces complexities due to scoping (i.e., routers won't forward packets with link-local scope addresses). If a packet goes through a relay agent, and the packet contains an IPSec AH, the relay agent's stack will attempt to authenticate the packet. Remember, the DHCP packet is sent to a link-local multicast address, so the relay agent will assume it is addressed to it. If the relay agent doesn't implement IPSec, we're in trouble. Even if it does, will the stack toss the packet if the relay agent can't authenticate it? Even if it does authenticate the packet, the AH itself will probably be discarded by the stack before it passed to the application layer. End result, even if the relay agent (application) gets the packet, the original AH is probably gone. So end-to-end host-server authentication is gone. Unfortunately, we MUST go through a relay agent if the server is off-link. The original host DHCP packet has a link-local (unicast) source address. Such a packet cannot be forwarded to a server (through a router); the router will toss the packet. So the relay agent has to step in to add its own addresses. There are two case: a) resend the original packet to a DHCP server with a new IP header with the relay agent's (properly-scoped) unicast address as the source. This clearly breaks the IPSec AH model. b) To preserve the original header, the relay agent could tunnel the packet to the DHCP server (assuming it even has access to the original AH). But the encapsulated packet has the original addresses in it, which have the wrong scope for the server's link. At a minimum, there is an architectural question as to whether such tunneling should even be allowed. The server couldn't directly reply to such a packet. Note that the server's stack would probably discard the outside header (from the relay) agent, and the server would think it received the packet from an on-link source. This last model seems to be the cleanest way to allow DHCP to use IPSec for authentication, but it relies on a lot of details being done a certain way (e.g., relay agent preserving original AH), an assumption that probably won't hold universally. It would require that the DHCP host know the 'giaddr' field, which could possibly be learned through RAs as you suggest. But I think the above details need to be worked out before going this route. 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 Jan 8 07:32:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24328; Mon, 8 Jan 96 07:32:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24314; Mon, 8 Jan 96 07:32:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08415; Mon, 8 Jan 1996 07:31:48 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id HAA12901; Mon, 8 Jan 1996 07:31:48 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id RAA01268; Mon, 8 Jan 1996 17:29:40 +0200 Date: Mon, 8 Jan 1996 17:29:40 +0200 From: Juha Heinanen Message-Id: <199601081529.RAA01268@lohi.dat.tele.fi> To: ipng@sunroof.eng.sun.com Cc: postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, yakov@cisco.com, brian@dxcoms.cern.ch Subject: (IPng 1027) proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i'll try once more to propose a fix to draft-ietf-ipngwg-unicast-addr-fmt-02.txt. if none of the authors reacts i guess i don't have any other change that to write another competing i-d. the current format is: | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 64 bits | +---+----------+----------+---+------------+---+----------------+ |010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber| +---+----------+----------+---+------------+---+----------------+ the first res doesn't make sense, since if a provider has got a 24 bit prefix x, it must remain a unique prefix for that provider, i.e, it is impossible that another provider would later get a 32 bit prefix xy. my proposal is that if 16 bits doesn't feel big enough for providerid, then the legth of the providerid field would be either 16 or 24 bits and which one it is is determined by the first bit of the providerid. if the provider has got a 16 bit providerid code, then the subscriberid begins right after it. the second res should also be deleted. it should be up to the provider to allocate intra-subscriber fields of various lengths to its subscriber. one very big site might need to get 72 bit intra-subscriber field whereas another site with a couple of pcs, could very well live with 56 bit intra-subscriber field. my proposal is that the length of the intra-subscriber field varies from 56 to 72 bits and it is up to the provider to select a coding of subscriberid field that determines how long the intra-subscriber field is. i hope that the authors of the draft could consider these changes and give their response. we need these addresses now and that is why i'm trying to get this issue solved as soon as possible. -- juha ------------------------------------------------------------------------------ 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 Jan 8 08:02:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24371; Mon, 8 Jan 96 08:02:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24365; Mon, 8 Jan 96 08:02:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10751; Mon, 8 Jan 1996 08:01:39 -0800 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id IAA18396; Mon, 8 Jan 1996 08:01:40 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id IAA00438; Mon, 8 Jan 1996 08:01:00 -0800 Message-Id: <199601081601.IAA00438@hubbub.cisco.com> To: Juha Heinanen Cc: ipng@sunroof.eng.sun.com, postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, yakov@cisco.com, brian@dxcoms.cern.ch Subject: (IPng 1028) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: Your message of "Mon, 08 Jan 96 17:29:40 +0200." <199601081529.RAA01268@lohi.dat.tele.fi> Date: Mon, 08 Jan 96 08:01:00 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha, > i'll try once more to propose a fix to > draft-ietf-ipngwg-unicast-addr-fmt-02.txt. if none of the authors > reacts i guess i don't have any other change that to write another > competing i-d. > > the current format is: > > | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 64 bits | > +---+----------+----------+---+------------+---+----------------+ > |010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber| > +---+----------+----------+---+------------+---+----------------+ > > the first res doesn't make sense, since if a provider has got a 24 bit > prefix x, it must remain a unique prefix for that provider, i.e, it is > impossible that another provider would later get a 32 bit prefix xy. > > my proposal is that if 16 bits doesn't feel big enough for providerid, > then the legth of the providerid field would be either 16 or 24 bits and > which one it is is determined by the first bit of the providerid. > if the provider has got a 16 bit providerid code, then the subscriberid > begins right after it. That would be fine by me. In fact, the previous version of this document allowed for both 24 and 16 bits for the ProvideID field. > > the second res should also be deleted. it should be up to the provider > to allocate intra-subscriber fields of various lengths to its > subscriber. one very big site might need to get 72 bit intra-subscriber > field whereas another site with a couple of pcs, could very well live > with 56 bit intra-subscriber field. Ditto. > my proposal is that the length of the intra-subscriber field varies from > 56 to 72 bits and it is up to the provider to select a coding of > subscriberid field that determines how long the intra-subscriber field > is. That would be fine too. > i hope that the authors of the draft could consider these changes and > give their response. we need these addresses now and that is why i'm > trying to get this issue solved as soon as possible. I would be glad to adopt the changes you suggested, provided that there is a (rough) consensus from the WG. Yakov. ------------------------------------------------------------------------------ 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 Jan 8 08:43:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24404; Mon, 8 Jan 96 08:43:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24398; Mon, 8 Jan 96 08:43:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15251; Mon, 8 Jan 1996 08:42:50 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id IAA26878; Mon, 8 Jan 1996 08:42:40 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18162; Mon, 8 Jan 1996 17:40:25 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA13252; Mon, 8 Jan 1996 17:40:22 +0100 Message-Id: <9601081640.AA13252@dxcoms.cern.ch> Subject: (IPng 1029) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt To: jh@lohi.dat.tele.fi (Juha Heinanen) Date: Mon, 8 Jan 1996 17:40:22 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, yakov@cisco.com In-Reply-To: <199601081529.RAA01268@lohi.dat.tele.fi> from "Juha Heinanen" at Jan 8, 96 05:29:40 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 These reserved fields came in a while back because the argument was made (by Ohta-san I think) that we don't know enough today to freeze the boundaries for ever. More recently I have even seen the argument that the format is over-specified even with the reserved fields added, and that the boundaries should actually be left completely floating. I think this is wrong and especially because of the argument about interface token size that we were having earlier today. Juha's point leads to a new issue - if the reserved fields are later allocated thoughtlessly, this might actually BREAK the previously perfect CIDRization of the IPv6 address space. That would be a total catastrophe of course. I agree with Yakov and juha on balance. Note that anyway we are only talking about 1/8 of the total address space here. We have more than half totally unassigned for when we screw up. But you will have to argue very well to get the IESG to agree to a more rigid allocation. 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 Mon Jan 8 09:38:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24487; Mon, 8 Jan 96 09:38:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24481; Mon, 8 Jan 96 09:38:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22247; Mon, 8 Jan 1996 09:37:52 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id JAA10628; Mon, 8 Jan 1996 09:37:50 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id MAA13589; Mon, 8 Jan 1996 12:37:40 -0500 Message-Id: <199601081737.MAA13589@thumper.bellcore.com> To: "Brian Carpenter CERN-CN" Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1030) Re: Max size of interface token In-Reply-To: Your message of Mon, 08 Jan 1996 14:49:11 +0100. <9601081349.AA17312@dxcoms.cern.ch> Date: Mon, 08 Jan 1996 12:37:39 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Brian wrote..] >>You have to realise that ATM "hardware" addresses can be >>20 bytes long. Squeezing them into 48 or 64 bits is going >>to be an effort. Setting a recommended maximum token size >>at 48 bits and an absolute maximum at 64 bits would seem >>reasonable to me. Just as an FYI, for anyone interested, the IP-ATM working group's first look at IPv6 over ATM is captured in the I-D . First 'best guess' at a suitable token size was 64 bits. cheers, gja ------------------------------------------------------------------------------ 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 Jan 8 10:31:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24548; Mon, 8 Jan 96 10:31:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24542; Mon, 8 Jan 96 10:30:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00662; Mon, 8 Jan 1996 10:30:23 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id KAA26523; Mon, 8 Jan 1996 10:30:25 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA14922; Mon, 8 Jan 1996 10:30:24 -0800 Date: Mon, 8 Jan 1996 10:30:24 -0800 From: Ran Atkinson Message-Id: <199601081830.KAA14922@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1031) Re: ND Asst for Security Issue for DHCPv6? Newsgroups: cisco.external.ietf.ipng In-Reply-To: <9601080510.AA07776@fwasted.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601080510.AA07776@fwasted.zk3.dec.com> you write: >Folks, > >Have to come to our IPng list again. > >See attached and then my question after. > >======================================================= >%> - authentication and relay agents. Do we need a new mechanism to >%> solve this? Does the problem need solving? > >%I think that any authentication stuff needs to be done as another >%option (that is, extension :-) which we can design later. This >%approach seemed to be acceptable at the last working group meeting. > >This is a harder problem and I have sent a proposed solution out to the >list I hope to get responses too. What I don't want to do is require >non-END-SYSTEMS which are not Hosts acting as relay-agents to have to >implement IPSEC. THis is tricky but can be designed in the prototocol. Sorry, I don't have enough context from your email to understand the issues, even though I talked in the hallway with Ralph Droms about DHCP authentication during Dallas. Could you please provide more background ?? >The discussion as I recall it at the WG was that the relay-agent must >change the packet of the client which breakes the IPSEC model to the >remote server. Serveral soultions were discussed: > > 1. Have End-to-End client-relay-agent then relay-agent-remote-server. > > Folks initially did not like this as it causes a security > association twice. It also can require IPSEC on routers for > IPv6 and this is not good or was intended in IPv6. IPsec is _already_ required to be implemented for all IPv6 nodes, including IPv6 routers, so I don't see that as an issue. > 2. The client must get the relay-agents address to put into the > packet and then resend the client message to the relay-agent. > > This will work but is a real hack and extra packet on the network. > > 3. Encapsulate the client packet in IPv6 to the remote server. > > This will work but causes a tunnel strategy as the norm as IPSEC > eventually will be widely implemented and used at least for > authentication. Tunneling is not necessarily so bad, though I still don't think I understand the context of your issue sufficiently to have a solid opinion. >======================================================================== > >Because DHCPv6 is an implementation of Stateful Address >Autoconfiguration can we have as an option to ND when the Managed bit >"M" or other config "O" is on that as another option a set of fields >identifying the gateway and server addresses for DHCPv6? I don't understand this last bit either. More background would be helpful here. Thanks, 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 Mon Jan 8 11:04:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24580; Mon, 8 Jan 96 11:04:47 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24574; Mon, 8 Jan 96 11:04:24 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA16430; Mon, 8 Jan 1996 11:03:33 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA25947; Mon, 8 Jan 1996 11:03:59 -0800 Date: Mon, 8 Jan 1996 11:03:59 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199601081903.LAA25947@bobo.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 1032) Re: ND Asst for Security Issue for DHCPv6? 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 don't understand the high-level pciture for how you propose securing (authenticating or whatever) DHCP. In order for the client to send an authenticated DHCP packet is has to create a security association before it has a global IPv6 address. This would require some form of key management server on every link. Is this the assumption? 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 Jan 8 12:30:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24700; Mon, 8 Jan 96 12:30:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24694; Mon, 8 Jan 96 12:30:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18981; Mon, 8 Jan 1996 12:29:45 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id MAA03798; Mon, 8 Jan 1996 12:29:45 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA21212; Mon, 8 Jan 1996 12:29:43 -0800 Date: Mon, 8 Jan 1996 12:29:43 -0800 From: Ran Atkinson Message-Id: <199601082029.MAA21212@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1033) Re: ND Asst for Security Issue for DHCPv6? Newsgroups: cisco.external.ietf.ipng In-Reply-To: <199601081433.JAA00263@hygro.raleigh.ibm.com> References: <9601080510.AA07776@fwasted.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199601081433.JAA00263@hygro.raleigh.ibm.com> Tom Narten wrote: >Jim, > >>Because DHCPv6 is an implementation of Stateful Address >>Autoconfiguration can we have as an option to ND when the Managed bit >>"M" or other config "O" is on that as another option a set of fields >>identifying the gateway and server addresses for DHCPv6? > >I've thought about this for a while, but I'm not sure it really buys >as much as first appears. Relay agents *really* mess up the IPSec >model. In addition, address scoping issues get in the way. The client >will only (in general) have a link-local unicast address. If the >server is on a remote link, getting the host's packet to the server >introduces complexities due to scoping (i.e., routers won't forward >packets with link-local scope addresses). The main thing that will run foul the IPsec model is to modify packets that are in transit between the node adding the security header and the node verifying/processing the security header. If the "relay agent" securely tunnels the original packet without modifying the original packet, all is well. My, possibly incorrect, understanding is that DHCP "relay agents" must modify a particular field in the DHCP header to add their own IP address so that the DHCP server knows how to return the DHCP reply. One option that ought to be seriously considered is adding authentication into DHCP. >If a packet goes through a relay agent, and the packet contains an >IPSec AH, the relay agent's stack will attempt to authenticate the >packet. Remember, the DHCP packet is sent to a link-local multicast >address, so the relay agent will assume it is addressed to it. If the >relay agent doesn't implement IPSec, we're in trouble. Even if it >does, will the stack toss the packet if the relay agent can't >authenticate it? Even if it does authenticate the packet, the AH >itself will probably be discarded by the stack before it passed to the >application layer. End result, even if the relay agent (application) >gets the packet, the original AH is probably gone. So end-to-end >host-server authentication is gone. It is not generally the case that intermediate systems will attempt to authenticate or decrypt packets not addressed to them. If a node attempts authentication/decryption and that attempt is NOT successful, then that node MUST drop the packet in question (etc). If the relay agent is an IPv6 node (it must be to receive a link-local IPv6 multicast packet), then it DOES implement IPsec. >Unfortunately, we MUST go through a relay agent if the server is >off-link. The original host DHCP packet has a link-local (unicast) >source address. Such a packet cannot be forwarded to a server (through >a router); the router will toss the packet. So the relay agent has to >step in to add its own addresses. There are two case: > >a) resend the original packet to a DHCP server with a new IP header >with the relay agent's (properly-scoped) unicast address as the >source. This clearly breaks the IPSec AH model. > >b) To preserve the original header, the relay agent could tunnel the >packet to the DHCP server (assuming it even has access to the original >AH). But the encapsulated packet has the original addresses in it, >which have the wrong scope for the server's link. At a minimum, there >is an architectural question as to whether such tunneling should even >be allowed. The server couldn't directly reply to such a packet. Note >that the server's stack would probably discard the outside header >(from the relay) agent, and the server would think it received the >packet from an on-link source. Yes. There is a solid argument that packets using link-local addresses ought not be forwarded off-link because that would take them outside the scope of the addresses used in the packet. >This last model seems to be the cleanest way to allow DHCP to use >IPSec for authentication, but it relies on a lot of details being done >a certain way (e.g., relay agent preserving original AH), an >assumption that probably won't hold universally. It would require that >the DHCP host know the 'giaddr' field, which could possibly be learned >through RAs as you suggest. But I think the above details need to be >worked out before going this route. One half-baked idea I just had would be for the DHCP Relay to cache the data about the link-local node requesting DHCP information and then send a new packet (Relay->Server) requesting whatever the link-local node needs and including some token (meaningful to the relay) to keep straight which link-local node the request is for. The server would then reply directly to the relay, including the same token as was in the request. The relay would use the token to figure out which link-local node the information was needed by and would send a message (relay->local-node) with the reply information. This could not provide end-to-end authentication, but would limit the trust to the DHCP Relay Agent (which already has to be trusted to send the messages to the correct server, so perhaps not a big change in the trust model). This might have problems that I'm clueless about, but is worth 60 seconds of consideration to see if there are problems. :-) 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 Mon Jan 8 12:35:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24712; Mon, 8 Jan 96 12:35:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24706; Mon, 8 Jan 96 12:34:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19481; Mon, 8 Jan 1996 12:34:27 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id MAA04791; Mon, 8 Jan 1996 12:34:27 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA21464; Mon, 8 Jan 1996 12:33:53 -0800 Date: Mon, 8 Jan 1996 12:33:53 -0800 From: Ran Atkinson Message-Id: <199601082033.MAA21464@puli.cisco.com> To: jh@lohi.dat.tele.fi Subject: (IPng 1034) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: <199601081529.RAA01268@lohi.dat.tele.fi> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199601081529.RAA01268@lohi.dat.tele.fi> Juha wrote: >i'll try once more to propose a fix to >draft-ietf-ipngwg-unicast-addr-fmt-02.txt. if none of the authors >reacts i guess i don't have any other change that to write another >competing i-d. > >the current format is: > > | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 64 bits | > +---+----------+----------+---+------------+---+----------------+ > |010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber| > +---+----------+----------+---+------------+---+----------------+ > >the first res doesn't make sense, since if a provider has got a 24 bit >prefix x, it must remain a unique prefix for that provider, i.e, it is >impossible that another provider would later get a 32 bit prefix xy. > >my proposal is that if 16 bits doesn't feel big enough for providerid, >then the legth of the providerid field would be either 16 or 24 bits and >which one it is is determined by the first bit of the providerid. >if the provider has got a 16 bit providerid code, then the subscriberid >begins right after it. This might be an argument for moving the first RES field to between [Registry ID] and [Provider ID] ?? >the second res should also be deleted. it should be up to the provider >to allocate intra-subscriber fields of various lengths to its >subscriber. one very big site might need to get 72 bit intra-subscriber >field whereas another site with a couple of pcs, could very well live >with 56 bit intra-subscriber field. I strongly object to removing the second RES field as shown in the diagram above. This places too much power in the hands of providers, whose interests don't always coincide with users. >my proposal is that the length of the intra-subscriber field varies from >56 to 72 bits and it is up to the provider to select a coding of >subscriberid field that determines how long the intra-subscriber field >is. I object to this as being too strongly biasing the playing field in favour of providers against users. >i hope that the authors of the draft could consider these changes and >give their response. we need these addresses now and that is why i'm >trying to get this issue solved as soon as possible. Ran rja@inet.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 Mon Jan 8 13:04:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24792; Mon, 8 Jan 96 13:04:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24774; Mon, 8 Jan 96 13:04:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23065; Mon, 8 Jan 1996 13:03:44 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id NAA10638; Mon, 8 Jan 1996 13:03:43 -0800 Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi.dat.tele.fi (8.6.12/8.6.12) with SMTP id XAA02044; Mon, 8 Jan 1996 23:01:54 +0200 Message-Id: <30F18669.42B8@lohi.dat.tele.fi> Date: Mon, 08 Jan 1996 23:02:33 +0200 From: Juha Heinanen Organization: Telecom Finland Inc. X-Mailer: Mozilla 2.0b4 (Win95; I) Mime-Version: 1.0 To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1035) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt References: <199601082033.MAA21464@puli.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson wrote: > > This might be an argument for moving the first RES field to between > [Registry ID] and [Provider ID] ?? if you move it there, then the net effect is that provider id has been extended to 3 bytes, since for what else could it be used for? i tried to explain in my first message on this subject, that if there is two reserved fields as suggested, there is not enough bits for the subscriber id for large providers. it has been a mistake not to have enough address bytes in the first place and now the proposal would make the too small number even smaller by reserving two bytes of it. don't we never learn. may be the 16 byte address length should be reconsidered, since there are not many implementations arround yet and then we would not need to have this discussion. > I strongly object to removing the second RES field as shown in the diagram > above. This places too much power in the hands of providers, whose > interests don't always coincide with users. if you don't get enough bytes from one provider, you can always buy your service from another one. market will take care of your fear that a subscriber that really needs three bytes will get it. reserving that byte doesn't make sense, since it means that neither the provider nor the subscriber can use it. the current wording is that only the subscriber could ever use the reserved field, which means that it factually belongs to the subscriber already. but since not all subscriber need three bytes, that is why i suggested that it should be up to the provider to allocate a proper length of prefix to each customer site. -- juha ------------------------------------------------------------------------------ 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 Jan 8 13:19:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24825; Mon, 8 Jan 96 13:19:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24816; Mon, 8 Jan 96 13:18:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25180; Mon, 8 Jan 1996 13:18:37 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id NAA14341; Mon, 8 Jan 1996 13:18:37 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id NAA23798; Mon, 8 Jan 1996 13:18:02 -0800 Date: Mon, 8 Jan 1996 13:18:02 -0800 From: Ran Atkinson Message-Id: <199601082118.NAA23798@puli.cisco.com> To: jh@lohi.dat.tele.fi Subject: (IPng 1036) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This might be an argument for moving the first RES field to between > [Registry ID] and [Provider ID] ?? % if you move it there, then the net effect is that provider id has been % extended to 3 bytes, since for what else could it be used for? Aggregating several providers at a NAP, NAP-oriented addressing, etc. % i tried % to explain in my first message on this subject, that if there is two % reserved fields as suggested, there is not enough bits for the % subscriber id for large providers. it has been a mistake not to have % enough address bytes in the first place and now the proposal would make % the too small number even smaller by reserving two bytes of it. don't % we never learn. may be the 16 byte address length should be % reconsidered, since there are not many implementations arround yet and % then we would not need to have this discussion. I think you are worrying about the wrong problem, unless perhaps you're trying to ensure that providers get an even tighter grip over their customers ability to change providers... % > I strongly object to removing the second RES field as shown in the diagram % > above. This places too much power in the hands of providers, whose % > interests don't always coincide with users. % % if you don't get enough bytes from one provider, you can always buy your % service from another one. market will take care of your fear % that a subscriber that really needs three bytes will get it. reserving % that byte doesn't make sense, since it means that neither the provider % nor the subscriber can use it. the current wording is that only the % subscriber could ever use the reserved field, which means that it % factually belongs to the subscriber already. but since not all % subscriber need three bytes, that is why i suggested that it should be % up to the provider to allocate a proper length of prefix to each % customer site. This isn't as easy as you suggest. We do NOT have the kind of scalable renumbering technology that is needed for decent sized organisations to be able to just change providers. If we did, I'd be A LOT less concerned about this. Lack of renumbering technology means that market forces are obstructed significantly in actual practice, so I don't buy the market forces assertion above. Providers have in the past used address renumbering to discourage customers from picking another provider. The IETF should not standardise an approach that puts even more power into the hands of the provider. I view your request as an attempted power play from a service provider, pure and simple. Ran rja@inet.org DISCLAIMER: I'm speaking only for myself here, as a user and based on significant experience in my previous life as a user of multiple providers... ------------------------------------------------------------------------------ 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 Jan 8 13:54:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24882; Mon, 8 Jan 96 13:54:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24876; Mon, 8 Jan 96 13:54:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00354; Mon, 8 Jan 1996 13:53:40 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id NAA22819; Mon, 8 Jan 1996 13:53:38 -0800 Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi.dat.tele.fi (8.6.12/8.6.12) with SMTP id XAA02077; Mon, 8 Jan 1996 23:51:49 +0200 Message-Id: <30F1921D.5C13@lohi.dat.tele.fi> Date: Mon, 08 Jan 1996 23:52:29 +0200 From: Juha Heinanen Organization: Telecom Finland Inc. X-Mailer: Mozilla 2.0b4 (Win95; I) Mime-Version: 1.0 To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1037) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt References: <199601082118.NAA23798@puli.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson wrote: > Aggregating several providers at a NAP, NAP-oriented addressing, etc. then i suggest that you define the details of this now, since how can you use the byte for provider aggregation unless the plan on how to do so is clear from the very beginning. on the other hand, i don't think we can afford to waste that byte from the provider field and don't consider such provider aggregation practical. > This isn't as easy as you suggest. We do NOT have the kind of scalable > renumbering technology that is needed for decent sized organisations > to be able to just change providers. If we did, I'd be A LOT less > concerned about this. Lack of renumbering technology means that > market forces are obstructed significantly in actual practice, > so I don't buy the market forces assertion above. i didn't talk about changing providers, i was talking about getting one in the first place. when you do that, you can ask fro one that gives you enough bytes and if you ever would like to change, change to one that gives you the same amount of bytes. renumbering cannot be avoided anyway. but i repeat, the root cause of this discussion is that we have too few bytes in the address field. i think we should therefore seriously consider changing the address field to 20 bytes, before inpg spec is advanced. > I view your request as an attempted power play from a service > provider, pure and simple. you are wrong here. i'm simply trying to get enough bits so build a reasonable routing hierarchy. i thought that the whole idea of ipng was to solve the scalability problem. now i have shown that in order to do so, i would need at least one of the proposed reserved bytes, but you don't want to give it. and i didn't even consider provider aggregation in my calculation that you brought up. my conclusion of this is that ipng has failed its most important mission even before the deployment has begun. in any case, the reserved fields in the current draft are meaningless and need to be fixed. -- juha ------------------------------------------------------------------------------ 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 Jan 8 16:38:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25077; Mon, 8 Jan 96 16:38:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25071; Mon, 8 Jan 96 16:38:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22205; Mon, 8 Jan 1996 16:38:02 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id QAA29721; Mon, 8 Jan 1996 16:38:02 -0800 Received: from uvite53.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA02490; Mon, 8 Jan 1996 19:37:59 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Jan 1996 19:38:00 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 1038) Re: ND Asst for Security Issue for DHCPv6? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:29 PM 1/8/96, Ran Atkinson wrote: >One option that ought to be seriously considered is adding authentication >into DHCP. Seems the tradeoff we have to evaluate is making changes to ND and the underlying DHCP client-server commmunication model to accommodate IPSEC, or adding a DHCP-specific authentication mechanism to DHCP. Do we save more effort by using IPSEC than we expend by making the necessary changes? >One half-baked idea I just had would be for the DHCP Relay to cache the >data about the link-local node requesting DHCP information and then send a >new packet (Relay->Server) requesting whatever the link-local node needs >and including some token (meaningful to the relay) to keep straight which >link-local node the request is for. The server would then reply directly >to the relay, including the same token as was in the request. The relay >would use the token to figure out which link-local node the information was >needed by and would send a message (relay->local-node) with the reply >information. One of the design principles of DHCP has been to avoid requiring the relay agent to keep any state for DHCP messages, to avoid complexity and scale problems in the relay agent. That's not to say we couldn't use it; we've tried to stay away from similar mechanisms in the past. - 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 Mon Jan 8 16:50:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25096; Mon, 8 Jan 96 16:50:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25090; Mon, 8 Jan 96 16:50:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23540; Mon, 8 Jan 1996 16:49:55 -0800 Received: from ns.iij.ad.jp by mercury.Sun.COM (Sun.COM) id QAA02358; Mon, 8 Jan 1996 16:49:53 -0800 Received: from shiosai.iij.ad.jp (shiosai.iij.ad.jp [192.244.176.35]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id JAA27986; Tue, 9 Jan 1996 09:48:52 +0900 Message-Id: <199601090048.JAA27986@ns.iij.ad.jp> To: Yakov Rekhter Cc: Juha Heinanen , ipng@sunroof.eng.sun.com, postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, brian@dxcoms.cern.ch, davidc@ns.iij.ad.jp Subject: (IPng 1039) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: Your message of "Mon, 08 Jan 1996 08:01:00 PST." <199601081601.IAA00438@hubbub.cisco.com> Date: Tue, 09 Jan 1996 09:48:52 +0900 From: David R Conrad Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, >> my proposal is that if 16 bits doesn't feel big enough for providerid, >> then the legth of the providerid field would be either 16 or 24 bits and >> which one it is is determined by the first bit of the providerid. >> if the provider has got a 16 bit providerid code, then the subscriberid >> begins right after it. > >That would be fine by me. In fact, the previous version of this >document allowed for both 24 and 16 bits for the ProvideID field. For the poor saps in the registries, please define the criteria which distinguishes between a provider that gets a 24 bit prefix and one that gets a 16 bit brefix. Thanks, -drc ------------------------------------------------------------------------------ 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 Jan 8 17:32:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25180; Mon, 8 Jan 96 17:32:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25168; Mon, 8 Jan 96 17:32:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28125; Mon, 8 Jan 1996 17:31:55 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id RAA10244; Mon, 8 Jan 1996 17:31:43 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id RAA07699; Mon, 8 Jan 1996 17:29:55 -0800 Date: Mon, 8 Jan 1996 17:29:55 -0800 From: Ran Atkinson Message-Id: <199601090129.RAA07699@puli.cisco.com> To: jh@lohi.dat.tele.fi Subject: (IPng 1040) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Content-Length: 2054 % % Ran Atkinson wrote: % % > Aggregating several providers at a NAP, NAP-oriented addressing, etc. % % then i suggest that you define the details of this now, since how can % you use the byte for provider aggregation unless the plan on how to do % so is clear from the very beginning. on the other hand, i don't think % we can afford to waste that byte from the provider field and don't % consider such provider aggregation practical. Juha, I have done so several times in the past -- using NRL as an example user and using MAE_EAST or FIX_EAST as examples of NAPs. I don't feel compelled to replay that scenario in detail today. In general, we have about double the address space we need, so your anxiety about "waste that byte" strikes me as very misplaced. % > This isn't as easy as you suggest. We do NOT have the kind of scalable % > renumbering technology that is needed for decent sized organisations % > to be able to just change providers. If we did, I'd be A LOT less % > concerned about this. Lack of renumbering technology means that % > market forces are obstructed significantly in actual practice, % > so I don't buy the market forces assertion above. % % i didn't talk about changing providers, i was talking about getting one % in the first place. when you do that, you can ask fro one that gives % you enough bytes and if you ever would like to change, change to one % that gives you the same amount of bytes. renumbering cannot be % avoided anyway. Nonsense. Provider-oriented addressing simply will NOT work at all for multi-homed large campuses. NRL has order(8) external network providers. Trying to force provider-oriented addressing is a total non-starter for sites like NRL. Now it might be true that NRL pays more to have its routing prefix advertised, but that is an entirely separate question. Similarly, we know that renumbering is very painful for networks of any size. Efforts can and need to be made to reduce the number of renumberings needed for nodes that ARE using provider-oriented addressing. % but i repeat, the root cause of this discussion is that we have too few % bytes in the address field. i think we should therefore seriously % consider changing the address field to 20 bytes, before inpg spec is % advanced. I think your paranoia about address size is really way off. If you want 20 bytes, you can go use OSI CLNP if you wish. % > I view your request as an attempted power play from a service % > provider, pure and simple. % % you are wrong here. i'm simply trying to get enough bits so build a % reasonable routing hierarchy. i thought that the whole idea of ipng was % to solve the scalability problem. now i have shown that in order to do % so, i would need at least one of the proposed reserved bytes, but you % don't want to give it. and i didn't even consider provider aggregation % in my calculation that you brought up. my conclusion of this is that % ipng has failed its most important mission even before the deployment % has begun. The proposal on the table has PLENTY of room for "reasonable routing heirarchy". You have asserted WITHOUT sufficient justification that you need another byte, but its just your assertion. It has no substance behind it that you've prevented to date. There is no rule saying you have to support IPng. You can sell CLNP to your customers if you wish, or whatever else you wish to. % in any case, the reserved fields in the current draft are meaningless % and need to be fixed. Not true. As noted before, the allow room for future growth on the part of both providers and users, while reducing the amount of renumbering that will be provided. Ran rja@inet.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 Mon Jan 8 18:22:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25281; Mon, 8 Jan 96 18:22:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25275; Mon, 8 Jan 96 18:22:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04145; Mon, 8 Jan 1996 18:22:18 -0800 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id SAA06113; Mon, 8 Jan 1996 18:22:19 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id SAA17673; Mon, 8 Jan 1996 18:21:40 -0800 Message-Id: <199601090221.SAA17673@hubbub.cisco.com> To: Ran Atkinson Cc: jh@lohi.dat.tele.fi, ipng@sunroof.eng.sun.com Subject: (IPng 1041) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: Your message of "Mon, 08 Jan 96 17:29:55 PST." <199601090129.RAA07699@puli.cisco.com> Date: Mon, 08 Jan 96 18:21:40 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, > Provider-oriented addressing simply will NOT work at all > for multi-homed large campuses. NRL has order(8) external network > providers. Would you please enumerate the *specific details* why provider-oriented addressing simply will "NOT work at all for multi-homed large campuses". Many thanks in advance. Yakov. ------------------------------------------------------------------------------ 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 Jan 8 19:02:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25378; Mon, 8 Jan 96 19:02:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25372; Mon, 8 Jan 96 19:02:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07239; Mon, 8 Jan 1996 19:02:20 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id TAA11262; Mon, 8 Jan 1996 19:02:21 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA16794; Mon, 8 Jan 96 21:59:03 EST Received: from [199.242.35.71] (bnw_cs3_port1.corpwest.baynetworks.com) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA15366; Mon, 8 Jan 96 21:59:16 EST Message-Id: <9601090259.AA15366@pobox.BayNetworks.com> To: Juha Heinanen , "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 1042) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Date: Mon, 08 Jan 96 22:02:10 -0500 From: Dimitry Haskin X-Mailer: E-Mail Connection v2.5.03 Cc: "postel@isi.edu" , "deering@parc.xerox.com" , "hinden@ipsilon.com" , "roll@stupi.se" , Yakov Rekhter , "brian@dxcoms.cern.ch" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -- [ From: Dimitry Haskin * EMC.Ver #2.5.02 ] -- Juha, > the second res should also be deleted. it should be up to the provider to > allocate intra-subscriber fields of various lengths to its subscriber. one > very big site might need to get 72 bit intra-subscriber field whereas another > site with a couple of pcs, could very well live with 56 bit intra- subscriber > field. > > my proposal is that the length of the intra-subscriber field varies from 56 to > 72 bits and it is up to the provider to select a coding of subscriber id field > that determines how long the intra-subscriber field is. > The problem is that it has been felt that ATM interfaces need 64-bits for the interface token which is a part of the intra-subscriber field. Since a provider can not dictate which technology its subscriber may use, if the ATM token is allowed to be 64 bits long, 64 bits is the absolute and unreasonable minimum size of the intra-subscriber field. This size of the intra- subscriber field is unreasonable since it does not permit any routing hierarchy within a subscriber. So a provider will need to give to a subscriber at least 8 additional bits for the internal subneting (which is only 255 subnets). This brings the minimum size of the intra-subscriber field to 72 bits. I guess, commonly, 80 bits or so will need to be given to a subscriber. Ha, what would we do with the 64-bits address ?l ;) Dimitry P.S. Another approach would be to limit the interface token size to 48 bits on all medias. ------------------------------------------------------------------------------ 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 Jan 8 19:23:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25398; Mon, 8 Jan 96 19:23:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25392; Mon, 8 Jan 96 19:23:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08287; Mon, 8 Jan 1996 19:22:44 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id TAA13739; Mon, 8 Jan 1996 19:22:45 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA02035; Mon, 8 Jan 1996 22:15:26 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21034; Mon, 8 Jan 1996 22:15:24 -0500 Message-Id: <9601090315.AA21034@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: Robert Elz , droms@bucknell.edu (Ralph Droms), ipng@sunroof.eng.sun.com Subject: (IPng 1043) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Mon, 08 Jan 96 09:24:09 EST." <199601081424.JAA00250@hygro.raleigh.ibm.com> Date: Mon, 08 Jan 96 22:15:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 08 Jan 1996 09:24:09 -0500 From: "Thomas Narten" >For many of the possible uses suggested there, I concur with the >author that there are better alternative solutions. For many of the >examples cited, I think that using multiple addresses will be rather >difficult to implement when the details are considered. Thus, I would >really like to see a more convincing argument that we should >*encourage* such behavior and that the base DHCP architecture requires >such behavior. In the specific case of DHCP, allowing clients to >request "extra" addresses will significantly complicate the protocol >and administration model. Again, what is the benefit to the end user >(i.e., the system administrator)? I don't think this is the only way to handle it or that we should encourage it either. But I do think from the discussions and from what practically will happen in the end user market we need to design into our implementations the ability for clients to request new addresses a second, third, fourth, etc, time. And for servers to be able to deal with this fact. As I said last night we need to go do some protocol design brainstorming. WHich is cool and we will get back to IPng OK. Thats the fun part of being an engineer. If the requirement is real expensive we will say that too. /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 Jan 8 19:48:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25468; Mon, 8 Jan 96 19:48:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25462; Mon, 8 Jan 96 19:48:25 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09535; Mon, 8 Jan 1996 19:48:03 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id TAA16284; Mon, 8 Jan 1996 19:48:05 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA11303; Mon, 8 Jan 1996 22:40:25 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25534; Mon, 8 Jan 1996 22:40:23 -0500 Message-Id: <9601090340.AA25534@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1044) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Mon, 08 Jan 96 09:33:00 EST." <199601081433.JAA00263@hygro.raleigh.ibm.com> Date: Mon, 08 Jan 96 22:40:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >>Because DHCPv6 is an implementation of Stateful Address >>Autoconfiguration can we have as an option to ND when the Managed bit >>"M" or other config "O" is on that as another option a set of fields >>identifying the gateway and server addresses for DHCPv6? >I've thought about this for a while, but I'm not sure it really buys >as much as first appears. Relay agents *really* mess up the IPSec >model. In addition, address scoping issues get in the way. The client >will only (in general) have a link-local unicast address. If the >server is on a remote link, getting the host's packet to the server >introduces complexities due to scoping (i.e., routers won't forward >packets with link-local scope addresses). Yes it does mess up IPSEC because the relay-agent must change the packet which means the authentication or even encryption changes. The relay-agent does not forward the clients link-local address the src address is the relay-agents interface address. I am not sure what your concern is about scoping? I don't see a scoping problem here? Can you say more? thanks... >If a packet goes through a relay agent, and the packet contains an >IPSec AH, the relay agent's stack will attempt to authenticate the >packet. Remember, the DHCP packet is sent to a link-local multicast >address, so the relay agent will assume it is addressed to it. If the >relay agent doesn't implement IPSec, we're in trouble. Even if it >does, will the stack toss the packet if the relay agent can't >authenticate it? Even if it does authenticate the packet, the AH >itself will probably be discarded by the stack before it passed to the >application layer. End result, even if the relay agent (application) >gets the packet, the original AH is probably gone. So end-to-end >host-server authentication is gone. Well my DHCPv6 daemon as relay-agent will be able to authenticate or decrypt an IPSEC header. I don't see that as a problem at all. In fact the scenario that client-to-relay-agent authenticate/encrpt AND THEN relay-agent-to-server authenticate/encrypt AND THEN vice a versa in the other direction will work very well and require no change to IPSEC or DHCP. But during the DHCP meeting several router vendors did not want to have to authenticate/encrypt as a relay-agent in their code base. I agree with them being a host kind of guy as it will be even expensive when building a relay-agent daemon on a host too. >Unfortunately, we MUST go through a relay agent if the server is >off-link. The original host DHCP packet has a link-local (unicast) >source address. Such a packet cannot be forwarded to a server (through >a router); the router will toss the packet. So the relay agent has to >step in to add its own addresses. There are two case: Yes this is the case. >a) resend the original packet to a DHCP server with a new IP header >with the relay agent's (properly-scoped) unicast address as the >source. This clearly breaks the IPSec AH model. No it does not. It can be done. Its just a new IPSEC AH header between the relay-agent and server. The end-to-end becomes as follows: client ----- relay-agent and relay-agent ---- remote server This is fine for IPSEC as IPSEC does not define what constitutes each end of a connection. But its expensive and forces every IPv6 router to implement IPSEC where DHCPv6 is used. But it can work. >b) To preserve the original header, the relay agent could tunnel the >packet to the DHCP server (assuming it even has access to the original >AH). But the encapsulated packet has the original addresses in it, >which have the wrong scope for the server's link. At a minimum, there >is an architectural question as to whether such tunneling should even >be allowed. The server couldn't directly reply to such a packet. Note >that the server's stack would probably discard the outside header >(from the relay) agent, and the server would think it received the >packet from an on-link source. You need to discuss your scope issue I don't see one. But.. the tunnel has no problem here is how the packet would look being sent from the relay-agent. It would use the new spec IPv6 Generic Tunneling by Alex Conta and Steve Deering as a note. IPv6 Header (src is relay-agent dst is server) NEXT Header would be destination option (for the dst server) with the relay-agents gateway address. This is how the server knows how to get back to the original relay-agent. We would have to define all this in DHCPv6 to work with IPv6. NEXT Header would be the IPv6 encapsulated packet. The server would save the address of the gateway address in the destination option. The it would decapsulate the IPv6 DHCPv6 packet and process it just like a normal DHCP packet with IPSEC too. Then the server would encapsulate the response and send it back to the relay-agent. The relay-agent when sending to the remote server and receiving the message from the remote server each time has to parse the packet and do the authentication to just figure out what client its dealing with (well maybe not on sending to the remote server). Because of this its no less complex than just doing it end-to-end at each point in the transaction as depicted above. UNLESS we change the model of the DHCPv6 relay-agent and keep state. Then we can tunnel client packets to servers and also remove two 16 byte fields from the DHCPv6 packet. Whatever we do here the relay-agent has more work to do and nothing can be done about it if IPSEC is being used. >This last model seems to be the cleanest way to allow DHCP to use >IPSec for authentication, but it relies on a lot of details being done >a certain way (e.g., relay agent preserving original AH), an >assumption that probably won't hold universally. It would require that >the DHCP host know the 'giaddr' field, which could possibly be learned >through RAs as you suggest. But I think the above details need to be >worked out before going this route. I agree we need to talk about this more. /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 Jan 8 20:02:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25492; Mon, 8 Jan 96 20:02:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25486; Mon, 8 Jan 96 20:02:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10257; Mon, 8 Jan 1996 20:02:23 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id UAA17715; Mon, 8 Jan 1996 20:02:24 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA30737; Mon, 8 Jan 1996 22:58:04 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26094; Mon, 8 Jan 1996 22:58:02 -0500 Message-Id: <9601090358.AA26094@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1045) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Mon, 08 Jan 96 10:30:24 PST." <199601081830.KAA14922@puli.cisco.com> Date: Mon, 08 Jan 96 22:58:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 8 Jan 1996 10:30:24 -0800 From: Ran Atkinson %In article <9601080510.AA07776@fwasted.zk3.dec.com> you write: %>Folks, %> %>Have to come to our IPng list again. %> %>See attached and then my question after. %> %>======================================================= %>%> - authentication and relay agents. Do we need a new mechanism to %>%> solve this? Does the problem need solving? %> %>%I think that any authentication stuff needs to be done as another %>%option (that is, extension :-) which we can design later. This %>%approach seemed to be acceptable at the last working group meeting. %> %>This is a harder problem and I have sent a proposed solution out to the %>list I hope to get responses too. What I don't want to do is require %>non-END-SYSTEMS which are not Hosts acting as relay-agents to have to %>implement IPSEC. THis is tricky but can be designed in the prototocol. %Sorry, I don't have enough context from your email to understand the %issues, even though I talked in the hallway with Ralph Droms about DHCP %authentication during Dallas. Could you please provide more background ?? DHCPv6 Today: Client sends DISCOVER with DHCPv6 Multicast defined address. Servers and Relay-Agents hear this Multicast packet. Servers respond and DHCPv6 is off and running. Relay-Agents must forward the packet to remote servers. Relay-Agents must put the address of the interface the client message is received on inside the DHCPv6 packet in a field called relay-agent address. This is done so that when the packet reaches the remote server the server can respond directly back to the Relay-Agent. The reason is that the message could traverse "multiple" relay-agents to get to the DHCPv6 server. DHCPv4 also works this way today. The issue is we do not want to maintain state in the relay-agents (I tried to do this with the first DHCPv6 spec and it got shot down per the WG as its painful for routers when they are acting as relay-agents). Hence, the relay-agent must alter the packet which is going to the server which changes the authentication data. That is the meat of the problem. We have had three ideas thrown around and a new one: 1. Do authentication as follows: client-to-relay-agent relay-agent-to-server server-to-relay-agent relay-agent-to-client At Dallas this was perceived bad for router implementations and would force them to implement IPSEC when acting as a relay-agent. IMHO I agree. 2. Re-Do DHCPv6 to DISCOVER relay-agents and servers on the network first and then send unicasts to each of them and await a response. This could also be learned via extensions to ND to supply relay-agent and server addresses in RAs. 3. Tunnel client packets IPv6-in-IPv6 to the servers from the relay-agents. But this would require the Relay-Agents to maintain state about clients to really work elegantly and to just leave the IPv6 client packet alone. This would be a change but I have always thought it was OK if the router vendors can live with it. 4. A new one per Ralph Droms talking with Christian Huitema and Jeff Schiller is to make IPSEC ignore the relay-agent field in the creation of the secured data. %>The discussion as I recall it at the WG was that the relay-agent must %>change the packet of the client which breakes the IPSEC model to the %>remote server. Serveral soultions were discussed: %> %> 1. Have End-to-End client-relay-agent then relay-agent-remote-server. %> %> Folks initially did not like this as it causes a security %> association twice. It also can require IPSEC on routers for %> IPv6 and this is not good or was intended in IPv6. % %IPsec is _already_ required to be implemented for all IPv6 nodes, %including IPv6 routers, so I don't see that as an issue. Ah. I did not know this. I thought only Hosts were required to implement IPSEC in IPv6? Sorry I missed that. So its a question of whether we want our relay-agents doing this for performance reasons than requirement reasons. That changes the picture for me a little bit. %> 2. The client must get the relay-agents address to put into the %> packet and then resend the client message to the relay-agent. %> %> This will work but is a real hack and extra packet on the network. %> %> 3. Encapsulate the client packet in IPv6 to the remote server. %> %> This will work but causes a tunnel strategy as the norm as IPSEC %> eventually will be widely implemented and used at least for %> authentication. %Tunneling is not necessarily so bad, though I still don't think I %understand the context of your issue sufficiently to have a solid opinion. See above. %>======================================================================== %> %>Because DHCPv6 is an implementation of Stateful Address %>Autoconfiguration can we have as an option to ND when the Managed bit %>"M" or other config "O" is on that as another option a set of fields %>identifying the gateway and server addresses for DHCPv6? %I don't understand this last bit either. More background would be %helpful here. See message from Thomas Narten and my response just sent. 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 Jan 8 20:14:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25520; Mon, 8 Jan 96 20:14:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25514; Mon, 8 Jan 96 20:14:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10806; Mon, 8 Jan 1996 20:13:43 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id UAA18843; Mon, 8 Jan 1996 20:13:44 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA17078; Mon, 8 Jan 1996 23:05:41 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26626; Mon, 8 Jan 1996 23:05:23 -0500 Message-Id: <9601090405.AA26626@fwasted.zk3.dec.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1046) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Mon, 08 Jan 96 11:03:59 PST." <199601081903.LAA25947@bobo.eng.sun.com> Date: Mon, 08 Jan 96 23:05:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, >I don't understand the high-level pciture for how you propose >securing (authenticating or whatever) DHCP. In order for the client >to send an authenticated DHCP packet is has to create a security >association before it has a global IPv6 address. This would require >some form of key management server on every link. Is this the assumption? The security association would be done with a link-local address. Thats all the client has when it first goes to DHCPv6 is one case. I am assuming if the client is doing security there is a key management server on the link and that I agree could be a problem. You raise a very good point. I am not sure the link-local vs global-address matters but I am not a security expert either? Could it be there is a key managment strategy for the dumb node like a client which is a new-born node. ALso for the light-switch or toaster too?????? Is this something we need to think about architecturally in IPv6 now that you bring it up? 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 Jan 8 20:24:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25540; Mon, 8 Jan 96 20:24:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25534; Mon, 8 Jan 96 20:24:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11191; Mon, 8 Jan 1996 20:23:38 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id UAA19842; Mon, 8 Jan 1996 20:23:40 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA11329; Mon, 8 Jan 1996 23:18:26 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27067; Mon, 8 Jan 1996 23:18:24 -0500 Message-Id: <9601090418.AA27067@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1047) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Mon, 08 Jan 96 12:29:43 PST." <199601082029.MAA21212@puli.cisco.com> Date: Mon, 08 Jan 96 23:18:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 8 Jan 1996 12:29:43 -0800 From: Ran Atkinson %In article <199601081433.JAA00263@hygro.raleigh.ibm.com> Tom Narten wrote: %>Jim, %> %>>Because DHCPv6 is an implementation of Stateful Address %>>Autoconfiguration can we have as an option to ND when the Managed bit %>>"M" or other config "O" is on that as another option a set of fields %>>identifying the gateway and server addresses for DHCPv6? %> %>I've thought about this for a while, but I'm not sure it really buys %>as much as first appears. Relay agents *really* mess up the IPSec %>model. In addition, address scoping issues get in the way. The client %>will only (in general) have a link-local unicast address. If the %>server is on a remote link, getting the host's packet to the server >introduces complexities due to scoping (i.e., routers won't forward %>packets with link-local scope addresses). %The main thing that will run foul the IPsec model is to modify packets that %are in transit between the node adding the security header and the node %verifying/processing the security header. This will happen too. %If the "relay agent" securely tunnels the original packet without modifying %the original packet, all is well. My, possibly incorrect, understanding %is that DHCP "relay agents" must modify a particular field in the DHCP %header to add their own IP address so that the DHCP server knows how %to return the DHCP reply. Exactly. We could do it without modifying the packet but then we would need to maintain state about the client in the relay-agent. This was in my very first design for the very architecture reason we are dealing with now. I envisioned a case of just forwardign the packet in a tunnel to avoid any complexities in the base protocol which adds state to the underlying protocol. That was shot down but maybe now has to be revisited. I think it cheaper to maintain state in the DHCPv6 relay-agent than having to handle all the cases if we do not just for security and most likely other issues in the future. %One option that ought to be seriously considered is adding authentication %into DHCP. I was hoping that IPSEC was enough for the base protocol. Then later as Charlie Perkins has suggested we add another form of security similar as to how we are deailing with Dynamic Updates to DNS via DNSSEC. %>If a packet goes through a relay agent, and the packet contains an %>IPSec AH, the relay agent's stack will attempt to authenticate the %>packet. Remember, the DHCP packet is sent to a link-local multicast %>address, so the relay agent will assume it is addressed to it. If the %>relay agent doesn't implement IPSec, we're in trouble. Even if it %>does, will the stack toss the packet if the relay agent can't %>authenticate it? Even if it does authenticate the packet, the AH %>itself will probably be discarded by the stack before it passed to the %>application layer. End result, even if the relay agent (application) %>gets the packet, the original AH is probably gone. So end-to-end %>host-server authentication is gone. %It is not generally the case that intermediate systems will attempt to %authenticate or decrypt packets not addressed to them. If a node %attempts authentication/decryption and that attempt is NOT successful, %then that node MUST drop the packet in question (etc). Thats what I thought too. Dropping the packet in DHCPv6 is really not too good for the client. %If the relay agent is an IPv6 node (it must be to receive a link-local %IPv6 multicast packet), then it DOES implement IPsec. Yep. %>Unfortunately, we MUST go through a relay agent if the server is %>off-link. The original host DHCP packet has a link-local (unicast) %>source address. Such a packet cannot be forwarded to a server (through %>a router); the router will toss the packet. So the relay agent has to %>step in to add its own addresses. There are two case: %> %>a) resend the original packet to a DHCP server with a new IP header %>with the relay agent's (properly-scoped) unicast address as the %>source. This clearly breaks the IPSec AH model. %> %>b) To preserve the original header, the relay agent could tunnel the %>packet to the DHCP server (assuming it even has access to the original %>AH). But the encapsulated packet has the original addresses in it, %>which have the wrong scope for the server's link. At a minimum, there %>is an architectural question as to whether such tunneling should even %>be allowed. The server couldn't directly reply to such a packet. Note %>that the server's stack would probably discard the outside header %>(from the relay) agent, and the server would think it received the %>packet from an on-link source. %Yes. There is a solid argument that packets using link-local addresses %ought not be forwarded off-link because that would take them outside %the scope of the addresses used in the packet. Well the addresses are not used they are only maintained at the relay-agent so it can get the global-address back to the client. I agree with the principle completely. I could see a strategy where the packet to the server from the relay-agent is a completely separate packet of its own context. But this means relay-agents must now maintain state about the client. As a note its not a lot of work to maintain such state on a host for the client at all. %>This last model seems to be the cleanest way to allow DHCP to use %>IPSec for authentication, but it relies on a lot of details being done %>a certain way (e.g., relay agent preserving original AH), an %>assumption that probably won't hold universally. It would require that %>the DHCP host know the 'giaddr' field, which could possibly be learned %>through RAs as you suggest. But I think the above details need to be %>worked out before going this route. %One half-baked idea I just had would be for the DHCP Relay to cache the %data about the link-local node requesting DHCP information and then send a %new packet (Relay->Server) requesting whatever the link-local node needs %and including some token (meaningful to the relay) to keep straight which %link-local node the request is for. The server would then reply directly %to the relay, including the same token as was in the request. The relay %would use the token to figure out which link-local node the information was %needed by and would send a message (relay->local-node) with the reply %information. This could not provide end-to-end authentication, but %would limit the trust to the DHCP Relay Agent (which already has to be %trusted to send the messages to the correct server, so perhaps not a %big change in the trust model). This might have problems that I'm %clueless about, but is worth 60 seconds of consideration to see if %there are problems. :-) This is exactly how I first designed DHCPv6. I think we need to give it 60 seconds of thought again. /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 Jan 8 20:37:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25572; Mon, 8 Jan 96 20:37:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25566; Mon, 8 Jan 96 20:37:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11721; Mon, 8 Jan 1996 20:37:23 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id UAA21204; Mon, 8 Jan 1996 20:37:24 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA27868; Mon, 8 Jan 1996 23:31:24 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27532; Mon, 8 Jan 1996 23:31:22 -0500 Message-Id: <9601090431.AA27532@fwasted.zk3.dec.com> To: droms@bucknell.edu (Ralph Droms) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1048) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Mon, 08 Jan 96 19:38:00 EST." Date: Mon, 08 Jan 96 23:31:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 8 Jan 1996 19:38:00 -0500 From: droms@bucknell.edu (Ralph Droms) %At 12:29 PM 1/8/96, Ran Atkinson wrote: %>One option that ought to be seriously considered is adding authentication %>into DHCP. %Seems the tradeoff we have to evaluate is making changes to ND and the %underlying DHCP client-server commmunication model to accommodate IPSEC, or %adding a DHCP-specific authentication mechanism to DHCP. Do we save more %effort by using IPSEC than we expend by making the necessary changes? Good discussion to have. %>One half-baked idea I just had would be for the DHCP Relay to cache the %>data about the link-local node requesting DHCP information and then send a %>new packet (Relay->Server) requesting whatever the link-local node needs %>and including some token (meaningful to the relay) to keep straight which %>link-local node the request is for. The server would then reply directly %>to the relay, including the same token as was in the request. The relay %>would use the token to figure out which link-local node the information was %>needed by and would send a message (relay->local-node) with the reply %>information. %One of the design principles of DHCP has been to avoid requiring the relay %agent to keep any state for DHCP messages, to avoid complexity and scale %problems in the relay agent. That's not to say we couldn't use it; we've %tried to stay away from similar mechanisms in the past. I think its time to revisit our design principles for DHCPv6 at least. Keeping the state does create some knowledge but I think in this case it buys a lot. The same question about ND vs new DHCP security mechanism applies to creating state in relay-agents. Also lets remember that most DHCPv6 sites will be in private enterprise (or as they now call the "Intranet"). Security problems in this case where the nodes are not on the Internet are employee or roaming mobile node problems. In many cases I think most users will not USE security for DHCPv6 and rely on existing access controls used today. So I would like to keep DHCPv6 moving forward. But, the issue of whether relay-agents maintain state about a client affects the overall architecture and design. If we want to pursue this I can layout what exactly is the state that must be maintained? WOuld folks find this useful for the discussion? I am also getting a bit nervous that this discussion needs to happen on DHCPv6 mailing list too. So could I ask those who are interested in that discussion could they come to the DHCPv6 list or should I ask DHCPv6 to come to IPng list? /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 Jan 8 22:33:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25662; Mon, 8 Jan 96 22:33:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25656; Mon, 8 Jan 96 22:32:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16308; Mon, 8 Jan 1996 22:32:38 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id WAA00976; Mon, 8 Jan 1996 22:32:37 -0800 Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi.dat.tele.fi (8.6.12/8.6.12) with SMTP id IAA02248; Tue, 9 Jan 1996 08:30:41 +0200 Message-Id: <30F20BB8.51A8@lohi.dat.tele.fi> Date: Tue, 09 Jan 1996 08:31:20 +0200 From: Juha Heinanen Organization: Telecom Finland Inc. X-Mailer: Mozilla 2.0b4 (Win95; I) Mime-Version: 1.0 To: Dimitry Haskin Cc: "ipng@sunroof.Eng.Sun.COM" , "postel@isi.edu" , "deering@parc.xerox.com" , "hinden@ipsilon.com" , "roll@stupi.se" , Yakov Rekhter , "brian@dxcoms.cern.ch" Subject: (IPng 1049) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt References: <9601090259.AA15366@pobox.BayNetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry Haskin wrote: > The problem is that it has been felt that ATM interfaces need 64-bits > for > the interface token which is a part of the intra-subscriber field. > Since i don't understand what you mean by above. atm end stations have 48 bit mac address that uniquely identifies it. there is no difference between atm end stations and ethernet end stations in that regard. could you eleborate your point? -- juha ------------------------------------------------------------------------------ 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 Jan 8 22:48:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25674; Mon, 8 Jan 96 22:48:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25668; Mon, 8 Jan 96 22:48:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16731; Mon, 8 Jan 1996 22:47:55 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id WAA02228; Mon, 8 Jan 1996 22:47:55 -0800 Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi.dat.tele.fi (8.6.12/8.6.12) with SMTP id IAA02252; Tue, 9 Jan 1996 08:45:52 +0200 Message-Id: <30F20F47.1378@lohi.dat.tele.fi> Date: Tue, 09 Jan 1996 08:46:31 +0200 From: Juha Heinanen Organization: Telecom Finland Inc. X-Mailer: Mozilla 2.0b4 (Win95; I) Mime-Version: 1.0 To: David R Conrad Cc: Yakov Rekhter , ipng@sunroof.eng.sun.com, postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, brian@dxcoms.cern.ch, davidc@ns.iij.ad.jp Subject: (IPng 1050) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt References: <199601090048.JAA27986@ns.iij.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David R Conrad wrote: > For the poor saps in the registries, please define the criteria which > distinguishes between a provider that gets a 24 bit prefix and one > that gets a 16 bit brefix. i agree with david here. making the provider field variable length, will result in very difficult battles (most like in courts) on who gets what length prefix. you start as a small regional provider and may up as a very large national and international one. so the best thing to do is to fix the length of the provider field. the same doesn't apply to the length to the intra-subscriber field. if we say that each subscriber must always gets a three byte hierarchy component that will result in enormous waste of the address space, since by numbers the most subscribers will be home users. i, for example, have at home a router and an eight port ethernet hub, but only four of those ports are curently in use. it would not make any sense if my ip provider would need to allocate me three bytes of hierarchy to configure my home network, which never contains more than a couple of routers and 10-20 end stations even if i count everything here than runs with electricity. so i propose that we eliminate both of the reserved fields, fix the provider id field of this address format to be 2 bytes and that the hierarchy part of the intra subscriber field can be from 1 to 3 bytes long. i would like to hear what the other people on this list think about this issue. ran couldn't stay with the topic, but already changed the subject to osi and nsaps which i consider totally inappropriate to this list. -- juha ------------------------------------------------------------------------------ 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 Jan 9 00:05:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25889; Tue, 9 Jan 96 00:05:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25883; Tue, 9 Jan 96 00:05:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19057; Tue, 9 Jan 1996 00:04:44 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id AAA07994; Tue, 9 Jan 1996 00:04:44 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA22083; Tue, 9 Jan 1996 09:04:42 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA06823; Tue, 9 Jan 1996 09:04:41 +0100 Message-Id: <9601090804.AA06823@dxcoms.cern.ch> Subject: (IPng 1051) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt To: ipng@sunroof.eng.sun.com Date: Tue, 9 Jan 1996 09:04:41 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <30F1921D.5C13@lohi.dat.tele.fi> from "Juha Heinanen" at Jan 8, 96 11:52:29 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 Juha, > but i repeat, the root cause of this discussion is that we have too few > bytes in the address field. i think we should therefore seriously > consider changing the address field to 20 bytes, before inpg spec is > advanced. > have you any idea how long we argued before compromising on 16 bytes? Brian ------------------------------------------------------------------------------ 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 Jan 9 04:10:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26026; Tue, 9 Jan 96 04:10:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26020; Tue, 9 Jan 96 04:09:56 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27666; Tue, 9 Jan 1996 04:09:36 -0800 Received: from coral.bucknell.edu by venus.Sun.COM (Sun.COM) id EAA17943; Tue, 9 Jan 1996 04:09:36 -0800 Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA01391; Tue, 9 Jan 1996 07:09:31 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Jan 1996 07:09:33 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 1052) Re: ND Asst for Security Issue for DHCPv6? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:58 PM 1/8/96, bound@zk3.dec.com wrote: > 4. A new one per [DHCP authentication scheme] > Ralph Droms talking with Christian Huitema and Jeff > Schiller is to make IPSEC ignore the relay-agent field in the > creation of the secured data. Small clarification here - Jeff and Christian suggested a DHCP-specific scheme that ignores the relay-agent field, not (necessarily) a modified version of IPSEC. - 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 Jan 9 05:03:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26183; Tue, 9 Jan 96 05:03:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26177; Tue, 9 Jan 96 05:03:45 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29914; Tue, 9 Jan 1996 05:03:24 -0800 Received: from venera.isi.edu by venus.Sun.COM (Sun.COM) id FAA21940; Tue, 9 Jan 1996 05:03:24 -0800 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 Jan 1996 05:02:33 -0800 Posted-Date: Tue, 9 Jan 1996 04:58:18 -0800 (PST) Message-Id: <199601091258.AA01299@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 9 Jan 1996 04:58:18 -0800 Subject: (IPng 1053) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt To: jh@lohi.dat.tele.fi (Juha Heinanen) Date: Tue, 9 Jan 1996 04:58:18 -0800 (PST) Cc: davidc@iij.ad.jp, yakov@cisco.com, ipng@sunroof.eng.sun.com, postel@ISI.EDU, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, brian@dxcoms.cern.ch, davidc@ns.iij.ad.jp In-Reply-To: <30F20F47.1378@lohi.dat.tele.fi> from "Juha Heinanen" at Jan 9, 96 08:46:31 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > David R Conrad wrote: > > > For the poor saps in the registries, please define the criteria which > > distinguishes between a provider that gets a 24 bit prefix and one > > that gets a 16 bit brefix. > > i agree with david here. making the provider field variable length, > will result in very difficult battles (most like in courts) on who gets > what length prefix. you start as a small regional provider and may up > as a very large national and international one. so the best thing to do > is to fix the length of the provider field. > Fixed fields break CIDR. Geoff Huston has proposed a very viable solution. Providers select how big, based on cost per bit. With dynamic renumbering, when a provider grows, it renumbers to its new provider block. Whats the problem? (drc, poking the ant hill again? :) --bill ------------------------------------------------------------------------------ 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 Jan 9 05:52:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26200; Tue, 9 Jan 96 05:52:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26194; Tue, 9 Jan 96 05:51:50 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01406; Tue, 9 Jan 1996 05:51:29 -0800 Received: from VNET.IBM.COM by venus.Sun.COM (Sun.COM) id FAA25563; Tue, 9 Jan 1996 05:51:27 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2692; Tue, 09 Jan 96 08:50:37 EST Received: by RTP (XAGENTA 4.0) id 9312; Tue, 9 Jan 1996 08:50:36 -0500 Received: from rsalh1p26.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18562; Tue, 9 Jan 1996 08:51:04 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id IAA00227; Tue, 9 Jan 1996 08:49:02 -0500 Message-Id: <199601091349.IAA00227@hygro.raleigh.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1054) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Mon, 08 Jan 1996 12:29:43 PST." <199601082029.MAA21212@puli.cisco.com> Date: Tue, 09 Jan 1996 08:49:02 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, I should note that in my discussions I have been aiming for end-to-end host->server authentication using IPSec AH without the relay agent being involved. That is, host->server, not host->relay, relay->server. The latter problem is not so hard to solve, but changes the trust model and forces all relay agents to ENABLE IPSec and (more important) to distribute keys/SPIs. I'd like to avoid the need for this in the name of keeping relay agents simple. >The main thing that will run foul the IPsec model is to modify packets that >are in transit between the node adding the security header and the node >verifying/processing the security header. >If the "relay agent" securely tunnels the original packet without modifying >the original packet, all is well. My, possibly incorrect, understanding >is that DHCP "relay agents" must modify a particular field in the DHCP >header to add their own IP address so that the DHCP server knows how >to return the DHCP reply. Right. As currently defined in v6 (and as is done in v4), the relay agent adds a 'giaddr' field identifying the relay agent (and just as important) the link on which the host resides (so the server can return an address with the proper prefix). We could certainly modify the protocol so that the host obtains that information before sending a packet. That way the relay agent need not modify the packet it relays. For example, RAs could list (for example) the anycast address for the routers (relay agents) on the link, or the host could query the neighboring relay agents for that information. However, that only solves part of the problem. The other half is how does the relay agent forward the original (unmodified) packet. Issues: 1) the source/dest addresses in the original packet are link-local, so if the packet is tunneled to the server, once the outer header is removed, the internal (original) packet will be improperly scoped (e.g., refer to the link the host resides on rather than the link where the server is). The server somehow needs to figure this out (not impossible). However, it is also not clear that allowing this sort of tunneling (sending a packet beyond the scope of the tunnelled packet's source/dest addresses) is a good thing. 2) Since the packet will be processed by the relay agent, and the relay agent thinks the packet is addressed to it (it is), it will run it through its IPSec engine. This means the relay agent needs to have the proper SPI (undesirable for a requirement) and/or relay agent needs to be able to receive the packet at the application layer with the AH intact (i.e., not discarded by the stack during normal processing). My sense (and I could be wrong) is that we will not be able to assume that applications have access to the original header. Ran: what is your sense here (this is an "what will implementations do" question). Is this route a dead end? 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 Tue Jan 9 06:04:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26212; Tue, 9 Jan 96 06:04:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26206; Tue, 9 Jan 96 06:04:42 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02114; Tue, 9 Jan 1996 06:04:21 -0800 Received: from lohi.dat.tele.fi by venus.Sun.COM (Sun.COM) id GAA26865; Tue, 9 Jan 1996 06:04:21 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id QAA02926; Tue, 9 Jan 1996 16:01:19 +0200 Date: Tue, 9 Jan 1996 16:01:19 +0200 From: Juha Heinanen Message-Id: <199601091401.QAA02926@lohi.dat.tele.fi> To: bmanning@ISI.EDU Cc: davidc@iij.ad.jp, yakov@cisco.com, ipng@sunroof.eng.sun.com, postel@ISI.EDU, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, brian@dxcoms.cern.ch, davidc@ns.iij.ad.jp In-Reply-To: <199601091258.AA01299@zed.isi.edu> (bmanning@ISI.EDU) Subject: (IPng 1055) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geoff Huston has proposed a very viable solution. Providers select how big, based on cost per bit. With dynamic renumbering, when a provider grows, it renumbers to its new provider block. we are very far from means to dynamically and painlessly renumber the provider and all its clients. with this kind of scheme only the already big ones could protect themselves from the renumbering hassle. -- juha ------------------------------------------------------------------------------ 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 Jan 9 06:11:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26224; Tue, 9 Jan 96 06:11:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26218; Tue, 9 Jan 96 06:11:12 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02595; Tue, 9 Jan 1996 06:10:51 -0800 Received: from venera.isi.edu by venus.Sun.COM (Sun.COM) id GAA27355; Tue, 9 Jan 1996 06:10:51 -0800 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 Jan 1996 06:10:13 -0800 Posted-Date: Tue, 9 Jan 1996 06:05:47 -0800 (PST) Message-Id: <199601091405.AA01423@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 9 Jan 1996 06:05:47 -0800 Subject: (IPng 1056) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt To: jh@lohi.dat.tele.fi (Juha Heinanen) Date: Tue, 9 Jan 1996 06:05:47 -0800 (PST) Cc: bmanning@ISI.EDU, davidc@iij.ad.jp, yakov@cisco.com, ipng@sunroof.eng.sun.com, postel@ISI.EDU, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, brian@dxcoms.cern.ch, davidc@ns.iij.ad.jp In-Reply-To: <199601091401.QAA02926@lohi.dat.tele.fi> from "Juha Heinanen" at Jan 9, 96 04:01:19 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Geoff Huston has proposed a very viable solution. > Providers select how big, based on cost per bit. > With dynamic renumbering, when a provider grows, > it renumbers to its new provider block. > > we are very far from means to dynamically and painlessly renumber the > provider and all its clients. with this kind of scheme only the already > big ones could protect themselves from the renumbering hassle. > But this is one of the promises of IPv6. Dynamic renumbering (well, "renumbering") support was one of the design criteria. If its not there in IPv6... As to protection, I expect that the only form of addressing that provides renumbering protection is -not- provider based. -- --bill ------------------------------------------------------------------------------ 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 Jan 9 08:15:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26323; Tue, 9 Jan 96 08:15:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26317; Tue, 9 Jan 96 08:15:10 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12212; Tue, 9 Jan 1996 08:14:47 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id IAA05223; Tue, 9 Jan 1996 08:14:48 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25727; Tue, 9 Jan 96 11:12:21 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA07367; Tue, 9 Jan 96 11:12:41 EST Date: Tue, 9 Jan 96 11:12:41 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601091612.AA07367@pobox.BayNetworks.com> To: jh@lohi.dat.tele.fi Subject: (IPng 1057) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Cc: ipng@sunroof.eng.sun.com, postel@isi.edu, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, yakov@cisco.com, brian@dxcoms.cern.ch Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Juha Heinanen > > Dimitry Haskin wrote: > > > The problem is that it has been felt that ATM interfaces need 64-bits > > for > > the interface token which is a part of the intra-subscriber field. > > Since > > i don't understand what you mean by above. atm end stations have 48 bit > mac address that uniquely identifies it. there is no difference between > atm end stations and ethernet end stations in that regard. could you > eleborate your point? > > -- juha Interesting?! The last I heard an ATM interface could be identified by a 20 byte NSAP-like number or an E.164 number. It has been proposed to use 8 octets of such an ATM address to form the interface token which is used for address autoconfiguration. I refer you to the draft-ietf-ipatm-ipv6nd-00.txt and draft-ietf-addrconf-ipv6-auto-07.txt. If the IP-over-ATM WG finds way to construct 48 bit interface tokens for ATM interfaces, it is fine with me. 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 Jan 9 09:23:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26507; Tue, 9 Jan 96 09:23:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26501; Tue, 9 Jan 96 09:23:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21094; Tue, 9 Jan 1996 09:22:39 -0800 Received: from ns.iij.ad.jp by mercury.Sun.COM (Sun.COM) id JAA25755; Tue, 9 Jan 1996 09:22:38 -0800 Received: from shiosai.iij.ad.jp (shiosai.iij.ad.jp [192.244.176.35]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id CAA00733; Wed, 10 Jan 1996 02:18:01 +0900 Message-Id: <199601091718.CAA00733@ns.iij.ad.jp> To: bmanning@ISI.EDU Cc: jh@lohi.dat.tele.fi (Juha Heinanen), davidc@iij.ad.jp, yakov@cisco.com, ipng@sunroof.eng.sun.com, postel@ISI.EDU, deering@parc.xerox.com, hinden@ipsilon.com, roll@stupi.se, brian@dxcoms.cern.ch, davidc@ns.iij.ad.jp, davidc@ns.iij.ad.jp Subject: (IPng 1058) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: Your message of "Tue, 09 Jan 1996 04:58:18 PST." <199601091258.AA01299@zed.isi.edu> Date: Wed, 10 Jan 1996 02:18:01 +0900 From: David R Conrad Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, > Fixed fields break CIDR. You mean like fixed 128 bit addresses?^A^KUmm, yeah. > Geoff Huston has proposed a very viable solution. > Providers select how big, based on cost per bit. Hey, why don't we try that out with IPv4?^A^KUmm, yeah. > With dynamic renumbering, when a provider grows, > it renumbers to its new provider block. With dynamic renumbering a whole raft of problems go away, the world becomes a wonderful place, cats and dogs living in peace and harmony, etc. However, people in this thread seem to be making an assumption that renumbering is and will be far too painful for people to do, so we have to protect them from the evil greedy service providers. After all, with the Internet doubling in size every year, it is obviously much more important to lock your existing customers into your service (no, they can't use NAT/ALG, that's evil too, remember?) than to generate new customers. > Whats the problem? "Problem"? Singular? Oh, that one. For reasons not entirely clear to me, I'd like to avoid seeing the registries getting put into yet another position where everybody on the planet whines and/or threatens lawsuits at them. All I'm asking (at least in this thread) is that _if_ there is a distinction made between who gets what in terms of prefixes, please come up with some *OBJECTIVE* criteria the registries can rely on to make the appropriate decisions. > (drc, poking the ant hill again? :) No, engaging in your hobby (profession?): tilting at windmills... Regards, -drc "Everything is wonderful, until you know something about it." P.S. Insert smileys where appropriate. ------------------------------------------------------------------------------ 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 Jan 9 12:41:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26791; Tue, 9 Jan 96 12:41:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26785; Tue, 9 Jan 96 12:40:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22080; Tue, 9 Jan 1996 12:40:36 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id MAA01630; Tue, 9 Jan 1996 12:40:36 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA03785; Tue, 9 Jan 1996 12:40:34 -0800 Date: Tue, 9 Jan 1996 12:40:34 -0800 From: Ran Atkinson Message-Id: <199601092040.MAA03785@puli.cisco.com> To: dimitry_haskin@baynetworks.com Subject: (IPng 1059) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Newsgroups: cisco.external.ietf.ipng In-Reply-To: <9601090259.AA15366@pobox.BayNetworks.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601090259.AA15366@pobox.BayNetworks.com> Dimitry wrote: > The problem is that it has been felt that ATM interfaces need 64-bits for > the interface token which is a part of the intra-subscriber field. Since > a provider can not dictate which technology its subscriber may use, if the > ATM token is allowed to be 64 bits long, 64 bits is the absolute and > unreasonable minimum size of the intra-subscriber field. This size of > the intra-subscriber field is unreasonable since it does not permit > any routing hierarchy within a subscriber. So far, this makes sense, though only if one assumes that 64-bits are needed. > So a provider will need to give to a subscriber at least 8 additional bits > for the internal subneting (which is only 255 subnets). This brings the > minimum size of the intra-subscriber field to 72 bits. I guess, commonly, > 80 bits or so will need to be given to a subscriber. This follows logically from the above. >P.S. Another approach would be to limit the interface token size to 48 bits > on all medias. This is indeed begging the question. Now I was briefly involved with the ATM Forum in a previous life and I was the one who finally convinced them to use IEEE 802 MAC addresses for the station identifier portion of the NSAP-like addressing used by ATM. Hence, I know full well that ATM interfaces DO in fact have a 48-bit MAC address that they can use as a token just as Ethernet/FDDI/Token-Ring do. I suspect that the ATM people are trying to embed ATM routing topology into the low-order portion of the IPv6 address. Please someone tell me this isn't true and that there is some GOOD reason they need to put more than the 48-bit IEEE MAC address of the ATM interface into the IPv6 address. (Aside: I still think that 64-bits was way plenty of address space and I'll note that this particular silliness and abuse of address space would NEVER have happened had SIP/SIPP addressing been retained. :-) Ran rja@cisco.com PS: My related discussion with Yakov has been taken offline by me in order to spare the rest of the list a rehash of old material. ------------------------------------------------------------------------------ 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 Jan 9 13:25:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26870; Tue, 9 Jan 96 13:25:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26864; Tue, 9 Jan 96 13:25:21 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28691; Tue, 9 Jan 1996 13:25:00 -0800 Received: from mail13.digital.com by venus.Sun.COM (Sun.COM) id NAA13292; Tue, 9 Jan 1996 13:24:58 -0800 From: schulter@zk3.dec.com Received: from ralpha.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA14098; Tue, 9 Jan 1996 16:19:19 -0500 Received: from dogfish.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA20520; Tue, 9 Jan 1996 16:19:15 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA22912; Tue, 9 Jan 1996 16:19:46 -0500 Message-Id: <9601092119.AA22912@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: ipng@sunroof.eng.sun.com Cc: dhaskin@baynetworks.com (Dimitry Haskin), gja@thumper.bellcore.com Subject: (IPng 1060) Re: Max size of interface token Date: Tue, 09 Jan 96 16:19:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Grenville wrote ...] > Just as an FYI, for anyone interested, the IP-ATM working > group's first look at IPv6 over ATM is captured in the > I-D . First 'best guess' > at a suitable token size was 64 bits. > > cheers, > gja I would also like to point out that there is another proposal for IPv6 over ATM in the I-D draft-schulter-ipv6atm-framework.txt (and ps). The IP over ATM WG just started looking at IPv6 over ATM and these two I-Ds simply represent to different approaches to the problems. I expect my I-D to be updated later this month to bring it into alignment with ND-03. As for the issue of token size, I agree with Grenville that a token size of 64 bits seems most appropriate for ATM. Both our drafts call for an 8 byte token (in fact, my I-D references Grenville's since the token described is his I-D seems the most reasonable). I don't think a token size of less than 64 bits will work for ATM since a shorter token would not provide the necessary uniqueness in all cases. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 9 13:31:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26885; Tue, 9 Jan 96 13:31:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26879; Tue, 9 Jan 96 13:31:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29564; Tue, 9 Jan 1996 13:30:55 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id NAA14672; Tue, 9 Jan 1996 13:30:55 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id NAA06625; Tue, 9 Jan 1996 13:30:53 -0800 Date: Tue, 9 Jan 1996 13:30:53 -0800 From: Ran Atkinson Message-Id: <199601092130.NAA06625@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1061) Forwarding Link-local addresses In-Reply-To: <9601090340.AA25534@fwasted.zk3.dec.com> References: <199601081433.JAA00263@hygro.raleigh.ibm.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601090340.AA25534@fwasted.zk3.dec.com> Jim Bound wrote: >The relay-agent does not forward the clients link-local address the src >address is the relay-agents interface address. I am not sure what your >concern is about scoping? I don't see a scoping problem here? Can you >say more? thanks... I'm not sure how DHCP works, so I'll put DHCP aside and discuss the issue in the revised subject line and let others figure out if this issue arises with DHCP. I'm VERY nervous about people (mis- ??)using link-local addresses in address fields of packets that get forwarded off the original link. Bridging isn't a problem, its forwarding that makes me nervous. If a packet gets forwarded off-link and contains a link-local in an address field, then the address might be examined outside its scope and hence end up at the wrong place. In the case of source-routing with a link-local as the final address, there is definitely an issue figuring out what the semantics would be for the last-hop router. The fundamental problem is how to correctly forward an address that is outside its scope of definition. I think this can't be correctly done in any dependable way. My proposed solution to this is a rule that says: "Routers MUST NOT forward an IPv6 packet containing a link-local source or destination address" and "Routers MUST NOT send redirects for packets addressed to a link-local address. with its corollary for hosts: "Redirects received for link-local addresses MUST be ignored by the receiving node." and "Routers MUST NOT advertise the link-local prefix in their router advertisements." with its corollary for hosts: "Hosts MUST automatically know about the link-local routing prefix whenever they bring an interface up and Host MUST ignore any advertisement of the link-local prefix." Comments on these ?? 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 Tue Jan 9 14:34:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26979; Tue, 9 Jan 96 14:34:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26973; Tue, 9 Jan 96 14:34:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08872; Tue, 9 Jan 1996 14:34:17 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id OAA01203; Tue, 9 Jan 1996 14:34:16 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id RAA27669; Tue, 9 Jan 1996 17:34:09 -0500 Message-Id: <199601092234.RAA27669@thumper.bellcore.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1062) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: Your message of Tue, 09 Jan 1996 12:40:34 -0800. <199601092040.MAA03785@puli.cisco.com> Date: Tue, 09 Jan 1996 17:34:08 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >>This is indeed begging the question. Now I was briefly involved with the >>ATM Forum in a previous life and I was the one who finally convinced them >>to use IEEE 802 MAC addresses for the station identifier portion of >>the NSAP-like addressing used by ATM. Hence, I know full well that ATM >>interfaces DO in fact have a 48-bit MAC address that they can use as >>a token just as Ethernet/FDDI/Token-Ring do. you're forgetting that while an Ethernet interface is uniquely identified by the MAC bitstring, the IP/ATM interface is not. The ATM interface is. The key here is that _logical_ IP/ATM interfaces are being used today by including the SEL field into the picture - host internal call routing information, if you will. That's a total of 56 bits. Now add the E.164 scenario - perhaps your interfaces are only uniquely identified by a 15 digit number. BCD encoded that becomes 7.5 octets. 64 bits seemed the nearest round number. If bits are really tight then perhaps we (ipatm) drop our token down to 60 bits. (We've also noted that other 'unique' interface IDs are dynamically assigned in some IPv6/ATM models - e.g. by a MARS - which might allow a 16 bit token. However, it depends on your stomach for dynamic tokens being used to construct link local addresses.) cheers, gja ------------------------------------------------------------------------------ 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 Jan 9 15:30:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27093; Tue, 9 Jan 96 15:30:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27087; Tue, 9 Jan 96 15:30:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18074; Tue, 9 Jan 1996 15:30:25 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id PAA14834; Tue, 9 Jan 1996 15:30:24 -0800 Received: from localhost (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA13215; Tue, 9 Jan 1996 15:30:41 -0800 Message-Id: <199601092330.PAA13215@mailhost.Ipsilon.COM> X-Authentication-Warning: mailhost.Ipsilon.COM: Host localhost didn't use HELO protocol To: Bob Gilligan Subject: (IPng 1063) Re: - need for uniq ID's/PPP and identifying interfaces Cc: ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Fri, 22 Dec 1995 01:58:49 PST." Date: Tue, 09 Jan 1996 15:30:40 -0800 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I've only recently discovered that I cared about this, sorry for the late reply. >> 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 will admit I am biased towards making sure that the ability to have a BSD host do dual duty as a passable router is retained. With this in mind, and with respect to the Unix API in particular: (1) If you've been writing software for a router you've never ever been able to count on IPv4 addresses to identify interfaces (sometimes particular kernels force you to do this anyway, but this just causes interoperability problems if you try to use such a box as a router in arrangements it can't deal with). Some interfaces can be unnumbered or have non-unique local addresses (these two cases are approximately equivalent), and some of these may see identical addresses at the far end of circuits too. These cases aren't even rare. For IPv4 you have no alternative but to deal with receiving and sending interface identification using something other than protocol addresses. (2) Suppose I agree that it is in principle possible to change this for IPv6, using IPv6 protocol addresses instead. This doesn't alter the fact that I still need a non-protocol-address mechanism to deal with IPv4 (or, say, CLNP if I need to retain than, or most other protocols) in the absense of IPv6, and that this non-protocol-address mechanism would work fine for IPv6 too. Inventing a second protocol-specific mechanism for IPv6's use only doesn't seem sensible if you have have to support a protocol-neutral mechanism in any case. (3) There are other parts of a kernel API, which you haven't specified, which make using another mechanism for interface indentification highly desireable for efficiency. I would point out, for example, that the "next hop" for a multicast forwarding table entry is actually a structure which identifies an incoming interface and a list of outgoing interfaces, with the latter list conceivably numbering in the hundreds, and that these are installed in circumstances where installation speed counts. Right now I have a kernel implementation which will use interface indices for interface identification in this (and every other) context, since the multicast "next hop" becomes a bit mask a few 10's of bytes long. Your method of interface identification would appear to make it a list several kilobytes long, with code in the kernel having to compress it down (probably to the same bitmask) at the distant end of the system call. > 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 Note that user/application interface issues have only very indirect implications for what the application/kernel interface should look like, and, in particular, supporting the first command line usage in no way requires, or even makes it advantageous, that interfaces be identified to the kernel by address. In fact I think I could do a much better job of the above command line interface (for IPv4 as well, in fact) by carefully defining a system call interface to provide a convenient way to query the kernel for interface configuration and using this in a library subroutine to turn the address, or interface name, or whatever else you wanted to type on the command line, into whatever magic cookie is required to identify the related interface to the kernel. It's unnecessary that this code live in kernel space, and command-line issues are a non-argument with respect to this. And it isn't necessary that hard constraints be added which require (unique) addresses on every interface; if you want to configure your box this way, fine, but if you don't, that's fine too. How your neighbour configures his box is his business. In any event, I don't think protocol addresses are right for identifying interfaces between kernel and application. I'd also prefer not to use a sockaddr_dl since it contains stuff which is most often irrelevant. Given a choice between interface names and interface indices (or "short integer magic cookies") for use as a non-protocol-specific method I think I'd much prefer to use magic cookies at the kernel interface instead. This avoids the issue of how names should map to "interfaces", given that "interfaces" don't necessarily correspond one-to-one to physical cards in your box, and allows simple methods to be used to find interface data structures directly from magic cookies in a hurry, a concern if the number of interfaces is very large. Dennis Ferguson ------------------------------------------------------------------------------ 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 Jan 9 15:43:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27151; Tue, 9 Jan 96 15:43:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27145; Tue, 9 Jan 96 15:43:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19874; Tue, 9 Jan 1996 15:43:19 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id PAA18080; Tue, 9 Jan 1996 15:43:20 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA13617; Tue, 9 Jan 1996 15:43:01 -0800 Date: Tue, 9 Jan 1996 15:43:01 -0800 From: Ran Atkinson Message-Id: <199601092343.PAA13617@puli.cisco.com> To: gja@thumper.bellcore.com Subject: (IPng 1064) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville, The point isn't to "uniquely identify a logical interface" with the token. Its just to avoid address space collisions among the set of IPv6 link-local addresses on a (logical in the case of ATM) subnet. It appears to me that the 48-bit MAC, which IS (to my understanding) available on the ATM interface (regardless of whether that i/f has been _configured_ to use an E.164 ATM layer address), should be sufficient. Please correct my misunderstandings in detail if you think I still have some here. I'm pretty sure there is at least incomplete communication going on here. Bits are _absolutely_ an issue here and the IP/ATM group needs (IMO) to pay more attention to minimising the local token portion of the IPv6 address. Regards, 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 Tue Jan 9 15:53:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27182; Tue, 9 Jan 96 15:53:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27170; Tue, 9 Jan 96 15:53:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21193; Tue, 9 Jan 1996 15:52:46 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id PAA20568; Tue, 9 Jan 1996 15:52:47 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA14066; Tue, 9 Jan 1996 15:52:46 -0800 Date: Tue, 9 Jan 1996 15:52:46 -0800 From: Ran Atkinson Message-Id: <199601092352.PAA14066@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1065) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: <9601090431.AA27532@fwasted.zk3.dec.com> References: Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601090431.AA27532@fwasted.zk3.dec.com> Jim Bound wrote: >Also lets remember that most DHCPv6 sites will be in private enterprise >(or as they now call the "Intranet"). Security problems in this case >where the nodes are not on the Internet are employee or roaming mobile >node problems. In many cases I think most users will not USE security >for DHCPv6 and rely on existing access controls used today. So I would >like to keep DHCPv6 moving forward. One of the few things that virtually everyone concerned with The Internet agrees on is the need for good technology to make renumbering large sites a practical thing to do. If renumbering large multi-homed sites were practical to do with a downtime Order(Friday 1700 to Monday 0600) -- which is NOT currently the case, then several of us would have A LOT less heartburn over mandating provider-oriented addressing. DHCPv6 has potential to be part of the answer to the need for good renumbering technology ONLY IF it includes authentication sufficient to let the network admins use it on all the hosts and not have to worry about intruders using DHCPv6 to attack their systems. In my personal opinion, sites using DHCP at the moment would be well advised to have a DHCP-blocking firewall between their campus and The Internet. 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 Tue Jan 9 16:01:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27194; Tue, 9 Jan 96 16:01:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27188; Tue, 9 Jan 96 16:01:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22468; Tue, 9 Jan 1996 16:01:12 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id QAA22622; Tue, 9 Jan 1996 16:01:12 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id QAA14585; Tue, 9 Jan 1996 16:01:11 -0800 Date: Tue, 9 Jan 1996 16:01:11 -0800 From: Ran Atkinson Message-Id: <199601100001.QAA14585@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1066) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: <30F20F47.1378@lohi.dat.tele.fi> Reply-To: rja@inet.org References: <199601090048.JAA27986@ns.iij.ad.jp> Organization: The Internet Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <30F20F47.1378@lohi.dat.tele.fi> Juha wrote: >i agree with david here. making the provider field variable length, >will result in very difficult battles (most like in courts) on who gets >what length prefix. you start as a small regional provider and may up >as a very large national and international one. so the best thing to do >is to fix the length of the provider field. I disagree that the provider field length needs-to/should be fixed (no surprise in the audience :-). If I were a registry, I'd approximately do this: (1) allocate all providers or would-be providers a long routing prefix initially (2) I'd allocate the provider prefixes very sparsely from within my registry's prefix space so that there are unallocated gaps between all providers (3) as a particular provider _needs_ more address space because they've already allocated what's been given to them, I'd decrease the length of their routing mask, giving them a larger allocation [This is where the initial sparse allocation from the registry space is important] This treats all comers on an even basis and yet lets providers that outgrow their initial allocation get more space once they've outgrown what they have. Moreover, this will still preserve the ability to aggregate a provider's routes nicely. >so i propose that we eliminate both of the reserved fields, fix the >provider id field of this address format to be 2 bytes and that the >hierarchy part of the intra subscriber field can be from 1 to 3 bytes >long. Not a starter in my view. >i would like to hear what the other people on this list think about this >issue. ran couldn't stay with the topic, but already changed the >subject to osi and nsaps which i consider totally inappropriate to this >list. Au Contraire ! You were the one who said you wanted 20 byte addresses. I merely pointed out that CLNP already has them. Perhaps I should point out that most routers already implement CLNP so those who wish 20 byte addresses can have them today ?? Ran rja@inet.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 Tue Jan 9 16:24:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27302; Tue, 9 Jan 96 16:24:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27296; Tue, 9 Jan 96 16:24:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25692; Tue, 9 Jan 1996 16:24:05 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id QAA27967; Tue, 9 Jan 1996 16:24:05 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id QAA16002; Tue, 9 Jan 1996 16:24:03 -0800 Date: Tue, 9 Jan 1996 16:24:03 -0800 From: Ran Atkinson Message-Id: <199601100024.QAA16002@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1067) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: <199601091349.IAA00227@hygro.raleigh.ibm.com> References: <199601082029.MAA21212@puli.cisco.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199601091349.IAA00227@hygro.raleigh.ibm.com> you write: >Ran, > >I should note that in my discussions I have been aiming for end-to-end >host->server authentication using IPSec AH without the relay agent >being involved. That is, host->server, not host->relay, >relay->server. The latter problem is not so hard to solve, but changes >the trust model and forces all relay agents to ENABLE IPSec and (more >important) to distribute keys/SPIs. I'd like to avoid the need for >this in the name of keeping relay agents simple. Hmm. It looks to me that only sites that are concerned with DHCP security would need to _enable_ IPsec in their systems. That seems reasonable to me. Sites in private-only networks that trust everyone needn't enable IPsec if they don't think they need it, do they ? >Right. As currently defined in v6 (and as is done in v4), the relay >agent adds a 'giaddr' field identifying the relay agent (and just as >important) the link on which the host resides (so the server can >return an address with the proper prefix). How about this? [IPv6 hdr, Relay->Server][AH][DHCP Relay Header][tunnelled IPv6 packet, from client to server, possibly including client->server AH] The DHCP Relay Header would look roughly like this: [Next Header][Reserved] [IPv6 address of relay node] This gets the information the server needs to the server and permits both client-to-server and relay-to-server authentication. The reply from the DHCP server would look like this: [IPv6 hdr, Server->Relay][AH][tunnelled IPv6 packet addressed server->client, possibly including server->client AH] This similarly gets the information needed where it needs to go, with optional authentication on each leg. This isn't hard for the DHCP Relay to implement (all it requires is IP in IP tunneling) and doesn't add state to the relay and provides reasonable security. The main cost is the additional bandwidth due to tunneling and more parsing needed by the DHCP server. >1) the source/dest addresses in the original packet are link-local, so >if the packet is tunneled to the server, once the outer header is >removed, the internal (original) packet will be improperly scoped >(e.g., refer to the link the host resides on rather than the link >where the server is). The server somehow needs to figure this out (not >impossible). However, it is also not clear that allowing this sort of >tunneling (sending a packet beyond the scope of the tunnelled >packet's source/dest addresses) is a good thing. I'm also nervous about IP addresses leaving their scope as I noted earlier. >2) Since the packet will be processed by the relay agent, and the >relay agent thinks the packet is addressed to it (it is), it will run >it through its IPsec engine. This means the relay agent needs to have >the proper SPI (undesirable for a requirement) and/or relay agent >needs to be able to receive the packet at the application layer with >the AH intact (i.e., not discarded by the stack during normal >processing). My sense (and I could be wrong) is that we will not be >able to assume that applications have access to the original >header. Ran: what is your sense here (this is an "what will >implementations do" question). Is this route a dead end? I'm confused about the part where the packet is addressed to the Relay Agent (lack of DHCP clue on my part, my apologies)... If the packet is addressed to the Relay Agent as the final destination, the Relay Agent will indeed attempt to do the normal IPsec processing, with possibly bad consequences (a dropped packet). Upper layers do not generally have access to IP-layer mechanisms such as IPsec. In the NRL BSD implementation, which is the basis for several vendors IPsec efforts, if the checks invoked as part of ipv6_input() fail, the packet is dropped then and is not passed up at all. Oh, we've also got a key management problem here. How does a bootstrapping diskless node without a clue about its own address become aware of the appropriate Security Association to use with a DHCP Server whose address might well be equally unknown ?? The answer to this isn't clear to me. Use of DHCP for updates _after_ bootstrapping don't have a hard problem with this. Secure bootstrapping with DHCP looks like a hard, subtle problem to me. Sigh. (Aside: Those who talk freely about users renumbering when they change providers and so forth might consider that DHCP is the leading approach in sight for making renumbering practical for large campuses.) 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 Tue Jan 9 16:28:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27335; Tue, 9 Jan 96 16:28:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27329; Tue, 9 Jan 96 16:28:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26130; Tue, 9 Jan 1996 16:27:39 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id QAA28909; Tue, 9 Jan 1996 16:27:38 -0800 Subject: (IPng 1068) Re: Forwarding Link-local addresses To: rja@cisco.com, IPng Mailing list Date: Tue, 9 Jan 1996 19:28:08 -0500 (EST) From: Dan McDonald Cc: 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: <9601091928.aa28474@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm VERY nervous about people (mis- ??)using link-local addresses in > address fields of packets that get forwarded off the original link. So am I Ran! In fact, I was so concerned about it, I made sure that my hosts always send link locals only on link. Even if the default route is hit on a lookup, I special-case link-locals such that they become on-link route entries, rather than normal through-default-router entries. And yes, NRL's forwarding code just had the link-local sanity check added. (Though it's not quite on mallorn yet.) Oh, BTW, the discovery document (or is it addrconf?) already mentions that link-local prefixes MUST NOT be advertised. Thanks for the reality checks. I think I'll go cash one now. :-) 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 Jan 9 16:33:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27363; Tue, 9 Jan 96 16:33:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27357; Tue, 9 Jan 96 16:32:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26729; Tue, 9 Jan 1996 16:32:24 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id QAA00211; Tue, 9 Jan 1996 16:32:24 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id QAA16553; Tue, 9 Jan 1996 16:32:22 -0800 Date: Tue, 9 Jan 1996 16:32:22 -0800 From: Ran Atkinson Message-Id: <199601100032.QAA16553@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1069) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: <199601091401.QAA02926@lohi.dat.tele.fi> References: <199601091258.AA01299@zed.isi.edu> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Geoff Huston has proposed a very viable solution. > Providers select how big, based on cost per bit. > With dynamic renumbering, when a provider grows, > it renumbers to its new provider block. > In article <199601091401.QAA02926@lohi.dat.tele.fi> Juha wrote: > we are very far from means to dynamically and painlessly renumber the > provider and all its clients. with this kind of scheme only the already > big ones could protect themselves from the renumbering hassle. Absolutely correct. Yet you would inflict exactly that same pain on user sites ! This is a large reason why I personally have real problems with provider-oriented addressing being mandated for all sites/users and why I personally have real problems with providers being in a position to constrain how many bits users get. I've renumbered two sets of systems in my life. Both cases were very painful, even though one of them involved only about 250 nodes. Many users don't have any good method of predicting how many IP nodes they will have on campus in a few years, even when they have many current IP nodes. Who predicted in 1990 that all PCs running current versions of Windows would implement IPv4 ? Reserved bits between provider and user permit two things: (1) unanticipated user growth to be accomodated somewhat (without renumbering) by letting the user begin using some of the low-order reserved bits and shortening their user routing prefix. (2) providers add an additional unexpected user site (that is topologically near the original user :-) by consuming a few of the high-order reserved bits. Those initially reserved bits are a safety net that we will need to have. Ran rja@inet.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 Tue Jan 9 16:47:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27404; Tue, 9 Jan 96 16:47:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27398; Tue, 9 Jan 96 16:47:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28741; Tue, 9 Jan 1996 16:47:09 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id QAA03544; Tue, 9 Jan 1996 16:47:09 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id QAA17303; Tue, 9 Jan 1996 16:47:09 -0800 Date: Tue, 9 Jan 1996 16:47:09 -0800 From: Ran Atkinson Message-Id: <199601100047.QAA17303@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1070) ATM interface token for IPv6 In-Reply-To: <9601092119.AA22912@dogfish.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601092119.AA22912@dogfish.zk3.dec.com> Peter Schulter wrote: >As for the issue of token size, I agree with Grenville that a token size >of 64 bits seems most appropriate for ATM. Both our drafts call >for an 8 byte token (in fact, my I-D references Grenville's since the >token described is his I-D seems the most reasonable). I don't think a >token size of less than 64 bits will work for ATM since a shorter token >would not provide the necessary uniqueness in all cases. Could you please provide more detail ? In particular, which cases are problematic ? In particular, why is the IEEE 802 MAC token required on all interfaces by the ATM Forum UNI specification (dating back to 1992 or 1993) not sufficient for the IPv6 address token ? With more data, perhaps someone can come up with a shorter alternative. Ran rja@cisco.com PS: Subject line was changed slightly to be more clear about the topic. ------------------------------------------------------------------------------ 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 Jan 9 17:17:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27464; Tue, 9 Jan 96 17:17:59 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27458; Tue, 9 Jan 96 17:17:48 PST Received: from kandinsky by caribe.eng.sun.com (5.x/SMI-SVR4) id AA23650; Tue, 9 Jan 1996 17:16:57 -0800 Date: Tue, 9 Jan 1996 17:22:33 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1071) Re: - need for uniq ID's/PPP and identifying interfaces To: Dennis Ferguson Cc: ipng@sunroof Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dennis. I get the sense that your concerns have to do with applications such as routing daemons (e.g. routed and gated) and system administrative commands (e.g. ifconfig). The API spec that Sue, Jim and I wrote actually doesn't address that "layer" of the API. Instead, it is targetted at standard user applications such as inetd, the telnet server, FTP client, tftp client, or web server on single- or multi-homed hosts. Router functionallity was not the objective. I do think that we should define the IPv6 equivalents of ioctls like SIOCADDRT, and SIOCGIFCONF as well as the routing socket at some point, and that these APIs probably *do* need to carry something other than an IPv6 address to identify an interface. Clearly, in the IPv6 version of the SIOCSIFADDR ioctl, you need to identify the interface with something other than the address you are trying to assign to it. > > 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 > > Note that user/application interface issues have only very indirect > implications for what the application/kernel interface should look like, > and, in particular, supporting the first command line usage in no way > requires, or even makes it advantageous, that interfaces be identified > to the kernel by address. In fact I think I could do a much better job > of the above command line interface (for IPv4 as well, in fact) by carefully > defining a system call interface to provide a convenient way to query the > kernel for interface configuration and using this in a library subroutine > to turn the address, or interface name, or whatever else you wanted to type > on the command line, into whatever magic cookie is required to identify the > related interface to the kernel. It's unnecessary that this code live in > kernel space, and command-line issues are a non-argument with respect to > this. And it isn't necessary that hard constraints be added which require > (unique) addresses on every interface; if you want to configure your box > this way, fine, but if you don't, that's fine too. How your neighbour > configures his box is his business. Yes we could, if we wanted to, invent a new mechanism designed specifically to resolve names of interfaces into "interface tokens" or "unique identifiers". The advantage of the alternative I'm suggesting is that we don't have to invent such a thing; We can re-use existing functionallity. In the example above, the application can use the same function (hostname2addr()) to translate "myhost-ethernet" into the interface IPv6 address, as it does to translate "server" into the destination IPv6 address. So we don't have to invent much in the way of new API functionallity in order to deal with multi-homed hosts. > In any event, I don't think protocol addresses are right for identifying > interfaces between kernel and application. I'd also prefer not to use > a sockaddr_dl since it contains stuff which is most often irrelevant. > Given a choice between interface names and interface indices (or "short > integer magic cookies") for use as a non-protocol-specific method I think > I'd much prefer to use magic cookies at the kernel interface instead. How about using a 16-byte "magic cookie" stored in a sockaddr_in6 struct? > This avoids the issue of how names should map to "interfaces", given > that "interfaces" don't necessarily correspond one-to-one to physical > cards in your box, and allows simple methods to be used to find interface > data structures directly from magic cookies in a hurry, a concern if > the number of interfaces is very large. But if you punt on the question of how an application maps the name of an interface into its "magic cookie" or "interface index", then you have not provided a complete solution to the problem. 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 Tue Jan 9 20:25:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27638; Tue, 9 Jan 96 20:25:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27632; Tue, 9 Jan 96 20:24:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17359; Tue, 9 Jan 1996 20:24:31 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id UAA06717; Tue, 9 Jan 1996 20:24:33 -0800 Received: from localhost (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id UAA19713; Tue, 9 Jan 1996 20:24:51 -0800 Message-Id: <199601100424.UAA19713@mailhost.Ipsilon.COM> X-Authentication-Warning: mailhost.Ipsilon.COM: Host localhost didn't use HELO protocol To: Bob Gilligan Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1072) Re: - need for uniq ID's/PPP and identifying interfaces In-Reply-To: Your message of "Tue, 09 Jan 1996 17:22:33 PST." Date: Tue, 09 Jan 1996 20:24:51 -0800 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > Hi Dennis. I get the sense that your concerns have to do with > applications such as routing daemons (e.g. routed and gated) and system > administrative commands (e.g. ifconfig). The API spec that Sue, Jim and > I wrote actually doesn't address that "layer" of the API. Instead, it > is targetted at standard user applications such as inetd, the telnet > server, FTP client, tftp client, or web server on single- or multi-homed > hosts. Router functionallity was not the objective. No, in fact the functionality you need for a router is a superset of the functionality you need for a "normal" application. In particular routers need to (at least) be able to determine the arrival interface when receiving packets with recvmsg() (for nearly all packets), need to be able to specify the sending interface when sending packets with sendmsg() (for nearly all packets) and need to be able to pin connections to an interface, to operate correctly. They need to be able to do this for IPv6, IPv4 and whatever other network layer a routing protocol is running over, and they need to be able to do this independent of the address configuration (or lack thereof) of the interfaces. This is exactly the "layer" of the API which the draft specifies. So the comment still stands, this time put in terms strictly related to the draft: (1) Interface identification in sendmsg() and recvmsg() is needed by routers for protocols other than IPv6, where there is no possibility of using protocol addresses. A non-protocol-address mechanism is needed. (2) If you have a non-protocol-address mechanism to specify interfaces for other protocols it can be used for IPv6 too, using a common mechanism everywhere and with the added bonus that it is independent of the address configuration of the interfaces. The latter is an essential feature for a router, and the former is certainly desireable regardless. Boxes which are being used as routers need lots of support in addition to this, but getting interface identification right in sendmsg() and recvmsg() are necessary prerequisites and this is exactly what is addressed by your draft. And you shouldn't assume that all routing protocols which install IPv6 routes are actually running over IPv6, so you can't specify your API with IPv6-is-everything blinkers on, whatever is API is used for IPv6 needs to be useful for other protocols too even if your only aim is to obtain routes for IPv6. >> > 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 >> >> Note that user/application interface issues have only very indirect >> implications for what the application/kernel interface should look like, >> and, in particular, supporting the first command line usage in no way >> requires, or even makes it advantageous, that interfaces be identified >> to the kernel by address. In fact I think I could do a much better job >> of the above command line interface (for IPv4 as well, in fact) by carefully >> defining a system call interface to provide a convenient way to query the >> kernel for interface configuration and using this in a library subroutine >> to turn the address, or interface name, or whatever else you wanted to type >> on the command line, into whatever magic cookie is required to identify the >> related interface to the kernel. It's unnecessary that this code live in >> kernel space, and command-line issues are a non-argument with respect to >> this. And it isn't necessary that hard constraints be added which require >> (unique) addresses on every interface; if you want to configure your box >> this way, fine, but if you don't, that's fine too. How your neighbour >> configures his box is his business. > > Yes we could, if we wanted to, invent a new mechanism designed > specifically to resolve names of interfaces into "interface tokens" or > "unique identifiers". The advantage of the alternative I'm suggesting > is that we don't have to invent such a thing; We can re-use existing > functionallity. In the example above, the application can use the same > function (hostname2addr()) to translate "myhost-ethernet" into the > interface IPv6 address, as it does to translate "server" into the > destination IPv6 address. So we don't have to invent much in the way of > new API functionallity in order to deal with multi-homed hosts. Please read my comments carefully. First, there is no, repeat no, "existing functionality" which guarantees that it is possible at all to uniquely identify an interface by a protocol address if your box is a router. IPv4 certainly can't do it, for reasons I explained, and IPv6 as it is currently specified doesn't either. You need a method to specify interfaces in sendmsg(), recvmsg() and setsockopt() which does not use protocol addresses if the mechanism is going to work reliably for both protocols, independent of interface configuration, and I see no reason to expect anything less from an API. Second, I can support this command-line behaviour, for both IPv6 and IPv4, with magic-cookie sendmsg()/recvmsg()/setsockopt() interface identification as long as a kernel interface (which is needed in any case) exists to allow me to query for interface configuration at the application level. All this is doing is moving some work you would have the kernel do into an application-level libarary instead. You can't, however, reliably identify interfaces in sendmsg()/recvmsg()/setsockopt(), independent of network protocol and interface configuration, using protocol addresses. So whose API is better? >> In any event, I don't think protocol addresses are right for identifying >> interfaces between kernel and application. I'd also prefer not to use >> a sockaddr_dl since it contains stuff which is most often irrelevant. >> Given a choice between interface names and interface indices (or "short >> integer magic cookies") for use as a non-protocol-specific method I think >> I'd much prefer to use magic cookies at the kernel interface instead. > > How about using a 16-byte "magic cookie" stored in a sockaddr_in6 > struct? Okay, let's do a thought experiment. Suppose the box we're dealing with has 400 interfaces (this is not out-of-line for a router, I've configured over 200 "interfaces" on a Cisco with a 68040 processor and my big-iron unix box should't do worse than this). Let's suppose we both send packets using sendmsg(), with the "magic cookie" attached. How many cycles are going to be spent in the kernel for every packet sent determining the outgoing interface your 16-byte "magic cookie" is specifying, and what data structure are you going to use for this (repeated once per protocol)? And how many cycles will I spend, given my well-chosen-for-the-job two-byte "magic cookie" interface index, and what data structure will I use (hint: think array, repeated once per system)? If you aren't clever it may cost you substantially more to determine the interface to send each packet out of than it does to actually send the packet, and you still haven't dealt with the issue that your method can't uniquely identify IPv4 interfaces given current configuration practices, and requires unnecessary constraints on interface configuration to work with IPv6. Yet the only advantage you've been able to identify for your method is that it avoids one having to write one single user-level library function to find an interface from an address (if possible), by moving this code into the kernel instead. This doesn't seem like a good tradeoff. >> This avoids the issue of how names should map to "interfaces", given >> that "interfaces" don't necessarily correspond one-to-one to physical >> cards in your box, and allows simple methods to be used to find interface >> data structures directly from magic cookies in a hurry, a concern if >> the number of interfaces is very large. > > But if you punt on the question of how an application maps the name of > an interface into its "magic cookie" or "interface index", then you have > not provided a complete solution to the problem. I've not punted this at all. We're talking about code which finds an interface given an address in any case and the only issue is whether it is in the kernel or in a library. You need a system call to make queries about interface configuration, and you need a library routine to use it to search the interface configuration to find the address (and determine whether it uniquely identifies the interface?). The system call will need to exist anyway if there is to be any hope at all of using the box as a router sometimes, but needn't necessarily be (and traditionally hasn't been) standardized across all systems. For the library routine, call it with: ifindex_t addr2ifindex(struct sockaddr *); Add another one called like ifindex_t ifname2ifindex(char *); and you can even have your cake and eat it too. Add a third one like int ifindex2ifconfig(if_index_t, struct if_config *, if_config_len); to fetch everything you ever wanted to know about the interface given its magic cookie, and you can't go wrong. And note that all of this is protocol-independent, and imposes no unneeded constraints on interface address configuration. So what is the difficulty? Dennis Ferguson ------------------------------------------------------------------------------ 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 Jan 10 02:53:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27803; Wed, 10 Jan 96 02:53:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27797; Wed, 10 Jan 96 02:53:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04845; Wed, 10 Jan 1996 02:53:13 -0800 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id CAA12577; Wed, 10 Jan 1996 02:53:09 -0800 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 1073) Re: - need for uniq ID's/PPP and identifying interfaces To: Bob.Gilligan@Eng Date: Wed, 10 Jan 1996 10:54:19 +0000 (GMT) Cc: dennis@Ipsilon.COM, ipng@sunroof.eng.sun.com In-Reply-To: from "Bob Gilligan" at Jan 9, 96 05:22:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I do think that we should define the IPv6 equivalents of ioctls like > SIOCADDRT, and SIOCGIFCONF as well as the routing socket at some point, > and that these APIs probably *do* need to carry something other than an > IPv6 address to identify an interface. Clearly, in the IPv6 version of > the SIOCSIFADDR ioctl, you need to identify the interface with something > other than the address you are trying to assign to it. SIOCSIFADDR uses names to identify devices. There are issues for older stacks extrapolating this because pre 4.4BSD there isnt support for multiple addresses per device using SIOCAIFADDR/SIOCDIFADDR. > But if you punt on the question of how an application maps the name of > an interface into its "magic cookie" or "interface index", then you have > not provided a complete solution to the problem. I don't believe you can punt this problem. Its come up quite a bit in various common guises - both ATM and Frame Relay where a physical device presents multiple logical interfaces and also for 'interface aliases'. In these cases its hardly proved insoluble. Alan ------------------------------------------------------------------------------ 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 Jan 10 05:44:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27849; Wed, 10 Jan 96 05:44:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27842; Wed, 10 Jan 96 05:44:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10974; Wed, 10 Jan 1996 05:43:41 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id FAA27400; Wed, 10 Jan 1996 05:43:42 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA16962; Wed, 10 Jan 1996 08:36:07 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22362; Wed, 10 Jan 1996 08:36:02 -0500 Message-Id: <9601101336.AA22362@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: Ran Atkinson , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1074) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Tue, 09 Jan 96 08:49:02 EST." <199601091349.IAA00227@hygro.raleigh.ibm.com> Date: Wed, 10 Jan 96 08:36:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, THIS IS IMPORTANT: >We could certainly modify the protocol so that the host obtains that >information before sending a packet. That way the relay agent need >not modify the packet it relays. For example, RAs could list (for >example) the anycast address for the routers (relay agents) on the Relay-Agents are not ONLY routers. Relay-Agents can be Hosts running Relay-Agent daemon. I am working a proposal why Hosts should have anycast addresses and other stuff but that won't be done until Feb after the IPv6 bake off. So any RAs presented cannot only be anycast addresses for DHCPv6 unless we now change the addressing spec for hosts to be able to have anycast addresses before my proposal is complete. /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 Jan 10 06:16:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27870; Wed, 10 Jan 96 06:16:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27864; Wed, 10 Jan 96 06:16:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12700; Wed, 10 Jan 1996 06:16:12 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id GAA01938; Wed, 10 Jan 1996 06:16:13 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA24005; Wed, 10 Jan 1996 09:09:25 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24088; Wed, 10 Jan 1996 09:09:07 -0500 Message-Id: <9601101409.AA24088@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1075) Re: Forwarding Link-local addresses In-Reply-To: Your message of "Tue, 09 Jan 96 13:30:53 PST." <199601092130.NAA06625@puli.cisco.com> Date: Wed, 10 Jan 96 09:09:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, I am in synch with your points. DHCPv6 does not break this at all. 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 Jan 10 07:54:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27894; Wed, 10 Jan 96 07:54:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27888; Wed, 10 Jan 96 07:53:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21454; Wed, 10 Jan 1996 07:53:33 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id HAA19072; Wed, 10 Jan 1996 07:53:34 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA24817; Wed, 10 Jan 1996 10:30:04 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00633; Wed, 10 Jan 1996 10:29:45 -0500 Message-Id: <9601101529.AA00633@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1076) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Tue, 09 Jan 96 16:24:03 PST." <199601100024.QAA16002@puli.cisco.com> Date: Wed, 10 Jan 96 10:29:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, Date: Tue, 9 Jan 1996 16:24:03 -0800 From: Ran Atkinson >In article <199601091349.IAA00227@hygro.raleigh.ibm.com> you write: >>Ran, >> >>I should note that in my discussions I have been aiming for end-to-end >>host->server authentication using IPSec AH without the relay agent >>being involved. That is, host->server, not host->relay, >>relay->server. The latter problem is not so hard to solve, but changes >>the trust model and forces all relay agents to ENABLE IPSec and (more >>important) to distribute keys/SPIs. I'd like to avoid the need for >>this in the name of keeping relay agents simple. >Hmm. It looks to me that only sites that are concerned with DHCP security >would need to _enable_ IPsec in their systems. That seems reasonable to >me. Sites in private-only networks that trust everyone needn't enable >IPsec if they don't think they need it, do they ? I think we need IPSEC in DHCP for sure. I don't think we need other security than IPSEC. >>Right. As currently defined in v6 (and as is done in v4), the relay >>agent adds a 'giaddr' field identifying the relay agent (and just as >>important) the link on which the host resides (so the server can >>return an address with the proper prefix). >How about this? >[IPv6 hdr, Relay->Server][AH][DHCP Relay Header][tunnelled IPv6 packet, > from client to server, possibly including client->server AH] >The DHCP Relay Header would look roughly like this: > > [Next Header][Reserved] > [IPv6 address of relay node] This is good and will work. >This gets the information the server needs to the server and permits >both client-to-server and relay-to-server authentication. Yes which I like a lot. >The reply from the DHCP server would look like this: >[IPv6 hdr, Server->Relay][AH][tunnelled IPv6 packet addressed server->client, > possibly including server->client AH] > >This similarly gets the information needed where it needs to go, >with optional authentication on each leg. >This isn't hard for the DHCP Relay to implement (all it requires is >IP in IP tunneling) and doesn't add state to the relay and provides >reasonable security. The main cost is the additional bandwidth due >to tunneling and more parsing needed by the DHCP server. I like your header and strategy. There is one problem though. If the relay-node is to respond back to the client node it must know the clients link-local address. Presently we put that address in the DHCPv6 DISCOVER packet. The reason we put it in the DISCOVER packet (it can be done by the client or the relay-node actually) so when the packet returns from the server to the relay-node; the relay-node can look again into the packet and "know" what the client link-local address is on the relay-node link to send the packet. That being said and some other thought we can still avoid keeping state and anyone putting the clients link-local address anywhere by including in the tunneled packet with the relay-nodes address the clients link-local address so it can be returned to the relay-node by the server. In this manner the relay-node does not have to snoop at the actual server response to determine the clients link-local address. Then the relay-node can return the packet to the client from the server. I do have an IPSEC question though. Assuming we figure this all out OK. The relay-node when sending to the client IPv6 header will have: 1. as src address the relay-node IPv6 address. 2. as dst address the clients link-local address. The relay-node will not touch the server AH packet in our scenario so far. But because the relay-node packet to the client uses the relay-node src address and not the servers will the AH packet authenticate correctly at the client node? Thanks >>1) the source/dest addresses in the original packet are link-local, so >>if the packet is tunneled to the server, once the outer header is >>removed, the internal (original) packet will be improperly scoped >>(e.g., refer to the link the host resides on rather than the link >>where the server is). The server somehow needs to figure this out (not >>impossible). However, it is also not clear that allowing this sort of >>tunneling (sending a packet beyond the scope of the tunnelled >>packet's source/dest addresses) is a good thing. >I'm also nervous about IP addresses leaving their scope as I noted earlier. The server does not have to figure out anything (when its remote and getting packets from relay-agents) about the client address. One because the server knows that the packet is coming from a relay-node because the relay-agent address has an entry in the packet (though this logic may change per these discussions). But the server treats the packet from the relay-node as a packet that is being forwarded on behalf of the client not "from" the client. So no scoping rules are broken in IPv6. The only reason the client link-local address is being discussed is so that the relay-node when getting messages back from the server can forward the packet to the client node. The link-local address is not used by the server or the relay-node to determine any scoping or address semantics for sending packets on the network. I am beginning to think that the DHCPv4 model needs to be changed for DHCPv6. Here is why. First the client in IPv6 now can communicate on the link (LAN) immediately with a link-local address and is one of the benefits in the IPv6 architecture. Second we have defined a MUST security model for implementors of IPv6 (though users MAY NOT USE). Here is what I suggest: That the relay-nodes keep state about clients. Why? Because in this case we no longer need to keep fields in the packet for relay-agent address or the client address. All packet to servers from relay-nodes to servers become "IPv6-in-IPv6 tunneled Packets" or we figure out a way to add another option to packets going to servers from relay-nodes. Also the client link-local address really does not have to be passed to the server from the relay-node becuase the server does not really need it as it is making is client-server bindings with a bonified properly scoped IPv6 address it sending to the client via the relay-node (all the transaction semantics et al are in DHCPv6 and we should not discuss that here but on DHCPv6 list). So this can be done in two ways. 1. Keep a binding for the client link-local address at the relay-node in the node that does this for the link (not a big deal it can be implemented in a number of ways). 2. Pass the client link-local to the server and then back to the relay-node in destination option. I don't like this for security reasons and I believe it less complex to do #1 above. This strategy permits: 1. A very clean way to tunnel packet to servers with IPSEC per Ran's headers above (I think). 2. It reduces the size of the "defined" DHCPv6 packet by 32 bytes which is a good savings for many reasons. 3. Its a solution with a comprise to all nodes concerned. But: I am still not clear on the question to Ran above on the security association at the client end when the relay-node uses its src address for the packet to the client when all other AH data MAY be based on the remote-servers src address? I simply don't know the answer? >>2) Since the packet will be processed by the relay agent, and the >>relay agent thinks the packet is addressed to it (it is), it will run >>it through its IPsec engine. This means the relay agent needs to have >>the proper SPI (undesirable for a requirement) and/or relay agent >>needs to be able to receive the packet at the application layer with >>the AH intact (i.e., not discarded by the stack during normal >>processing). My sense (and I could be wrong) is that we will not be >>able to assume that applications have access to the original >>header. Ran: what is your sense here (this is an "what will >>implementations do" question). Is this route a dead end? >I'm confused about the part where the packet is addressed to the Relay >Agent (lack of DHCP clue on my part, my apologies)... >If the packet is addressed to the Relay Agent as the final destination, the >Relay Agent will indeed attempt to do the normal IPsec processing, with >possibly bad consequences (a dropped packet). Upper layers do not >generally have access to IP-layer mechanisms such as IPsec. In the NRL BSD >implementation, which is the basis for several vendors IPsec efforts, if >the checks invoked as part of ipv6_input() fail, the packet is dropped then >and is not passed up at all. I think my question about the relay-node src address will get us closer to resolving this aspect of the problem. >Oh, we've also got a key management problem here. How does a bootstrapping >diskless node without a clue about its own address become aware of the >appropriate Security Association to use with a DHCP Server whose address >might well be equally unknown ?? The answer to this isn't clear to me. >Use of DHCP for updates _after_ bootstrapping don't have a hard problem >with this. Secure bootstrapping with DHCP looks like a hard, subtle >problem to me. Sigh. I think we have a key management problem as Eric Nordmark pointed out. Do we now need Key Management servers on "every" link? And if the client comes up at bootstrap to first locate an address should it first use its link-local address to get necessary data from the Key Management server? This is a real problem and discussion I am not sure there is an answer for yet in the IETF? Ran: Could we have special key management software in our implementations that we would seed (not sure thats the right term) for each node when it first comes up to define what is needed for IPSEC just to do address configuration. Or is this just too wild of an idea? >(Aside: Those who talk freely about users renumbering when they change > providers and so forth might consider that DHCP is the leading > approach in sight for making renumbering practical for large > campuses.) I agree. I also envision using DHCPv6 as a vehicle to work with my provider to renumber. In other words I would set up a server at my provider to seed all the necessary prefixes for my border nodes to the provider as one wild arse guess on something I am thinking a lot about these days. Also I really believe DHCPv6 should be able to some how as an "option" give addresses to routers but that is another discussion or something implementor may do anyway with their router vendors as system integrators. p.s. I am sending this note in another message to the DHCPv6 WG folks so they know this discussion is going on to see if we are missing any wisdom from that set of implementors too. thanks for working on this with us its appreciated, /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 Jan 10 08:39:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27942; Wed, 10 Jan 96 08:39:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27936; Wed, 10 Jan 96 08:38:59 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25983; Wed, 10 Jan 1996 08:38:36 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id IAA29500; Wed, 10 Jan 1996 08:38:38 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id IAA11372; Wed, 10 Jan 1996 08:36:06 -0800 Date: Wed, 10 Jan 1996 08:36:06 -0800 From: Ran Atkinson Message-Id: <199601101636.IAA11372@puli.cisco.com> To: bound@zk3.dec.com Subject: (IPng 1077) Re: ND Asst for Security Issue for DHCPv6? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % THIS IS IMPORTANT: % % >We could certainly modify the protocol so that the host obtains that % >information before sending a packet. That way the relay agent need % >not modify the packet it relays. For example, RAs could list (for % >example) the anycast address for the routers (relay agents) on the % % Relay-Agents are not ONLY routers. Relay-Agents can be Hosts running % Relay-Agent daemon. I am working a proposal why Hosts should have % anycast addresses and other stuff but that won't be done until Feb after % the IPv6 bake off. So any RAs presented cannot only be anycast % addresses for DHCPv6 unless we now change the addressing spec for hosts % to be able to have anycast addresses before my proposal is complete. Jim, If a node forwards packets, then its a router. A "host" (sic) that forwards DHCP request/response packets is really a "router". Now it might or might not be a conforming router in the context of the Router Requirements spec, but that is an entirely separate issue. Please lets avoid confusing the precise IETF terms for things with the customary uses of certain commercial products. If I understand correctly, Geert is using BSDI Pentium boxes for his routers to give a concrete example :-). 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 Wed Jan 10 09:03:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28000; Wed, 10 Jan 96 09:03:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27994; Wed, 10 Jan 96 09:03:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29092; Wed, 10 Jan 1996 09:03:03 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA06325; Wed, 10 Jan 1996 09:03:03 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA12380 for ipng@sunroof.eng.sun.com; Wed, 10 Jan 1996 09:03:02 -0800 Date: Wed, 10 Jan 1996 09:03:02 -0800 From: Ran Atkinson Message-Id: <199601101703.JAA12380@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1078) Re: ND Asst for Security Issue for DHCPv6? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % I think we need IPSEC in DHCP for sure. I don't think we need other % security than IPSEC. I'm not so sure, but that might be because I'm not a DHCP person. % This is good and will work. I'm not sure it works. The problem is that the relay needs to know which link the tunneled packet should be forwarded to. This goes back to my earlier stated anxiety about ever having a link-local address in a packet that leaves the link. More thought is needed. % I like your header and strategy. There is one problem though. If the % relay-node is to respond back to the client node it must know the % clients link-local address. Presently we put that address in the DHCPv6 % DISCOVER packet. The reason we put it in the DISCOVER packet (it can be % done by the client or the relay-node actually) so when the packet % returns from the server to the relay-node; the relay-node can look again % into the packet and "know" what the client link-local address is on the % relay-node link to send the packet. Sigh. The relay also needs to keep track of which link that link-local is attached to and there is no guarantee that 2 separate links won't happen to have nodes with the same link-local address (being separate links, this is OK). So I don't think IP tunneling works because of the link-local address being referenced outside its scope. Of all people, I should have caught this before sending the original note. My apologies. % That being said and some other thought we can still avoid keeping state % and anyone putting the clients link-local address anywhere by including % in the tunneled packet with the relay-nodes address the clients % link-local address so it can be returned to the relay-node by the % server. In this manner the relay-node does not have to snoop at the % actual server response to determine the clients link-local address. Then % the relay-node can return the packet to the client from the server. I think this still has the problem relating to forwarding link-local addresses outside of their scope. Please see above. Sigh. % I do have an IPSEC question though. % % Assuming we figure this all out OK. The relay-node when sending to the % client IPv6 header will have: % % 1. as src address the relay-node IPv6 address. % 2. as dst address the clients link-local address. % % The relay-node will not touch the server AH packet in our scenario so % far. But because the relay-node packet to the client uses the % relay-node src address and not the servers will the AH packet % authenticate correctly at the client node? Thanks I forget what the packet looks like, so I'm not sure. If you mean that the relay->client packet is [IP, relay->client][AH][IP, server->client][AH][DHCP response] then (assuming the client didn't use a link-local address and hence the relay knew how to forward the packet), The client accepts the packet from the network, authenticates that it came from the relay. Sets the M_AUTHENTIC bit in the mbuf chain. Now sees the next header is a tunneled IP packet and that the inner src is != the outer src so it clears the M_AUTHENTIC bit from the mbuf chain (to prevent a forged tunnel attack). Now it processes the inner packet, sees and processes AH successfully and sets the M_AUTHENTIC bit and passes the data up to the DHCP application. (M_AUTHENTIC is an mbuf flag) % >I'm also nervous about IP addresses leaving their scope as I noted earlier. % % The server does not have to figure out anything (when its remote and % getting packets from relay-agents) about the client address. One % because the server knows that the packet is coming from a relay-node % because the relay-agent address has an entry in the packet (though this % logic may change per these discussions). But the server treats the % packet from the relay-node as a packet that is being forwarded on behalf % of the client not "from" the client. So no scoping rules are broken in % IPv6. The only reason the client link-local address is being discussed % is so that the relay-node when getting messages back from the server can % forward the packet to the client node. The link-local address is not % used by the server or the relay-node to determine any scoping or address % semantics for sending packets on the network. Let me explain. There is, I think, a scoping violation with the link-local. The DHCP relay is forwarding the reply packet from _outside_ the scope of the destination address. Picking which of several possible interfaces is the right link for that particular link-local address can't dependably be done because each link might have the same valid link-local address (probably each for a different node since they are different links). % That the relay-nodes keep state about clients. Why? Because in this % case we no longer need to keep fields in the packet for relay-agent % address or the client address. All packet to servers from relay-nodes % to servers become "IPv6-in-IPv6 tunneled Packets" or we figure out a way % to add another option to packets going to servers from relay-nodes. % Also the client link-local address really does not have to be passed to % the server from the relay-node becuase the server does not really need % it as it is making is client-server bindings with a bonified properly % scoped IPv6 address it sending to the client via the relay-node (all the % transaction semantics et al are in DHCPv6 and we should not discuss that % here but on DHCPv6 list). % % So this can be done in two ways. % % 1. Keep a binding for the client link-local address at the relay-node % in the node that does this for the link (not a big deal it % can be implemented in a number of ways). I need to think some more, but I prefer this to option 2 below at first glance. % 2. Pass the client link-local to the server and then back to the % relay-node in destination option. I don't like this for % security reasons and I believe it less complex to do #1 % above. I don't like this because of the scoping violation. % >Oh, we've also got a key management problem here. How does a bootstrapping % >diskless node without a clue about its own address become aware of the % >appropriate Security Association to use with a DHCP Server whose address % >might well be equally unknown ?? The answer to this isn't clear to me. % >Use of DHCP for updates _after_ bootstrapping don't have a hard problem % >with this. Secure bootstrapping with DHCP looks like a hard, subtle % >problem to me. Sigh. % % I think we have a key management problem as Eric Nordmark pointed out. % Do we now need Key Management servers on "every" link? And if the % client comes up at bootstrap to first locate an address should it first % use its link-local address to get necessary data from the Key Management % server? This is a real problem and discussion I am not sure there is an % answer for yet in the IETF? Not sure. Part of the problem here is that Security Associations are between/among IP addresses rather than domain names. So how do we use an address-oriented technique off-link before we have a globally routable address ? This seems like a classic chicken-egg problem. % Ran: Could we have special key management software in our % implementations that we would seed (not sure thats the right term) for % each node when it first comes up to define what is needed for IPSEC just % to do address configuration. Or is this just too wild of an idea? One approach it to manually configure a public/private key pair into each node for it to use AND to also configure a public key that can be used to authenticate DNS responses. Then use AH with an asymmetric algorithm using those public/private keys. This is still some manual configuration per box, but not a lot compared with the present. This is too hard. :-( 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 Wed Jan 10 09:10:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28012; Wed, 10 Jan 96 09:10:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28006; Wed, 10 Jan 96 09:10:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00047; Wed, 10 Jan 1996 09:09:41 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id JAA08407; Wed, 10 Jan 1996 09:09:42 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA01802; Wed, 10 Jan 1996 09:09:42 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1390828644==_============" Date: Wed, 10 Jan 1996 09:10:53 -0800 To: minutes@cnri.reston.va.us From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1079) IPng December Meeting Minutes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --============_-1390828644==_============ Content-Type: text/plain; charset="us-ascii" December meeting minutes are attached. Bob --============_-1390828644==_============ Content-Type: text/plain; name="IPng-Meeting.Dec95"; charset="us-ascii" Content-Disposition: attachment; filename="IPng-Meeting.Dec95" IPng W.G. Dallas IETF December 5 & 7, 1995 Working Group Chairs: Steve Deering / Xerox PARC Bob Hinden / Ipsilon Networks Minutes written by Bob Hinden (hinden@ipsilon.com) ---------------------------------------------------------------------- ---------------------------------------------------------------------- Agenda ------- Bash Agenda Status of Base set of Docs Status of WG Last Called Docs Changes in IPv6 and ICMP Specs Status of other IPv6-over-Foo Docs Token Ring FDDI PPP ATM other Multi-Homed Hosts Unique link-local address other issues PMTU Discovery Tunneling specification Anycast usage by Hosts API Specification ICMP Echo Response Truncation What Pieces are Left? FTP Header compression Multicast (son of RFC1112 Multihoming Routing Protocols MIBs (many?) Service Location Protocol IPng Area Conclusion Status of 6-Bone / Testing & Deployment Status of Implementations ---------------------------------------------------------------------- ---------------------------------------------------------------------- Introduction ------------ Steve Deering introduced meeting. He reviewed the agenda and asked for additional topics to be added to agenda. Status of Base set of Docs ------------------------------ Bob Hinden reviewed status of the base documents. The following documents were approved by the IESG and as of last week are at the RFC editor waiting for publication as RFC's: Proposed Standard "Internet Protocol, Version 6 (IPv6) Specification" "IP Version 6 Addressing Architecture" "DNS Extensions to support IP version 6" "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Informational RFC "An Architecture for IPv6 Unicast Address Allocation" After the meeting the RFC Editor indicated he expects to release these documents as RFC's by the end of the year. The following documents were previously recommended by the working group to be published as RFC with the indicated status: Proposed Standard "An IPv6 Provider-Based Unicast Address Format" Experimental "IPv6 Testing Address Allocation" The IESG did not approve these documents. The IPng w.g. chairs have written and sent (with a cc: to the IPng w.g.) a response to the IESG comments. The reply responds to the issues raised by the IESG which the chairs believe represents a misunderstanding with the motivation behind the design choices. The IPng working group chairs believe that these document should go forward. Status of WG Last Called Docs ----------------------------- The following documents have completed working group last call: "A Method for the Transmission of IPv6 Packets over Ethernet Networks "Neighbor Discovery for IP Version 6 (IPv6)" There were no comments received during the last call or at the meeting. The chairs will forward these documents to the IPng Area Directors with a recommendations that they become Proposed Standards. Changes in IPv6 and ICMP Specs ------------------------------- Steve Deering summarized the editorial changes and protocol changes agreed to by the working group at the Stockholm IETF meeting which made to these documents as part of submitting them to the RFC editor. IPv6 ---- 1) Headers and options must be processed in order, not in the order picked by receiver. Important to preserve semantics specified by sender and to make it easier to add new kinds of headers and options in the future. There are security issues in how headers/options are processed, but options must still be processed in order. 2) Description of jumbo payload options made clearer. Length includes length of header and all options. 3) Routing header changed to allow final destination to skip the routing header if it does not know about a new type of routing header. This was agreed to at the Stockholm meeting. Also added examples and text to describe how the routing header should be processes. 4) Fragmentation section augmented with additional text to describe how it works and how suggested mechanisms work. 5) Added requirement that all nodes must be able to reassemble packets 1500 bytes long. Min MTU still 576. ICMP ---- 1) Deleted description of Pseudo header and replace it with a pointer to the pseudo header in the base IPv6 document. Status of other IPv6-over-Foo Docs ---------------------------------- FDDI: Same state as Ethernet. Ready to do last call. Working group chairs will issue working group last call. Token Ring: Status unknown. Author did not attend. Will check with author then do a last call. PPP: Need to get a code point. Document editor will ask Internet AD to get a code point. Dimitry Haskin will write a IPv6overPPP document. ATM: Work going on in IPoverATM w.g. There are several proposals. Other: AppleTalk? HIPPI? FiberChannel? Discussion about AppleTalk. There is a old working group and a draft (expired?). We need to find this draft and do a IPv6overAppleTalk version. Chairs will talk to Internet AD's. AppleTalk Forum may have started doing an IPv4 version, but did not complete it. This document appears to be harder to write than the Ethernet/FDDI versions. Brian C. this is an IPv6overPropritary protocol, maybe we don't have to worry about it. Deering mentioned that Appletalk was the reason to have 576 MTU. It would be very unfortunate if we don't end up doing IPv6 over Appletalk. Running IP over Appletalk is also very common. No plan to do IPv6 over SLIP. Multihomed Hosts ---------------- Multihomed hosts need to have an unique interface token for of their interfaces on the same link. One way to accomplishing this is to add a unique value (such as an interface number) to link local address. There was not a consensus on this approach. A number of questions and issues were raised, and further discussion was deferred to the mailing list. KRE said w.g. need to define what bits are in the address format. Does not need to define the contents of the field. Nordmark said that it was not clear what is the advantage of this approach. Doesn't think this would make multihomed easier. It was also pointed out this approach has a conflict with duplicate detection in ND. Gilligan mentioned that new API spec. has some features with make multihomed easier. The feature depends on each interface having unique addresses (not same link local address). KRE said he was not sure the API interface alone is sufficient to solve this problem. Long discussion. Important to have overall solution. This proposal only helps host differentiate it's own interface address. It does not help host know which interface to use when going to a specific off link destination. No consensus on this approach. We need a document which covers the whole issue. KRE agreed to write a draft. Dan McDonald, Jim Bound (and other people from Digital) are also working on a multihomed proposal. Suggestion that this should also cover multiple interfaces on same link. PMTU Discovery / Jack McCann ---------------------------- Started with RFC1191. Took out IPv4 specific pieces which include: router specification DF bit TCP MSS old stype DGTP messages plateau tables What is left: definition of path : src, dest, flow-id, routing header info Packet too big message detecting MTU increases (timers) implementation suggestions This document also applies to multicast. Note need to do PathMTU discovery for local link destinations. No issues raised. Chairs will do a working group last call when next version of the internet draft is out. Anycast usage by Hosts ----------------------- Currently anycast addresses can only be assigned to routers. Discussion on mailing list about also assigning anycast addresses to hosts. Anycast are desirable powerful tool, but are also dangerous due to scaling problems. What is next step to use? Currently hosts can not be members of anycast groups because routing system needs to learn about anycast addresses. Hosts do not currently participate in routing protocols. Proposal on list to use an extension to the IGMP protocol for hosts to tell routers what anycast addresses they have (similar to the way they tell routers which multicast addresses they). The working group like this proposal. It might not even have to define any new messages, though it may not fit exactly. The larger questions is how to distribute this information around routing system? A good next step is a write a document describing how hosts should tell routers which anycast addresses a host has. First step should be how host should use these address, not how to inject into routing system. Someone should write a specification. Working group is inviting a document to be written. API Specification / Bob Gilligan -------------------------------- Reviewed detailed changes in new version of document. Changes from previous version of the document include: - Changed u_long and u_short types in structures to u_int32_t and u_int16_t for consistency and clarity. - Added implementation-provided constants for IPv4 and IPv6 text address buffer length. - Defined a set of constants for subfields of sin6_flowid and for priority values. - Defined constants for getting and setting the source route flag. - Define where ansi prototypes for hostname2addr(), addr2hostname(), addr2ascii(), ascii2addr(), and ipv6_isipv4addr() reside. - Clarified the include file requirements. Say that the structure definitions are defined as a result of including the header file , not that the structures are necessarily defined there. - Removed underscore chars from is_ipv4_addr() function name for BSD compatibility. - Added inet6_ prefix to is_ipv4_addr() function name to avoid name space conflicts. - Changes setsockopt option naming convention to use IPV6_ prefix instead of IP_ so that there is clearly no ambiguity with IPv4 options. Also, use level IPPROTO_IPV6 for these options. - Made hostname2addr() and addr2hostname() functions thread-safe. - Added support for sendmsg() and recvmsg() in source routing section. - Changed in_addr6 to in6_addr for consistency. - Re-structured document into sub-sections. - Deleted the implementation experience section. It was too wordy. - Added argument types to multicast socket options. - Added constant for largest source route array buffer. - Added the freehostent() function. - Added receiving interface determination and sending interface selection options. - Added definitions of ipv6addr_any and ipv6addr_loopback. - Added text making the lookup of IPv4 addresses by hostname2addr() optional. A few issues were brought up in the resulting discussion: - Matt Thomas suggested that in addition to the global variables ipv6addr_any and ipv6addr_loopback, systems should also provide constants for that can be used for initializing IPv6 address variables to these values. - A number of people suggested that systems should be allowed to use the all-zeros IPv6 address as the value for ipv6addr_any. - Erik Nordmark suggested that the return parameter to the hostname2addr() function be changed to include the address lifetime (TTL) which is stored with the address in the DNS. This would provide applications with the information they need to know when to stop using an address. Bob agreed to make these changes and re-issue the internet-draft. After that, a working group last-call will be held to promote the specification to Informational RFC. ICMP Echo Response Truncation ------------------------------ Text should be changed suggest to hosts should try to send back all data. Document editor will talk to RFC editor to see if this change can be made before RFC is published. [Should I include this section] What Pieces are Left? --------------------- This working group should deal with: FTP, header compression, multicast, multihoming, Brian Carpenter suggested we look at list in RFC 1752 for topics to be addresses. FTP Discussion about using FooBAR. Some input that might be better to include names instead of addresses. Needs to be looked at again. Routing Protocols RIP, OSPF, IDRP, InterDomain (IDRP or BGPng), Multicast Routing? MIBs Dimitry Haskin has a private MIB for v6, is willing to propose it to the w.g. IESG started working group in internet area to do IPv6 MIBs. Dave Arneson is chair of this group. Name of group is ipv6-mib w.g. Subscribe by sending email to: ip6mib-request@research.ftp.com There is a document archive at: ftp://research.ftp.com/pub/ip6mib/archive Service Location Important for plug and play operation. Current working group working on service for IPv4. Charlie Perkins thinks it would be easy to adapt for IPv6. Some question about using names instead of address in service location protocol. Deering suggest when group produces protocol for IPv4, we should look at it see how it applies to IPv6. Mobility Assigned to Mobile IP group. Our goal is that every IPv6 host can be mobile and know how to talk to a mobile host. Nice to eliminate triangle routing problem too. Charlie Perkons has written a draft. Dynamic DNS New Lifetimes in DNS The issue is whether we need lifetime fields in the DNS to handle renumbering or if it is sufficient to overload the cache TTL values for this purpose. A second point/question was whether the standard gethostbyname()-type API routines should be changed to return a TTL as well, so applications could determine how long the addresses they cache are valid. Tunneling Specification / Alex Conta ------------------------------------- Presented model for IPv6 tunnels, each tunnel is only one directions. Showed effect on protocol modules and packet flows through system. Specification does not have any association between hop-limit of encapsulated packet and tunnel header. Results in having to limit number of recursive encapsulations because it will not detect tunnel routing loops. Discussion on how tunnel destination option works. Some question if it is really necessary. Continuing working on this on the mailing list then do a last call. ---------------------------------------------------------------------- Thursday ---------------------------------------------------------------------- Status of IPng Area ------------------- Steve Deering reported on lunch meeting w/ IPng area directors and Internet Area and Routing AD on discussion when IPng area concludes. Then the IPng working groups will move into appropriate area. IPng will move into Internet area. AddrConf will conclude and work will move into IPng working group. NG-Trans will move into Ops area. Sue Thompson will be primary AD for the IPng working group. Working group also thanked Scott Bradner and Allison for their work as Internet AD's. They did a great job! Implementation Status / Questions --------------------------------- SD mentioned again the importance of IPv6 extension headers be processed in order. To subscribe to IPv6 Implementors list send email to: ipv6imp-request@munuari.oz.au Request to add notice of this list in IPng list mail signatures, in the charter, and on the IPng web pages. IPng bakeoff will be held February 6-10 at the University of New Hampshire. There is a small charge to cover food and other minor expenses. IPv4 mobility group approved the general direction of IPv6 mobility specification. It is important that every IPv6 node support mobility. Time for Implementors to look at current draft. Charlie Perkins described the features of this draft. IPv6 Mobility draft written by Perkins. Deering suggested that it would be good for current routers to be assigned native IPv6 address and set up tunnels to other similar nodes. Dimitry Haskin asked if any provider wanted to donate any links for IPv6 native testing. Jim Bound reported that he thought that ISI will do a RIPng and IDRP. Deering mentioned the test address allocation document and suggest that people use it to get native IPv6 addresses. Suggestion to add list of current IPv6 hosts on IPng web page. Bill Manning had previously volunteered to do initial IPv6 DNS. Bob Hinden volunteered to have people install machines at Ipsilon to be on the Internet. Geert Jan de Groot, RIPE NCC, volunteered to become the first root server for the IPv6 6-BONE. Discussion of approach to use a new root domain for experimentation. Goal of group is to set up 6-BONE by the next IETF meeting. Discussion about what IPv6 features should be tested during interoperability testing. The group came up with the following list: o Base IPv6 o Option Processing o Fragmentation & Reassembly o MTU Discovery (unicast & multicast) o Routing Header handling o Authentication Header o ESP Header o Neighbor Discovery - Router Discovery - Address Resolution (normal & proxy) - Redirects - Prefix Discovery - Auto-Configuration - Duplicate Detection - Neighbor Unreachability Detection o Transition - Dual IP stack selection - Configured Tunnels - Automatic Tunnels o Multicast (sending, receiving, ICMP) o DNS Resolver o Routing - Unicast - Multicast o Applications - Ping - Telnet - FTP - email - NFS - vat - traceroute - X11 - WWW / HTTP o BSD API o ICMP Error generation and processing o No Next Header This list will be posted on the implementations mailing list and Implementors should respond with which thing they can be ready to test in February at UNH. The current Implementors meet and came up with the following subset of features they thought could be ready for testing in February at UNH: - base ipv6 - option processing - fragmentation and reassembly - mtu discovery (unicast and multicast) - routing header handling - authentication - esp (not) - router discovery - address resolution (but no proxy yet) - redirects - prefix discovery - stateless autoconfig - duplicate detect - nud - stack selection for dual IP (not an interoperability issue) - configured tunnels - automatic tunneling - multicast (sending, receiving, icmp) (yes, optional for icmp) - dns resolver (over v4) (optional, or /etc/hosts6) - bsd api (by porting a simple application) - ICMP error generation and processing (yes, exercised by testing program) - no next header - unicast routing (static, then RIP by February) Test applications: - ping, traceroute - telnet, ftp (with foobar), email - vat/ ivs - multicast version of rwhod, mping, mtest... ------------------------------------------------------------------------ ------------------------------------------------------------------------ --============_-1390828644==_============-- ------------------------------------------------------------------------------ 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 Jan 10 09:39:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28062; Wed, 10 Jan 96 09:39:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28056; Wed, 10 Jan 96 09:39:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03678; Wed, 10 Jan 1996 09:39:16 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id JAA16366; Wed, 10 Jan 1996 09:39:16 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA11850; Wed, 10 Jan 1996 12:32:43 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16123; Wed, 10 Jan 1996 12:32:24 -0500 Message-Id: <9601101732.AA16123@fwasted.zk3.dec.com> To: Ran Atkinson Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 1080) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Wed, 10 Jan 96 12:13:43 EST." <9601101713.AA13652@fwasted.zk3.dec.com> Date: Wed, 10 Jan 96 12:32:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually the relay-node is more of an "application gateway". /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 Jan 10 09:54:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28128; Wed, 10 Jan 96 09:54:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28122; Wed, 10 Jan 96 09:54:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06338; Wed, 10 Jan 1996 09:53:51 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id JAA20615; Wed, 10 Jan 1996 09:53:53 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA24515; Wed, 10 Jan 1996 12:44:35 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17254; Wed, 10 Jan 1996 12:44:33 -0500 Message-Id: <9601101744.AA17254@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1081) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Wed, 10 Jan 96 09:03:02 PST." <199601101703.JAA12380@puli.cisco.com> Date: Wed, 10 Jan 96 12:44:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, Just on identifying the case where a relay-node receives multiple messages on "two" different links and those link-local addresses are the same. We discussed this in the DHCPv6 WG. The way around this is for the relay-node to record the interface IPv6 global address for each interface the message came in on for each link: So: relay-node: link#1 is 1::2 link#2 is 4::5 client on link#1 sends link-local of FE80::x. client on link#2 sends link-local of FE80::x. relay-node treats them as two-tuple (just for this example other tuples may be needed or could be used by an implementation): client on link#1 is (1::2, FE80::x). client on link#2 is (4::5, FE80::x). Assumptions are: 1. link-local addresses are not duplicated on a link. 2. relay-node has IPv6 Global (site, org, or global) addresses for the interfaces its listens for clients upon. Other issues in your mail I need to go ponder a bit and can't do off the top of my head. Got to go back to my day job now too. 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 Jan 10 10:23:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28534; Wed, 10 Jan 96 10:23:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27877; Wed, 10 Jan 96 07:32:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19171; Wed, 10 Jan 1996 07:32:32 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id HAA14899; Wed, 10 Jan 1996 07:32:33 -0800 Received: from munin.fnal.gov ("port 1894"@munin.fnal.gov) by FNAL.FNAL.Gov (PMDF V5.0-4 #3998) id <01HZU9Q5TY6C0001M5@FNAL.FNAL.Gov>; Wed, 10 Jan 1996 09:32:19 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA02646; Wed, 10 Jan 1996 09:30:35 -0600 (CST) Date: Wed, 10 Jan 1996 09:30:34 -0600 From: Matt Crawford Subject: (IPng 1082) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt In-Reply-To: "09 Jan 96 16:01:11 PST." <199601100001.QAA14585@puli.cisco.com> To: rja@inet.org Cc: ipng@sunroof.eng.sun.com Message-Id: <9601101530.AA02646@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{ If I were a registry, I'd approximately do this: > [description of allocation from-the-left] I think that's precisely the intended purpose of the first RES field under discussion. A provider P gets a prefix from a registry R of the form 010rrrrrpppppppppppppppp00000000 If the provider grows beyond the capacity of that prefix, one or more zeros are lopped off the end and the SubscriberID field grows *for that provider*. If, on the other hand, the number of directly registered providers grows beyond 2^16, new providers get a few 1 bits in the leftmost portion of the RES field: 010rrrrrpppppppppppppppp10000000, and so on. It's very simple, but I've been waiting since Monday to say this plainly to Juha and nobody seems to have done so. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A PS: Ran, your inet.org's SOA is messed up. ------------------------------------------------------------------------------ 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 Jan 10 10:54:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28584; Wed, 10 Jan 96 10:54:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28578; Wed, 10 Jan 96 10:54:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17258; Wed, 10 Jan 1996 10:54:08 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id KAA14943; Wed, 10 Jan 1996 10:54:10 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA07773; Wed, 10 Jan 96 10:53:37 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA02983; Wed, 10 Jan 1996 10:54:06 -0800 Date: Wed, 10 Jan 1996 10:54:06 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601101854.AA02983@feller.mentat.com> To: narten@VNET.IBM.COM Subject: (IPng 1083) Unicast Solicitations Cc: nordmark@Eng, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, In the previous version of the ND spec (draft-ietf-ipngwg-discovery- 03.txt) the following restriction was applied to neighbor solicitations in section 6.2.3. "- if the Source Address is the unspecified address or the Dest- ination Address is a unicast address, there is no Source Link-layer Address option." This restriction has been removed is the most recent draft. Assuming that it does not break anything, it would be nice if some text could be added to the current draft in or about section 7.2.2 indicating that neighbor solicitations sent to a unicast destination need not include a Source Link-layer Address option. The option should only be included if the remote node needs to be informed of a local address change. Does this sound like a reasonable optimization to NUD? Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 10 11:27:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28633; Wed, 10 Jan 96 11:27:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28627; Wed, 10 Jan 96 11:27:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23099; Wed, 10 Jan 1996 11:26:39 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id JAA10730; Wed, 10 Jan 1996 09:18:37 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA22157; Wed, 10 Jan 1996 12:13:50 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13652; Wed, 10 Jan 1996 12:13:43 -0500 Message-Id: <9601101713.AA13652@fwasted.zk3.dec.com> To: Ran Atkinson Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 1084) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Wed, 10 Jan 96 08:36:06 PST." <199601101636.IAA11372@puli.cisco.com> Date: Wed, 10 Jan 96 12:13:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >% THIS IS IMPORTANT: >% >% >We could certainly modify the protocol so that the host obtains that >% >information before sending a packet. That way the relay agent need >% >not modify the packet it relays. For example, RAs could list (for >% >example) the anycast address for the routers (relay agents) on the >% >% Relay-Agents are not ONLY routers. Relay-Agents can be Hosts running >% Relay-Agent daemon. I am working a proposal why Hosts should have >% anycast addresses and other stuff but that won't be done until Feb after >% the IPv6 bake off. So any RAs presented cannot only be anycast >% addresses for DHCPv6 unless we now change the addressing spec for hosts >% to be able to have anycast addresses before my proposal is complete. >Jim, > > If a node forwards packets, then its a router. A "host" (sic) that forwards >DHCP request/response packets is really a "router". Now it might or might >not be a conforming router in the context of the Router Requirements spec, >but that is an entirely separate issue. Please lets avoid confusing >the precise IETF terms for things with the customary uses of certain >commercial products. If I understand correctly, Geert is using BSDI >Pentium boxes for his routers to give a concrete example :-). I agree with you and this is a sticky and difficult case. Is the packet forwarded in the sense that we perceive forwarding in the IP architecture of IPv4 or IPv6? Let me state a case and see if we have come up with "yet-another-type-of-forwarding". The client sends a packet to a Multicast address. A relay-node (Ran I like this term better than relay-agent too I am going to ask DHC WG if we can use this instead of relay-agent) gets that packet. So what happens in the relay-node. It gets the packet on a well-known UDP multicast address. The transaction according to UDP protocol is complete (not for DHCPv6 semantics though). The relay-node takes that message (in the application layer not at the routing or network layer) and creates an entirely new DHCPv6 packet to send to a server. It can be the case that the relay-node is a host with another interface to a link where the DHCPv6 server resides. The relay-node simply sends a UDP packet to the server. Or the relay-node in fact sends it to a router that is another relay-node (we have to assume multiple relay-nodes in DHCPv6 and is the case in DHCPv4 which is why we record the relay-nodes address in the first place so the server can respond directly back to that node and not hop through the relay-nodes that may have assisted to get the packet to the remote server). Yes the word "forward" applies but maybe we also can remove the word forward from the DHCPv6 spec and call it "relaying the packet". So have we come up with yet another term for "fowarding" and its semantic affect on our IPv6 term of "router". I can build a DHCPv6 relay-node without ever having my IP layer or transport layer deal with the case of forwarding a packet as a router typically does (in the case of a workstation as a router is why I mention the transport layer above). Clearly in a router implementation of a DHCPv6 relay-node this is exactly how it may be done, but we don't require that in DHCPv6. I think this conversation also borders on the affect to the entire client/server Internet model and architecture for that type of processing too. 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 Jan 10 14:17:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28833; Wed, 10 Jan 96 14:17:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28827; Wed, 10 Jan 96 14:16:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17572; Wed, 10 Jan 1996 14:16:35 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id OAA10863; Wed, 10 Jan 1996 14:16:34 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id RAA04640; Wed, 10 Jan 1996 17:16:19 -0500 Message-Id: <199601102216.RAA04640@thumper.bellcore.com> To: Ran Atkinson Cc: gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1085) IPv6/ATM link local token (was Re: Re: proposal...) In-Reply-To: Your message of Tue, 09 Jan 1996 15:43:01 -0800. <199601092343.PAA13617@puli.cisco.com> Date: Wed, 10 Jan 1996 17:16:15 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, I've cc'd ip-atm, because this specific issue needs to be debated on that list. >> The point isn't to "uniquely identify a logical interface" with the token. >>Its just to avoid address space collisions among the set of IPv6 link-local >>addresses on a (logical in the case of ATM) subnet. What if someone wants a single physical ATM NIC with single MAC addr to support two IP interfaces on the same 'logical' link? Each IP interface presumably needs a unique link local token, yet just using the 48 bit MAC value does not achieve uniqueness within the scope of the logical link. It would appear you need the SEL field. I _think_ a similar argument applies to the E.164 case too. [..] >> Bits are _absolutely_ an issue here and the IP/ATM group needs (IMO) >>to pay more attention to minimising the local token portion of the IPv6 >>address. True. cheers, gja _________________________________________________________________________ Grenville Armitage gja@thumper.bellcore.com Bellcore, 445 South St. http://gump.bellcore.com:8000/~gja/home.html Morristown, NJ 07960 USA (voice) +1 201 829 2635 {.. 2504 (fax)} ------------------------------------------------------------------------------ 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 Jan 10 15:18:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28875; Wed, 10 Jan 96 15:18:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28869; Wed, 10 Jan 96 15:18:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27157; Wed, 10 Jan 1996 15:18:00 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id PAA27324; Wed, 10 Jan 1996 15:18:00 -0800 From: schulter@zk3.dec.com Received: from quarry.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA25175; Wed, 10 Jan 1996 18:12:44 -0500 Received: from dogfish.zk3.dec.com by quarry.zk3.dec.com; (5.65/1.1.8.2/13Feb95-0113PM) id AA04566; Wed, 10 Jan 1996 18:12:38 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA06763; Wed, 10 Jan 1996 18:13:10 -0500 Message-Id: <9601102313.AA06763@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1086) Re: ATM interface token for IPv6 In-Reply-To: Your message of "Tue, 09 Jan 96 16:47:09 PST." <199601100047.QAA17303@puli.cisco.com> Date: Wed, 10 Jan 96 18:13:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, > Could you please provide more detail ? > In particular, which cases are problematic ? > In particular, why is the IEEE 802 MAC token required on all interfaces by > the ATM Forum UNI specification (dating back to 1992 or 1993) not > sufficient for the IPv6 address token ? As Grenville pointed out, this was a first guess. It looks quite reasonable to me. I had looked at the problem separately in preparing my I-D and also came up with an 8 byte token. Again, this was a first cut. My reasons for choosing an 8 byte token were to try to minimize duplicate host tokens in the cases of both NSAPA addresses and native E.164 addresses. Native E.164 ATM address are ISDN telephone numbers. They consist of 15 BCD digits encoded into 7.5 bytes. There is no ESI or MAC portion of a native E.164 address. Thus, all 15 digits are needed to uniquely identify an interface on the network. Anything less than 15 digits will not uniquely identify a specific interface (rather like supplying your telephone number without country code or area code). NSAPA address are composed of a network prefix and a host End System Identifier (ESI) and a selector byte. The ESI is not necessarily a MAC, but a unique end system number. The ESI does not uniquely identify an interface on the ATM network, only the prefix+ESI (19 bytes) uniquely identifies an interface. This is because the scope in which the ESI is required to be unique is not global. In fact, the ESI need only be unique for a given prefix, which generally specifies a specific switch. The UNI spec only mentions using a MAC as an ESI to make autoconfiguration of ATM interfaces easier; it does not say that the ESIs MUST be MACs. So, two endsystems on different switches in the same building (or even side-by-side) could have the same ESI, and would have unique ATM addresses (by virtue of the IDP+HO-DSP part of the ATM address being different). But, if these two systems joined the same LIS, and used only their ESIs for their host tokens, they would end up with duplicate addresses. Thus, there seems to be a need for more information than is provided in the ESI alone to increase the uniqueness of the host token in the NSAPA case. Since it already appeared that 8 bytes were required for E.164 addresses, why not use the same length for NSAPA addresses and add more info to make the token more unique? One easy thing to add is the selector byte. When I finished all this reasoning I found I had ended up in pretty much the same place as Grenville, so I just referenced his I-D from mine. However, Grenville's I-D specifies the unused 8th byte as 0, and I keep wondering if we might want to do something more with that byte to further increase the uniqueness of the token. > With more data, perhaps someone can come up with a shorter alternative. There might be alternatives, but I think they would all greately increase the chances of host tokens being non-unique on a given subnet. So far I've tryed to choose tokens which maximize uniqueness. If we restrict the size of the ATM host token we need to understand how this affects token uniqueness, and what restrictions this might place on forming IPv6 subnets over ATM. Such restrictions would also have to be run by the IP over ATM WG (which is just beginning to look at IPv6). --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 10 16:24:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28964; Wed, 10 Jan 96 16:24:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28958; Wed, 10 Jan 96 16:24:21 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07148; Wed, 10 Jan 1996 16:23:57 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id QAA12461; Wed, 10 Jan 1996 16:23:56 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id TAA20883; Wed, 10 Jan 1996 19:23:31 -0500 Date: Wed, 10 Jan 1996 19:23:31 -0500 Message-Id: <199601110023.TAA20883@borg.mindspring.com> X-Sender: sthomas@mindspring.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hinden@Ipsilon.COM (Bob Hinden) From: Stephen Thomas Subject: (IPng 1087) Re: IPng December Meeting Minutes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:10 AM 1/10/96 -0800, Bob Hinden wrote: >Token Ring: Status unknown. Author did not attend. Will check with >author then do a last call. Sorry I couldn't make the meeting, but those of us doing this on our own dime (I'm not a consultant either) can be travel-budget-challenged. I've got a draft ready with some editorial corrections based on the December circulation to the mailing list. I was holding back on re- submitting to see how the dust clears on the including-an-interface- number-in-the-link-local-address discussion. As it stands, the spec simply calls for the MAC address only. If we want to submit the draft like that, just let me know and I'll turn it around immediately. >Other: AppleTalk? HIPPI? FiberChannel? How about frame relay? Consider this email a volunteering to do a frame relay draft. I'll assume encapsulation is SNAP a la RFC 1490. The problematic issues are (1) multicast (there is a multicast frame agreement, but it's not widely implemented) and (2) interface tokens. Unless someone chimes up with a better idea, I'll address those by (1) replicate on individual PVCs/SVCs, (2) in order of priority: (a) if "global DLCIs" are available, use the lowest numbered one padded to 6 bytes with the first 4.75 bytes padded so as to be an illegal MAC address (i.e. a multicast one). Any company want to volunteer one of their IEEE prefixes to be munged into a multicast-like prefix? (b) if a real MAC address is available on some other interface, use it (c) configuration (yech but I see no other option) --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 Wed Jan 10 17:06:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28997; Wed, 10 Jan 96 17:06:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28991; Wed, 10 Jan 96 17:06:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12726; Wed, 10 Jan 1996 17:05:45 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id RAA21741; Wed, 10 Jan 1996 17:05:47 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id RAA11887; Wed, 10 Jan 1996 17:05:46 -0800 Date: Wed, 10 Jan 1996 17:05:46 -0800 From: Ran Atkinson Message-Id: <199601110105.RAA11887@puli.cisco.com> To: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1088) Re: IPv6/ATM link local token (was Re: proposal...) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % What if someone wants a single physical ATM NIC with single MAC addr to % support two IP interfaces on the same 'logical' link? Each IP interface % presumably needs a unique link local token, yet just using the 48 bit % MAC value does not achieve uniqueness within the scope of the logical % link. It would appear you need the SEL field. % % I _think_ a similar argument applies to the E.164 case too. How do you handle this for Ethernet/FDDI/Token-Ring ?? Its the same question and SHOULD have the same answer. If this is the rationale, then there is NO WAY that I'll buy ATM getting more than 48-bits of local identification token. 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 Wed Jan 10 17:17:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29009; Wed, 10 Jan 96 17:17:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29003; Wed, 10 Jan 96 17:17:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13990; Wed, 10 Jan 1996 17:17:13 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id RAA23964; Wed, 10 Jan 1996 17:17:15 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id RAA12448; Wed, 10 Jan 1996 17:14:42 -0800 Date: Wed, 10 Jan 1996 17:14:42 -0800 From: Ran Atkinson Message-Id: <199601110114.RAA12448@puli.cisco.com> To: rja@cisco.com, schulter@zk3.dec.com Subject: (IPng 1089) Re: ATM interface token for IPv6 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % > In particular, which cases are problematic ? % % > In particular, why is the IEEE 802 MAC token required on all interfaces by % > the ATM Forum UNI specification (dating back to 1992 or 1993) not % > sufficient for the IPv6 address token ? % % As Grenville pointed out, this was a first guess. It looks quite reasonable % to me. I had looked at the problem separately in preparing my I-D and % also came up with an 8 byte token. Again, this was a first cut. % % My reasons for choosing an 8 byte token were to try to minimize duplicate % host tokens in the cases of both NSAPA addresses and native E.164 addresses. % Native E.164 ATM address are ISDN telephone numbers. They consist of % 15 BCD digits encoded into 7.5 bytes. There is no ESI or MAC % portion of a native E.164 address. Thus, all 15 digits are needed to % uniquely identify an interface on the network. Anything less than 15 % digits will not uniquely identify a specific interface (rather like supplying % your telephone number without country code or area code). Nope. The ATM Forum UNI specification _requires_ that each specific interface have an IEEE 802 MAC address on it. That should be used as the token. The local identification component of the IPv6 address SHOULD NOT vary as a function of whether an NSAP or E.164 address has been _configured_ on that interface. Embedding ATM topology into the IPv6 address isn't worth the extra bytes, if its desirable at all IMHO. % NSAPA address are composed of a network prefix and a host End System % Identifier (ESI) and a selector byte. The ESI is not necessarily a MAC, % but a unique end system number. The ESI does not uniquely identify % an interface on the ATM network, only the prefix+ESI (19 bytes) uniquely % identifies an interface. This is because the scope in which the % ESI is required to be unique is not global. In fact, the ESI need only be % unique for a given prefix, which generally specifies a specific switch. The % UNI spec only mentions using a MAC as an ESI to make autoconfiguration % of ATM interfaces easier; it does not say that the ESIs MUST be MACs. So, % two endsystems on different switches in the same building (or even % side-by-side) could have the same ESI, and would have unique ATM addresses % (by virtue of the IDP+HO-DSP part of the ATM address being different). But, if % these two systems joined the same LIS, and used only their ESIs for their host % tokens, they would end up with duplicate addresses. Thus, there seems to be a % need for more information than is provided in the ESI alone to increase the % uniqueness of the host token in the NSAPA case. Since it already appeared % that % 8 bytes were required for E.164 addresses, why not use the same length for % NSAPA addresses and add more info to make the token more unique? One easy % thing to add is the selector byte. When I finished all this reasoning I % found I had ended up in pretty much the same place as Grenville, so I just % referenced his I-D from mine. However, Grenville's I-D specifies the % unused 8th byte as 0, and I keep wondering if we might want to do something % more with that byte to further increase the uniqueness of the token. I refer you back to the ATM Forum UNI spec which DOES REQUIRE that _each_ ATM interface have an IEEE 802 MAC address available to it. If you don't, ATM UNI address auto-configuration will not work anyway. ATM interfaces ought not be embedding ATM topology into the IPv6 address. There are good reasons that the world has layers. % There might be alternatives, but I think they would all greately increase % the chances of host tokens being non-unique on a given subnet. So far I've % tryed to choose tokens which maximize uniqueness. If we restrict % the size of the ATM host token we need to understand how this affects % token uniqueness, and what restrictions this might place on forming IPv6 % subnets over ATM. Such restrictions would also have to be run by the % IP over ATM WG (which is just beginning to look at IPv6). The chance of an 2 ATM interfaces having the same MAC address burned into their PROM is no greater from the chance for 2 FDDI/Ethernet/Token-Ring interfaces having the same address burned into their PROM. Yes it will probably happen sometimes, no the world will not end when it does. No this does not affect the ability to form IPv6 subnets over ATM. Sigh. 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 Wed Jan 10 18:38:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29267; Wed, 10 Jan 96 18:38:27 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29261; Wed, 10 Jan 96 18:38:12 PST Received: from kandinsky.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA11545; Wed, 10 Jan 1996 18:37:20 -0800 Received: by kandinsky.eng.sun.com (5.x/SMI-SVR4) id AA04502; Wed, 10 Jan 1996 18:42:57 -0800 Date: Wed, 10 Jan 1996 18:42:57 -0800 From: gilligan@caribe.eng.sun.com (Bob Gilligan) Message-Id: <9601110242.AA04502@kandinsky.eng.sun.com> To: ipng@sunroof Subject: (IPng 1090) Re: - need for uniq ID's/PPP and identifying interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No, in fact the functionality you need for a router is a superset of > the functionality you need for a "normal" application. In particular > routers need to (at least) be able to determine the arrival interface when > receiving packets with recvmsg() (for nearly all packets), need to be able > to specify the sending interface when sending packets with sendmsg() > (for nearly all packets) and need to be able to pin connections to > an interface, to operate correctly. They need to be able to do this for > IPv6, IPv4 and whatever other network layer a routing protocol is > running over, and they need to be able to do this independent of the > address configuration (or lack thereof) of the interfaces. This is exactly > the "layer" of the API which the draft specifies. Well, the current draft of the API spec does provide all the functionallity listed above, but the scope of the spec was IPv6. If we want to open it up to fixing the problems of IPv4, or other protocol stacks, I think the API would get alot more complex. > So the comment still stands, this time put in terms strictly related > to the draft: > > (1) Interface identification in sendmsg() and recvmsg() is needed > by routers for protocols other than IPv6, where there is no > possibility of using protocol addresses. A non-protocol-address > mechanism is needed. > > (2) If you have a non-protocol-address mechanism to specify interfaces > for other protocols it can be used for IPv6 too, using a common mechanism > everywhere and with the added bonus that it is independent of the address > configuration of the interfaces. The latter is an essential feature for > a router, and the former is certainly desirable regardless. I agree that a non-protocol-address mechanism (such as using an interface name) would probably apply to other protocol stacks in addition to IPv6. But I don't see that as providing much benefit to applications except perhaps to a small set of routing protocol daemons. And its not clear how great the benefit would be to even those programs. After all, those programs already need to have stack-specific code to get interface addresses, add routes, etc. > Please read my comments carefully. First, there is no, repeat no, > "existing functionality" which guarantees that it is possible at all > to uniquely identify an interface by a protocol address if your box is > a router. The "existing functionallity" I was referring is the ability of applications to use a function already defined (hostname2addr()) to map the name of an interface into its address. And I understand that machines may not necessarily be configured with unique addresses. In this case, the system could simply provide a 16-byte magic cookie that uniquely identifies each interface. > Okay, let's do a thought experiment. Suppose the box we're dealing with > has 400 interfaces (this is not out-of-line for a router, I've configured > over 200 "interfaces" on a Cisco with a 68040 processor and my big-iron > unix box should't do worse than this). Let's suppose we both send packets > using sendmsg(), with the "magic cookie" attached. How many cycles are > going to be spent in the kernel for every packet sent determining the > outgoing interface your 16-byte "magic cookie" is specifying, and what > data structure are you going to use for this (repeated once per protocol)? > And how many cycles will I spend, given my well-chosen-for-the-job two-byte > "magic cookie" interface index, and what data structure will I use > (hint: think array, repeated once per system)? If you aren't clever it > may cost you substantially more to determine the interface to send each > packet out of than it does to actually send the packet, and you still haven't > dealt with the issue that your method can't uniquely identify IPv4 interfaces > given current configuration practices, and requires unnecessary constraints > on interface configuration to work with IPv6. I'm not sure I agree that a 16-byte magic cookie is necessarily perform much worse than a 2-byte one. Keep in mind that the system gets to choose the magic cookie, so it could put the array index in the low-order 2 bytes and set the high-order bytes to all-zeros. > . . . Yet the only advantage you've > been able to identify for your method is that it avoids one having to write > one single user-level library function to find an interface from an > address (if possible), by moving this code into the kernel instead. This > doesn't seem like a good tradeoff. The advantage of approach in the current API spec is that it is simpler for applications to deal with. I am thinking about the complexity of the API to the application programmer, not complexity to the system implementor. There will (hopefully) be lots of IPv6 applications using this API, but we will only have to implement the API on our systems once (again, hopefully!). I do think that keeping the API simple for the application programmer is a good objective. > I've not punted this at all. We're talking about code which finds an > interface given an address in any case and the only issue is whether it > is in the kernel or in a library. You need a system call to make queries > about interface configuration, and you need a library routine to use it > to search the interface configuration to find the address (and determine > whether it uniquely identifies the interface?). The system call will need > to exist anyway if there is to be any hope at all of using the box as a > router sometimes, but needn't necessarily be (and traditionally hasn't > been) standardized across all systems. For the library routine, call > it with: > > ifindex_t addr2ifindex(struct sockaddr *); > > Add another one called like > > ifindex_t ifname2ifindex(char *); > > and you can even have your cake and eat it too. Add a third one like > > int ifindex2ifconfig(if_index_t, struct if_config *, if_config_len); > > to fetch everything you ever wanted to know about the interface given > its magic cookie, and you can't go wrong. And note that all of this > is protocol-independent, and imposes no unneeded constraints on interface > address configuration. The disadvantage of this approach is that it introduces two or three new library functions that application programmers need to know about and use. I think that the tradeoff here is about how much added complexity we add to the base API to support routing daemons. I don't think we should not design the transport-layer API around the requirements of routing daemons. These applications need to have alot of knowledge about the IP layer, and typically need to use things like ioctls or the routing socket to learn the configuration of interfaces, add and delete routes, etc. Designing the API for routing applications correctly brings up lots of issues. I think the API should stick to host-side functionallity. What do others think? 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 Jan 11 00:46:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29627; Thu, 11 Jan 96 00:46:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29621; Thu, 11 Jan 96 00:46:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14092; Thu, 11 Jan 1996 00:45:40 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id AAA16462; Thu, 11 Jan 1996 00:45:41 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id KAA02175; Thu, 11 Jan 1996 10:43:34 +0200 Date: Thu, 11 Jan 1996 10:43:34 +0200 From: Juha Heinanen Message-Id: <199601110843.KAA02175@lohi.dat.tele.fi> To: dhaskin@BayNetworks.com Cc: ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com In-Reply-To: <9601091612.AA07367@pobox.BayNetworks.com> (dhaskin@BayNetworks.com) Subject: (IPng 1091) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Interesting?! The last I heard an ATM interface could be identified by a 20 byte NSAP-like number or an E.164 number. It has been proposed to use 8 octets of such an ATM address to form the interface token which is used for address autoconfiguration. I refer you to the draft-ietf-ipatm-ipv6nd-00.txt and draft-ietf-addrconf-ipv6-auto-07.txt. If the IP-over-ATM WG finds way to construct 48 bit interface tokens for ATM interfaces, it is fine with me. if nsap addresses are used i don't understand how an atm interface differs from an ethernet interface. both have a 48 bit mac address and both can be used to implement logical interfaces .at least my linux box implement the concept of dummy interfaces that the guys running web servers are using to create logical ethernet interfaces each with a different ip address. the e.164 case is different, but i don't would like the idea of very rare e.164 hosts to extend every atm link-local ipv6 address to 8 bytes. let the link-local ipv6 address be 6 bytes for nsap addresses hosts and 8 bytes for e.164 addressed hosts. -- juha ------------------------------------------------------------------------------ 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 Jan 11 01:37:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29669; Thu, 11 Jan 96 01:37:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29663; Thu, 11 Jan 96 01:36:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16092; Thu, 11 Jan 1996 01:36:34 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id BAA21525; Thu, 11 Jan 1996 01:36:33 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id LAA02247; Thu, 11 Jan 1996 11:34:23 +0200 Date: Thu, 11 Jan 1996 11:34:23 +0200 From: Juha Heinanen Message-Id: <199601110934.LAA02247@lohi.dat.tele.fi> To: gja@thumper.bellcore.com Cc: rja@cisco.com, gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com In-Reply-To: <199601102216.RAA04640@thumper.bellcore.com> (gja@thumper.bellcore.com) Subject: (IPng 1092) Re: IPv6/ATM link local token (was Re: proposal...) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What if someone wants a single physical ATM NIC with single MAC addr to support two IP interfaces on the same 'logical' link? Each IP interface presumably needs a unique link local token, yet just using the 48 bit MAC value does not achieve uniqueness within the scope of the logical link. It would appear you need the SEL field. I _think_ a similar argument applies to the E.164 case too. what is the problem of having a different 48 bit mac address for each logical interface and not allowing one logical interface more than one ip address? further, i fail to see how this differs from ethernet. my linux box implements so called dummy interfaces that can be layered over any physical interface and www-servers use these logical interfaces to give several ip addressed to one physical ethernet. -- juha ------------------------------------------------------------------------------ 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 Jan 11 02:22:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29698; Thu, 11 Jan 96 02:22:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29692; Thu, 11 Jan 96 02:21:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17864; Thu, 11 Jan 1996 02:21:36 -0800 Received: from bridge2.NSD.3Com.COM by mercury.Sun.COM (Sun.COM) id CAA25067; Thu, 11 Jan 1996 02:21:24 -0800 Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA04069 (5.65c/IDA-1.4.4nsd for ); Thu, 11 Jan 1996 02:21:22 -0800 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA13993 (5.65c/IDA-1.4.4-910730); Thu, 11 Jan 1996 02:18:25 -0800 Message-Id: <199601111018.AA13993@remmel.NSD.3Com.COM> To: Grenville Armitage Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 1093) Re: IPv6/ATM link local token (was Re: proposal...) In-Reply-To: Your message of "Wed, 10 Jan 1996 17:16:15 EST." <199601102216.RAA04640@thumper.bellcore.com> Date: Thu, 11 Jan 1996 02:18:25 -0800 From: Tracy Mallory Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville, > What if someone wants a single physical ATM NIC with single MAC addr to > support two IP interfaces on the same 'logical' link? Each IP interface > presumably needs a unique link local token, yet just using the 48 bit > MAC value does not achieve uniqueness within the scope of the logical > link. It would appear you need the SEL field. Ran's replies are probably sufficient, but I would like to add my two cents that this question is probably a red herring, in that it takes the use of the interface token outside of it's intended scope in the ongoing discussion (link-local addresses). The whole point of link-local addresses is to be able to communicate when there has been no other assignment of network addresses. Any host on a logical can talk with any other host connected to the same logical link. If it happens that your switch can provide logical link independence through the use of the SEL field, that is fine, but only the 48-bit MAC address is needed on a single logical link. You seem to be trying to ask 1) "how can I use two different network interfaces which would likely have the same IPv6 address" (isn't this where the whole thing started?) or 2) "how can we use link local addresses with greater than link-local scope" (Ran: we mustn't!). These questions are themselves quite reasonable within the original discussion thread, but don't appear to have unique requirements or answers in the ATM case. Tracy ------------------------------------------------------------------------------ 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 Jan 11 05:22:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29790; Thu, 11 Jan 96 05:22:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29784; Thu, 11 Jan 96 05:21:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23884; Thu, 11 Jan 1996 05:21:33 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id FAA09657; Thu, 11 Jan 1996 05:21:32 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5833; Thu, 11 Jan 96 08:20:46 EST Received: by RTP (XAGENTA 4.0) id 9886; Thu, 11 Jan 1996 08:16:16 -0500 Received: from rsalh1p46.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20687; Thu, 11 Jan 1996 08:16:40 -0500 Received: from hygro (narten@localhost [127.0.0.1]) by hygro (8.6.12/8.6.9) with ESMTP id IAA00169; Thu, 11 Jan 1996 08:08:13 -0500 Message-Id: <199601111308.IAA00169@hygro> To: thartric@mentat.com (Tim Hartrick) Cc: nordmark@Eng, ipng@sunroof.eng.sun.com Subject: (IPng 1094) Re: Unicast Solicitations In-Reply-To: Your message of "Wed, 10 Jan 1996 10:54:06 PST." <9601101854.AA02983@feller.mentat.com> Date: Thu, 11 Jan 1996 08:08:13 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, > In the previous version of the ND spec (draft-ietf-ipngwg-discovery- >03.txt) the following restriction was applied to neighbor solicitations in >section 6.2.3. You mean version -02 of the draft, I think. > "- if the Source Address is the unspecified address or the Dest- > ination Address is a unicast address, there is no Source > Link-layer Address option." I don't recall right off anymore why we had the latter restriction in the first place. Checking for the unspecified source case was to ensure that an implementation didn't install a bogus entry in its Neighbor Cache for the unspecified address together with a valid link-layer address. We handle that case elsewhere in the spec now. On the other hand, it seems like it should be OK for a unicast NS to include a Source Link-Layer Address. It shouldn't be required to be included, but I don't see right off why it MUST NOT be included. I suspect that is why we got rid of this restriction. >This restriction has been removed is the most recent draft. Assuming >that it does not break anything, it would be nice if some text could be >added to the current draft in or about section 7.2.2 indicating that >neighbor solicitations sent to a unicast destination need not include a >Source Link-layer Address option. The option should only be included >if the remote node needs to be informed of a local address change. Hmm. It's actually a bit more complicated than that. You really want to include the Source Link-Layer Address option if the destination doesn't have it in its cache. In general, there is no way for the sender to know that. In 99% (??) of the cases, the entry will be there in the scenario we are talking about here. However, it may also be the case that no traffic has been sent between a pair of nodes for some time, and one of them has deleted the other's cache entry for garbage collections purposes. If so, an extra NS/NA packet pair would be exchanged. What is the cost of having the Source Link-Layer Address option included in unicast NS messages? Not much on the receiver side I would think. Certainly a small additional number of machine cycles relative to the overall cost of processing the received NS. In an earlier message, thartric@mentat.com (Tim Hartrick) writes: >I need a ruling. The following sentence appears in the current ND >document in section 7.2.4 "Sending Solicited Neighbor Advertisements". > "If the Target Address is either an anycast address or a > unicast address for which the node is providing proxy service > , the Override flag SHOULD be set to zero. Otherwise, it > SHOULD be set to one." >It seems to me that if a neighbor solicitation prompting the advertise- >ment has a unicast destination address, the responding host should not >set the Override bit unless the link address being used by the remote >node needs to be changed for some reason. If the solicitation has a >multicast destination then obviously the Override bit in the responding >advertisement should be zero. >This could make NUD quite a bit more efficient since the link address in- >formation in the cache would only be updated as needed instead of every >thirty seconds or so. It seems reasonable to suggest that the node sending the NA response should simply exclude the Source Link-Layer Address option in this case. If it is responding to a unicast solicitation, the NS sender already has the target's proper link-layer address in its cache. No need to provide redundant information in the NA response. Would that provide the same performance enhancement? 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 Jan 11 08:19:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29870; Thu, 11 Jan 96 08:19:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29864; Thu, 11 Jan 96 08:19:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06930; Thu, 11 Jan 1996 08:18:50 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id IAA10347; Thu, 11 Jan 1996 08:18:51 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id IAA26033; Thu, 11 Jan 1996 08:18:06 -0800 Date: Thu, 11 Jan 1996 08:18:06 -0800 From: Ran Atkinson Message-Id: <199601111618.IAA26033@puli.cisco.com> To: jh@lohi.dat.tele.fi Subject: (IPng 1095) Re: IPv6/ATM link local token (was Re: proposal...) Cc: gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha, Thank you. Well put. 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 Jan 11 08:59:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29915; Thu, 11 Jan 96 08:59:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29909; Thu, 11 Jan 96 08:59:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11875; Thu, 11 Jan 1996 08:59:03 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id IAA20078; Thu, 11 Jan 1996 08:59:04 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id IAA27332; Thu, 11 Jan 1996 08:58:58 -0800 Date: Thu, 11 Jan 1996 08:58:58 -0800 From: Ran Atkinson Message-Id: <199601111658.IAA27332@puli.cisco.com> To: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1096) Re: IPv6 addresses & ATM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % I'm bothered by this requirement that the ESI be globally unique. It seems % to me that the ESI for E.164, DCC, or ICD is certainly not expected to be % a globally unique value, and that a MAC address, although supposedly % unique, cannot be guaranteed to be unique. Maybe "should not be expected % to be unique" is a safer way to put it. % % Basically, the ESI is equivalent to your 7-digit telephone number (if % using the US numbering plan), is it not?. There's nothing globally unique % about that number. % % Bert % manfredi@engr05.comsys.rockwell.com Bert, A couple of things. First, the quoted text is for Private UNI. Second, this does NOT (repeat NOT) relate to whether one has an E.164 or other address _configured_ at the ATM layer into the interface. This is ONLY talking about the IEEE 802 MAC address that ATM Forum UNI says exists on the interface (whether one uses it as part of one's ATM address is _entirely_ a separate issue; the IPv6 address ought not have any particular numeric relationship with a configured ATM interface address). If one has an interface card that can only be used with a Public UNI (IMHO, not a good business decision) then one can simply invent an IEEE 802 MAC address from the "local-use" portion of the IEEE 802 MAC address space (yes there is such a thing, no I don't have a bit map for this handy but yes it is documented in the 802.something documents). Again, due to the IPv6 duplicate address detection and the relative infrequency of needing to use an invented token, this shouldn't be a problem. By the way, I believe this latter approach (inventing a token from the local-use part of the MAC address space) would also work for the case where a single link interface (ATM, FDDI, etc) is trying to have two IPv6 link-local addresses onto the same IPv6 subnet. I would gently ask that the ATM folks who aren't familiar with IPv6 _please_ go read the set of IPv6 documents _before_ commenting on this issue. 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 Jan 11 09:31:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29943; Thu, 11 Jan 96 09:31:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29937; Thu, 11 Jan 96 09:31:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16122; Thu, 11 Jan 1996 09:31:19 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id JAA28597; Thu, 11 Jan 1996 09:31:17 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id MAA21742; Thu, 11 Jan 1996 12:31:04 -0500 Message-Id: <199601111731.MAA21742@thumper.bellcore.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: (IPng 1097) Re: IPv6 addresses & ATM In-Reply-To: Your message of Wed, 10 Jan 1996 18:25:04 -0800. <199601110225.SAA15733@puli.cisco.com> Date: Thu, 11 Jan 1996 12:30:59 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, [..] >>It bothers me that the IP/ATM WG has gone and done up some drafts without >>following the important related discussions on IPng (particularly the >>one regarding Sun workstations' conformance to the Ethernet spec which >>mandates one MAC address per workstation). >> >>Sigh. Well, mea culpa. But if you'd bothered to read the WG I-D (and you do remember its an I-D, and version 00 at that), I sprinkled it with invitations to revise the initial assumptions behind the I-D's first guesses on a number of IPv6-ATM issues. If you prefer an us-vs-them approach to this, rather than collaboration, then fine. But basically I dont care for any particular method of identifying a local token for ATM interfaces, so how about you dont get so bent out of shape. The IP/ATM WG has not "gone and done" anything yet. gja ------------------------------------------------------------------------------ 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 Jan 11 10:39:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00188; Thu, 11 Jan 96 10:39:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29244; Wed, 10 Jan 96 18:25:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22010; Wed, 10 Jan 1996 18:25:03 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id SAA06418; Wed, 10 Jan 1996 18:25:05 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id SAA15733; Wed, 10 Jan 1996 18:25:04 -0800 Date: Wed, 10 Jan 1996 18:25:04 -0800 From: Ran Atkinson Message-Id: <199601110225.SAA15733@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1098) IPv6 addresses & ATM Cc: ip-atm@matmos.hpl.hp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, With help from someone locally, I've gone and found chapter and verse to back up my assertion that the IEEE 802 MAC is plenty sufficient for use as the local identification token of an IPv6 address on an ATM interface. ATM folks should read section 5.1.3.1.10 of ATM Forum UNI v3.0. It discusses the use of the IEEE MAC address. The local-token part of the IPv6 address is comparable (though not identical semantics) with the ESI of an ATM ESI component and is NOT comparable with the (ESI + SEL). The equivalent passage is 5.1.3.1.2.2 in UNI 3.1 and a similar location in the UNI 4.0 draft that is available local to me. I note that a nearby (slightly later) section of UNI 4.0 draft indicates that "Equipment at the Private UNI must support the Address Registration procedure described in this section." and that said procedure won't work unless an IEEE 802 MAC address or another globally unique 6 byte identifier is present on the interface. I think this requirement dates back to UNI 3.0 (based on my memory from ATM Forum meetings), but I'm not bothering to hunt all over using GhostView for that level of detail. It bothers me that the IP/ATM WG has gone and done up some drafts without following the important related discussions on IPng (particularly the one regarding Sun workstations' conformance to the Ethernet spec which mandates one MAC address per workstation). Sigh. Ran rja@cisco.com >From owner-ipng@sunroof Thu Jan 11 08:44 PST 1996 Return-Path: Received: from sunroof.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA26877; Thu, 11 Jan 1996 08:44:20 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29885; Thu, 11 Jan 96 08:45:12 PST Date: Thu, 11 Jan 96 08:45:12 PST Message-Id: <9601111645.AA29885@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com From: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [manfredi@engr05.comsys.rockwell.com (Albert E. Manfredi)] Content-Type: text Content-Length: 1909 X-Lines: 40 Status: RO From manfredi@engr05.comsys.rockwell.com Thu Jan 11 08:44:57 1996 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29879; Thu, 11 Jan 96 08:44:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09855; Thu, 11 Jan 1996 08:44:33 -0800 Received: from ENGR05 by mercury.Sun.COM (Sun.COM) id IAA16557; Thu, 11 Jan 1996 08:44:33 -0800 Date: Thu, 11 Jan 1996 11:35:21 -0500 Message-Id: <96011111352151@engr05.comsys.rockwell.com> From: manfredi@engr05.comsys.rockwell.com (Albert E. Manfredi) To: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, rja@cisco.com Subject: Re: IPv6 addresses & ATM X-Vms-To: SMTP%"rja@cisco.com" X-Vms-Cc: ipatm,smtp%"ipng@sunroof.eng.sun.com" > From: rja@cisco.com 11-JAN-1996 07:10 [ ... ] > I note that a nearby (slightly later) section of UNI 4.0 draft indicates > that "Equipment at the Private UNI must support the Address Registration > procedure described in this section." and that said procedure won't > work unless an IEEE 802 MAC address or another globally unique 6 byte > identifier is present on the interface. I think this requirement dates > back to UNI 3.0 (based on my memory from ATM Forum meetings), but I'm > not bothering to hunt all over using GhostView for that level of detail. I'm bothered by this requirement that the ESI be globally unique. It seems to me that the ESI for E.164, DCC, or ICD is certainly not expected to be a globally unique value, and that a MAC address, although supposedly unique, cannot be guaranteed to be unique. Maybe "should not be expected to be unique" is a safer way to put it. Basically, the ESI is equivalent to your 7-digit telephone number (if using the US numbering plan), is it not?. There's nothing globally unique about that number. Bert manfredi@engr05.comsys.rockwell.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 Jan 11 10:44:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00254; Thu, 11 Jan 96 10:44:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00248; Thu, 11 Jan 96 10:44:07 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27950; Thu, 11 Jan 1996 10:43:40 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id KAA25065; Thu, 11 Jan 1996 10:43:39 -0800 From: schulter@zk3.dec.com Received: from quarry.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA05042; Thu, 11 Jan 1996 12:45:17 -0500 Received: from dogfish.zk3.dec.com by quarry.zk3.dec.com; (5.65/1.1.8.2/13Feb95-0113PM) id AA22653; Thu, 11 Jan 1996 12:44:57 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA18902; Thu, 11 Jan 1996 12:45:28 -0500 Message-Id: <9601111745.AA18902@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1099) Re: ATM interface token for IPv6 In-Reply-To: Your message of "Wed, 10 Jan 96 17:14:42 PST." <199601110114.RAA12448@puli.cisco.com> Date: Thu, 11 Jan 96 12:45:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Nope. The ATM Forum UNI specification _requires_ that each specific > interface have an IEEE 802 MAC address on it. That should be used > as the token. Nope. From the UNI 3.1 spec: 5.1.3.1.2.2 End System Identifier (ESI) The end system identifier identifies an end system. The identifier must be unique within a particular value of the IDP + HO-DSP. In ^^^^ addition, to ensure the ability of an end system to autoconfigure its address, this end system identifier can be a globally unique ^^^ identifier specified by an IEEE MAC address. The length of this field is 6 octects. Note that this states only that the ESI MUST be unique within each prefix. It CAN be an IEEE MAC to facilitate autoconfiguration, but does not have to be a MAC. It can really be anything that is unique within a specific prefix. In fact, it entirely possible to have an ESI that is not a MAC (it could be an IPv4 address for example). > The local identification component of the IPv6 address SHOULD NOT vary > as a function of whether an NSAP or E.164 address has been _configured_ > on that interface. Embedding ATM topology into the IPv6 address isn't > worth the extra bytes, if its desirable at all IMHO. I'm not trying to embed ATM topology into IPv6 addresses (if I were I would use the prefix and not the ESI), and I agree that we don't want to do this. What we need is a value the uniquely (as possible) identifies a specific interface on the network. In the case of NSAPA addresses this is very hard, but this is not necessarily the ESI alone since the ESI need not be globally unique (and if it were, it would limit the size of ATM networks to 2^48 nodes, and then why have the extra 13 bytes of prefix). In the case of native E.164 addresses there is no ESI or MAC. Interfaces simply have phone numbers. Besides, using either the ESI or E.164 address in the host token doesn't really embed any topology in the token (since this information is not used for routing), it is simply a bit pattern which is unique for that interface. The idea here is to try to find some interface unique sequence of bits. The bits themselves have no intrinsic meaning. > I refer you back to the ATM Forum UNI spec which DOES REQUIRE that _each_ > ATM interface have an IEEE 802 MAC address available to it. If you don't, > ATM UNI address auto-configuration will not work anyway. Again, it does not require this. Using MACs is simply a recommended for autoconfiguration when using NSAPAs. One could just as easily use IPv4 addresses or some other bit pattern that has equal uniqueness (and the uniqueness MUST only extend to the scope of the prefix). Also, the use of the MAC (or any 6 byte value) for autoconfiguration does not apply to native E.164 addresses since these do not have ESI fields. > ATM interfaces ought not be embedding ATM topology into the IPv6 address. > There are good reasons that the world has layers. Again, this is true and I agree, but that's not what using the ESI or E.164 address would be doing. It's simply a way of creating some unique bit pattern based on the interface's link-layer address. I don't see that this is any different from using a MAC on an Ethernet. Also, I think PPP has the same problems as ATM in the choice of host tokens since a serial line doesn't have a MAC, and something like a phone number would need to be used. > The chance of an 2 ATM interfaces having the same MAC address burned into > their PROM is no greater from the chance for 2 FDDI/Ethernet/Token-Ring > interfaces having the same address burned into their PROM. Yes it > will probably happen sometimes, no the world will not end when it does. > No this does not affect the ability to form IPv6 subnets over ATM. Well, since ATM networks can be larger than Ethernet or FDDI networks, the probability of collision increases. This is especially true if MACs are not being used as ESIs. Also, in the case of native E.164 the probability of collision goes up as you lop off more digits from the address. Only the full 15 digit (7.5 byte) address is guaranteed to be globally unique. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 11 10:57:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00282; Thu, 11 Jan 96 10:57:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00276; Thu, 11 Jan 96 10:57:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00205; Thu, 11 Jan 1996 10:57:08 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id KAA29431; Thu, 11 Jan 1996 10:57:10 -0800 Received: from munin.fnal.gov ("port 2311"@munin.fnal.gov) by FNAL.FNAL.Gov (PMDF V5.0-4 #3998) id <01HZVV60W1C00001M5@FNAL.FNAL.Gov>; Thu, 11 Jan 1996 12:56:48 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA08678; Thu, 11 Jan 1996 12:55:03 -0600 (CST) Date: Thu, 11 Jan 1996 12:55:03 -0600 From: Matt Crawford Subject: (IPng 1100) Re: ATM interface token for IPv6 In-Reply-To: "11 Jan 96 12:45:28 EST." <9601111745.AA18902@dogfish.zk3.dec.com> To: schulter@zk3.dec.com Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Message-Id: <9601111855.AA08678@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{ Well, since ATM networks can be larger than Ethernet or FDDI networks, > the probability of collision increases. Can they? What's the basis for this claim? (Crystal ball arguments are inoperative.) That aside, can anyone draw an important distinction between the case of an ATM interface (with an 802 MAC address) being used on multiple logical networks and the case of several ethernet interfaces sharing a single MAC address on one node. I allege that if the latter is solved, the former is. _________________________________________________________ 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 Jan 11 11:14:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00330; Thu, 11 Jan 96 11:14:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00324; Thu, 11 Jan 96 11:14:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02705; Thu, 11 Jan 1996 11:14:18 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id LAA04016; Thu, 11 Jan 1996 11:14:17 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id OAA28284; Thu, 11 Jan 1996 14:14:03 -0500 Message-Id: <199601111914.OAA28284@thumper.bellcore.com> To: Juha Heinanen Cc: gja@thumper.bellcore.com, rja@cisco.com, ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1101) Re: IPv6/ATM link local token (was Re: proposal...) In-Reply-To: Your message of Thu, 11 Jan 1996 11:34:23 +0200. <199601110934.LAA02247@lohi.dat.tele.fi> Date: Thu, 11 Jan 1996 14:13:58 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> What if someone wants a single physical ATM NIC with single MAC addr to >> support two IP interfaces on the same 'logical' link? Each IP interface >> presumably needs a unique link local token, yet just using the 48 bit >> MAC value does not achieve uniqueness within the scope of the logical >> link. It would appear you need the SEL field. >>what is the problem of having a different 48 bit mac address for each >>logical interface and not allowing one logical interface more than one >>ip address? That is certainly another solution. >>further, i fail to see how this differs from ethernet. my linux box >>implements so called dummy interfaces that can be layered over any >>physical interface and www-servers use these logical interfaces to give >>several ip addressed to one physical ethernet. Is this an IPv6 box? A crucial assumption I made when writing the I-D back in August was that each dummy/logical/virtual IP interface needed its own link local token, not a common one. With that assumption, which I'm willing to accept correction on, the scenario I note at the top of this email demands an ESI+SEL based token. If my assumption is wrong, we are down to an ESI. cheers, gja ------------------------------------------------------------------------------ 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 Jan 11 11:17:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00342; Thu, 11 Jan 96 11:17:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00336; Thu, 11 Jan 96 11:16:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03037; Thu, 11 Jan 1996 11:16:27 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id LAA04760; Thu, 11 Jan 1996 11:16:27 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA01194; Thu, 11 Jan 96 11:15:52 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA03912; Thu, 11 Jan 1996 11:16:22 -0800 Date: Thu, 11 Jan 1996 11:16:22 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601111916.AA03912@feller.mentat.com> To: narten@VNET.IBM.COM Subject: (IPng 1102) Re: Unicast Solicitations Cc: ipng@sunroof.eng.sun.com, nordmark@Eng X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > > I don't recall right off anymore why we had the latter restriction in > the first place. Checking for the unspecified source case was to > ensure that an implementation didn't install a bogus entry in its > Neighbor Cache for the unspecified address together with a valid > link-layer address. We handle that case elsewhere in the spec now. On > the other hand, it seems like it should be OK for a unicast NS to > include a Source Link-Layer Address. It shouldn't be required to be > included, but I don't see right off why it MUST NOT be included. I > suspect that is why we got rid of this restriction. > > Hmm. It's actually a bit more complicated than that. You really want > to include the Source Link-Layer Address option if the destination > doesn't have it in its cache. In general, there is no way for the > sender to know that. In 99% (??) of the cases, the entry will be there > in the scenario we are talking about here. However, it may also be the > case that no traffic has been sent between a pair of nodes for some > time, and one of them has deleted the other's cache entry for garbage > collections purposes. If so, an extra NS/NA packet pair would be > exchanged. > Yes, in order for what I am asking for to make sense it requires im- plementations to have neighbor caches of reasonable size and for the garbage collection policy to make sense. If the cache hit rate were more like 50% rather than 99% then what I am suggesting would be more costly overall. I am not convinced that implementations will not be in the 99% hit rate area since the spec makes a point of indicating that the cache needs to be of reasonable size and the garbage collection policy needs to make sense. > What is the cost of having the Source Link-Layer Address option > included in unicast NS messages? Not much on the receiver side I would > think. Certainly a small additional number of machine cycles relative > to the overall cost of processing the received NS. > > The cost in machine cycles to update the link layer address contained in the neighbor cache is likely to vary from implementation to implementa- tion. Given appropriate data structures it is likely to be inexpensive. However, if the cost being paid (no matter how small) is unnecessary 99% of the time then I would argue that the cost is infinitely too high. As long as implementations do not adopt overly aggressive garbage collec- tion schemes I don't see why solicitations with unicast destinations should be required to carry the SLL option. I am not asking for the return of the "MUST NOT" requirement. I am asking that the "SHOULD" be changed to a "MAY" for unicast solicitations. Thoughts? Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 11 11:54:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00463; Thu, 11 Jan 96 11:54:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00457; Thu, 11 Jan 96 11:54:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08637; Thu, 11 Jan 1996 11:54:01 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id LAA15189; Thu, 11 Jan 1996 11:53:59 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id OAA00346; Thu, 11 Jan 1996 14:53:50 -0500 Message-Id: <199601111953.OAA00346@thumper.bellcore.com> To: Tracy Mallory Cc: Grenville Armitage , ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1103) Re: IPv6/ATM link local token (was Re: proposal...) In-Reply-To: Your message of Thu, 11 Jan 1996 02:18:25 -0800. <199601111018.AA13993@remmel.NSD.3Com.COM> Date: Thu, 11 Jan 1996 14:53:48 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tracy, (I've put ip-atm back in - its important.) >>> What if someone wants a single physical ATM NIC with single MAC addr to >>> support two IP interfaces on the same 'logical' link? Each IP interface >>> presumably needs a unique link local token, yet just using the 48 bit >>> MAC value does not achieve uniqueness within the scope of the logical >>> link. It would appear you need the SEL field. [..] >>You seem to be trying to ask 1) "how can I use two different network >>interfaces which would likely have the same IPv6 address" nope. >> or 2) "how can we use link local >>addresses with greater than link-local scope" nope. Actually, I'm now contemplating a scenario where a single physical machine, using a single ATM NIC, supports a number of independent, 'virtual hosts'. In an ATM environment doing this is trivial - each virtual host's IP interface is built over a logical ATM interface, themselves distinguished within the context of the single ATM NIC by using different SEL field values. Now consider two or more of these virtual hosts needing to be 'on' the same link (logical, in the IPv6/ATM case). Each virtual host is an independent entity, presumably with auto-config needs, and certainly with the need to communicate with other on-link {virtual}hosts. They need independent link local tokens (especially if you consider a logical link that was router-less, and contained a number of such virtual hosts in addition to other less virtual hosts). Rightly or wrongly this leads me to the ESI+SEL model for link local token. (Interestingly, you cannot actually implement the virtual hosts I mention above using IPv6-over-Ethernet as currently defined.) cheers, gja _________________________________________________________________________ Grenville Armitage gja@thumper.bellcore.com Bellcore, 445 South St. http://gump.bellcore.com:8000/~gja/home.html Morristown, NJ 07960 USA (voice) +1 201 829 2635 {.. 2504 (fax)} ------------------------------------------------------------------------------ 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 Jan 11 12:43:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00483; Thu, 11 Jan 96 12:43:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00477; Thu, 11 Jan 96 12:43:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15429; Thu, 11 Jan 1996 12:43:08 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id MAA01799; Thu, 11 Jan 1996 12:43:08 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA10846; Thu, 11 Jan 1996 12:40:35 -0800 Date: Thu, 11 Jan 1996 12:40:35 -0800 From: Ran Atkinson Message-Id: <199601112040.MAA10846@puli.cisco.com> To: schulter@zk3.dec.com Subject: (IPng 1104) Re: ATM interface token for IPv6 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % From the UNI 3.1 spec: % % 5.1.3.1.2.2 End System Identifier (ESI) % % The end system identifier identifies an end system. The identifier % must be unique within a particular value of the IDP + HO-DSP. In % ^^^^ % addition, to ensure the ability of an end system to autoconfigure % its address, this end system identifier can be a globally unique % ^^^ % identifier specified by an IEEE MAC address. The length of this % field is 6 octects. % % Note that this states only that the ESI MUST be unique within each prefix. % It CAN be an IEEE MAC to facilitate autoconfiguration, but does not have % to be a MAC. It can really be anything that is unique within a specific % prefix. In fact, it entirely possible to have an ESI that is not a MAC % (it could be an IPv4 address for example). Doesn't matter. There has to already be a _6_ byte token available on the interface. The _same_ 6 byte token ought to be used for the low-order part of the IPv6 address. In practice, all ATM interfaces that I'm aware of include an IEEE 802 MAC. Those that don't can use whatever they are using for the ATM purpose OR they can invent a 6 byte token from the IEEE 802 MAC local-use address space OR anything else that doesn't collide as determined experimentally at boot time via IPv6 Duplicate Address Detection. My important point is that _6 bytes_ is sufficient for ALL interfaces that comply with the ATM Forum UNI specification that you quote above. % > The local identification component of the IPv6 address SHOULD NOT vary % > as a function of whether an NSAP or E.164 address has been _configured_ % > on that interface. Embedding ATM topology into the IPv6 address isn't % > worth the extra bytes, if its desirable at all IMHO. % % I'm not trying to embed ATM topology into IPv6 addresses (if I were I % would use the prefix and not the ESI), and I agree that we don't want to % do this. What we need is a value the uniquely (as possible) identifies % a specific interface on the network. In the case of NSAPA addresses this % is very hard, but this is not necessarily the ESI alone since the ESI % need not be globally unique (and if it were, it would limit the size of % ATM networks to 2^48 nodes, and then why have the extra 13 bytes of prefix). % In the case of native E.164 addresses there is no ESI or MAC. Interfaces % simply have phone numbers. Besides, using either the ESI or E.164 address % in the host token doesn't really embed any topology in the token (since % this information is not used for routing), it is simply a bit pattern % which is unique for that interface. The idea here is to try to find % some interface unique sequence of bits. The bits themselves have no % intrinsic meaning. % Also, the use of the MAC (or any 6 byte value) for autoconfiguration % does not apply to native E.164 addresses since these do not have ESI fields. All Private UNI compliant hardware/software combinations MUST have that 6 byte token. They might not be _using_ it because E.164 was configured, but the token must be there or the interface isn't Private UNI compliant. Presense or absence of a PROM with a MAC address is a hardware question, entirely unrelated to whether you have E.164 (telephone numbers), NSAPs, or other kinds of addresses _configured_. One can still _use_ the MAC address in the PROM, even if the E.164 is _configured_ for ATM addressing. Regardless of that, they can use 48 bits from the IEEE 802 local-use space or invent something. Only 6 bytes are needed and its irrelevant WHICH kind of address was configured on the ATM interface. The token NEED NOT be collision-free because we have duplicate-address detection. Moreover, at least one well-known Ethernet card vendor has shipped thousands of cards with the same MAC address. Those cards are far and away the dominant collision probability, IMHO. We don't have so much address space that we can afford to let ATM addressing consume _half_ of it. 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 Jan 11 12:58:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00519; Thu, 11 Jan 96 12:58:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00513; Thu, 11 Jan 96 12:57:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17119; Thu, 11 Jan 1996 12:57:31 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id MAA05831; Thu, 11 Jan 1996 12:57:28 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA11578; Thu, 11 Jan 1996 12:57:27 -0800 Date: Thu, 11 Jan 1996 12:57:27 -0800 From: Ran Atkinson Message-Id: <199601112057.MAA11578@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1105) Re: Unicast Solicitations In-Reply-To: <9601111916.AA03912@feller.mentat.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601111916.AA03912@feller.mentat.com> Tim wrote: >Yes, in order for what I am asking for to make sense it requires im- >plementations to have neighbor caches of reasonable size and for the >garbage collection policy to make sense. If the cache hit rate were >more like 50% rather than 99% then what I am suggesting would be more >costly overall. I am not convinced that implementations will not be in >the 99% hit rate area since the spec makes a point of indicating that >the cache needs to be of reasonable size and the garbage collection >policy needs to make sense. We normally try to avoid making that level of implementation detail required in a standards-track specification. >I am not asking for the return of the "MUST NOT" requirement. I am >asking that the "SHOULD" be changed to a "MAY" for unicast solicitations. > >Thoughts? I like "SHOULD". It doesn't require it absolutely but it does correctly indicate that sending them is likely to provide better network reliability in the face of unknown implementation internals. This is the old "conservative in what one sends" philosophy. 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 Jan 11 13:01:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00540; Thu, 11 Jan 96 13:01:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00534; Thu, 11 Jan 96 13:01:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17601; Thu, 11 Jan 1996 13:01:11 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id NAA06885; Thu, 11 Jan 1996 13:01:11 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id NAA11860; Thu, 11 Jan 1996 13:01:10 -0800 Date: Thu, 11 Jan 1996 13:01:10 -0800 From: Ran Atkinson Message-Id: <199601112101.NAA11860@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1106) Re: IPv6/ATM link local token (was Re: proposal...) In-Reply-To: <199601111953.OAA00346@thumper.bellcore.com> References: <199601111018.AA13993@remmel.NSD.3Com.COM> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199601111953.OAA00346@thumper.bellcore.com> Grenville wrote: >Actually, I'm now contemplating a scenario where a single physical >machine, using a single ATM NIC, supports a number of independent, >'virtual hosts'. In an ATM environment doing this is trivial - each >virtual host's IP interface is built over a logical ATM interface, >themselves distinguished within the context of the single ATM NIC >by using different SEL field values. > >Now consider two or more of these virtual hosts needing to >be 'on' the same link (logical, in the IPv6/ATM case). > >Each virtual host is an independent entity, presumably with auto-config >needs, and certainly with the need to communicate with other >on-link {virtual}hosts. They need independent link local tokens (especially >if you consider a logical link that was router-less, and contained >a number of such virtual hosts in addition to other less virtual >hosts). > >Rightly or wrongly this leads me to the ESI+SEL model for link >local token. (Interestingly, you cannot actually implement the >virtual hosts I mention above using IPv6-over-Ethernet as currently >defined.) One possible 6 byte solution for this is: Use the MAC address as token for the 1st virtual interfaces For each additional interface 1: Invent a token pseudo-randomly Perform IPv6 duplicate address detection If it tests as duplicate, Goto 1 End For 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 Jan 11 13:04:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00569; Thu, 11 Jan 96 13:04:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00557; Thu, 11 Jan 96 13:03:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17866; Thu, 11 Jan 1996 13:03:33 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id NAA07598; Thu, 11 Jan 1996 13:03:32 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id NAA13451; Thu, 11 Jan 1996 13:03:32 -0800 Date: Thu, 11 Jan 1996 13:03:32 -0800 From: Ran Atkinson Message-Id: <199601112103.NAA13451@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1107) Re: IPv6/ATM link local token (was Re: proposal...) In-Reply-To: <199601111953.OAA00346@thumper.bellcore.com> References: <199601111018.AA13993@remmel.NSD.3Com.COM> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199601111953.OAA00346@thumper.bellcore.com> Grenville wrote: > (Interestingly, you cannot actually implement the > virtual hosts I mention above using IPv6-over-Ethernet as currently > defined.) Interesting. Why do you believe this can't be solved by inventing tokens for the 2nd and later virtual interfaces ? 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 Jan 11 13:37:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00608; Thu, 11 Jan 96 13:37:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00602; Thu, 11 Jan 96 13:37:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22268; Thu, 11 Jan 1996 13:36:48 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id NAA16320; Thu, 11 Jan 1996 13:36:47 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04028; Thu, 11 Jan 96 13:36:13 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA04003; Thu, 11 Jan 1996 13:36:44 -0800 Date: Thu, 11 Jan 1996 13:36:44 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601112136.AA04003@feller.mentat.com> To: rja@cisco.com Subject: (IPng 1108) Re: Unicast Solicitations Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------------------------------------------------------------------------------ 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 Jan 11 13:42:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00620; Thu, 11 Jan 96 13:42:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00614; Thu, 11 Jan 96 13:41:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22903; Thu, 11 Jan 1996 13:41:25 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id NAA17675; Thu, 11 Jan 1996 13:41:24 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04190; Thu, 11 Jan 96 13:40:53 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA04006; Thu, 11 Jan 1996 13:41:24 -0800 Date: Thu, 11 Jan 1996 13:41:24 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601112141.AA04006@feller.mentat.com> To: rja@cisco.com Subject: (IPng 1109) Re: Unicast Solicitations Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >Yes, in order for what I am asking for to make sense it requires im- > >plementations to have neighbor caches of reasonable size and for the > >garbage collection policy to make sense. If the cache hit rate were > >more like 50% rather than 99% then what I am suggesting would be more > >costly overall. I am not convinced that implementations will not be in > >the 99% hit rate area since the spec makes a point of indicating that > >the cache needs to be of reasonable size and the garbage collection > >policy needs to make sense. > > We normally try to avoid making that level of implementation > detail required in a standards-track specification. Since the text is in the spec I would guess that some portion of "We" thought it was a necessary caveat to insert in the doc- ument. Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 11 13:44:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00634; Thu, 11 Jan 96 13:44:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00628; Thu, 11 Jan 96 13:44:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23246; Thu, 11 Jan 1996 13:44:21 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id NAA18522; Thu, 11 Jan 1996 13:44:21 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id QAA07769; Thu, 11 Jan 1996 16:43:27 -0500 Message-Id: <199601112143.QAA07769@thumper.bellcore.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1110) Re: IPv6/ATM link local token (was Re: proposal...) In-Reply-To: Your message of Thu, 11 Jan 1996 13:03:32 -0800. <199601112103.NAA13451@puli.cisco.com> Date: Thu, 11 Jan 1996 16:43:20 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I've put ip-atm back in - could people please leave this thread on both lists. It is important, and as regards resolution of these issues, it is definately something that ip-atm needs to do.) >>In article <199601111953.OAA00346@thumper.bellcore.com> Grenville wrote: >> >>> (Interestingly, you cannot actually implement the >>> virtual hosts I mention above using IPv6-over-Ethernet as currently >>> defined.) >> >>Interesting. Why do you believe this can't be solved by inventing >>tokens for the 2nd and later virtual interfaces ? That's not strictly what I said. As IPv6/Ethernet currently stands I believe there is no mechanism for inventing MAC addresses to act as 'virtual' Ethernet tokens. Never the less, inventing MAC addresses for the subsequent virtual interfaces/hosts is certainly another possible solution. Getting back to IP/ATM, in a related post you wrote: >>One possible 6 byte solution for this is: >> Use the MAC address as token for the 1st virtual interfaces >> For each additional interface >>1: Invent a token pseudo-randomly >> Perform IPv6 duplicate address detection >> If it tests as duplicate, Goto 1 >> End For The question is whether this adds more complexity (both real and conceptual) to the run-time functioning of virtual IP over ATM interfaces than it is worth to save 8 bits. Maybe it's fine. I'm going to update the ip-atm group's I-D on this topic by the end of February (its been out since August) based on conclusions reached by the ip-atm WG on this thread. I'm not particularly concerned what mechanism the ip-atm group converges on, just so long as we've discussed on the list the implications of our design choices. For now I think I should leave this thread to others. cheers, gja ------------------------------------------------------------------------------ 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 Jan 11 14:39:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00780; Thu, 11 Jan 96 14:39:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00774; Thu, 11 Jan 96 14:39:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00916; Thu, 11 Jan 1996 14:38:37 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id OAA03006; Thu, 11 Jan 1996 14:38:36 -0800 From: schulter@zk3.dec.com Received: from quarry.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA20581; Thu, 11 Jan 1996 17:30:06 -0500 Received: from dogfish.zk3.dec.com by quarry.zk3.dec.com; (5.65/1.1.8.2/13Feb95-0113PM) id AA00137; Thu, 11 Jan 1996 17:29:34 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA21984; Thu, 11 Jan 1996 17:30:06 -0500 Message-Id: <9601112230.AA21984@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Matt Crawford Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 1111) Re: ATM interface token for IPv6 In-Reply-To: Your message of "Thu, 11 Jan 96 12:55:03 CST." <9601111855.AA08678@munin.fnal.gov> Date: Thu, 11 Jan 96 17:30:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Well, since ATM networks can be larger than Ethernet or FDDI networks, >> the probability of collision increases. > > Can they? What's the basis for this claim? (Crystal ball arguments > are inoperative.) How many nodes can you have on an Ethernet? How many nodes can you have on an ATM network? I think the number of nodes you can have on an ATM network is roughly equal to the number of telephones in the world, after all, this is what ATM is really designed for. I doubt there are currently ATM networks with more nodes than some large Ethernet or FDDI segments, but the technology permits (and is designed for) networks of global size. Of course, all anyone is doing with ATM these days is prediction since the technology is not deployed or even fully specified. This is one reason I think we need to plan for what could be, based on the technology, since no one really knows exactly how it may be used and deployed. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 11 17:00:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00898; Thu, 11 Jan 96 17:00:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00892; Thu, 11 Jan 96 17:00:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20538; Thu, 11 Jan 1996 17:00:15 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id RAA07792; Thu, 11 Jan 1996 17:00:15 -0800 From: schulter@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA19123; Thu, 11 Jan 1996 18:52:05 -0500 Received: from dogfish.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18645; Thu, 11 Jan 1996 18:51:46 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA23157; Thu, 11 Jan 1996 18:52:18 -0500 Message-Id: <9601112352.AA23157@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Ran Atkinson Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1112) Re: IPv6 addresses & ATM In-Reply-To: Your message of "Thu, 11 Jan 96 08:58:58 PST." <199601111658.IAA27332@puli.cisco.com> Date: Thu, 11 Jan 96 18:52:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A couple of things. First, the quoted text is for Private UNI. > Second, this does NOT (repeat NOT) relate to whether one has an E.164 > or other address _configured_ at the ATM layer into the interface. The quoted text (UNI 3.0 5.1.3.1.10 and UNI 3.1 5.1.3.1.2.2) only defines what the ESI value of the NSAP ATM address is. Since an ESI is only present in an NSAP address, then yes, this applies only to the private UNI. The text does not relate to what's configured on the interface, it only defines the fields of each NSAP address type. > This is ONLY talking about the IEEE 802 MAC address that ATM Forum UNI > says exists on the interface As far as I remember, the UNI spec does not say anything about a MAC address existing on an interface. It simply says that an IEEE MAC can (not must, not should, but can) be used as an ESI, and that the ESI MUST be unique only for a given prefix (being globally unique is a superset of being unique to a single prefix). It says nothing about the source of this value (it could be obtained from any source, and does not need to be associated with the specific interface). For example, given the discussion a while back on the IPNG list about Sun systems which configure their Ethernet cards from a single MAC is system ROM, this same MAC could be used as an ESI. This brings up an interesting point which can demonstrate the required uniqueness of an ESI. Suppose we take the case of a SUN with a single MAC in the system ROM which is used to configure all interfaces. Such a MAC could be used to configure more than one ATM interface on the system depending on how the interfaces were connected to the network (just as it is used to configure multiple Ethernet adapters). If the adapters were connected to the ATM network such that the prefixes for each UNI connection was the same, the MAC could only be used for a single adapter. However, if the interfaces were connected to the network such that the prefixes for each UNI connection were different then the same MAC could be used for both (or many) adapters. Now, if the system wanted to do some sort of host aliasing and connect to the same IP subnet through each adapter it would end up with duplicate addresses. If a couple of extra bytes are added to the token (say, making an extra byte an interface number) then the host token becomes unique in seven bytes. > the IPv6 address ought not > have any particular numeric relationship with a configured ATM interface > address). Well, I would say "need not" rather than "ought not" since the host token has no intrinsic meaning. It simply must be fairly unique. If you say "ought not" then this statement could be applied to legacy LAN host tokens which have a 1-to-1 relationship with the interface's configured address. > If one has an interface card that can only be used with a > Public UNI (IMHO, not a good business decision) I don't know, but am willing to conjecture that a public only adapter might be reasonable. Perhaps a card for PCs that is intended only to connect to the public ATM (phone) network for home Internet access. This seems like a reasonably large market to me if ATM really does become the phone system of the future. These cards would not have MACs since they would never be configured with anything other than an E.164 address. Also, would public UNI cards be required to be certified like ISDN cards? If so, this might be another reason to have public only cards. > Again, due to the IPv6 duplicate address detection and > the relative infrequency of needing to use an invented token, this > shouldn't be a problem. Certainly, that's what we want. Though we want to choose a token that minimizes the possibility of a collision (since collisions will require manual intervention and configuration to fix, or complicated algorithms). We seem to be using a good deal of bandwidth and aren't getting too far. Maybe we should let some others comment or propose workable alternatives. I would be quite happy with a six byte token if I was convinced it would provide sufficient uniqueness to make the probability of duplicate addresses very small, it was easy to generate, it provided a way to generate as many tokens as are needed to implement some sort of virtual interfaces, and it is usable for both public and private UNIs. Your suggestion of using the "local-use" MAC address is interesting, but I would like to understand how these are generated. Randomly generated tokens seem to introduce too much complexity, especially in the DAD and regeneration (though if there were some general spec for this for the legacy LAN cases, it might be applicable to ATM also). --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 11 18:57:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01036; Thu, 11 Jan 96 18:57:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01030; Thu, 11 Jan 96 18:57:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03933; Thu, 11 Jan 1996 18:56:38 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id SAA28836; Thu, 11 Jan 1996 18:56:39 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28242; Thu, 11 Jan 96 21:55:38 EST Received: from [192.32.95.51] (BNE_CS1_Port1) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA16451; Thu, 11 Jan 96 21:55:48 EST Message-Id: <9601120255.AA16451@pobox.BayNetworks.com> To: "schulter@zk3.dec.com" Subject: (IPng 1113) Re: ATM interface token for IPv6 Date: Thu, 11 Jan 96 21:58:25 -0500 From: Dimitry Haskin X-Mailer: E-Mail Connection v2.5.03 Cc: "ipng@sunroof.Eng.Sun.COM" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -- [ From: Dimitry Haskin * EMC.Ver #2.5.02 ] -- Pete, > > >> Well, since ATM networks can be larger than Ethernet or FDDI networks, > >> the probability of collision increases. > > > > Can they? What's the basis for this claim? (Crystal ball arguments > > are inoperative.) > > How many nodes can you have on an Ethernet? How many nodes can you have on an > ATM network? I think the number of nodes you can have on an ATM network is > roughly equal to the number of telephones in the world, after all, this is what > ATM is really designed for. I doubt there are currently ATM networks with more > nodes than some large Ethernet or FDDI segments, but the technology permits > (and is designed for) networks of global size. > It is only required that an interface token be unique on a logical link, i.e . among IPv6 interfaces that share the same address prefix. I doubt it will be possible to build a gigantic ATM network consisting of just a single logical link. 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 Jan 11 19:11:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01056; Thu, 11 Jan 96 19:11:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01050; Thu, 11 Jan 96 19:11:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05320; Thu, 11 Jan 1996 19:11:14 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id TAA00697; Thu, 11 Jan 1996 19:11:16 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28248; Thu, 11 Jan 96 21:57:10 EST Received: from [192.32.95.51] (BNE_CS1_Port1) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA16468; Thu, 11 Jan 96 21:56:51 EST Message-Id: <9601120256.AA16468@pobox.BayNetworks.com> To: Matt Crawford Subject: (IPng 1114) Re: ATM interface token for IPv6 Date: Thu, 11 Jan 96 21:59:33 -0500 From: Dimitry Haskin X-Mailer: E-Mail Connection v2.5.03 Cc: "ipng@sunroof.Eng.Sun.COM" , "ip-atm@matmos.hpl.hp.com" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -- [ From: Dimitry Haskin * EMC.Ver #2.5.02 ] -- Matt, > > That aside, can anyone draw an important distinction between the case > of an ATM interface (with an 802 MAC address) being used on multiple > logical networks and the case of several ethernet interfaces sharing > a single MAC address on one node. I allege that if the latter is > solved, the former is. >From what I've gathered so far, there is some interest to have multiple logical IPv6 interfaces that share the same 802 MAC address to have the same address prefix, i.e. to be connected to the same IPv6 subnet. Such a case is not currently supported by autoconfiguration for the ethernet media. Assuming that needs for this will be extremely insignificant in the ethernet case, it is reasonable to spare the generic autoconfiguration mechanism from the complexities of supporting such very exceptional cases and require that it be handled by some other means such as manual configuration, statefull configuration, or whatever. Now the question is if such configurations are going to be so common on ATM networks that, in the ATM case, a generic autoconfiguration solution has to be provided either by using 64-bit tokens or specifying some additional protocol mechanisms. 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 Jan 11 23:42:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01374; Thu, 11 Jan 96 23:42:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01368; Thu, 11 Jan 96 23:42:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21071; Thu, 11 Jan 1996 23:42:02 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id XAA28974; Thu, 11 Jan 1996 23:42:02 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id JAA03496; Fri, 12 Jan 1996 09:39:39 +0200 Date: Fri, 12 Jan 1996 09:39:39 +0200 From: Juha Heinanen Message-Id: <199601120739.JAA03496@lohi.dat.tele.fi> To: gja@thumper.bellcore.com Cc: tracym@nsd.3com.com, gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com In-Reply-To: <199601111953.OAA00346@thumper.bellcore.com> (gja@thumper.bellcore.com) Subject: (IPng 1115) Re: IPv6/ATM link local token (was Re: proposal...) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rightly or wrongly this leads me to the ESI+SEL model for link local token. (Interestingly, you cannot actually implement the virtual hosts I mention above using IPv6-over-Ethernet as currently defined.) yes, it leads to esi+sel model UNLESS you require that each virtual interface also has its own mac address. remember that an atm host can register any number of atm addresses with the switch, each with a different esi (mac) field. that would be prefered choise so solve the autoconfiguration problem. if the current definition of ipv6-over-ethernet doesn't support virtual hosts (interfaces), then the model is broken in a big time. if you don't believe me, ask anyone who runs a web server. -- juha ------------------------------------------------------------------------------ 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 Jan 12 00:00:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01390; Fri, 12 Jan 96 00:00:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01384; Thu, 11 Jan 96 23:59:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21924; Thu, 11 Jan 1996 23:59:19 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id XAA00909; Thu, 11 Jan 1996 23:59:19 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id JAA03505; Fri, 12 Jan 1996 09:57:14 +0200 Date: Fri, 12 Jan 1996 09:57:14 +0200 From: Juha Heinanen Message-Id: <199601120757.JAA03505@lohi.dat.tele.fi> To: dimitry_haskin@BayNetworks.com Cc: crawdad@FNAL.Gov, ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com In-Reply-To: <9601120256.AA16468@pobox.BayNetworks.com> (dimitry_haskin@BayNetworks.com) Subject: (IPng 1116) Re: ATM interface token for IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Assuming that needs for this will be extremely insignificant in the ethernet case, it is reasonable to spare the generic autoconfiguration mechanism from the complexities of supporting such very exceptional cases and require that it be handled by some other means such as manual configuration, statefull configuration, or whatever. every web service provider that i know of use virtual interfaces on the same physical ethernet interface. even my web server on my laptop does so. if ipv6 autoconfiguration can't cope with that then it is an academic protocol that has nothing to do with real life. -- juha ------------------------------------------------------------------------------ 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 Jan 12 00:18:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01464; Fri, 12 Jan 96 00:18:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01458; Fri, 12 Jan 96 00:18:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22755; Fri, 12 Jan 1996 00:18:10 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id AAA03261; Fri, 12 Jan 1996 00:18:10 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10805 Fri, 12 Jan 1996 19:17:35 +1100 (from kre@munnari.OZ.AU) To: Juha Heinanen Cc: dimitry_haskin@BayNetworks.com, crawdad@FNAL.Gov, ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1117) Re: ATM interface token for IPv6 In-Reply-To: Your message of "Fri, 12 Jan 1996 09:57:14 +0200." <199601120757.JAA03505@lohi.dat.tele.fi> Date: Fri, 12 Jan 1996 19:17:50 +1100 Message-Id: <3506.821434670@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 12 Jan 1996 09:57:14 +0200 From: Juha Heinanen Message-ID: <199601120757.JAA03505@lohi.dat.tele.fi> every web service provider that i know of use virtual interfaces on the same physical ethernet interface. That's due to incredible botches in the http & url design, there's no good reason things should be that way. That said however, there are other more sensible reasons for having multiple addresses on an interface, and IPv6 certanly supports that. if ipv6 autoconfiguration can't cope with that then it is an academic protocol that has nothing to do with real life. Do you expect that people should be able to have their node out of the box from the manufacturer, plug it in, and have the box automatically start providing web service for some number of virtal domains? If so, then we still have quite a bit of work to do, as something somewhere is going to have to automatically generate the appropriate home pages, and that is going to be an interresting challenge. On the other hand, if configuration is required, then configuration can be assumed possible, and it is rather less cricial that autoconf solve the problem. Autoconf is designed to make "plug and play" work, it doesn't have to do more than that. 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 Fri Jan 12 06:05:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01688; Fri, 12 Jan 96 06:05:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01682; Fri, 12 Jan 96 06:04:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06979; Fri, 12 Jan 1996 06:04:22 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA07258; Fri, 12 Jan 1996 06:04:21 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6508; Fri, 12 Jan 96 09:03:35 EST Received: by RTP (XAGENTA 4.0) id 0093; Fri, 12 Jan 1996 09:03:36 -0500 Received: from rsalh1p27.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17568; Fri, 12 Jan 1996 09:04:02 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id JAA00270; Fri, 12 Jan 1996 09:01:46 -0500 Message-Id: <199601121401.JAA00270@hygro.raleigh.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1118) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Tue, 09 Jan 1996 16:24:03 PST." <199601100024.QAA16002@puli.cisco.com> Date: Fri, 12 Jan 1996 09:01:45 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >>I should note that in my discussions I have been aiming for end-to-end >>host->server authentication using IPSec AH without the relay agent >>being involved. That is, host->server, not host->relay, >>relay->server. The latter problem is not so hard to solve, but changes >>the trust model and forces all relay agents to ENABLE IPSec and (more >>important) to distribute keys/SPIs. I'd like to avoid the need for >>this in the name of keeping relay agents simple. >Hmm. It looks to me that only sites that are concerned with DHCP security >would need to _enable_ IPsec in their systems. That seems reasonable to >me. Sites in private-only networks that trust everyone needn't enable >IPsec if they don't think they need it, do they ? I agree that for sites wanting to authenticate DHCP, IPSec will be generally be enabled. However, I view the relay agent as doing a low-level "grunt" job of just resending a packet, much as a router simply forwards a packet. It would be nice if relay agents could be used without *requiring* that they enable IPSec as a prerequisite for DHCP using it. By enable, I mean going through the hassle of setting up SPIs, keys, etc. Looking at it another way, relay agents exists for three purposes: 1) identify (to the DHCP server) which link a host is on. The server needs this info in order to return an address with the proper prefix/subnet. In DHCPv4, the relay agent adds that info to the relayed packet via the 'giaddr' field. In principle, we could have the DHCP host obtain that same information before it sends a DHCP packet, eliminating the need for the relay agent to modify the DHCP packet's data contents. 2) Identify the unicast address of the DHCP server, if the server is off-link. The host could obtain this info as in 1) above. 3) To resend a DHCP packet to the server, in those cases where the DHCP host lacks an address of proper scope for reaching the server. This will always be the case for an out-of-the-box machine. This last requirement is IMO the one hardest to deal with. We could certainly invent mechanisms at the IP level that allows a host to (for example) source route a packet with a link-local source address to the server. And the server could source-route the response back, etc. Nice elegant solution for DHCP (maybe :-). However, this opens a potentially *huge* architectural security hole for circumventing access controls based on packet addresses, etc., etc. Lots of reasons why this is a really bad idea. Thus, we come back again to the need for a relay agent to resend the DHCP packet with properly scoped addresses. Given that tunnelling the DHCP packet to the server won't properly preserve the end-to-end AH semantics that are needed (as discussed below), it seems that the best bet may well be to fall back on a DHCP-specific authentication scheme. (Unless we are willing to accept the host->relay, relay->server authentication model as a requirement.) >>2) Since the packet will be processed by the relay agent, and the >>relay agent thinks the packet is addressed to it (it is), it will run >>it through its IPsec engine. This means the relay agent needs to have >>the proper SPI (undesirable for a requirement) and/or relay agent >>needs to be able to receive the packet at the application layer with >>the AH intact (i.e., not discarded by the stack during normal >>processing). My sense (and I could be wrong) is that we will not be >>able to assume that applications have access to the original >>header. Ran: what is your sense here (this is an "what will >>implementations do" question). Is this route a dead end? >I'm confused about the part where the packet is addressed to the Relay >Agent (lack of DHCP clue on my part, my apologies)... The Initial DHCP packets are multicast to a well-known address, the same address identifing both servers and relay agents. There aren't different addresses (or port numbers) for distinguishing relay agents from servers. If both a DHCP server and relay agent are present, they both process the packet independently. So, a DHCP packet *is* addressed to the relay agent, from the perspective of the IP destination address (and IPSec), and any attempt to include an AH header intended to be processed only by the server runs into problems. >If the packet is addressed to the Relay Agent as the final destination, the >Relay Agent will indeed attempt to do the normal IPsec processing, with >possibly bad consequences (a dropped packet). Which implies that relay agents have to enable IPSec (and relay agents and servers need to share the *same* SPI/key) if hosts want to use it. I'd rather not see this required. >Oh, we've also got a key management problem here. How does a bootstrapping >diskless node without a clue about its own address become aware of the >appropriate Security Association to use with a DHCP Server whose address >might well be equally unknown ?? Um, how does it do Neighbor Discovery for that matter? Or stateless autoconfig and DAD? ND is a prerequisite for running DHCP. The DHCP server/relay agent needs to send unicast responses back to the host. If everyone else requires IPSec be enabled, they will all ignore unauthenticated ND packets from the booting host... Since we seem to be in the mood for half-baked ideas, would it be useful to break DHCP up into two logical phases? The first phase focuses solely on obtaining a single (possibly temporary) unicast address with proper scope for reaching a server. The second phase deals with getting all the other information and addresses. But the second phase can use IPSec if it chooses, since the client and server are talking directly to each (i.e., no relay agent). Phase 1 would only be necessary for out-of-the-box machines, those that retain no state whatsoever, or those that have been turned off for so long that previously acquired addresses have expired. We could even skip authentication and such during the first phase, under the assumption that IPSec would be used in the second phase (if necessary), and having the proper SPIs/keys suffices for authentication (though this needs to be reconciled against a thread on the ipsec list requiring the source address of incoming packets to be checked against the one associated with an SPI as part of the IPSec processing). In essence, we could use stateless autoconfig to generate a properly scoped address for reaching the DHCP server. 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 Jan 12 06:42:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01700; Fri, 12 Jan 96 06:42:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01694; Fri, 12 Jan 96 06:42:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08810; Fri, 12 Jan 1996 06:42:10 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA14798; Fri, 12 Jan 1996 06:42:11 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7372; Fri, 12 Jan 96 09:41:25 EST Received: by RTP (XAGENTA 4.0) id 0098; Fri, 12 Jan 1996 09:41:27 -0500 Received: from rsalh1p27.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA21731; Fri, 12 Jan 1996 09:41:54 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id JAA00289; Fri, 12 Jan 1996 09:39:37 -0500 Message-Id: <199601121439.JAA00289@hygro.raleigh.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1119) Re: Forwarding Link-local addresses In-Reply-To: Your message of "Tue, 09 Jan 1996 13:30:53 PST." <199601092130.NAA06625@puli.cisco.com> Date: Fri, 12 Jan 1996 09:39:37 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >My proposed solution to this is a rule that says: > "Routers MUST NOT forward an IPv6 packet containing a link-local > source or destination address" I think this is a bit too strong. In the spirit of "be liberal in what you accept ... ", I think we should not disallow forwarding a packet sent to a link-local unicast address back out on the same link. Although one wouldn't expect this behavior to be common, I don't see the need to ban it. Note that if a router "forwards" such a packet back out on the same link it came in on, scoping rules have not been violated. One example where this might be useful is with routers and link-local anycast addresses. A router may decide to stop recognizing a particular anycast address as one of its own, but know that another router on the link will accept such addresses. Shouldn't the router be allowed to forward the packet, and also send a redirect? >and "Routers MUST NOT send redirects for packets addressed to a > link-local address. I think this goes too far, as outlined above. > "Redirects received for link-local addresses MUST be ignored > by the receiving node." Such a rule strikes me as odd because it says that if a node incorrectly forwards a link-local packet to the wrong destination, and that destination tells me (via a redirect), I'm supposed to ignore the redirect and continue sending traffic to the wrong destination. >and "Routers MUST NOT advertise the link-local prefix in their > router advertisements." >with its corollary for hosts: > "Hosts MUST automatically know about the link-local routing > prefix whenever they bring an interface up and Host MUST > ignore any advertisement of the link-local prefix." I'm not sure how I feel about the last two requirements. The current ND model currently allows for a configuration in which *no* destinations are considered on-link, and that all packets are forwarded to a router by default. The router can then send redirects for those destinations that are on-link (and include the link-layer address of the target). This model allows a site to defer all routing decisions to routers *and* to move address resolution from the host to the routers. This is deemed potentially useful in "shared media" environments, i.e., WANs with many hosts in which hosts don't have prefixes for all on-link destinations. Things get murky when link-local destinations are considered. The above rules would not allow address resolution to be pushed off to routers. In ethernets, this is not a problem, but it could be on other media. 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 Jan 12 07:57:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01730; Fri, 12 Jan 96 07:57:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01724; Fri, 12 Jan 96 07:57:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15891; Fri, 12 Jan 1996 07:57:09 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id HAA05050; Fri, 12 Jan 1996 07:57:09 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15169(13)>; Fri, 12 Jan 1996 07:56:45 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Fri, 12 Jan 1996 07:56:24 -0800 To: Juha Heinanen Cc: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com, deering@parc.xerox.com Subject: (IPng 1120) Re: ATM interface token for IPv6 In-Reply-To: jh's message of Thu, 11 Jan 96 23:57:14 -0800. <199601120757.JAA03505@lohi.dat.tele.fi> Date: Fri, 12 Jan 1996 07:56:20 PST From: Steve Deering Message-Id: <96Jan12.075624pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > every web service provider that i know of use virtual interfaces on the > same physical ethernet interface. even my web server on my laptop does > so. if ipv6 autoconfiguration can't cope with that then it is an > academic protocol that has nothing to do with real life. How does ipv4 autoconfiguration cope with it, or is ipv4 also an academic protocol that has nothing to do with real life? ipv6 copes with it the same way as ipv4 does. 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 Jan 12 08:07:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01742; Fri, 12 Jan 96 08:07:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01736; Fri, 12 Jan 96 08:07:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16992; Fri, 12 Jan 1996 08:06:46 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id IAA07905; Fri, 12 Jan 1996 08:06:46 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id SAA00453; Fri, 12 Jan 1996 18:04:10 +0200 Date: Fri, 12 Jan 1996 18:04:10 +0200 From: Juha Heinanen Message-Id: <199601121604.SAA00453@lohi.dat.tele.fi> To: deering@parc.xerox.com Cc: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com, deering@parc.xerox.com In-Reply-To: <96Jan12.075624pst.75270@digit.parc.xerox.com> (deering@parc.xerox.com) Subject: (IPng 1121) Re: ATM interface token for IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How does ipv4 autoconfiguration cope with it, or is ipv4 also an academic protocol that has nothing to do with real life? ipv6 copes with it the same way as ipv4 does. you are reading far too fast. i was talking about the autoconfiguration protocol, not ipv4 or ipv6 protocol. it should take into account that people have logical interfaces over physical ones no matter if the physical interface is ethernet or atm. one solution of course is that we require each logical interface to have its own mac address. we could say to computer vendors that each nic should come with N mac addresses that are assigned to the logical interfaces until they run out after which you can's have more. or we could invent somethign else. however, whatever solution is selected, it should be independent of the type of the physical media. -- juha ------------------------------------------------------------------------------ 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 Jan 12 09:04:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01811; Fri, 12 Jan 96 09:04:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01805; Fri, 12 Jan 96 09:04:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24100; Fri, 12 Jan 1996 09:04:01 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA26453; Fri, 12 Jan 1996 09:04:00 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA16427; Fri, 12 Jan 1996 09:03:53 -0800 Date: Fri, 12 Jan 1996 09:03:53 -0800 From: Ran Atkinson Message-Id: <199601121703.JAA16427@puli.cisco.com> To: narten@VNET.IBM.COM Subject: (IPng 1122) Re: Forwarding Link-local addresses Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tom, Tom, IMNVHO, the existing Neighbor Discovery spec should be used only on broadcast media. This specifically means that I personally don't think that the existing Neighbor Discovery spec is the right approach for NBMA media (e.g. ATM, Frame Relay). The latter would, IMHO, be MUCH better served by using NBMA NHRP techniques in lieu of traditional Neighbor Discovery. One side effect of this is that I disagree with your reasoning against my proposed implementation rules. I'd be interested in other folks' views on the proposed rules. 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 Jan 12 09:14:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01833; Fri, 12 Jan 96 09:14:13 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01827; Fri, 12 Jan 96 09:13:58 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA27646; Fri, 12 Jan 1996 09:12:44 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28572; Fri, 12 Jan 1996 09:13:13 -0800 Date: Fri, 12 Jan 1996 09:13:13 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199601121713.JAA28572@bobo.eng.sun.com> To: jh@lohi.dat.tele.fi Subject: (IPng 1123) Re: IPv6/ATM link local token (was Re: proposal...) Cc: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > if the current definition of ipv6-over-ethernet doesn't support virtual > hosts (interfaces), then the model is broken in a big time. if you > don't believe me, ask anyone who runs a web server. Let's take a step back. IPv6 has two models for automatic address configuration: autonomous (stateless) and stateful. The intent of the autonomous one is, as far as I understand, to handle the common and simple case of a host needing an address. In this model a host gets one global address for every subnet prefix that the routers advertise. If a host needs more than one address per subnet prefix it can use stateful autoconfiguration where a DHCPv6 server can provide whatever addresses has been configured. I frankly can not understand how you can expect the stateless mechanisms to magically know that a particular host needs 17 addresses (in the same subnet prefix) - this information must be either captured in the host or in some server. If the host knows that it needs to serve 17 distinct addresses (www.foo.com for multiple "foo") I would make the claim that this is no longer the simple and common case and that DHCPv6 provides the solution. 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 Jan 12 09:45:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01910; Fri, 12 Jan 96 09:45:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01904; Fri, 12 Jan 96 09:44:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29424; Fri, 12 Jan 1996 09:44:18 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id JAA10440; Fri, 12 Jan 1996 09:44:12 -0800 Received: from ppp-pm01-dy-14.opr.oakland.edu (ppp-pm01-dy-14.opr.oakland.edu [141.210.14.175]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id LAA18894; Fri, 12 Jan 1996 11:43:12 -0600 Received: by ppp-pm01-dy-14.opr.oakland.edu with Microsoft Mail id <01BAE0EB.1A2CF400@ppp-pm01-dy-14.opr.oakland.edu>; Fri, 12 Jan 1996 12:40:06 -0500 Message-Id: <01BAE0EB.1A2CF400@ppp-pm01-dy-14.opr.oakland.edu> From: Brad Wilson To: "'ipng@sunroof.eng.sun.com'" Cc: "'ip-atm@matmos.hpl.hp.com'" Subject: (IPng 1124) Re: ATM interface token for IPv6 Date: Fri, 12 Jan 1996 12:37:53 -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 Juha Heinanen[SMTP:jh@lohi.dat.tele.fi] said: >> however, whatever solution is selected, it should be independent of the >> type of the physical media. What's wrong with the random choice? IPv6 over PPP states that a random number generation should be used to generate a 48-bit token, since PPP connections don't come with MAC addresses (although PPP uses this token in a PPP configuration option rather than ND, since point-to-point links only get one neighbor :-). This seems like a bunch of shouting for nothing. We are GOING to have 48-bit tokens that are NOT unique on the link, period. An automatic way of dealing with it (ie, random choice and redo ND) seems far better than worrying about including 8 more bits of an ATM address (which is not an option for Ethernet). Please, let's solve the general case instead of bickering about this small detail Random choice was suggested quite a long time ago in this discussion. It seems to me to be adequate (and for hosts that cannot generate random numbers, they must be manually or statefully configured, like IPv6 over PPP). -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } CString GetDisclaimer() { return CString("All I say is fact :-p"); } }; "Money is the living power that dies without its root. Money will not serve the mind that cannot match it. Is this the reason why you call it evil?" ------------------------------------------------------------------------------ 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 Jan 12 10:15:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01978; Fri, 12 Jan 96 10:15:58 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01972; Fri, 12 Jan 96 10:15:43 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA02426; Fri, 12 Jan 1996 10:14:47 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA28592; Fri, 12 Jan 1996 10:15:16 -0800 Date: Fri, 12 Jan 1996 10:15:16 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199601121815.KAA28592@bobo.eng.sun.com> To: rja@cisco.com Subject: (IPng 1125) Re: Forwarding Link-local addresses 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'm VERY nervous about people (mis- ??)using link-local addresses in > address fields of packets that get forwarded off the original link. > Bridging isn't a problem, its forwarding that makes me nervous. If a > packet gets forwarded off-link and contains a link-local in an address > field, then the address might be examined outside its scope and hence end > up at the wrong place. In the case of source-routing with a link-local as > the final address, there is definitely an issue figuring out what the > semantics would be for the last-hop router. I'm also concerned about link-local addresses escaping the link. I think we can handle this by requiring that routers never forward packets with link-local source and/or destination address to another link. You can not remove the ability to forward such packets back on the same link (and send a redirect) for the following reasons. Neighbor Discovery was designed to work in two differents modes (or a combination of them on a per-prefix level): - The host knows that a prefix is on-link and uses (multicast) address resolution to learn the link-layer address for on-link destinations. - The host does not have information about a particular prefix (which is the case for all off-link destinations) so it sends the packet to a default router. If the destination is on-link the router forwards the packets and it typically would send a redirect to inform the sender that 1) the destination is on-link, and 2) the destination's link-layer address. People have argued in the past that both modes are useful. I expect that the smallish multicast capable LAN would use the first model where hosts know all the on-link prefixes. But e.g. for a very large switched LAN (with gigabit Ethernet "trunks" and 10 and 100 Mbit links) that might be built in the future it might be easier to manage if the hosts only are made aware of a subset of the subnet prefixes. The other utility of the second model is that it does not require multicast. Thus on NBMA (non-broadcast multiple access) links it might make perfect sense to use "send to router and get redirect" as, in effect, an address resolution mechanism. I assume there will be some debate about this for the various IPv6-over-foo specs for NBMA links. BTW: The above two models have been part of IPv6 since back in the SIP days are far as I can remember. With your proposal, if the 2nd model is used two neighbors can communicate using each others global and site addresses but not using their link-local address. This seems broken. I think it would be prudent to preserve the capabilities of the 2nd model unless we can convince outselves that it is useless for both large multicast links as well as NBMA links. Thus I argue for the simple rule "don't forward link-locals off-link, forward (and redirect) link-locals out the arriving interface". ------- This still leaves open the question about the link-local prefix: should routers advertise it or not? I don't have an strong opinion on this other than that the solution should work for NBMA links. One simple suggestion is to make it link type specific. For multicast links the hosts automatically know about the link-local prefix as being on-link (hence they use address resolution). For NBMA links hosts do not have such knowledge. Routers never advertise the link-local prefix. Hosts should ignore the link-prefix when received in a router advertisement. 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 Jan 12 10:23:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01994; Fri, 12 Jan 96 10:23:00 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01988; Fri, 12 Jan 96 10:22:45 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA03017; Fri, 12 Jan 1996 10:21:50 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA28596; Fri, 12 Jan 1996 10:22:19 -0800 Date: Fri, 12 Jan 1996 10:22:19 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199601121822.KAA28596@bobo.eng.sun.com> To: narten@VNET.IBM.COM Subject: (IPng 1126) Re: ND Asst for Security Issue for DHCPv6? 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 > Looking at it another way, relay agents exists for three purposes: > > 1) identify (to the DHCP server) which link a host is on. The server > needs this info in order to return an address with the proper > prefix/subnet. In DHCPv4, the relay agent adds that info to the > relayed packet via the 'giaddr' field. In principle, we could have > the DHCP host obtain that same information before it sends a DHCP > packet, eliminating the need for the relay agent to modify the DHCP > packet's data contents. > > 2) Identify the unicast address of the DHCP server, if the server is > off-link. The host could obtain this info as in 1) above. > > 3) To resend a DHCP packet to the server, in those cases where the > DHCP host lacks an address of proper scope for reaching the > server. This will always be the case for an out-of-the-box machine. If the host does the work for #1 and #2 couldn't #3 be handled using the IPv6 routing header? If we've reached the point when the DHCP relay is just a router that acts on some information contained in the packet we might as well just use the routing header to source route through the relay. BTW: I don't necessarily think this is the best model since it places more complexity in the hosts (i.e. in the boot proms) to gather the address of the DHCP server and a router to source route through. 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 Jan 12 10:35:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02015; Fri, 12 Jan 96 10:35:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02009; Fri, 12 Jan 96 10:34:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07689; Fri, 12 Jan 1996 10:34:27 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id KAA28112; Fri, 12 Jan 1996 10:34:01 -0800 From: schulter@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA12559; Fri, 12 Jan 1996 13:02:51 -0500 Received: from dogfish.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21820; Fri, 12 Jan 1996 13:02:50 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA25908; Fri, 12 Jan 1996 13:03:23 -0500 Message-Id: <9601121803.AA25908@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Dimitry Haskin Cc: "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 1127) Re: ATM interface token for IPv6 In-Reply-To: Your message of "Thu, 11 Jan 96 21:58:25 EST." <9601120255.AA16451@pobox.BayNetworks.com> Date: Fri, 12 Jan 96 13:03:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is only required that an interface token be unique on a logical link, i.e > . among > IPv6 interfaces that share the same address prefix. I doubt it will be > possible to > build a gigantic ATM network consisting of just a single logical link. Right, and given that the ESI is always globally unique I wouldn't be concerned, but my concern here (apart from other things like host aliasing) is that we're counting on ESIs having a uniqueness greater than that which is _required_ by the UNI spec. If we look at the minimal uniqueness the UNI spec mandates, then ESIs need only be unique to a prefix. This generally means that the ESI need only be unique to a switch. Thus, you may not have to have a particularly large subnet (two switches?) before you could start having duplicate addresses. The main reason MACs are used for ESIs is that it is a convienent value which has sufficient uniqueness that the chances of two or more systems registering the same ESI for the same prefix is small. However, any value can be used which provides the necessary uniqueness. This means that if someone uses something other than a MAC, the ESI could be sufficiently unique for ATM, but not sufficiently unique for use in IPv6 addresses. Just call me paranoid, but I don't like to depend on something that is commonly used rather than something that is mandated by a spec. I do think there will be subnets on ATM which are larger than subnets on legacy LANs, simply because the technology permits it. I've already seen some customers who are looking to ATM to solve both the bandwidth and size limitations they have with legacy LANs. If the underlying datalink permits it, I don't think we should do anything to restrict subnet size outside any restrictions imposed by the IPv6 address architecture. However, I agree that we're unlikely to see really huge subnets because of human organizational factors (plus, who would want to manage it). --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 12 10:41:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02038; Fri, 12 Jan 96 10:41:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02032; Fri, 12 Jan 96 10:41:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08655; Fri, 12 Jan 1996 10:40:41 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id KAA04418; Fri, 12 Jan 1996 10:40:14 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3271; Fri, 12 Jan 96 13:39:06 EST Received: by RTP (XAGENTA 4.0) id 0132; Fri, 12 Jan 1996 13:39:03 -0500 Received: from rsalh1p27.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA22212; Fri, 12 Jan 1996 13:39:29 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id NAA00505; Fri, 12 Jan 1996 13:37:09 -0500 Message-Id: <199601121837.NAA00505@hygro.raleigh.ibm.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1128) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Fri, 12 Jan 1996 10:22:19 PST." <199601121822.KAA28596@bobo.eng.sun.com> Date: Fri, 12 Jan 1996 13:37:09 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> 3) To resend a DHCP packet to the server, in those cases where the >> DHCP host lacks an address of proper scope for reaching the >> server. This will always be the case for an out-of-the-box machine. >If the host does the work for #1 and #2 couldn't #3 be handled using >the IPv6 routing header? Well, there's the small problem that the host only has a link-local address, and routers are supposed to toss such packets. If we changed the rules (or came up with a special routing header just for this) so that routers did forward such packets and DHCP could use a generic Routing Header mechanism, we'd also open up a new way of circumventing scoping rules (and firewall filters) to reach destinations. Quite likely a lot more negatives here than pluses. >BTW: I don't necessarily think this is the best model since it places >more complexity in the hosts (i.e. in the boot proms) to gather >the address of the DHCP server and a router to source route through. Given that the DHCP algorithm already says "wait for an RA, then do what it says regarding DHCP", it wouldn't be unimaginable to include the address of the DHCP server and router in the RA as well. And if there are no RAs (i.e., routers), the DHCP server has to be on the same link anyway (use a well-known link-local multicast address), and things would still work. But I'm not at all convinced that a general Routing Header mechanism is a good solution in this case because of its potential (ab)use by things other than DHCP. 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 Jan 12 10:54:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02065; Fri, 12 Jan 96 10:54:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02059; Fri, 12 Jan 96 10:53:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10579; Fri, 12 Jan 1996 10:53:24 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id KAA10473; Fri, 12 Jan 1996 10:53:19 -0800 Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi.dat.tele.fi (8.6.12/8.6.12) with SMTP id UAA00718; Fri, 12 Jan 1996 20:51:26 +0200 Message-Id: <30F6ADD9.76DF@lohi.dat.tele.fi> Date: Fri, 12 Jan 1996 20:52:09 +0200 From: Juha Heinanen Organization: Telecom Finland Inc. X-Mailer: Mozilla 2.0b5 (Win95; I) Mime-Version: 1.0 To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1129) Re: IPv6/ATM link local token (was Re: proposal...) References: <199601121713.JAA28572@bobo.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > If the host knows that it needs to serve > 17 distinct addresses (www.foo.com for multiple "foo") I would make > the claim that this is no longer the simple and common case and that > DHCPv6 provides the solution. the host knows that it needs 17 addresses because it has 17 virtual interfaces configured. if we assume that it has a way to generate 17 mac addresses for those and the host gets a prefix from the router, it knows what all those 17 addresses are. it can then tell the router about all of them. looks like i'm missing where the complication comes from? -- juha ------------------------------------------------------------------------------ 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 Jan 12 11:01:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02095; Fri, 12 Jan 96 11:01:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02085; Fri, 12 Jan 96 11:01:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11963; Fri, 12 Jan 1996 11:00:59 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id LAA13036; Fri, 12 Jan 1996 11:00:53 -0800 Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi.dat.tele.fi (8.6.12/8.6.12) with SMTP id UAA00726; Fri, 12 Jan 1996 20:58:54 +0200 Message-Id: <30F6AF9A.4BD1@lohi.dat.tele.fi> Date: Fri, 12 Jan 1996 20:59:38 +0200 From: Juha Heinanen Organization: Telecom Finland Inc. X-Mailer: Mozilla 2.0b5 (Win95; I) Mime-Version: 1.0 To: Brad Wilson Cc: "'ipng@sunroof.eng.sun.com'" , "'ip-atm@matmos.hpl.hp.com'" Subject: (IPng 1130) Re: ATM interface token for IPv6 References: <01BAE0EB.1A2CF400@ppp-pm01-dy-14.opr.oakland.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brad Wilson wrote: > > Juha Heinanen[SMTP:jh@lohi.dat.tele.fi] said: > > >> however, whatever solution is selected, it should be independent of > the > >> type of the physical media. > > What's wrong with the random choice? nothing, it sounds like a very good solution, because it handles well the problem of getting a unique 48 bit token for each virtual interface too. -- juha ------------------------------------------------------------------------------ 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 Jan 12 12:27:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02184; Fri, 12 Jan 96 12:27:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02178; Fri, 12 Jan 96 12:27:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26299; Fri, 12 Jan 1996 12:26:57 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id MAA12390; Fri, 12 Jan 1996 12:26:44 -0800 Received: from munin.fnal.gov ("port 2602"@munin.fnal.gov) by FNAL.FNAL.Gov (PMDF V5.0-4 #3998) id <01HZXCLMXD9U000427@FNAL.FNAL.Gov>; Fri, 12 Jan 1996 14:26:33 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA12794; Fri, 12 Jan 1996 14:26:32 -0600 (CST) Date: Fri, 12 Jan 1996 14:26:32 -0600 From: Matt Crawford Subject: (IPng 1131) Re: Forwarding Link-local addresses In-Reply-To: "12 Jan 96 10:15:16 PST." <199601121815.KAA28592@bobo.eng.sun.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: rja@cisco.com, ipng@sunroof.eng.sun.com Message-Id: <9601122026.AA12794@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{ I'm also concerned about link-local addresses escaping the link. > ... > You can not remove the ability to forward such packets back on the same > link (and send a redirect) for the following reasons. > > Neighbor Discovery was designed to work in two differents modes: > - The host knows that a prefix is on-link ... > - The host does not have information about a particular prefix (which is > the case for all off-link destinations) so it sends the packet to > a default router. Pardon me, but I'm so incurably dense that I think destinations reachable by link-local addresses are always on-link. Please show me the exceptions. > But e.g. for a very large switched LAN that might be built in the future it > might be easier to manage if the hosts only are made aware of a subset of > the subnet prefixes. And wouldn't it be dead simple to make the link-local prefix always be a member of this subset? _________________________________________________________ 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 Fri Jan 12 14:49:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02311; Fri, 12 Jan 96 14:49:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02305; Fri, 12 Jan 96 14:48:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17036; Fri, 12 Jan 1996 14:48:24 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id OAA24548; Fri, 12 Jan 1996 14:48:24 -0800 From: schulter@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA17447; Fri, 12 Jan 1996 17:40:48 -0500 Received: from dogfish.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24930; Fri, 12 Jan 1996 17:40:47 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA29308; Fri, 12 Jan 1996 17:41:18 -0500 Message-Id: <9601122241.AA29308@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Juha Heinanen Cc: Brad Wilson , "'ipng@sunroof.eng.sun.com'" , "'ip-atm@matmos.hpl.hp.com'" Subject: (IPng 1132) Re: ATM interface token for IPv6 In-Reply-To: Your message of "Fri, 12 Jan 96 20:59:38 +0200." <30F6AF9A.4BD1@lohi.dat.tele.fi> Date: Fri, 12 Jan 96 17:41:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha Heinanen wrote: > nothing, it sounds like a very good solution, because it handles well > the problem of getting a unique 48 bit token for each virtual interface > too. This isn't a bad idea, but it's not something that I see involving the datalink, so it would be specified independent of ATM, PPP, or anything else. Since what we're after here is a unique token for the network layer, then the network layer should handle the creation of the random token, the DAD, and the retry when it finds a duplicate. The datalink shouldn't be involved. I think this is especially true if we now think we have two datalinks (ATM and PPP) which already require this. If folks think this is reasonable maybe someone could volunteer to write and I-D for random host token generation for IPv6 (might solve some other problems too). Maybe pull some of this stuff out of the IPv6 PPP draft and make it more generic to it can be applied to any interface which doesn't have it's own MAC or other appropriate token, and to virtual interfaces. This might even be usable on interfaces with MACs if the MAC produces a duplicate address and we want the system to try to proceed with a random token rather than not configuring and requiring manual intervention. I might volunteer if there is consensus that this is a good idea (and no one else wants to do it), but I couldn't make any promises on getting it done by March. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 12 16:05:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02367; Fri, 12 Jan 96 16:05:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02361; Fri, 12 Jan 96 16:05:07 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28745; Fri, 12 Jan 1996 16:04:41 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id QAA12437; Fri, 12 Jan 1996 16:04:41 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id SAA19791; Fri, 12 Jan 1996 18:57:46 -0500 Date: Fri, 12 Jan 1996 18:57:46 -0500 Message-Id: <199601122357.SAA19791@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" To: schulter@zk3.dec.com, Juha Heinanen From: Stephen Thomas Subject: (IPng 1133) Random Interface Tokens (Was: ATM interface token for IPv6) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:41 PM 1/12/96 -0500, schulter@zk3.dec.com wrote: [suggestion to generate link-local tokens via random numbers] >This isn't a bad idea, but it's not something that I see involving the >datalink, so it would be specified independent of ATM, PPP, or anything >else. Such as Frame Relay. >If folks think this is reasonable On first blush I do. I'd like to see a bit of discussion and think it over a bit myself. >maybe someone could volunteer to write and I-D for random host token >generation for IPv6 I was getting ready to put together a Frame Relay I-D anyway. If this random token thing still seems like a good idea on, say, Wednesday, I'd be happy to help put one together. >I might volunteer if there is consensus that this is a good idea >(and no one else wants to do it) If someone else does want to do it (i.e. me), is that an offer to help? ;^) --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 Jan 12 16:14:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02402; Fri, 12 Jan 96 16:14:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02396; Fri, 12 Jan 96 16:14:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00081; Fri, 12 Jan 1996 16:14:11 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id QAA14654; Fri, 12 Jan 1996 16:14:12 -0800 Received: from ppp-pm01-dy-10.opr.oakland.edu (ppp-pm01-dy-10.opr.oakland.edu [141.210.14.171]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id SAA29400; Fri, 12 Jan 1996 18:13:39 -0600 Received: by ppp-pm01-dy-10.opr.oakland.edu with Microsoft Mail id <01BAE121.AA53D0E0@ppp-pm01-dy-10.opr.oakland.edu>; Fri, 12 Jan 1996 19:10:41 -0500 Message-Id: <01BAE121.AA53D0E0@ppp-pm01-dy-10.opr.oakland.edu> From: Brad Wilson To: Juha Heinanen , "'schulter@zk3.dec.com'" Cc: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1134) Re: ATM interface token for IPv6 Date: Fri, 12 Jan 1996 19:10:32 -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 >> This isn't a bad idea, but it's not something that I see involving the >> datalink, True. >> I think this is especially true if we now think >> we have two datalinks (ATM and PPP) which already require this. It appears to me that *ALL* datalinks suffer this. The desire to create multiple IP addresses over a single physical device doesn't have anything to do with any specific device. It would seem to me that the general strategy that works best is: (1) Use a 48-bit token that is moderately unique if possible (such as the ESI on an ATM device, or the MAC address on other devices); if that fails or isn't possible, (2) generate a "random" token (perhaps "steering" the random choice to local use MAC addresses is a SHOULD) This way, EVERY device and EVERY box (regardless of number of virtual IP addresses) can come up stateless. >> This might even be usable on interfaces with MACs >> if the MAC produces a duplicate address and we want the system to >> try to proceed with a random token rather than not configuring and >> requiring manual intervention. Absolutely! This is far more user friendly than "oops, you've collided; get a DHCPv6 server or start picking tokens". I can just imagine the theoretical dentist's office getting a bunch of those Ethernet cards with identical addresses burned into them ... what a quick way to eliminate the benefits of statless configuration. :-( >> I might volunteer if there is consensus >> that this is a good idea (and no one else wants to do it), but I couldn't >> make any promises on getting it done by March. I would also be willing to do it in a much quicker time frame (how about two weeks?) if people are interested. Brad -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Fri Jan 12 17:19:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02470; Fri, 12 Jan 96 17:19:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02464; Fri, 12 Jan 96 17:19:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07848; Fri, 12 Jan 1996 17:18:37 -0800 Received: from noao.edu by mercury.Sun.COM (Sun.COM) id RAA27023; Fri, 12 Jan 1996 17:18:38 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G104) id AA22619; Fri, 12 Jan 96 18:18:30 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA01166; Fri, 12 Jan 96 18:18:30 MST; for ipv6imp@munnari.oz.au Message-Id: <9601130118.AA01166@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Fri, 12 Jan 1996 18:18:29 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 1135) getconninfo()/getaddrinfo() implementation? Cc: posix-net-ptp@nemo.ncsl.nist.gov, ipv6imp@munnari.oz.au Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is anyone aware of an implementation (preferably freely available) of either the IPv6 getconninfo() function (the Internet Draft ) or the Posix .1g getaddrinfo() function? The two functions are nearly identical (the function names and structure member names are different, but that's about it), so either will do. (Hopefully the two will merge into one soon.) I wanted to check with the mailing lists before reinventing the wheel. Rich Stevens ------------------------------------------------------------------------------ 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 Jan 12 21:41:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02573; Fri, 12 Jan 96 21:41:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02567; Fri, 12 Jan 96 21:41:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23784; Fri, 12 Jan 1996 21:40:56 -0800 Received: from cais.cais.com by mercury.Sun.COM (Sun.COM) id VAA23387; Fri, 12 Jan 1996 21:40:57 -0800 Received: from infobro.cais.com (infobro.cais.com [205.161.100.60]) by cais.cais.com (8.6.10/8.6.5) with SMTP id AAA08267; Sat, 13 Jan 1996 00:39:47 -0500 Message-Id: <30F7467F.1F5E@InfoBro.com> Date: Sat, 13 Jan 1996 00:43:27 -0500 From: Eric Williams Organization: Information Brokers, Inc. X-Mailer: Mozilla 2.0b4 (Win95; I) Mime-Version: 1.0 To: Steve Deering Cc: Juha Heinanen , ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1136) Re: ATM interface token for IPv6 References: <96Jan12.075624pst.75270@digit.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > > > every web service provider that i know of use virtual interfaces on the > > same physical ethernet interface. even my web server on my laptop does > > so. if ipv6 autoconfiguration can't cope with that then it is an > > academic protocol that has nothing to do with real life. > > How does ipv4 autoconfiguration cope with it, or is ipv4 also an academic > protocol that has nothing to do with real life? ipv6 copes with it the > same way as ipv4 does. > Steve, As far as I can figure the answer to your question is that the autoconf is _NOT_ supported in the "virtual" domain model used on web servers. In fact I think it is specifically prohibited. Hotep, Eric ------------------------------------------------------------------------------ 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 Jan 13 01:16:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02696; Sat, 13 Jan 96 01:16:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02690; Sat, 13 Jan 96 01:16:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00997; Sat, 13 Jan 1996 01:16:07 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id BAA05148; Sat, 13 Jan 1996 01:16:06 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26057 Sat, 13 Jan 1996 20:15:55 +1100 (from kre@munnari.OZ.AU) To: Brad Wilson Cc: "'ipng@sunroof.eng.sun.com'" , "'ip-atm@matmos.hpl.hp.com'" Subject: (IPng 1137) Re: ATM interface token for IPv6 In-Reply-To: Your message of "Fri, 12 Jan 1996 12:37:53 CDT." <01BAE0EB.1A2CF400@ppp-pm01-dy-14.opr.oakland.edu> Date: Sat, 13 Jan 1996 20:16:10 +1100 Message-Id: <3938.821524570@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 12 Jan 1996 12:37:53 -0500 From: Brad Wilson Message-ID: <01BAE0EB.1A2CF400@ppp-pm01-dy-14.opr.oakland.edu> What's wrong with the random choice? I think we have been over this path before. Currently the design has colission detection, but no collision rectification (ie: collide and you halt). This design assumes that collisions will be extremely rare, which using MAC addresses they probably will be in general. They could be with random choice too, a 48 bit space, there is a lot of scope for lots of numbers, only a very small fraction of which would be used on any particular link (no matter how big it seems). The problem is, however, that essentially no systems have any real way to generate truly random numbers, they're all algorithmic pseudo-random, which for many purposes is fine, but not really for this - you're likely to have 50 pc's all running the same algorithm at the same time and producing the same answers - all colliding, then all stepping off to the same next choice. What's more, this stuff is absolutely not needed - everyone seems to be acting as if the "token" is the one variable part in an address - it need not be. Sites will get at least 64 bits of addr space. With a 48 bit token, there are still 16 bits left (and note the "at least" in the previous line if you are a real big site). The simple thing to do with that is to allow 64K subnets, simply numbering them - that's a hell of a lot of subnets... What could be done, would be to split that into two fields, say 10 bits for subnet (high order 10 bits), and 6 bits to allow every token to generate 64 different addresses on each of those subnets - ie: each interface could generate up to 64 virtual addresses. If that isn't enough, you could have some subnets that are just 4 bits (you could have 15 of those), in which the other 12 bits are available for the node to generate up to 4096 virtual addresses on every interface. The other 4 bit value could be used to be sub-divided into more subnets to handle all your other nodes (VLSM type uses). Of course, there are lots of possible other variations. I think this will handle quite enough uses for anyone, and no need for random anything, which until your average node comes equipped with white noise receptors is something we really should avoid. 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 Sat Jan 13 08:33:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02889; Sat, 13 Jan 96 08:33:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02883; Sat, 13 Jan 96 08:33:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08088; Sat, 13 Jan 1996 08:32:49 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id IAA19736; Sat, 13 Jan 1996 08:32:50 -0800 Received: from ppp-pm01-dy-19.opr.oakland.edu (ppp-pm01-dy-19.opr.oakland.edu [141.210.14.180]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id KAA04098; Sat, 13 Jan 1996 10:32:17 -0600 Received: by ppp-pm01-dy-19.opr.oakland.edu with Microsoft Mail id <01BAE1AA.6DC7A3C0@ppp-pm01-dy-19.opr.oakland.edu>; Sat, 13 Jan 1996 11:29:40 -0500 Message-Id: <01BAE1AA.6DC7A3C0@ppp-pm01-dy-19.opr.oakland.edu> From: Brad Wilson To: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1138) [LONG] Random support for IPv6 auto configuration Date: Sat, 13 Jan 1996 11:29:35 -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 I said ... >> >> What's wrong with the random choice? Robert Elz said ... >> I think we have been over this path before. Currently the >> design has colission detection, but no collision rectification >> (ie: collide and you halt). Which is what I want to fix. >> This design assumes that collisions >> will be extremely rare, which using MAC addresses they probably >> will be in general. Collisions will be rare if you have one IP address over top of one physical interface. If you want to have more, you either need to encroach on more of the bits to the left. And when the collision takes place (ie, someone buys a bunch of those duplicate MAC address cards), then the system administrator must go and hand configure all of those boxes. What is so wrong with planning for this contingency? >> The problem is, however, that essentially no >> systems have any real way to generate truly random numbers, To that end, it's virtually impossible (completely impossible?) to generate _TRULY_ random numbers. _TRULY_ random numbers are not required for this. >> they're all algorithmic pseudo-random, which for many purposes >> is fine, but not really for this I'm definitely not convinced of this. In PPP we have had the need for "random" numbers for quite a long time for Magic Number support. Magic Number support is meant for PPP links to be able to detect when a link is looped back (you're talking to yourself) among other things. The most common thing to do is to seed the random number generator with as many pseudo-random things as you have at your disposal. The following text is from draft-ietf-ipngwg-pppext-ipv6cp-00.txt: 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. (that text, by the way, was taken straight from the Magic Number text in RFC1548). My experience with PPP's Magic Number is that almost everyone on the PC uses the time-of-day clock (specifically, the clock that says how many milliseconds the machine has been alive) as the primary seed for their algorithm. Collisions on Magic Number (which is 32-bit) are virtually non-existant. This text is from RFC 1548 (PPP Link Control Protocol): If the link is indeed looped-back, this sequence (transmit Configure-Request, receive Configure-Request, transmit Configure- Nak, receive Configure-Nak) will repeat over and over again. If the link is not looped-back, this sequence might occur a few times, but it is extremely unlikely to occur repeatedly. More likely, the Magic-Numbers chosen at either end will quickly diverge, terminating the sequence. The following table shows the probability of collisions assuming that both ends of the link select Magic-Numbers with a perfectly uniform distribution: Number of Collisions Probability -------------------- --------------------- 1 1/2**32 = 2.3 E-10 2 1/2**32**2 = 5.4 E-20 3 1/2**32**3 = 1.3 E-29 Good sources of uniqueness or randomness are required for this divergence to occur. If a good source of uniqueness cannot be found, it is recommended that this Configuration Option not be enabled... For 48 bit numbers: 1/2**48 is 1.5 E-15, 1/2**48**2 is 1.2 E-29, and 1/2**48**3 is 4.5 E-44. The likelihood for collision is incredibly miniscule (one could probably argue that it's less likely than MAC address collision :-). >> you're likely to have 50 pc's >> all running the same algorithm at the same time and producing >> the same answers That's where intelligent seed selection comes into play. Choosing the clock that says how many ms the machine has been alive rather than the time right now (which is a horrible seed) is almost 100% guaranteed to give you random results. Even if the machines were turned on at the exact same moment (a feat in itself), it's unlikely that they will send the packet at the exact same millisecond in time. Even if they manage to send that packet at the exact same ms in time, it is far less likely that they will find out they are both colliding and construct a new packet from a new random number at the exact same ms in time AGAIN. Also keep in mind that, even if you have 50 machines each trying the same address time and again, one machine each time would get an address and sooner (or later, with 50 machines :-) everyone would be up and running with no manual configuration. Isn't it the whole point to be as plug-and-play as possible for everyone? What is harm in doing this (other than a possible, though incredibly unlikely, flurry of packets sent out while the machines self-configure themselves)? >> What's more, this stuff is absolutely not needed - everyone >> seems to be acting as if the "token" is the one variable part >> in an address - it need not be. It is, however, the one part of the address that is free from local policy decisions (when running stateless). >> Sites will get at least 64 bits of addr space. With a 48 bit >> token, there are still 16 bits left (and note the "at least" in >> the previous line if you are a real big site). Yes, but by defering to the 64-bit use (which, IMO, eats up address space with something that could be easier handled with the random algorithm) causes the problem to move from stateless to stateful/ manual configuration. Instead of allowing the box to figure itself out automatically, you've deferred the problem into a policy decision at the site and forced them to run DHCPv6 or manual configuration (not to mention you've eaten up subnet space too). Brad -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Sat Jan 13 09:15:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02957; Sat, 13 Jan 96 09:15:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02951; Sat, 13 Jan 96 09:14:53 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08922; Sat, 13 Jan 1996 09:14:25 -0800 Received: from ceres.fokus.gmd.de by mercury.Sun.COM (Sun.COM) id JAA22037; Sat, 13 Jan 1996 09:14:26 -0800 Message-Id: <199601131714.JAA22037@mercury.Sun.COM> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Sat, 13 Jan 1996 18:11:36 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: Brad Wilson Cc: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: (IPng 1139) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Sat, 13 Jan 1996 11:29:35 EST." <01BAE1AA.6DC7A3C0@ppp-pm01-dy-19.opr.oakland.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Jan 1996 18:11:21 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Given that more or more protocols need random numbers (PPP, RTP, IPv6 autoconfig, almost all cryptographic protocols) and that an A/D converter on a thermal noise source (being preferable for practical reasons to the other source of true randomness, nuclear decay) occupies a tiny chip area, maybe someday soon, systems will offer built-in randomness, just like all systems have a time-of-day clock today. The RTP spec (draft-ietf-avt-rtp-*) also contains discussion (and some code) for an RNG. Henning Schulzrinne ------------------------------------------------------------------------------ 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 Jan 13 16:43:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03203; Sat, 13 Jan 96 16:43:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03197; Sat, 13 Jan 96 16:43:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07526; Sat, 13 Jan 1996 16:43:12 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id QAA23322; Sat, 13 Jan 1996 16:42:56 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03517; Sat, 13 Jan 96 19:42:01 EST Received: from [192.32.95.51] (BNE_CS1_Port1) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA26209; Sat, 13 Jan 96 19:42:50 EST Message-Id: <9601140042.AA26209@pobox.BayNetworks.com> To: Brad Wilson , "schulter@zk3.dec.com" , Juha Heinanen Subject: (IPng 1140) Re: ATM interface token for IPv6 Date: Sat, 13 Jan 96 19:45:53 -0500 From: Dimitry Haskin X-Mailer: E-Mail Connection v2.5.03 Cc: "'ip-atm@matmos.hpl.hp.com'" , "ipng@sunroof.Eng.Sun.COM" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -- [ From: Dimitry Haskin * EMC.Ver #2.5.02 ] -- Before we get highly excited over the randomly generated token idea (which is not new) let's recall that, with exception of point-to-point links, one of the important and intended attributes of the link-local address is its stability over time, i.e. it should rarely change even if the node is re- started. This is addressed somewhat in section 6.2.8 the ND spec. Apart from the ND requirements, bellow is an example where permanence of the interface token and, subsequently, the link-local address is very desirable From owner-ipng Sat Jan 13 17:26:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03232; Sat, 13 Jan 96 17:26:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03226; Sat, 13 Jan 96 17:26:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10645; Sat, 13 Jan 1996 17:25:41 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id RAA25903; Sat, 13 Jan 1996 17:25:40 -0800 Received: from ppp-pm01-dy-21.opr.oakland.edu (ppp-pm01-dy-21.opr.oakland.edu [141.210.14.182]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id TAA17025; Sat, 13 Jan 1996 19:25:14 -0600 Received: by ppp-pm01-dy-21.opr.oakland.edu with Microsoft Mail id <01BAE1F4.C3F086A0@ppp-pm01-dy-21.opr.oakland.edu>; Sat, 13 Jan 1996 20:21:48 -0500 Message-Id: <01BAE1F4.C3F086A0@ppp-pm01-dy-21.opr.oakland.edu> From: Brad Wilson To: Brad Wilson , "'Dimitry Haskin'" , Juha Heinanen , "schulter@zk3.dec.com" Cc: "'ip-atm@matmos.hpl.hp.com'" , "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 1141) Re: ATM interface token for IPv6 Date: Sat, 13 Jan 1996 20:21:20 -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 >> Before we get highly excited over the randomly generated token idea (which >> is not new) let's recall that, with exception of point-to-point links, one >> of the important and intended attributes of the link-local address is its >> stability over time, i.e. it should rarely change even if the node is re- >> started. I understand that. I am not suggesting changing the idea that some useful, non-changing token should be tried first. I would suspect that the MAC address is sufficient for this case (as I pointed out in my previous Email). >> In order to configur a static route one needs to specify the outgoing >> interface and the next hop address (luckily for p-to-p links the outgoing >> interface is sufficient). As a non-rhetorical question, why would people statically configure routes when we have router discovery (I'm not very well versed on why static routes would be preferable to router discovery). Brad -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Sat Jan 13 17:48:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03263; Sat, 13 Jan 96 17:48:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03257; Sat, 13 Jan 96 17:47:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14408; Sat, 13 Jan 1996 17:47:30 -0800 Received: from lint.cisco.com by mercury.Sun.COM (Sun.COM) id RAA27474; Sat, 13 Jan 1996 17:47:29 -0800 Received: from pferguso-pc.cisco.com (c2robo6.cisco.com [171.68.13.32]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id RAA28538; Sat, 13 Jan 1996 17:46:20 -0800 Message-Id: <199601140146.RAA28538@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Jan 1996 20:46:51 -0500 To: Brad Wilson From: Paul Ferguson Subject: (IPng 1142) Re: ATM interface token for IPv6 Cc: "ipng@sunroof.Eng.Sun.COM" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:21 PM 1/13/96 -0500, Brad Wilson wrote: > >As a non-rhetorical question, why would people statically configure >routes when we have router discovery (I'm not very well versed on >why static routes would be preferable to router discovery). > > These are two altogether different issues. Static routing can be configured to indicate the location of a particluar destination network by a next-hop address. Router discovery is only useful in discovering gateway [routers] adjacencies. - paul -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s ------------------------------------------------------------------------------ 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 Jan 13 19:42:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03331; Sat, 13 Jan 96 19:42:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03325; Sat, 13 Jan 96 19:41:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21835; Sat, 13 Jan 1996 19:41:25 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id TAA03233; Sat, 13 Jan 1996 19:41:25 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04416; Sat, 13 Jan 96 22:25:29 EST Received: from dima.wellfleet.com (BNE_CS1_Port2) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA29034; Sat, 13 Jan 96 22:26:19 EST Message-Id: <30F87893.3AE6@baynetworks.com> Date: Sat, 13 Jan 1996 22:29:23 -0500 From: Dimitry Haskin Organization: Bay Networks, Inc. X-Mailer: Mozilla 2.0b4 (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Cc: dhaskin@BayNetworks.com Subject: (IPng 1143) Re: ATM interface token for IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I appears my message was truncated. So I'm resending it. ------------------------- Before we get highly excited over the randomly generated token idea (which is not new) let's recall that, with exception of point-to-point links, one of the important and intended attributes of the link-local address is its stability over time, i.e. it should rarely change even if the node is re-started. This is addressed somewhat in section 6.2.8 the ND spec. Apart from the ND requirements, bellow is an example where permanence of the interface token and, subsequently, the link-local address is very desirable. In order to configur a static route one needs to specify the outgoing interface and the next hop address (luckily for p-to-p links the outgoing interface is sufficient). If the next hope address is autoconfigured and a randomly selected token is used to generate this address, one can easily see that every time the next-hop router is re-started all static routes pointing to the router need to be manually reconfigured. I don't think it will be appreciated by our dear network operators. And please don't tell me that static routing is bad and needs to be abolished ;) Dimitry P.S. I like Philip's observation that an E.164 address can be compressed into a 50 bit value. It was also very difficult to miss his 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 Sun Jan 14 00:57:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03409; Sun, 14 Jan 96 00:57:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03403; Sun, 14 Jan 96 00:56:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01388; Sun, 14 Jan 1996 00:56:30 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id AAA18079; Sun, 14 Jan 1996 00:56:29 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01859 Sun, 14 Jan 1996 19:47:26 +1100 (from kre@munnari.OZ.AU) To: Brad Wilson Cc: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1144) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Sat, 13 Jan 1996 11:29:35 CDT." <01BAE1AA.6DC7A3C0@ppp-pm01-dy-19.opr.oakland.edu> Date: Sun, 14 Jan 1996 19:47:41 +1100 Message-Id: <4141.821609261@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 13 Jan 1996 11:29:35 -0500 From: Brad Wilson Message-ID: <01BAE1AA.6DC7A3C0@ppp-pm01-dy-19.opr.oakland.edu> Collisions will be rare if you have one IP address over top of one physical interface. Yes, provided you don't then go fake the MAC addr to add more IP addresses. If you want to have more, you either need to encroach on more of the bits to the left. There's no "or" after that "either" ? And when the collision takes place (ie, someone buys a bunch of those duplicate MAC address cards), They take them back to the vendor and get replacements. They're broken. then the system administrator must go and hand configure all of those boxes. Even if you randomly generate the IP addresses, these broken cards still all have the same MAC address, so you'd need to be randomly generating that too. What is so wrong with planning for this contingency? One thing is that it is sending a message to the vendors that getting the MAC addresses unique is not real important for IPv6. On the other hand if systems with dup MAC addresses fail to work reasonably with IPv6, then manufacturers are more likely to get them right (they have more incentive). The occasional accidents that will always happen aren't important, the dups aren't likely to appear on the same link. Suggested sources of uniqueness include machine serial numbers, which many nodes don't have (distinct from the MAC addr anyway, besides, if you postulate lots of nodes with the same mac addr, they're even more likely to have the same serial number) other network hardware addresses, all nodes are identical time-of-day clocks, etc. Its the same time of day - and more, all nodes have been started after power on at the same instant. They're all running the exact same code out of the identical prom images... For PPP, with just two parties to deal with, and quite likely made by different manufacturers, and/or reasonably complex equipment at that, I would accept that random generation, and have no problem with it. For all IPv6 nodes, sorry, no way. Note this (from your message, and I suspect from 1548)... Good sources of uniqueness or randomness are required for this divergence to occur. If a good source of uniqueness cannot be found, it is recommended that this Configuration Option not be enabled... I doubt that good sources of uniqueness or randomness exist in *all* IPv6 nodes. That's where intelligent seed selection comes into play. Choosing the clock that says how many ms the machine has been alive rather than the time right now (which is a horrible seed) is almost 100% guaranteed to give you random results. How so? Consider the much touted light bulbs - they all turn on within a few microseconds of each other when the switch is operated... Even if the machines were turned on at the exact same moment (a feat in itself), You're imagining only the kinds of workstation (PC) type things we now connect to the net - for IPv6 we want lots more kinds of nodes, includeing kinds that we can't imagine today. it's unlikely that they will send the packet at the exact same millisecond in time. Why? What makes them diverge? Consider production line equipment, all stamped out exactly identically. Isn't it the whole point to be as plug-and-play as possible for everyone? Yes, and for that to work, we require one unique element of every node - that being the MAC address. If the nodes are to differ at all, they may as well differ that way. It [the token] is, however, the one part of the address that is free from local policy decisions (when running stateless). Yes, but a node running lots of virtual interfaces (which is what started this stream, where use of random MAC addresses was postulated) you already have local policy decisions, and can reasonably depend on those existing. Sites planning on runnig with hundreds, or thousands, of virtual interfaces can easily plan their addressing structure to do this - and further, as Dimitry pointed out, can do it in a way that will keep all those addresses quite stable (as stable as is possible). Yes, but by defering to the 64-bit use (which, IMO, eats up address space with something that could be easier handled with the random algorithm) Again, another place this argument comes from was the decision (or proposal) by the ATM people to use 64 bit tokens, apparently because they have a different use for virtual addresses than running HTTP servers for virtual domains (a truly bogus motivation). The effect there would be that any site with even one ATM link (numberer from their space) would require either bigger than 64 bits of address space, or to dedicate their entire address space to the one ATM link. That is a waste. causes the problem to move from stateless to stateful/ manual configuration. I'm afraid I'm a little lost where you're coming from here. That is, I'm not sure exactly what problem you're referring to. If you're concerned aout virtual domains for WWW servers, then there already is manual configuration. Most of the address generation can still be automated - the prefix still comes from the RAs, the token from the MAC addr, the box then has configured "this server is virtual addr 0, this is virtual 1, this is virtual 2, ..." and takes that number and sticks it between the prefix and token when generating addresses (except for link local, where none of this is relevant). On the other hand, if all you're concerned about is duplicate MAC addresses on a link, then we have already decided that the all the mechanism isn't worth it for the small likely benefit. Dup mac addresses are a manufacturing bug - as much as devices that overheat, drives that don't rotate, etc, and should be returned for exchange in exactly the same way as you would for any of the other problems. 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 Sun Jan 14 09:11:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03627; Sun, 14 Jan 96 09:11:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03621; Sun, 14 Jan 96 09:11:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09534; Sun, 14 Jan 1996 09:10:36 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id JAA04569; Sun, 14 Jan 1996 09:10:36 -0800 Received: from ppp-pm01-dy-28.opr.oakland.edu (ppp-pm01-dy-28.opr.oakland.edu [141.210.14.189]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id LAA15159; Sun, 14 Jan 1996 11:10:13 -0600 Received: by ppp-pm01-dy-28.opr.oakland.edu with Microsoft Mail id <01BAE278.D3A3F300@ppp-pm01-dy-28.opr.oakland.edu>; Sun, 14 Jan 1996 12:07:08 -0500 Message-Id: <01BAE278.D3A3F300@ppp-pm01-dy-28.opr.oakland.edu> From: Brad Wilson To: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1145) RE: [LONG] Random support for IPv6 auto configuration Date: Sun, 14 Jan 1996 12:07:03 -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 I think you're missing the major point of my messages. Robert Elz[SMTP:kre@munnari.OZ.AU] writes: >> then the system administrator must go and >> hand configure all of those boxes. >> >> Even if you randomly generate the IP addresses, these broken cards >> still all have the same MAC address, so you'd need to be randomly >> generating that too. That's an MAC issue. There's no technical reason that multiple cards with the identical MAC address couldn't live on the same Ethernet (although I'm not sure about other media, but Ethernet is where the bulk of the problem exists, right?) >> What is so wrong with planning for this contingency? >> >> One thing is that it is sending a message to the vendors that >> getting the MAC addresses unique is not real important for IPv6. I would rather give vendors a little leeway than to penalize the consumers, who get squeezed in the middle of our little political posturing. I would think -- maybe I'm wrong here? -- that anyone should be able to buy a network card, install it, and be up and running with IPv6. Regardless of who makes the card and whether or not there's a dup MAC address on the link. I would think being able to do that would be a GOOD thing for consumers, and definitely in line with the IPv6 philosophy. Perhaps you disagree. >> The occasional >> accidents that will always happen aren't important, the dups aren't >> likely to appear on the same link. Why not eliminate the possibility that even the occasional accident won't immobilize some node(s)? >> For PPP, with just two parties to deal with, and quite likely >> made by different manufacturers, and/or reasonably complex >> equipment at that, I would accept that random generation, and >> have no problem with it. For most of the cases where people want virutal IP addresses over top of a single physical connection (don't argue that it's stupid, because people want it, whether you like it or not), those machines are typically quite complex. >> For all IPv6 nodes, sorry, no way. Almost all IPv6 nodes are adequately serviced by use of MAC address anyway, so what's the objection here? I'm not saying we should REPLACE the use of the MAC address, just use the random possibility as an _optional_ fallback to getting things running. >> Note this (from your message, and I suspect from 1548)... >> >> Good sources of uniqueness or randomness are required for this >> divergence to occur. If a good source of uniqueness cannot be >> found, it is recommended that this Configuration Option not be >> enabled... >> >> I doubt that good sources of uniqueness or randomness exist >> in *all* IPv6 nodes. So? If they can't generate random numbers then they cannot use this optional fallback method. They're no worse off than the case now (where NOBODY has any fallback method at all). >> That's where intelligent seed selection comes into play. Choosing >> the clock that says how many ms the machine has been alive rather >> than the time right now (which is a horrible seed) is almost 100% >> guaranteed to give you random results. >> >> How so? Consider the much touted light bulbs - they all turn on >> within a few microseconds of each other when the switch is >> operated... Are the light bulbs likely to have colliding MAC addresses? Do the light bulbs HAVE to use the random fallback? -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Sun Jan 14 10:08:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03705; Sun, 14 Jan 96 10:08:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03699; Sun, 14 Jan 96 10:07:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10857; Sun, 14 Jan 1996 10:07:24 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id KAA07615; Sun, 14 Jan 1996 10:07:19 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15824 Mon, 15 Jan 1996 04:56:33 +1100 (from kre@munnari.OZ.AU) To: Brad Wilson Cc: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1146) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Sun, 14 Jan 1996 12:07:03 CDT." <01BAE278.D3A3F300@ppp-pm01-dy-28.opr.oakland.edu> Date: Mon, 15 Jan 1996 04:56:48 +1100 Message-Id: <4375.821642208@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 14 Jan 1996 12:07:03 -0500 From: Brad Wilson Message-ID: <01BAE278.D3A3F300@ppp-pm01-dy-28.opr.oakland.edu> For most of the cases where people want virutal IP addresses over top of a single physical connection (don't argue that it's stupid, because people want it, whether you like it or not), those machines are typically quite complex. Again, I'm lost, are you arguing in favour of random IP addresses for eliminating problems with duplicates, or for allowing a node to generate multiple addresses to use all at once. The two cases are quite different. Nodes with multiple addresses are likely to be complex, and if you assume they have a unique mac address already, start out with a nice unique number upon which to base future random numbers. However doing things this way means that all IP addreses a node generates (even the first) must be tested for uniqueness (DAD), rather than just the link local addr, and have to be tested every time they alter (link local addresses don't alter). All of that's not required, just sticking to the one MAC addr, supplied by the manufacturer, and tested for uniqueness as part of the link local addr allows generation of as many (known unique) secondary addresses, either with the same or different prefixes, as the node requires. On the other hand, for dup MAC address protection, there is no guaranteed nice unique number upon which to base pseudo-random numbers, further, the situation is very unlikely (ocassionally you hear reports about nodes on the same cable with dup addrs, they're very infrequent) - but if it is to be handled we would need to worry how to handle nets that are partitioned when the dup addr test is done (by assuming only manufacturer unique MAC addresses, we also assume that the chances of dups that way is so remote we can ignore it), basically, nodes would need lots of baggage (all nodes) just to handle a case that in practice arises so infrequently it isn't worth the bother. I mean, we have manufacturers these days manufacturing computers with no verification of memory contents at all - simply assume that memory doesn't ever go bad. We know that's not true, but the cost saving is deemed worth the hassle. The combination of both (seemingly) useless code for MAC addreses that in practice are never duplicate, plus the invitation to actually go and generate dups as IPv6 is "supposed to handle it" is too much for me. Are the light bulbs likely to have colliding MAC addresses? Probably not the high price well made ones - but your cheap Australian imports will all be stamped out identically, saves costs, and IPv6 can cope, can't it - so they'll all come with the same MAC addr, probably 48 bits of ones (cheap to generate). If you want to continue this, please indicate which of the two scenarios you really want to use random generation of MAC-like addresses to solve - they're so different that attempting to argue about both in one message can get very confusing. 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 Sun Jan 14 11:40:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03770; Sun, 14 Jan 96 11:40:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03764; Sun, 14 Jan 96 11:39:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12894; Sun, 14 Jan 1996 11:39:18 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id LAA17961; Sun, 14 Jan 1996 11:39:17 -0800 Received: from ppp-pm01-dy-11.opr.oakland.edu (ppp-pm01-dy-11.opr.oakland.edu [141.210.14.172]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id NAA26365; Sun, 14 Jan 1996 13:38:57 -0600 Received: by ppp-pm01-dy-11.opr.oakland.edu with Microsoft Mail id <01BAE28D.9C476260@ppp-pm01-dy-11.opr.oakland.edu>; Sun, 14 Jan 1996 14:35:54 -0500 Message-Id: <01BAE28D.9C476260@ppp-pm01-dy-11.opr.oakland.edu> From: Brad Wilson To: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1147) Re: [LONG] Random support for IPv6 auto configuration Date: Sun, 14 Jan 1996 14:35:51 -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 >> Again, I'm lost, are you arguing in favour of random IP addresses >> for eliminating problems with duplicates, or for allowing a node >> to generate multiple addresses to use all at once. What I am saying is this: Problem 1: Some nodes need multiple IP addresses over a single physical link. Problem 2: Some nodes do not have a MAC address from which to generate an address "token". Problem 3: Some nodes (a very small number) are going to have colliding "token"s (be they MAC address, or the ESI portion of an ATM address, or whatever). All three of these problems can (usually) be solved by saying this: Step 1: If a "unique" token like a MAC address is available, take the 48-bit token and test it for collisions using DAD. If the token is unique, use it to form your IP address(es) for that (potentially virtual) interface. Step 2: [OPTIONAL, requires moderately good seed of randomness] If step 1 fails, or if you do not have a reasonably unique token to start with, randomly generate a 48-bit token and do DAD on it to guarantee it's unique on your link. Repeat Step 2 until you have a unique token or until you are convinced that you cannot generate a unique token (some upper bound on the number of times you will try). Step 3: If all else fails, use manual or stateful configuration. Now, in this scenario, all I've done is stick step 2 in between step 1 and 3. The only difference between what I want to do and what is current is allowing the box to optionally generate a random token from which to create an address. Note that in PPP, step 1 isn't possible, so its current scenario is to simply keep pounding on step 2 until it gets an address, or to require manual/stateful configuration. >> Nodes with multiple addresses are likely to be complex, and >> if you assume they have a unique mac address already, start out >> with a nice unique number upon which to base future random >> numbers. Yes, I agree. MAC addresses are good random seeds. >> However doing things this way means that all IP >> addreses a node generates (even the first) must be tested for >> uniqueness (DAD), rather than just the link local addr, and >> have to be tested every time they alter (link local addresses >> don't alter). I'm not sure what you're trying to say here. The 48-bit token only needs to be unique on your link. Every address you use must be tested for uniqueness every time you start up, whether or not you use my scenario. What extra work am I creating? >> On the other hand, for dup MAC address protection, there is no >> guaranteed nice unique number upon which to base pseudo-random >> numbers Who needs guarantees? I'm talking about some optional method that should fix almost all of the above scenarios. In the unlikely case that you have two machines with dup MAC addresses and they try 4 or 5 address and collide with each other every time, then they will need to shut down the network support and wait for manual or stateful config. But you've not regressed any. This would be the case even without my step 2 above. At least there was an attempt (and in most cases, success) at getting an address to at least get up and running. >> basically, nodes would need >> lots of baggage (all nodes) just to handle a case that in practice >> arises so infrequently it isn't worth the bother. I'm not sure what you're trying to say here. Do you think trying to generate a random address is "lots of baggage"? If you do, you don't need to implement it. It would not be mandatory. And as I pointed out above, dup MACs is only one problem that it solves. -- class CBradWilson : public CWorldWatchProgrammingTeam { public: CString GetInetAddr() { return CString("bradw@exptech.com"); } CString GetPhone() { return CString("+1 (810) 620-9803"); } CString GetURL() { return CString("http://www.exptech.com"); } 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 Sun Jan 14 15:03:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03997; Sun, 14 Jan 96 15:03:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03991; Sun, 14 Jan 96 15:03:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17896; Sun, 14 Jan 1996 15:03:20 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id PAA28582; Sun, 14 Jan 1996 15:03:21 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA28598; Sun, 14 Jan 1996 17:58:38 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16700; Sun, 14 Jan 1996 17:58:37 -0500 Message-Id: <9601142258.AA16700@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1148) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Fri, 12 Jan 96 13:37:09 EST." <199601121837.NAA00505@hygro.raleigh.ibm.com> Date: Sun, 14 Jan 96 17:58:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At this point the DHCPv6 spec needs updates per Dallas. For this subject I will list all the alternatives including the Relay-Node keeping state and using tunneling. I am now treating the Relay-Agent as an Application Gateway in one scenario which is really what it is not a router. It just dawned on me that the next IETF is March 4-8. Thats coming quick. I am going to ask the DHCPv6 WG if they want to have a joint meeting with IPv6 for any overlaps at L.A. meetings. /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 Sun Jan 14 16:05:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04026; Sun, 14 Jan 96 16:05:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04020; Sun, 14 Jan 96 16:05:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20487; Sun, 14 Jan 1996 16:04:49 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id QAA02340; Sun, 14 Jan 1996 16:04:50 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA06845; Sun, 14 Jan 1996 18:56:25 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18743; Sun, 14 Jan 1996 18:56:24 -0500 Message-Id: <9601142356.AA18743@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1149) Re: ND Asst for Security Issue for DHCPv6? In-Reply-To: Your message of "Sun, 14 Jan 96 17:58:37 EST." <9601142258.AA16700@fwasted.zk3.dec.com> Date: Sun, 14 Jan 96 18:56:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk CORRECTION: >I am going to ask the DHCPv6 WG if they want to have a joint meeting >with IPv6 for any overlaps at L.A. meetings. This is all the same WG which is DHC. Mean't to say if the DHCPv6 mailing list of the DHC WG feels a joint meeting might be useful. We have two lists now. One for DHCPv4 and one for 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 Sun Jan 14 16:28:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04038; Sun, 14 Jan 96 16:28:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04032; Sun, 14 Jan 96 16:28:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22038; Sun, 14 Jan 1996 16:28:17 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id QAA03872; Sun, 14 Jan 1996 16:28:16 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA31525; Sun, 14 Jan 1996 19:24:18 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18477; Sun, 14 Jan 1996 19:24:17 -0500 Message-Id: <9601150024.AA18477@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1150) IPv6 ND for NBMA "Goal" (specifically for ATM) Date: Sun, 14 Jan 96 19:24:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, [FIRST: PLEASE DO NOT LET THIS DISCUSSION DRIFT INTO WHETHER ANYONE BELIEVES ATM IS A VIABLE, GOOD, OR COST EFFECTIVE SOLUTION FOR NETWORKING OK THATS NOT THE INTENT OF THIS THREAD ---> THANKS] Greeville Armitage and Peter Schulter have done a yeomans job of making the rolc and ip-atm WGs aware of the different needs for IPv6 in their drafts for ATM. I think though that I am hearing different background noises on what the objective of IPv6 is generally, and more specifically for ND being used by ATM. First, IPv6 is an architecture and a set of specifications. I assume it is a "goal" (objective) that adherence to the "core" architecture and base specifications is an objective of all future work to support IPv6 in the IETF. We are seeing this in the OSPFv6 and DHCPv6 work as two examples. I do not think that ATM should be an exception to this "goal". Peter has designed an architecture for IPv6 over ATM which will support IPv6 ND, Addr Conf, and DHCPv6. Greenville has also done work in this area and for Multicast. I think both Greenville and Peter are on the right course for IPv6 for ATM as one NBMA Technology, though they have differences clearly in strategy. At least for me when IPv6 and ND and other specs were first envisioned it was mean't to be a goal to provide ND as one example over NBMA. I think it should remain a goal. Does anyone disagree with this "goal"? 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 Sun Jan 14 22:54:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04234; Sun, 14 Jan 96 22:54:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04228; Sun, 14 Jan 96 22:53:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08285; Sun, 14 Jan 1996 22:53:24 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id WAA27780; Sun, 14 Jan 1996 22:53:22 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05343 Mon, 15 Jan 1996 17:32:35 +1100 (from kre@munnari.OZ.AU) To: Brad Wilson Cc: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1151) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Sun, 14 Jan 1996 14:35:51 CDT." <01BAE28D.9C476260@ppp-pm01-dy-11.opr.oakland.edu> Date: Mon, 15 Jan 1996 17:32:50 +1100 Message-Id: <4423.821687570@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 14 Jan 1996 14:35:51 -0500 From: Brad Wilson Message-ID: <01BAE28D.9C476260@ppp-pm01-dy-11.opr.oakland.edu> Problem 1: Some nodes need multiple IP addresses over a single physical link. That one can be better solved without randomising anything. Problem 2: Some nodes do not have a MAC address from which to generate an address "token". Nodes on links where MAC addresses are used as the token will have a MAC address. Nodes on other links will have other methods defined for generating their unique address - not all links are in any way suitable for random generation, as there isn't necessarily a way to reasonably contact all other nodes to test whether any others have picked the same random number. Then all you're left with is the occasional dup assigned MAC addr that has already been discussed and decided that invented MAC addresses are not the solution. The 48-bit token only needs to be unique on your link. Every address you use must be tested for uniqueness every time you start up, whether or not you use my scenario. What extra work am I creating? No, the current design uses "known uniqueueness" to avoid most of the testing. That is, you verify that your link local address is unique on your link, because everyone generates link locals the same way, that guarantees that your token is unique. Then, you can combine that token with any other prefix on the same link, and know that the address you have created is unique on the link as well, as no-one else has that token to combine with the prefix. Hence, only one address test (per link) is required, however many addresses you actually need to generate - be they multiple addresses from different prefixes (for whatever reason), or multiple addresses from the same prefix because you want to pose as a whole set of virtual hosts for whatever reason. This works, provided you don't go altering your token, and nor does anyone else. I'm not sure what you're trying to say here. Do you think trying to generate a random address is "lots of baggage"? If you do, you don't need to implement it. It would not be mandatory. And as I pointed out above, dup MACs is only one problem that it solves. I'm afraid I don't believe that. If all anyone uses is their own assigned MAC address, then I am willing to allow the occasional conflict, which should be rare, and simply shut down and have the hardware fixed (a clash is clearly a manufacturing bug). On the other hand, if other nodes are to be permitted to generate random MAC addresses, either because they have detected a duplicate, or because they have decided they need a thousand different IP addresses, and fiddling the token is the way that was designed, then I would be obliged to implement the random selection of addresses as well - then I could not simply say "broken hardware" if someone has randomly picked my MAC addr, as nothing is actually broken. If I encounter a conflict I would have to go choose a new address, and what's more, I'd have to do that even if I have no good source of even pseudo-random numbers, and my "random number" consists of adding 13 to the last number I chose. Not doing that would make my product clearly deficient in the marketplace, so even if the standard says "optional", it would not be truly optional. 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 Mon Jan 15 01:59:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04360; Mon, 15 Jan 96 01:59:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04354; Mon, 15 Jan 96 01:59:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14268; Mon, 15 Jan 1996 01:58:58 -0800 Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM) id BAA11138; Mon, 15 Jan 1996 01:58:57 -0800 Received: from [138.96.24.178] by pax.inria.fr (8.6.12/8.6.12) with SMTP id KAA03452; Mon, 15 Jan 1996 10:56:22 +0100 Date: Mon, 15 Jan 1996 10:56:22 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Elz From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1152) Re: [LONG] Random support for IPv6 auto configuration Cc: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:32 PM 15/1/96, Robert Elz wrote: >On the other hand, if other nodes are to be permitted to >generate random MAC addresses, either because they have detected >a duplicate, or because they have decided they need a thousand >different IP addresses, and fiddling the token is the way that >was designed, then I would be obliged to implement the random >selection of addresses as well - then I could not simply say >"broken hardware" if someone has randomly picked my MAC addr, >as nothing is actually broken. If I encounter a conflict I >would have to go choose a new address, and what's more, I'd have >to do that even if I have no good source of even pseudo-random >numbers, and my "random number" consists of adding 13 to the last >number I chose. Not doing that would make my product clearly >deficient in the marketplace, so even if the standard says >"optional", it would not be truly optional. IEEE-802 addresses start with two bits, one to distinguish Individual and Group addresses (I/G) and another to distinguish Universal and Local allocation (U/L). Only those addresses where I/G=0 and U/L=0 are expected to be world-wide unique. I would expect that anyone playing the random allocation game would only pick 46 random bits, leaving I/G to 0 and U/L to 1. They may collide with other randomees - and maybe with Decnet configurations - but only broken hardware would collide with your address. 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 Mon Jan 15 02:01:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04372; Mon, 15 Jan 96 02:01:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04366; Mon, 15 Jan 96 02:01:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14324; Mon, 15 Jan 1996 02:00:58 -0800 Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM) id CAA11452; Mon, 15 Jan 1996 02:00:57 -0800 Received: from [138.96.24.178] by pax.inria.fr (8.6.12/8.6.12) with SMTP id KAA03444; Mon, 15 Jan 1996 10:56:20 +0100 Date: Mon, 15 Jan 1996 10:56:20 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Brad Wilson From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1153) Re: [LONG] Random support for IPv6 auto configuration Cc: "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:29 AM 13/1/96, Brad Wilson wrote: >That's where intelligent seed selection comes into play. Choosing >the clock that says how many ms the machine has been alive rather >than the time right now (which is a horrible seed) is almost 100% >guaranteed to give you random results. Even if the machines were >turned on at the exact same moment (a feat in itself), it's unlikely >that they will send the packet at the exact same millisecond in >time. On the subject of random number generation, I suggest you read RFC-1750, "Randomness requirements for security". It recalls a very simple truth, i.e. that the randomness and unpredictability of the generated numbers is at most equal to that of the seed. That is, if you want 48 random bits, then you need to seed your generator with 48 unpredictable bits. Suppose the worst case of simultaneous powering up many machines. Yes, the millisecond clocks will drift, yes, the packets will not be sent at quite the same millisecond. But then, how many random bits does this make ? I would say, a couple. The millisecond clocks will not differ by much more than a second, which is ten bits. The probability of collision is then at least 1 E-3, not 1 E-29. Users in the field are going to notice that. When it come to making random numbers, software engineers have a very poor record -- the recent netscape fiasco is yet another example. Basically, KRE initial response was right, you need a random noise generator. You may in some case use the microsecond timing of at least 48 keystrokes, or get a few second of digitalized noise from the mike of the sound board. But then, how do you make sure that the mike is plugged ? How do you obtain keystroke in a light bulb controller ? 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 Mon Jan 15 06:52:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04562; Mon, 15 Jan 96 06:52:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04556; Mon, 15 Jan 96 06:52:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23626; Mon, 15 Jan 1996 06:52:00 -0800 Received: from centaur.cs.vu.nl by mercury.Sun.COM (Sun.COM) id GAA05499; Mon, 15 Jan 1996 06:51:59 -0800 Received: from cs.vu.nl (127.0.0.1) by centaur.cs.vu.nl with esmtp (Smail3.1.28.1 #23) id m0taqaG-00017yC; Fri, 12 Jan 96 22:00 +0100 Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 1154) Re: IPv6/ATM link local token (was Re: proposal...) In-Reply-To: Your message of "Thu, 11 Jan 1996 16:43:20 -0500 ." <199601112143.QAA07769@thumper.bellcore.com> Date: Fri, 12 Jan 1996 22:00:21 +0100 From: Philip Homburg Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I tried to send this to both the atm list and the ipng list. Unfortunately, the atm list got multiple copies, the ipng list got none and the mailer on my workstation dumped core.] >I'm going to update the ip-atm group's I-D on this topic by >the end of February (its been out since August) based on conclusions >reached by the ip-atm WG on this thread. I'm not particularly concerned >what mechanism the ip-atm group converges on, just so long as we've >discussed on the list the implications of our design choices. For now >I think I should leave this thread to others. Just a random remark: according to my calculator (python), a 15 digit number is slightly less than 50 bits. So you only need to squeeze out 2 bits to get an E.164 address into a 48 bit field. Philip Homburg ------------------------------------------------------------------------------ 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 Jan 15 09:27:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04729; Mon, 15 Jan 96 09:27:05 PST Date: Mon, 15 Jan 96 09:27:05 PST From: owner-ipng Message-Id: <9601151727.AA04729@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Mon Jan 15 09:57:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04768; Mon, 15 Jan 96 09:57:58 PST Date: Mon, 15 Jan 96 09:57:58 PST From: owner-ipng Message-Id: <9601151757.AA04768@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Mon Jan 15 10:15:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04822; Mon, 15 Jan 96 10:15:24 PST Date: Mon, 15 Jan 96 10:15:24 PST From: owner-ipng Message-Id: <9601151815.AA04822@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Mon Jan 15 11:25:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04841; Mon, 15 Jan 96 11:25:25 PST Date: Mon, 15 Jan 96 11:25:25 PST From: owner-ipng Message-Id: <9601151925.AA04841@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Mon Jan 15 13:32:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04937; Mon, 15 Jan 96 13:32:15 PST Date: Mon, 15 Jan 96 13:32:15 PST From: owner-ipng Message-Id: <9601152132.AA04937@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Mon Jan 15 14:52:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05008; Mon, 15 Jan 96 14:52:53 PST Date: Mon, 15 Jan 96 14:52:53 PST From: owner-ipng Message-Id: <9601152252.AA05008@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Mon Jan 15 18:36:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05173; Mon, 15 Jan 96 18:36:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05167; Mon, 15 Jan 96 18:36:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19529; Mon, 15 Jan 1996 18:35:45 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id SAA00084; Mon, 15 Jan 1996 18:35:45 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id VAA14037 for ; Mon, 15 Jan 1996 21:35:40 -0500 Date: Mon, 15 Jan 1996 21:35:40 -0500 Message-Id: <199601160235.VAA14037@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" To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 1155) Re: Random Interface Tokens (Was: ATM interface token for IPv6) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:57 PM 1/12/96 -0500, Stephen Thomas wrote: >At 05:41 PM 1/12/96 -0500, schulter@zk3.dec.com wrote: > >[suggestion to generate link-local tokens via random numbers] > >>This isn't a bad idea, but it's not something that I see involving the >>datalink, so it would be specified independent of ATM, PPP, or anything >>else. > >Such as Frame Relay. Following up on my own message, but I don't think random tokens will work for Frame Relay. Since Frame is non-broadcast, multi-access, duplicate address detection (at least as it's currently spec'd) won't work. (Two nodes, A & B, might each have a VC with node C. If they don't have a connection with each other, though, there would be no way for DAD to detect that they had chosen the same address in their connection with C.) Might still be useful for other technologies, though. --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 Tue Jan 16 07:23:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05501; Tue, 16 Jan 96 07:23:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05495; Tue, 16 Jan 96 07:23:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03613; Tue, 16 Jan 1996 07:22:46 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id HAA18746; Tue, 16 Jan 1996 07:22:45 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17297; Tue, 16 Jan 96 10:21:51 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA01471; Tue, 16 Jan 96 10:22:42 EST Date: Tue, 16 Jan 96 10:22:42 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601161522.AA01471@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1156) tunnel links and ND Cc: dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Has anyone given any thoughts of the scope of Autoconfiguration and/or ND support on an IPv6 link that constitutes a tunnel over another network layer protocol or IPv6 itself? I can see how Router Advertisement and NUD can be useful on such links. Can they? I can see two types of tunnel links: 1) point-to-point links, where a tunnel connections is established between two endpoints; and 2) point-to-multipoint links, where an IPv6 logical interface can be used to communicate with multiple destinations. An example of such a link would be an IPv6-over-IPv4 automatic tunnel where an IPv6 logical interface is used to sent packets to and receive packets from multiple IPv6 points. I'd probably classify such links as non-broadcast multiple access (NBMA). The ND spec is not clear (may be deliberately) on this subject. If people agree that some ND features (e.g. RA) can be used on tunnel links, rules for forming link-local addresses on such links need to be defined too. Thoughts? 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 Jan 16 09:14:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05592; Tue, 16 Jan 96 09:14:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05586; Tue, 16 Jan 96 09:13:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16496; Tue, 16 Jan 1996 09:13:20 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id JAA15987; Tue, 16 Jan 1996 09:13:18 -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 SAA17502; Tue, 16 Jan 1996 18:13:07 +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 SAA19071; Tue, 16 Jan 1996 18:13:06 +0100 Message-Id: <199601161713.SAA19071@givry.inria.fr> From: Francis Dupont To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1157) Re: tunnel links and ND In-Reply-To: Your message of Tue, 16 Jan 1996 10:22:42 EST. <9601161522.AA01471@pobox.BayNetworks.com> Date: Tue, 16 Jan 1996 18:12:57 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Has anyone given any thoughts of the scope of Autoconfiguration and/or ND support on an IPv6 link that constitutes a tunnel over another network layer protocol or IPv6 itself? ... 2) point-to-multipoint links, where an IPv6 logical interface can be used to communicate with multiple destinations. An example of such a link would be an IPv6-over-IPv4 automatic tunnel where an IPv6 logical interface is used to sent packets to and receive packets from multiple IPv6 points. I'd probably classify such links as non-broadcast multiple access (NBMA). => my idea about this problem is to use NHRP (because IPv4 is a large cloud :-)... The ND spec is not clear (may be deliberately) on this subject. If people agree that some ND features (e.g. RA) can be used on tunnel links, rules for forming link-local addresses on such links need to be defined too. => ND is far more than ARP and more than ISO ES-IS but even with external redirects and such like that I don't believe ND is a replacement for NHRP too. But this subject clearly needs more! Regards Francis.Dupont@inria.fr PS: if we want to use native (ie *real*) IPv6 addresses today we need configurated tunnels over the Internet between IPv6 islands. Of course we don't want to be stuck with manual configuration then we need something: ND is not enough, real IPv6 is too much and too soon, NHRP seems to do the job (and it is far less expensive to use the Internet than ATM if you are a NHRP hater and you want to show ugly static loops :-). ------------------------------------------------------------------------------ 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 Jan 16 09:15:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05604; Tue, 16 Jan 96 09:15:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05598; Tue, 16 Jan 96 09:15:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16732; Tue, 16 Jan 1996 09:14:38 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id JAA16360; Tue, 16 Jan 1996 09:14:32 -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 SAA17531 for ; Tue, 16 Jan 1996 18:14:28 +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 SAA19080 for ; Tue, 16 Jan 1996 18:14:27 +0100 Message-Id: <199601161714.SAA19080@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: (IPng 1158) IPv6 minimal support for BIND Release 4.9.3 Date: Tue, 16 Jan 1996 18:14:17 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have upgraded my old set of diffs for BIND to the last release. It provides minimal support for IPv6 (ie AAAA RRs are understood, read, written, ...). It is available in: ftp://ftp.inria.fr/network/ipv6/bind-4.9.3-REL.ipv6-diffs Francis.Dupont@inria.fr PS: it works with Patch1 too... ------------------------------------------------------------------------------ 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 Jan 16 10:56:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05860; Tue, 16 Jan 96 10:56:37 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05309; Mon, 15 Jan 96 23:33:18 PST Received: from picadilly.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA23014; Mon, 15 Jan 1996 23:32:15 -0800 Received: by picadilly.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA05491; Mon, 15 Jan 1996 19:31:50 -0800 Date: Mon, 15 Jan 1996 19:31:50 -0800 From: sparker@caribe-86 (Steve Parker) Message-Id: <199601160331.TAA05491@picadilly.eng.sun.com> To: ipng@sunroof Subject: (IPng 1159) Administrivia--messages lost. Cc: jrh@caribe-86, sxn@caribe-86, cathe@caribe-86 X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you noticed several messages like this today: ----- Begin Included Message ----- >From owner-ipng@sunroof Mon Jan 15 14:53 PST 1996 Date: Mon, 15 Jan 96 14:52:53 PST From: owner-ipng@sunroof ----- End Included Message ----- A transient disk-full problem caused the loss of several postings to this list. The problem has been corrected. If you did not see a posting you made today reflected back to you, you should re-post. Sorry for the inconvenience, ~sparker ------------------------------------------------------------------------------ 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 Jan 16 11:43:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05965; Tue, 16 Jan 96 11:43:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05959; Tue, 16 Jan 96 11:43:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13707; Tue, 16 Jan 1996 11:43:11 -0800 Received: from ncc.ripe.net by mercury.Sun.COM (Sun.COM) id LAA10467; Tue, 16 Jan 1996 11:43:08 -0800 Received: from berklix.ripe.net by ncc.ripe.net with SMTP id AA22974 (5.65a/NCC-2.30); Tue, 16 Jan 1996 20:43:06 +0100 Received: from berklix.ripe.net (geertj@localhost.ripe.net [127.0.0.1]) by berklix.ripe.net (8.7.3/8.6.9) with ESMTP id KAA00237; Tue, 16 Jan 1996 10:16:11 +0100 (MET) Message-Id: <199601160916.KAA00237@berklix.ripe.net> To: Robert Elz Cc: Brad Wilson , "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 1160) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Sun, 14 Jan 1996 19:47:41 +1100." <4141.821609261@munnari.OZ.AU> Date: Tue, 16 Jan 1996 10:16:10 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 14 Jan 1996 19:47:41 +1100 Robert Elz wrote: > And when the collision takes place (ie, someone buys a bunch > of those duplicate MAC address cards), > They take them back to the vendor and get replacements. They're > broken. The current scheme of using MAC-addresses has the property that only 2^48 hosts/ethernet cards can be produced globally before the 802 address space runs out. This looks like much, but keep in mind that IPv4 was designed with the idea that there would never be more than a couple of thousand computers globally. Also keep in mind that when a card/computer dies, the MAC number dies with it; there is no way the number is returned to a free pool or anything like that. Hence, this limitation is for *all* computer/widgets collectively produced over the IPv6 ALE (20 years? 30?) While I really don't want to start an MACaddress ALE effort, I think it is wise to keep in mind that the possibility exists that over the lifetime of IPv6, a potentially large number of hosts may pop up which do not use 802 MAC addresses as their initial seed for local link addresses and which may cause collisions. I therefore disagree with Robert (sorry!) and think that we should design for operability in this case. Saying 'these cards are broken and should be returned' works for the few instances where duplicate MACs were manufactured, but I don't think this approach is sufficient for the complete IPv6 design over its full lifetime, i.e. I think we should be able to deal with duplicates. 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 Tue Jan 16 12:21:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06036; Tue, 16 Jan 96 12:21:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06024; Tue, 16 Jan 96 12:20:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19982; Tue, 16 Jan 1996 12:20:23 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id MAA23823; Tue, 16 Jan 1996 12:20:02 -0800 Received: from munin.fnal.gov ("port 2918"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I02XIBVNL0000734@FNAL.FNAL.GOV>; Tue, 16 Jan 1996 14:19:32 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA24239; Tue, 16 Jan 1996 14:19:32 -0600 (CST) Date: Tue, 16 Jan 1996 14:19:31 -0600 From: Matt Crawford Subject: (IPng 1161) clash between PS rfc1884 and PS rfc1783 To: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Message-Id: <9601162019.AA24239@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{:@:/ (While RFC1738 only mentions IPv4 addresses appearing as , it will be widely presumed that IPv6 addresses may also be used.) If the last 16-bit component of an IPv6 address used as in a URL contains only digits 0 through 9, it may look as if a port number is present. Conversely, if a port number is present and has no more than four digits, it will resemble a part of the IPv6 address. Solutions: 1. Change the textual representation of IPv6 addresses. 2. Forbid the "::" abbreviation of IPv6 addresses in URLs and other contexts in which a port number might be appended with a colon. (Then counting the fields will reveal whether a port number is present.) 3. Forbid the use of literal IPv6 addresses in URLs. 4. Change the syntax of URLs. All of these have drawbacks. I suggest that #1 is better than #2, and #3 and #4 are out of the question. _________________________________________________________ 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 Tue Jan 16 12:52:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06131; Tue, 16 Jan 96 12:52:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06125; Tue, 16 Jan 96 12:52:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24492; Tue, 16 Jan 1996 12:51:49 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id MAA02597; Tue, 16 Jan 1996 12:51:48 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16552(1)>; Tue, 16 Jan 1996 12:44:33 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 16 Jan 1996 12:44:16 -0800 To: Matt Crawford Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1162) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: crawdad's message of Tue, 16 Jan 96 12:19:31 -0800. <9601162019.AA24239@munin.fnal.gov> Date: Tue, 16 Jan 1996 12:44:09 PST From: Steve Deering Message-Id: <96Jan16.124416pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Solutions: > > 1. Change the textual representation of IPv6 addresses. > > 2. Forbid the "::" abbreviation of IPv6 addresses in URLs and other > contexts in which a port number might be appended with a colon. > (Then counting the fields will reveal whether a port number is > present.) > > 3. Forbid the use of literal IPv6 addresses in URLs. > > 4. Change the syntax of URLs. Matt, Another possible solution: 1a. Change the textual representation of IPv6 address when they are used in URLs (e.g., an "escape" mechanism for encoding the IPv6 colons inside of URL strings). 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 Jan 16 14:03:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06220; Tue, 16 Jan 96 14:03:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06214; Tue, 16 Jan 96 14:03:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05689; Tue, 16 Jan 1996 14:03:16 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id OAA22722; Tue, 16 Jan 1996 14:03:13 -0800 From: schulter@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05458; Tue, 16 Jan 1996 16:58:24 -0500 Received: from dogfish.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28619; Tue, 16 Jan 1996 16:58:23 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA18315; Tue, 16 Jan 1996 16:58:57 -0500 Message-Id: <9601162158.AA18315@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Stephen Thomas Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1163) Re: Random Interface Tokens (Was: ATM interface token for IPv6) In-Reply-To: Your message of "Mon, 15 Jan 96 21:35:40 EST." <199601160235.VAA14037@borg.mindspring.com> Date: Tue, 16 Jan 96 16:58:57 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen Thomas wrote: > Following up on my own message, but I don't think random tokens > will work for Frame Relay. Since Frame is non-broadcast, multi-access, > duplicate address detection (at least as it's currently spec'd) won't > work. (Two nodes, A & B, might each have a VC with node C. If they > don't have a connection with each other, though, there would be no > way for DAD to detect that they had chosen the same address in their > connection with C.) This is the same sort of thing we're tackling for ATM. My current approach is to provide a mechanism which allows ND to operate unmodified (which I think is manditory since ND is an integral part of the network layer protocol and we can't/shouldn't change the network-layer protocol to compensate for "short comings" of specific datalinks). I think both Grenville's and my I-Ds have spec'ed ways for DAD and ND to work over ATM, maybe these are applicable to Frame Relay too. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 16 18:22:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06438; Tue, 16 Jan 96 18:22:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06432; Tue, 16 Jan 96 18:21:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13518; Tue, 16 Jan 1996 18:21:22 -0800 Received: from CU.NIH.GOV by mercury.Sun.COM (Sun.COM) id SAA28732; Tue, 16 Jan 1996 18:21:20 -0800 Message-Id: <199601170221.SAA28732@mercury.Sun.COM> To: deering@parc.xerox.com, crawdad@fnal.gov Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, deering@parc.xerox.com From: "Roger Fajman" Date: Tue, 16 Jan 1996 21:18:55 EST Subject: (IPng 1164) Re: clash between PS rfc1884 and PS rfc1783 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Solutions: > > > > 1. Change the textual representation of IPv6 addresses. > > > > 2. Forbid the "::" abbreviation of IPv6 addresses in URLs and other > > contexts in which a port number might be appended with a colon. > > (Then counting the fields will reveal whether a port number is > > present.) > > > > 3. Forbid the use of literal IPv6 addresses in URLs. > > > > 4. Change the syntax of URLs. > > Matt, > > Another possible solution: > > 1a. Change the textual representation of IPv6 address when they > are used in URLs (e.g., an "escape" mechanism for encoding the > IPv6 colons inside of URL strings). > > Steve IPv6 address syntax is a problem for email as well. The IPv4 domain literal looks like this: user@[nnn.nnn.nnn.nnn] where nnn.nnn.nnn.nnn is an IPv4 address. While not often used, this capability is considered by a number of people to be important for debugging email problems, so option 3 is not considered viable. The problem arises from the fact that colon already has a couple of meanings in RFC 822 header syntax. Some examples: @source1,@source2:user@domain list-name: addresses ; While allowing an IPv6 address in place of an IPv4 address in a domain literal address would be syntacically unambiguous, a number of implementors feel that major changes would be required to their header parsers. Option 1a is a possibility, but not a very attractive one. I believe that Option 1 was rejected by the IPng WG some time ago. Option 2 doesn't solve the problem for email and Option 4 (changing other parts of RFC 822 syntax) isn't really practical. The DRUMS WG, which is working on revising RFCs 821 and 822, has discussed the problem a couple of times, but has not been able to agree on a solution. ------------------------------------------------------------------------------ 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 Jan 16 19:08:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06527; Tue, 16 Jan 96 19:08:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06520; Tue, 16 Jan 96 19:08:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17445; Tue, 16 Jan 1996 19:07:32 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id TAA05596; Tue, 16 Jan 1996 19:07:31 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id WAA15916 for ; Tue, 16 Jan 1996 22:07:26 -0500 Date: Tue, 16 Jan 1996 22:07:26 -0500 Message-Id: <199601170307.WAA15916@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" To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 1165) Re: Random Interface Tokens Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:58 PM 1/16/96 -0500, schulter@zk3.dec.com wrote: > >Stephen Thomas wrote: > >> Following up on my own message, but I don't think random tokens >> will work for Frame Relay. Since Frame is non-broadcast, multi-access, >> duplicate address detection (at least as it's currently spec'd) won't >> work. (Two nodes, A & B, might each have a VC with node C. If they >> don't have a connection with each other, though, there would be no >> way for DAD to detect that they had chosen the same address in their >> connection with C.) > >This is the same sort of thing we're tackling for ATM. My current approach >is to provide a mechanism which allows ND to operate unmodified (which I >think is manditory since ND is an integral part of the network layer protocol >and we can't/shouldn't change the network-layer protocol to compensate >for "short comings" of specific datalinks). I think both Grenville's and >my I-Ds have spec'ed ways for DAD and ND to work over ATM, maybe these >are applicable to Frame Relay too. They are (my compliments on the good work) but ATM has at least one advantage when compared to Frame--at least you've got something to construct a local interface from (whether it's 48 bits, 64 bits, or whatever, at least it does exist). Frame Relay, as it's commonly used today (i.e. PVCs only) does not have any link address. In ATM terms, all Frame has is a VPI/VCI. And just like a VPI/VCI, Frame's DLCI usually has only local significance. A real bummer for stateless autoconfiguration. Recognizing the bad form of burying a significant proposal deep in a seemingly less significant message--is it a requirement that IPv6 support stateless autoconfiguration over all links (e.g. Frame)? --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 Tue Jan 16 19:34:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06601; Tue, 16 Jan 96 19:34:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06595; Tue, 16 Jan 96 19:34:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19392; Tue, 16 Jan 1996 19:33:34 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id TAA09123; Tue, 16 Jan 1996 19:33:34 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.1/8.7.1) id WAA01118 for ipng@sunroof.eng.sun.com; Tue, 16 Jan 1996 22:33:32 -0500 Received: via switchmail; Tue, 16 Jan 1996 22:33:31 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Jan 1996 22:31:47 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Jan 1996 22:31:42 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 16 Jan 1996 22:31:39 -0500 (EST) Message-Id: Date: Tue, 16 Jan 1996 22:31:39 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1166) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: <199601170221.SAA28732@mercury.Sun.COM> References: <199601170221.SAA28732@mercury.Sun.COM> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Roger Fajman" writes: > While allowing an IPv6 address in place of an IPv4 address in a > domain literal address would be syntacically unambiguous, a number > of implementors feel that major changes would be required to their > header parsers. The problem is much worse. Existing, widely deployed mail transport agents will take addresses like: <@source1.do.main,@[1080::8:800:200C:417A]:foo@bar.do.main> and turn them into swiss cheese: <:8:800:200C:417A]:foo@bar.do.main> For the functionality of mailing directly to IPv6 addresses, I would suggest using the ip6.int or some similar domain. Keep the knowledge of the feature localized to transport agents that support IPv6. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 16 19:36:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06617; Tue, 16 Jan 96 19:36:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06611; Tue, 16 Jan 96 19:36:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19556; Tue, 16 Jan 1996 19:35:38 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id TAA09597; Tue, 16 Jan 1996 19:35:37 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.1/8.7.1) id WAA01122 for ipng@sunroof.eng.sun.com; Tue, 16 Jan 1996 22:35:35 -0500 Received: via switchmail; Tue, 16 Jan 1996 22:35:34 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Jan 1996 22:35:22 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Jan 1996 22:35:21 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 16 Jan 1996 22:35:19 -0500 (EST) Message-Id: <0kz6trO00WBwMDG18U@andrew.cmu.edu> Date: Tue, 16 Jan 1996 22:35:19 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1167) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: <9601162019.AA24239@munin.fnal.gov> References: <9601162019.AA24239@munin.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Additional solution: 5. Require specification of the ":port" field when using IPv6 addresses in URLs. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 16 23:52:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07286; Tue, 16 Jan 96 23:52:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07280; Tue, 16 Jan 96 23:51:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02924; Tue, 16 Jan 1996 23:51:25 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id XAA06201; Tue, 16 Jan 1996 23:51:23 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA26654; Wed, 17 Jan 1996 08:51:21 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA20587; Wed, 17 Jan 1996 08:51:20 +0100 Message-Id: <9601170751.AA20587@dxcoms.cern.ch> Subject: (IPng 1168) Re: clash between PS rfc1884 and PS rfc1783 To: crawdad@fnal.gov (Matt Crawford) Date: Wed, 17 Jan 1996 08:51:20 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com In-Reply-To: <9601162019.AA24239@munin.fnal.gov> from "Matt Crawford" at Jan 16, 96 02:19:31 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 Matt, I disagree with you. I think your alternative #3 is the only reasonable one. IP addresses are variables, not constants, and should never be used as part of a namespace. As far as I am concerned, this bit of RFC 1738 is an architectural bug, and I wish I had picked it up at Last Call. Brian Carpenter >--------- Text sent by Matt Crawford follows: > > The text representation of IPv6 addresses specified in item 2 of > section 2.2 of RFC1884: > > For example the following addresses: > > 1080:0:0:0:8:800:200C:417A a unicast address > [...] > may be represented as: > > 1080::8:800:200C:417A a unicast address > > results in a possible ambiguity if such an IPv6 address appears in a > URL constructed according to RFC1738 (section 3.1): > > While the syntax for the rest of the URL may vary depending on the > particular scheme selected, URL schemes that involve the direct use > of an IP-based protocol to a specified host on the Internet use a > common syntax for the scheme-specific data: > > //:@:/ > > (While RFC1738 only mentions IPv4 addresses appearing as , it > will be widely presumed that IPv6 addresses may also be used.) > > If the last 16-bit component of an IPv6 address used as in a > URL contains only digits 0 through 9, it may look as if a port number > is present. Conversely, if a port number is present and has no more > than four digits, it will resemble a part of the IPv6 address. > > > > Solutions: > > 1. Change the textual representation of IPv6 addresses. > > 2. Forbid the "::" abbreviation of IPv6 addresses in URLs and other > contexts in which a port number might be appended with a colon. > (Then counting the fields will reveal whether a port number is > present.) > > 3. Forbid the use of literal IPv6 addresses in URLs. > > 4. Change the syntax of URLs. > > > All of these have drawbacks. I suggest that #1 is better than #2, > and #3 and #4 are out of the question. > _________________________________________________________ > 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 Jan 17 00:28:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07460; Wed, 17 Jan 96 00:28:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07453; Wed, 17 Jan 96 00:28:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04860; Wed, 17 Jan 1996 00:28:00 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id AAA10026; Wed, 17 Jan 1996 00:27:58 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA01726; Wed, 17 Jan 1996 09:27:55 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA19928; Wed, 17 Jan 1996 09:27:54 +0100 Message-Id: <9601170827.AA19928@dxcoms.cern.ch> Subject: (IPng 1169) Re: [LONG] Random support for IPv6 auto configuration To: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Wed, 17 Jan 1996 09:27:54 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: kre@munnari.oz.au, bradw@netnet.net, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com In-Reply-To: <199601160916.KAA00237@berklix.ripe.net> from "Geert Jan de Groot" at Jan 16, 96 10:16:10 am 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 Geert Jan, > I think we should be able to deal with duplicates. If two devices identify themselves with the same number, we cannot deal with it, except by modifying one of the numbers. 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 Wed Jan 17 01:39:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07672; Wed, 17 Jan 96 01:39:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07666; Wed, 17 Jan 96 01:39:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07974; Wed, 17 Jan 1996 01:38:40 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id BAA17663; Wed, 17 Jan 1996 01:38:40 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10342 Wed, 17 Jan 1996 20:36:35 +1100 (from kre@munnari.OZ.AU) To: "Brian Carpenter CERN-CN" Cc: crawdad@fnal.gov (Matt Crawford), iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Subject: (IPng 1170) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 08:51:20 BST." <9601170751.AA20587@dxcoms.cern.ch> Date: Wed, 17 Jan 1996 20:36:50 +1100 Message-Id: <5143.821871410@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 17 Jan 1996 08:51:20 +0100 (MET) From: "Brian Carpenter CERN-CN" Message-ID: <9601170751.AA20587@dxcoms.cern.ch> I disagree with you. I think your alternative #3 is the only reasonable one. For URLs I agree with this, we really don't want IPv6 addresses embedded in URLs, they are not likely to be nearly stable enough - that is, we want people to be able to go ahead and change IPv6 addresses when there is a need, and not have to worry about all their clients with the old address buried in some web browser's bookmark file. However, we do have to do something with e-mail addresses, and I'm not one who favours the magic domain solution - not because it can't work, which it clearly can, but because its close enough to normal usage that its special nature and transitory usefulness won't be nearly as apparent as if a magic syntax is selected. While e-mail (and other things) needs a way to use address literals for debugging, diagnostic, and emergency use, they don't need to be easy to use. I wouldn't object at all, for domain literals in e-mail anyway, to simply using 32 hex digits, with no other punctuation at all (no colons, dots, or elided zeroes). Anyone who ever really needs to use such things should be able to construct a tool to produce the 32 characters from an IPv6 address in standard notational form. 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 Jan 17 01:45:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07697; Wed, 17 Jan 96 01:45:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07690; Wed, 17 Jan 96 01:45:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08265; Wed, 17 Jan 1996 01:44:41 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id BAA18368; Wed, 17 Jan 1996 01:44:40 -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 KAA25231; Wed, 17 Jan 1996 10:44:20 +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 KAA20428; Wed, 17 Jan 1996 10:44:18 +0100 Message-Id: <199601170944.KAA20428@givry.inria.fr> From: Francis Dupont To: Matt Crawford Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 1171) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of Tue, 16 Jan 1996 14:19:31 CST. <9601162019.AA24239@munin.fnal.gov> Date: Wed, 17 Jan 1996 10:44:06 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The use of the character : into IPv6 seems to prevent IPv6 literals in several things (URL, E-mail addresses, X11 display names where it is *very* ambiguous, ...). This problem is not new and there is only one reasonable solution: forbid IPv6 literals! If we believe we need them I have seen a suitable idea: use *names* in the ip6.int domain, it solves the whole problem cleanly and is not difficult to implement... Any objection? Regards Francis.Dupont@inria.fr PS: about ip6.int it should be fine to have a *working* name service for it. I don't know who is in charge of this but this *must* be fixed ASAP! ------------------------------------------------------------------------------ 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 Jan 17 02:38:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07869; Wed, 17 Jan 96 02:38:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07863; Wed, 17 Jan 96 02:38:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10536; Wed, 17 Jan 1996 02:38:10 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id CAA23617; Wed, 17 Jan 1996 02:38:10 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12391 Wed, 17 Jan 1996 21:36:40 +1100 (from kre@munnari.OZ.AU) To: Francis Dupont Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, bmanning@ISI.EDU (Bill Manning) Subject: (IPng 1172) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 10:44:06 BST." <199601170944.KAA20428@givry.inria.fr> Date: Wed, 17 Jan 1996 21:36:56 +1100 Message-Id: <5164.821875016@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 17 Jan 1996 10:44:06 +0100 From: Francis Dupont Message-ID: <199601170944.KAA20428@givry.inria.fr> about ip6.int it should be fine to have a *working* name service for it. I don't know who is in charge of this but this *must* be fixed ASAP! I think its Bill, right Bill ?? It seems pretty clear that my nameserver (main one) is supposed to be a server for ip6.int - which is just fine - but it would help if the delegation had its name spelled correctly... Of course, it would help even more if the other server had a copy of the zone I could transfer before that is fixed, and I start getting lame delegation reports! Bill, please make at least a temporary zone on ns.isi.edu, and let me know its there so I can make munnari (note two n's!) transfer it - then the root servers can have their delegation updated. 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 Jan 17 02:55:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07919; Wed, 17 Jan 96 02:55:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07913; Wed, 17 Jan 96 02:55:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11532; Wed, 17 Jan 1996 02:54:57 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id CAA25200; Wed, 17 Jan 1996 02:54:57 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA26766; Wed, 17 Jan 1996 11:54:54 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA31070; Wed, 17 Jan 1996 11:54:52 +0100 Message-Id: <9601171054.AA31070@dxcoms.cern.ch> Subject: (IPng 1173) Re: clash between PS rfc1884 and PS rfc1783 To: kre@munnari.oz.au (Robert Elz) Date: Wed, 17 Jan 1996 11:54:52 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: crawdad@fnal.gov, iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com In-Reply-To: <5143.821871410@munnari.OZ.AU> from "Robert Elz" at Jan 17, 96 08:36:50 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 kre, > > While e-mail (and other things) needs a way to use address > literals for debugging, diagnostic, and emergency use, they > don't need to be easy to use. I wouldn't object at all, for > domain literals in e-mail anyway, to simply using 32 hex > digits, with no other punctuation at all (no colons, dots, > or elided zeroes). Anyone who ever really needs to use such > things should be able to construct a tool to produce the > 32 characters from an IPv6 address in standard notational form. > Neat idea. In fact, when you think about it, a straight 32 character hex representation could be a legal alternative format in RFC 1884. The punctuation is only for convenience. 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 Wed Jan 17 03:07:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07963; Wed, 17 Jan 96 03:07:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07956; Wed, 17 Jan 96 03:07:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12055; Wed, 17 Jan 1996 03:06:43 -0800 Received: from ncc.ripe.net by mercury.Sun.COM (Sun.COM) id DAA26325; Wed, 17 Jan 1996 03:06:42 -0800 Received: from berklix.ripe.net by ncc.ripe.net with SMTP id AA04066 (5.65a/NCC-2.30); Wed, 17 Jan 1996 12:06:41 +0100 Received: from berklix.ripe.net (geertj@localhost.ripe.net [127.0.0.1]) by berklix.ripe.net (8.7.3/8.6.9) with ESMTP id KAA00282; Wed, 17 Jan 1996 10:57:49 +0100 (MET) Message-Id: <199601170957.KAA00282@berklix.ripe.net> To: Matt Crawford Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 1174) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Tue, 16 Jan 1996 14:19:31 CST." <9601162019.AA24239@munin.fnal.gov> Date: Wed, 17 Jan 1996 10:57:48 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 16 Jan 1996 14:19:31 -0600 Matt Crawford wrote: > 3. Forbid the use of literal IPv6 addresses in URLs. > All of these have drawbacks. I suggest that #1 is better than #2, > and #3 and #4 are out of the question. Actually, option 3 should not be out of the question. Recent mail on the IPng list suggested thatsome people felt that renumbering had hard consequences and therefore should be put off. This scares me, as *easy and automatic renumbering* is one of the key properties of IPv6 and it should not be pushed off as being 'hard'. I understand the problems at this moment with the first initial implementations. However, since renumbering should be easy, I think that it should be exercised as soon as possible and as frequent as possible. One of the possibilities is to include the day-of-year somewhere in an update to the IPv6 test allocation; this means that people will renumber every day, hopefully automatic very soon when they get tired of doing it by hand ;-) It also means that URLs with literal IPv6 addresses become useless, and that may not be such a bad idea after all, i.e. maybe we should outlaw literal IPv6 numbers in odd places like URLs from the very beginning. I don't think we want an IPv6 version of the PIER WG ever. Let's make shure that we minimize the chance of building legacy that we have to correct later. Geert Jan GeertJan.deGroot@[193.0.0.129] ------------------------------------------------------------------------------ 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 Jan 17 03:10:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07980; Wed, 17 Jan 96 03:10:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07974; Wed, 17 Jan 96 03:10:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12154; Wed, 17 Jan 1996 03:09:38 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id DAA26750; Wed, 17 Jan 1996 03:09:30 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA13183 Wed, 17 Jan 1996 21:59:00 +1100 (from kre@munnari.OZ.AU) To: Geert Jan de Groot Cc: Brad Wilson , "'ip-atm@matmos.hpl.hp.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1175) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Tue, 16 Jan 1996 10:16:10 BST." <199601160916.KAA00237@berklix.ripe.net> Date: Wed, 17 Jan 1996 21:59:16 +1100 Message-Id: <5177.821876356@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 16 Jan 1996 10:16:10 +0100 From: Geert Jan de Groot Message-ID: <199601160916.KAA00237@berklix.ripe.net> The current scheme of using MAC-addresses has the property that only 2^48 hosts/ethernet cards can be produced globally before the 802 address space runs out. 2^46 actually. This looks like much, but keep in mind that IPv4 was designed with the idea that there would never be more than a couple of thousand computers globally. I don't follow the relevance of this. IEEE addresses were designed to be able to number 2^46 devices - and yes, that is a lot. IPv4 addresses weren't designed to be able to number large numbers of hosts, and we have a problem. The problem that we have with IPv4 addresses now isn't that 2^32 numbers (give or take) isn't enough to number all the internet devices will have for a long time to come, but that so much of the address space is wasted establishing the hierarchy that is needed to make the thing routable. I am personally not at all worried about IEEE addresses running out any time any of us will care a lot about 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 Wed Jan 17 05:46:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08381; Wed, 17 Jan 96 05:46:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08374; Wed, 17 Jan 96 05:46:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18722; Wed, 17 Jan 1996 05:45:57 -0800 Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM) id FAA11290; Wed, 17 Jan 1996 05:45:56 -0800 Received: from [138.96.24.178] by pax.inria.fr (8.6.12/8.6.12) with SMTP id OAA08098; Wed, 17 Jan 1996 14:40:05 +0100 Date: Wed, 17 Jan 1996 14:40:05 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Elz From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1176) Re: clash between PS rfc1884 and PS rfc1783 Cc: "Brian Carpenter CERN-CN" , crawdad@fnal.gov (Matt Crawford), iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, I don't favor breaking rules in order to accomodate broken softwares. Broken mailers are going to remain broken whatever we do. Some already do a dull job of handling lists of IPv6 addresses in @x@y@z:t@u constructs, some reply to lines like "To: mylist;". The question is not whether it works today - it doesn't - but rather whether it can work. If you look at: foo@[1:2:3::4:5:6] then there is all reasons to believe that it can work, provided the mailer is upgraded. The syntax of addresses has to be changed from: right-side ::= domain-name | '[' ipv4-address ']' to: right-side ::= domain-name | '[' ipv4-address ']' | '[' ipv6-address ']' Writing a parser that distinguishes ipv4 from ipv6 is not rocket science. Now, I would accept the argument that a syntax change would be better, e.g. right-side ::= domain-name | '[' ipv4-address ']' | '{' ipv6-address '}' because it would reduce the requirement for "look-ahead" and also enable you to write sendmail.cf clauses that send anything IPv6 to the nearest IPv6 gateway. But changing the ":" to something else is not going to help. As for URLs, maybe the same solution should apply, i.e. somehow quote the IPv6 address between braces that tell you "this is an IPv6 address". 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 Wed Jan 17 07:34:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08655; Wed, 17 Jan 96 07:34:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08649; Wed, 17 Jan 96 07:34:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25628; Wed, 17 Jan 1996 07:33:31 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id HAA01301; Wed, 17 Jan 1996 07:33:30 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA32256; Wed, 17 Jan 1996 10:28:58 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19088; Wed, 17 Jan 1996 10:28:54 -0500 Message-Id: <9601171528.AA19088@fwasted.zk3.dec.com> To: Geert Jan de Groot Cc: Matt Crawford , iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 1177) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 96 10:57:48 +0100." <199601170957.KAA00282@berklix.ripe.net> Date: Wed, 17 Jan 96 10:28:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geert, Renumbering is built into IPv6 implementations if they adhere to stateless addrconf, ND, and DHCPv6 drafts (since the work started). We will test this at UNH bake-off in February to some degree in a multivendor IPv6 environment. The only issue on that table (renumbering) is keeping connections in tact when the valid lifetime expires. This has pointed us in the IETF to go work on other problems specifically transport connections. Christian has a proposal on the table and I am going to provide the IETF with another one by L.A. IETF. Then we need to clean up implementations per PIER (hardcoding things, etc). So I think we are in good shape for IPv6 considering where we are in the IPv6 standardization process. If you have a technical or technology strategy we have not considered that effect the way implementations will be built please get that on the table in the 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 Wed Jan 17 07:47:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08697; Wed, 17 Jan 96 07:47:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08690; Wed, 17 Jan 96 07:46:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26764; Wed, 17 Jan 1996 07:46:21 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id HAA04048; Wed, 17 Jan 1996 07:46:20 -0800 Received: from munin.fnal.gov ("port 2965"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I0429V5LRU000734@FNAL.FNAL.GOV>; Wed, 17 Jan 1996 09:46:17 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA26927; Wed, 17 Jan 1996 09:46:16 -0600 (CST) Date: Wed, 17 Jan 1996 09:46:16 -0600 From: Matt Crawford Subject: (IPng 1178) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: "17 Jan 96 14:40:05 +0100." <"v02120d08ad229015562c"@[138.96.24.178]> To: iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Cc: Robert Elz , huitema@pax.inria.fr (Christian Huitema), Brian Carpenter CERN-CN , Francis Dupont , Geert Jan de Groot , John Gardiner Myers Message-Id: <9601171546.AA26927@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 AA08933; Wed, 17 Jan 96 08:45:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08927; Wed, 17 Jan 96 08:45:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03418; Wed, 17 Jan 1996 08:45:12 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id IAA19152; Wed, 17 Jan 1996 08:45:12 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA26617; Wed, 17 Jan 1996 08:45:15 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Jan 1996 08:46:45 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1179) Re: clash between PS rfc1884 and PS rfc1783 Cc: iesg@CNRI.Reston.VA.US Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This topic has been discussed several times before (documented in meeting minutes) and the after each discussion the conclusion is leave the text representation unchanged. I believe that using IPv6 (or IPv4) addresses in email addresses or URL's is not something we should promote. At the same time we should not make it impossible. Applications which accept literal addresses need to be upgraded to handle IPv6 addresses. As Christian points out the ":" is the least of the problems. Either the IPng working group should put together a proposal for the email and URL (and others?) syntax for embedded IPv6 addresses or the IESG should ask the relevant working groups to do this work. Comments? 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 Wed Jan 17 09:22:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09065; Wed, 17 Jan 96 09:22:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09056; Wed, 17 Jan 96 09:21:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08016; Wed, 17 Jan 1996 09:21:18 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id JAA29404; Wed, 17 Jan 1996 09:21:17 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.1/8.7.1) id MAA00592 for ipng@sunroof.Eng.Sun.COM; Wed, 17 Jan 1996 12:21:14 -0500 Received: via switchmail; Wed, 17 Jan 1996 12:21:13 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 17 Jan 1996 12:20:31 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 17 Jan 1996 12:20:30 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 17 Jan 1996 12:20:28 -0500 (EST) Message-Id: Date: Wed, 17 Jan 1996 12:20:28 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1180) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: <9601171546.AA26927@munin.fnal.gov> References: <9601171546.AA26927@munin.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: > So the magic would have to be wired into gethostbyname() or in the > resolver. (Concoct a AAAA record on the spot in answer to a AAAA > query on a name in ip6.int.) > > Does the gain justify the ugliness? Very much so. It localizes the knowledge of DNS bypassing to one place, the resolver. The higher layers don't have to recognize or parse a different syntax. (You also want to concoct the lack of any MX or CNAME records.) -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 17 09:22:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09066; Wed, 17 Jan 96 09:22:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09052; Wed, 17 Jan 96 09:21:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08013; Wed, 17 Jan 1996 09:21:17 -0800 Received: from jekyll.piermont.com by mercury.Sun.COM (Sun.COM) id JAA29399; Wed, 17 Jan 1996 09:21:17 -0800 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.6.12/8.6.12) with SMTP id MAA04923; Wed, 17 Jan 1996 12:20:59 -0500 Message-Id: <199601171720.MAA04923@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1181) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 08:46:45 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 Jan 1996 12:20:48 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden writes: > I believe that using IPv6 (or IPv4) addresses in email addresses or URL's > is not something we should promote. You can't help needing them sometimes, though. > Applications which accept literal addresses need to be upgraded to handle > IPv6 addresses. As Christian points out the ":" is the least of the > problems. The real problem that I see is a user on an IPv4 host needing to send mail to an IPv6 literal. I believe (perhaps mistakenly -- often these things are thought of by many people) that I first proposed the .ip6.int solution to v6 literals in email. In addition to not requiring that existing software on old machines be changed at all, one other reason I especially thought it was a good idea is that the v4 DNS could get an MX pointing .ip6.int mail at cooperating v4 to v6 gateways. Unfortunately, the .ip6.int solution results in addresses that are a half mile long. If only we had a way to slightly compact things... Perry ------------------------------------------------------------------------------ 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 Jan 17 09:49:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09179; Wed, 17 Jan 96 09:49:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09173; Wed, 17 Jan 96 09:49:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12198; Wed, 17 Jan 1996 09:49:15 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id JAA08709; Wed, 17 Jan 1996 09:49:13 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26306 Thu, 18 Jan 1996 04:44:42 +1100 (from kre@munnari.OZ.AU) To: huitema@pax.inria.fr (Christian Huitema) Cc: "Brian Carpenter CERN-CN" , crawdad@fnal.gov (Matt Crawford), iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Subject: (IPng 1182) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 14:40:05 BST." Date: Thu, 18 Jan 1996 04:44:58 +1100 Message-Id: <5356.821900698@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 17 Jan 1996 14:40:05 +0100 From: huitema@pax.inria.fr (Christian Huitema) Message-ID: I don't favor breaking rules in order to accomodate broken softwares. I agree, but .. Broken mailers are going to remain broken whatever we do. this is the problem, perhaps one that is unique to mail. The problem is not the mailers that can, and will, be upgraded to understand the new syntax, whatever it is, even if that is something that should now be legal, but just is not implemented well, but all the mailers that will never be upgraded. For just about any other protocol you could ignore this problem (eg: it is immaterial whether an FTP server that doesn't unterstand V6 knows how to handle whatever the revised PORT command syntax is, as it will never see that - its a V6 only thing). Unfortunately, for mail you can't - mail is relayed, and old V4 only mailers can pass on mail with V6 addresses in the headers (one way or the other). Current v4 mailers will simply mangle IPv6 addresses in the standard notation expresed in as a domain literal, that is a very high price to pay for the ideal of "it is (now) broken, fix it". Incidentally, there is something of a stand off here - the ipngwg simply say "this is a mail problem, they can fix it", and the mail people (an almost totally disjoint set) say "those idiots have broken things, we aren't going to mangle our mailers to deal with that trash - have them choose a different notation". As best I can tell, nothing at all is happening to attempt to reconcile those positions. We probably need a broad based "IPv6 affected applications" BOF, or something, where people involved in all kinds of applications which IPv6 might impact can come and meet with IPv6 people and discuss the issues, rather than each meeting at opposite ends of the IETF hotel, in parallel, and ignoring each other (in Dallas, when I was bouncing in and out of the ipngwg meeting I was also bouncing in and out of the DRUMS (mail cleanups) wg meeting...) As for URLs, maybe the same solution should apply, i.e. somehow quote the IPv6 address between braces that tell you "this is an IPv6 address". No, for URLs the correct answer is to do nothing. There is no need at all for a URL to contain a literal address, under any circumstances (IPv6 or IPv4). Mail has to work without the DNS, or there is no rational way to communicate the DNS problems to those who can fix them (so do things like telnet, ftp, and snmp, so routers can be configured to allow the DNS to work, new versions of code can be fetched when old ones are broken, and so the net can be monitored so you can tell why things are not working). Maybe a few more. The Web is, however, not one of those - it is entirely acceptable to require that sites housing web pages be correctly listed in the DNS so names can be used, there is no gain worth having in allowing literal addresses, and much to lose. Note, it's only the servers that need DNS working - if you're trying to connect to a WWW page to learn how to configure your own DNS domain properly, that will still work - all you will need to have is a working resolver, and that should simply be shipped with every system. 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 Jan 17 10:00:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09245; Wed, 17 Jan 96 10:00:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09239; Wed, 17 Jan 96 09:59:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13708; Wed, 17 Jan 1996 09:59:24 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id JAA12023; Wed, 17 Jan 1996 09:59:23 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26887 Thu, 18 Jan 1996 04:56:15 +1100 (from kre@munnari.OZ.AU) To: Matt Crawford Cc: iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com, huitema@pax.inria.fr (Christian Huitema), Brian Carpenter CERN-CN , Francis Dupont , Geert Jan de Groot , John Gardiner Myers Subject: (IPng 1183) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 09:46:16 MDT." <9601171546.AA26927@munin.fnal.gov> Date: Thu, 18 Jan 1996 04:56:30 +1100 Message-Id: <5361.821901390@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 17 Jan 1996 09:46:16 -0600 From: Matt Crawford Message-ID: <9601171546.AA26927@munin.fnal.gov> I like kre's idea of writing 32 unadorned hex digits, but it only works for email where there is some surrounding marker. Yes. Dropped into the URL format (or typed (ugh!) at a command line, Don't want it in URLs (I have probably made that clear by now), and command lines can generally take the standard syntax. Ie: with telnet, telnet a.b.c or telnet 1.2.3.4 or telnet fe80::80:20:fc:01:22:34 are easy to distinguish, any telnet that is able to connect over IPv6 can easily also be made to handle the 3rd form - older telnets simply dont' care (couldn't use the knowledge if they had it). Mail is just different. Mail is probably the only place where it is vital that domain literals (addresses representing themselves) both work, and don't break existing IPv4 applications that know nothing of IPv6 addresses at all - that one is a very special case. I like even more Francis' idea of writing literal IPv6 address as names in ip6.int. However, the times you'd want literal addresses are exactly the times you suspect DNS may not be fully operational. Yes. (As is the case now: ns.isi.edu. can't find ip6.int.: Server failed.) Yes, unfortunately it looks like Bill Manning is away, and I think this is his doing (I have enquired as to whether someone else might be able to get things fixed). So the magic would have to be wired into gethostbyname() or in the resolver. (Concoct a AAAA record on the spot in answer to a AAAA query on a name in ip6.int.) That was always the intention I believe. Does the gain justify the ugliness? Personally, I don't think so. 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 Jan 17 10:08:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09293; Wed, 17 Jan 96 10:08:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09287; Wed, 17 Jan 96 10:08:25 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15147; Wed, 17 Jan 1996 10:07:53 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id KAA15140; Wed, 17 Jan 1996 10:07:48 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27273 Thu, 18 Jan 1996 05:07:34 +1100 (from kre@munnari.OZ.AU) To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1184) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 12:20:28 CDT." Date: Thu, 18 Jan 1996 05:07:50 +1100 Message-Id: <5366.821902070@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 17 Jan 1996 12:20:28 -0500 (EST) From: John Gardiner Myers Message-ID: The higher layers don't have to recognize or parse a different syntax. This is a bug, not a feature. We really don't want to make the use of address literals "just work" or for people (the ultimate higher layer) to fail to recognise that what they are using is a literal IP address instead of a DNS hostname. Literal addresses should be used in as few places as possible, we really should be investigating each potential case and justifying it as a real need, and not just a frill that doesn't seem to hurt. If there is no real need, the use of literal addresses should not be supported at all. Making the resolver simply hide the details, so any and all applications could make use of literal addresses without even being aware that was what they were doing would be something that would live on to haunt us, and future generations, for a very long time - to risk mixing metaphores, we'd be looking for wooden stakes to drive through that heart, and never finding one long enough. kre ps: I believe Perry is right, and it was he who first suggested this abomination. ------------------------------------------------------------------------------ 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 Jan 17 10:59:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09432; Wed, 17 Jan 96 10:59:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09426; Wed, 17 Jan 96 10:59:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24059; Wed, 17 Jan 1996 10:58:57 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id KAA08064; Wed, 17 Jan 1996 10:58:57 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.1/8.7.1) id NAA00738 for ipng@sunroof.eng.sun.com; Wed, 17 Jan 1996 13:58:55 -0500 Received: via switchmail; Wed, 17 Jan 1996 13:58:54 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 17 Jan 1996 13:56:59 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 17 Jan 1996 13:56:56 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 17 Jan 1996 13:56:52 -0500 (EST) Message-Id: Date: Wed, 17 Jan 1996 13:56:52 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1185) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: <199601171720.MAA04923@jekyll.piermont.com> References: <199601171720.MAA04923@jekyll.piermont.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" writes: > The real problem that I see is a user on an IPv4 host needing to send > mail to an IPv6 literal. > > I believe (perhaps mistakenly -- often these things are thought of by > many people) that I first proposed the .ip6.int solution to v6 > literals in email. I think these are respectively the wrong problem to solve and the wrong way to solve the problem. There is no standardized facility in Internet mail for a non-IPv4-connected host to be able to send mail to an IPv4 literal. To send mail to an IPv4 literal, the mail transport agent needs to either be connected to IPv4, or needs local knowledge of how to relay the mail to a transport agent which is IPv4-connected. If neither of these is the case, then the user needs to apply local knowledge to source-route the mail to an IPv4-connected transport agent. The same situation should exist with IPv6 literals. Keep it simple. Robert Elz writes: > The higher layers don't have to recognize or > parse a different syntax. > > This is a bug, not a feature. We really don't want to make > the use of address literals "just work" or for people (the > ultimate higher layer) to fail to recognise that what they > are using is a literal IP address instead of a DNS hostname. The fact that an object can be referenced through a domain name does not imply persistence of the object, the name, or the name/object mapping. We already have "real" domains like annex-v32bis-57.slip.andrew.cmu.edu which if users put in such things as URL's they will get very disappointed. Domains are simply names, with a hierarchical, delegated assignment system and a default resolution mechanism. It is madness to try to control access to objects by making people go through hoops to get differently-syntaxed (syntax-challenged?) names for them. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 17 11:15:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09493; Wed, 17 Jan 96 11:15:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09485; Wed, 17 Jan 96 11:14:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26353; Wed, 17 Jan 1996 11:14:11 -0800 Received: from jekyll.piermont.com by mercury.Sun.COM (Sun.COM) id LAA13123; Wed, 17 Jan 1996 11:14:08 -0800 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.6.12/8.6.12) with SMTP id OAA05146; Wed, 17 Jan 1996 14:14:04 -0500 Message-Id: <199601171914.OAA05146@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1186) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 13:56:52 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 Jan 1996 14:14:03 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John Gardiner Myers writes: > "Perry E. Metzger" writes: > > The real problem that I see is a user on an IPv4 host needing to send > > mail to an IPv6 literal. [...] > There is no standardized facility in Internet mail for a > non-IPv4-connected host to be able to send mail to an IPv4 literal. Yes there is. You send to foo@[addr]. If you have properly configured your mailer on, say, your UUCP host, it should get through. I've had to use this on occassion. The uucp sites I used to set up did this properly. In any case, just because there is no standard mechanism now doesn't mean that one might not be damn useful during transition. Consider that there will be a long period where various components of IPv6 world may be screwed up, or hard to access. In any case, the .ip6.int address idea is the only mechanism I've heard thus far proposed that would allow us to encode literal IP6 addresses into mail addresses, which everyone agrees is not often needed but desperately needed on ocassion and thus too valuable to break. Its either a hack like this or fixing the :'s in the addresses. Perry ------------------------------------------------------------------------------ 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 Jan 17 11:27:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09534; Wed, 17 Jan 96 11:27:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09528; Wed, 17 Jan 96 11:27:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28631; Wed, 17 Jan 1996 11:27:11 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id LAA17462; Wed, 17 Jan 1996 11:27:10 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28582 Thu, 18 Jan 1996 06:26:59 +1100 (from kre@munnari.OZ.AU) To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1187) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 13:56:52 CDT." Date: Thu, 18 Jan 1996 06:27:14 +1100 Message-Id: <5414.821906834@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 17 Jan 1996 13:56:52 -0500 (EST) From: John Gardiner Myers Message-ID: There is no standardized facility in Internet mail for a non-IPv4-connected host to be able to send mail to an IPv4 literal. Of course not, non-IPv4-connected hosts aren't Internet, so nothing in Internet mail applies to them. However, it is quite possible for a non IPv4 host that happens to be connected to a mailer that uses an 822 type mail system (say uucp) to do ... To: relay!user@[1.2.3.4] If this is a pure uucp site, the "relay!" will be interpreted, the mail transport agent knows nothing at all about what the part that comes after means. Then the relay site will do its thing with the domain literal, and the message will be delivered. (All the other relay syntaxes could be used where understood as well). But this is not the real problem - the problem is IPv4 hosts that receive mail from addresses that are represented as domain literals, or which receive mail that has also been sent to an address that contains an IPv6 domain literal, and what the mailer that receives that message does with the headers before the user ever gets to see them. There is very very limited need for an IPv4 only site to want to go send to an IPv6 domain literal in any case - which is why that isn't the problem - only IPv6 nodes need to that, as they're the ones that will need to be debugging non-functional IPv6 setups. Literal addresses shouldn't be encouraged, or perhaps even allowed, for more than that - but there's no way to keep them out of mail that has been received. The fact that an object can be referenced through a domain name does not imply persistence of the object, the name, or the name/object mapping. No, I understand that (though people do tend to assume that URLs represent things that will be at least reasonably stable - they're appearing in books, magazines, newspapers - if the things changed every day they wouldn't be useful, IPv6 addresses may change every day). It is madness to try to control access to objects by making people go through hoops to get differently-syntaxed (syntax-challenged?) names for them. I agree totally, people should use, and only use, regular DNS names. Further, they should be able to understand the normal semantics of DNS names, and rely upon those. Literal IPv6 addresses, however encoded, simply shouldn't be used at all. Unfortunately, "shouldn't", while nice to aspire to, is impractical. Occasionally the need will arise when, in a few applications, use of a literal address will be required. I believe it is important to make it quite obvious that a non-standard, not for ordinary use, mechanism is being employed. I think the IPv4 domain literal stuff in rfc822 worked just perfectly for this - it is possible to use it, when you really need to, but it is so arcane that in ordinary day to day use, no-one ever does. That is the perfect outcome. 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 Jan 17 11:47:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09600; Wed, 17 Jan 96 11:47:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09299; Wed, 17 Jan 96 10:09:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15257; Wed, 17 Jan 1996 10:08:40 -0800 Received: from apb.iafrica.com by mercury.Sun.COM (Sun.COM) id KAA15392; Wed, 17 Jan 1996 10:08:37 -0800 Received: (from apb@localhost) by apb.iafrica.com (8.6.12/8.6.9) id UAA23613; Wed, 17 Jan 1996 20:08:30 +0200 Date: Wed, 17 Jan 1996 20:08:26 +0200 (GMT+0200) From: Alan Barrett To: ipng@sunroof.eng.sun.com Cc: iesg@CNRI.Reston.VA.US Subject: (IPng 1188) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: <9601171546.AA26927@munin.fnal.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have this idea of extending RFC822 domain-literals to make them self-describing, by inserting a keyword just inside the square brackets, like this: [IPv4:192.0.2.1] [IPv6:1080::8:800:200C:417A] Everything between the first colon and the closing bracket is the address in the address-space mentioned before the colon. Then I would suggest that addresses be wrapped in the "[IPv6: ]" brackets in all contexts where a bare address is inappropriate (mail addresses, URLs, just about anywhere a "hostname" is wanted). Several existing specs would have to be changed to accommodate this, but change is probably necessary anyway to accommodate IPv6. --apb (Alan Barrett) ------------------------------------------------------------------------------ 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 Jan 17 11:50:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09655; Wed, 17 Jan 96 11:50:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09649; Wed, 17 Jan 96 11:50:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01825; Wed, 17 Jan 1996 11:50:01 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id LAA24277; Wed, 17 Jan 1996 11:50:00 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15144(4)>; Wed, 17 Jan 1996 11:48:10 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 17 Jan 1996 11:47:56 -0800 To: Robert Elz Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1189) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: kre's message of Wed, 17 Jan 96 02:59:16 -0800. <5177.821876356@munnari.OZ.AU> Date: Wed, 17 Jan 1996 11:47:48 PST From: Steve Deering Message-Id: <96Jan17.114756pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, > The problem that we have with IPv4 addresses now isn't that > 2^32 numbers (give or take) isn't enough to number all the > internet devices will have for a long time to come, but that > so much of the address space is wasted establishing the hierarchy > that is needed to make the thing routable. > > I am personally not at all worried about IEEE addresses > running out any time any of us will care a lot about it. I agree with your basic point, however I'd just like to observe that IEEE 802/Ethernet addresses do include an administrative hierarchy (they are divided into 2 flag bits + 22-bit OUI + 24-bit remainder) which could conceivably lead to premature exhaustion, e.g., if lots of organization got their own OUI and then failed to use a significant part of their 24-bit space. It would be really interesting to see the OUI consumption curve. *However*, even if IEEE 802ng comes out with 64 bit addresses, I'd advocate simply hashing those longer addresses down to 48 bits for use in the lowest- order field of a statelessly-autoconfigured IPv6 address. It shouldn't be difficult to devise a hash from 64 bits to 48 bits that has negligible probability of collision -- probably just dropping the high-order bits would do. That is also what I would suggest for IPv6-over-ATM, if there really is a case of ATM interfaces without wired-in IEEE 802 addresses -- simply hash the NSAP address or E.164 address or whatever into 48 bits (or into the 46-bit non-multicast, non-global IEEE 802 space, if those nodes may co-exist on links with other ATM nodes that *do* use global IEEE 802 addresses as their v6 tokens). Regarding duplicate address tokens: IPv6 Duplicate Address Detection was designed under the assumption that duplicates would be very rare; it was intended more to catch configuration errors in human-assigned IPv6 addresses assigned through DHCP or manual configuration of a node itself, than to catch duplicate Ethernet addresses. If we create scenarios (like some that have been mentioned here) where there is a significant probability of duplicate tokens, and depend on DAD to detect and recover from those duplicates, then we will have to change ND to specify that the DAD process be run periodically and frequently by all nodes on a link, to detect possible duplicates that weren't detected at start-up time due to the link being partitioned or the host being temporarily disconnected (in an undetectable way) from the link. I'd rather not incur all that gratuitous control traffic, just to accomodate sleazy vendors of spec-violating Ethernet cards, or ATM. 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 Jan 17 11:56:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09682; Wed, 17 Jan 96 11:56:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09503; Wed, 17 Jan 96 11:15:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26523; Wed, 17 Jan 1996 11:14:59 -0800 Received: from apb.iafrica.com by mercury.Sun.COM (Sun.COM) id LAA13401; Wed, 17 Jan 1996 11:14:55 -0800 Received: (from apb@localhost) by apb.iafrica.com (8.6.12/8.6.9) id VAA23846; Wed, 17 Jan 1996 21:14:17 +0200 Date: Wed, 17 Jan 1996 21:14:14 +0200 (GMT+0200) From: Alan Barrett To: Robert Elz Cc: iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Subject: (IPng 1190) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: <5356.821900698@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Current v4 mailers will simply mangle IPv6 addresses > in the standard notation expresed in as a domain literal, that > is a very high price to pay for the ideal of "it is (now) broken, > fix it". OK, it's a hight price, OK. But is it too high a price? Domain literals are supposed to be extremely rare, and if they cause broken mailers to fall over, do we care? (We all agree that the mailers that will fall over are *already* broken, I hope.) As kre mentioned, mail to domain literals is sometimes necessary to help resolve problems. But it should always be possible to bring an extra human into the loop to relay messages that cause broken mailers to fall over. --apb (Alan Barrett) ------------------------------------------------------------------------------ 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 Jan 17 12:13:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09727; Wed, 17 Jan 96 12:13:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09721; Wed, 17 Jan 96 12:13:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05595; Wed, 17 Jan 1996 12:12:42 -0800 Received: from ncc.ripe.net by mercury.Sun.COM (Sun.COM) id MAA00654; Wed, 17 Jan 1996 12:12:35 -0800 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA13672 (5.65a/NCC-2.30); Wed, 17 Jan 1996 21:11:59 +0100 Message-Id: <9601172011.AA13672@ncc.ripe.net> To: Steve Deering Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 1191) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 11:09:29 PST." <96Jan17.110939pst.75270@digit.parc.xerox.com> Date: Wed, 17 Jan 1996 21:11:53 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 17 Jan 1996 11:09:29 PST Steve Deering wrote: > Automatic renumbering is easy in IPv6, and has not been pushed off -- please > see the addrconf spec. > > Whether or not upper layer protocols and applications can cope with having > their IP addresses change out from under them is the PIER WG's problem. > I happen to think they have a very tough problem, and until they have > "solved" it (the definition of "solved" is rather complicated here), I > have to wonder how much IPv6's easy and automatic renumbering capability > will be exercised. It is messages such as the one below which scare me (sorry Ran!) We don't need extra bits if people can renumber easily; the sooner this is exercised, the better. Speaking with registry experience I can say that reserving bits to allow for future growth does never work: either one reserves too much (waisting space), or one reserves too little (needing 'extra prefixes' anyway thus making the effort of reserving worthless). With automatic renumbering people just renumber (automatic & painless) in a new, shorter prefix and that's what I aim for. Any new design that will make this more difficult in the future should be looked at very carefully and IMHO rejected. Because of this renumbering thing, using IP numbers in URLs doesn't make sense (except for email in emergencies as discussed), and simply not providing any method to do this in URLs (again except for emergency email) looks like the correct thing to do to avoid having the possibility of getting legacy situations. Remember how quick the domainname-removed-in-http hack (the fact that http:foo.com/bar.html only causes bar.html to be requested by http, which is a reason for waisting address space as foo.com needs to have another address as bletch.com, even both domains are the same box) caught us? How long will it take before this problem is resolved? I want to avoid running into the possibility of getting a similar legacy situation. Geert Jan PS: I apologize for the seemingly duplicate messages on IPng this morning; I pulled the last email on my laptoy before I started commuting and responded to that; on arrival here my laptop had its email queue flushed before I saw new messages that said similar things as the ones I sent. I guess I must check my laptop for bugs and hidden transmitters ;-) >(Message /home/geertj/Mail/inbox:2132) > -- using template mhl.format -- >Date: Tue, 09 Jan 1996 16:32:22 PST >To: ipng@sunroof.Eng.Sun.COM > >From: Ran Atkinson >Subject: (IPng 1069) Re: proposal to fix draft-ietf-ipngwg-unicast-addr-fmt-02. > ***txt > >From owner-ipng@sunroof.Eng.Sun.COM Wed Jan 10 01: 33:44 1996 >In-Reply-To: <199601091401.QAA02926@lohi.dat.tele.fi> >References: <199601091258.AA01299@zed.isi.edu> >Organization: cisco Systems, Inc., Menlo Park, Ca. >Sender: owner-ipng@sunroof.Eng.Sun.COM >Precedence: bulk > > >> Geoff Huston has proposed a very viable solution. >> Providers select how big, based on cost per bit. >> With dynamic renumbering, when a provider grows, >> it renumbers to its new provider block. >> >In article <199601091401.QAA02926@lohi.dat.tele.fi> Juha wrote: >> we are very far from means to dynamically and painlessly renumber the >> provider and all its clients. with this kind of scheme only the already >> big ones could protect themselves from the renumbering hassle. > >Absolutely correct. > >Yet you would inflict exactly that same pain on user sites ! > >This is a large reason why I personally have real problems with >provider-oriented addressing being mandated for all sites/users and why I >personally have real problems with providers being in a position to >constrain how many bits users get. I've renumbered two sets of >systems in my life. Both cases were very painful, even though one >of them involved only about 250 nodes. > >Many users don't have any good method of predicting how many IP nodes they >will have on campus in a few years, even when they have many current IP >nodes. Who predicted in 1990 that all PCs running current versions of >Windows would implement IPv4 ? > >Reserved bits between provider and user permit two things: > (1) unanticipated user growth to be accomodated somewhat > (without renumbering) by letting the user begin using > some of the low-order reserved bits and shortening their > user routing prefix. > (2) providers add an additional unexpected user site (that > is topologically near the original user :-) by consuming > a few of the high-order reserved bits. > >Those initially reserved bits are a safety net that we will need to have. > >Ran >rja@inet.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 Jan 17 12:28:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09759; Wed, 17 Jan 96 12:28:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09753; Wed, 17 Jan 96 12:27:53 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07512; Wed, 17 Jan 1996 12:27:22 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id MAA05557; Wed, 17 Jan 1996 12:27:22 -0800 From: schulter@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA13319; Wed, 17 Jan 1996 15:16:26 -0500 Received: from dogfish.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22882; Wed, 17 Jan 1996 15:16:24 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA00196; Wed, 17 Jan 1996 15:16:59 -0500 Message-Id: <9601172016.AA00196@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Stephen Thomas Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1192) Re: Random Interface Tokens In-Reply-To: Your message of "Tue, 16 Jan 96 22:07:26 EST." <199601170307.WAA15916@borg.mindspring.com> Date: Wed, 17 Jan 96 15:16:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk on Tue, 16 Jan 96 22:07:26 EST Stephen Thomas wrote: > They are (my compliments on the good work) but ATM has at least one > advantage when compared to Frame--at least you've got something to > construct a local interface from (whether it's 48 bits, 64 bits, or > whatever, at least it does exist). Frame Relay, as it's commonly > used today (i.e. PVCs only) does not have any link address. In ATM > terms, all Frame has is a VPI/VCI. And just like a VPI/VCI, Frame's > DLCI usually has only local significance. A real bummer for stateless > autoconfiguration. Actually, ATM may not have any sort of interface token. That's what we've been discussing. Yes, ATM interfaces have to have some sort of interface token when using SVCs, but this token may not be usable by IPv6 for the host token. An unusable token is basically the same as no token at all. Thus, the perceived need for a random token (and then there are issues for multiple virtual subnets on ATM interfaces). And you also raise an interesting point for ATM. Support an ATM interface supports only PVCs. What is the host token? Maybe the board would have one, maybe not. Any IPv6 over ATM spec would have to address this case too. ------------------------------------------------------------------------------ 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 Jan 17 12:56:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09832; Wed, 17 Jan 96 12:56:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09826; Wed, 17 Jan 96 12:56:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11494; Wed, 17 Jan 1996 12:56:01 -0800 Received: from ncc.ripe.net by mercury.Sun.COM (Sun.COM) id MAA12799; Wed, 17 Jan 1996 12:56:00 -0800 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA13856 (5.65a/NCC-2.30); Wed, 17 Jan 1996 21:49:57 +0100 Message-Id: <9601172049.AA13856@ncc.ripe.net> To: Steve Deering Cc: Robert Elz , ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 1193) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Wed, 17 Jan 1996 11:47:48 PST." <96Jan17.114756pst.75270@digit.parc.xerox.com> Date: Wed, 17 Jan 1996 21:49:47 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 17 Jan 1996 11:47:48 PST Steve Deering wrote: > *However*, even if IEEE 802ng comes out with 64 bit addresses, I'd advocate > simply hashing those longer addresses down to 48 bits for use in the lowest- > order field of a statelessly-autoconfigured IPv6 address. It shouldn't be > difficult to devise a hash from 64 bits to 48 bits that has negligible > probability of collision -- probably just dropping the high-order bits > would do. Thanks for your message. I'm happy with this if we can agree on the following: If a collision happens nevertheless, that the spec will allow for these machines to work (e.g. by having the machine which detects the collision to take another number), and not suggesting 'you have to return those cards as they're broken' as both cards are fine and there is nothing to return to nobody.. 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 Wed Jan 17 13:44:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09881; Wed, 17 Jan 96 13:44:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09875; Wed, 17 Jan 96 13:44:10 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18016; Wed, 17 Jan 1996 13:43:38 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id NAA25238; Wed, 17 Jan 1996 13:43:38 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.1/8.7.1) id QAA00839 for ipng@sunroof.eng.sun.com; Wed, 17 Jan 1996 16:43:35 -0500 Received: via switchmail; Wed, 17 Jan 1996 16:43:35 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 17 Jan 1996 16:42:49 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 17 Jan 1996 16:42:47 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 17 Jan 1996 16:42:44 -0500 (EST) Message-Id: Date: Wed, 17 Jan 1996 16:42:44 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1194) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: <199601171914.OAA05146@jekyll.piermont.com> References: <199601171914.OAA05146@jekyll.piermont.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" writes: > Yes there is. You send to foo@[addr]. If you have properly configured > your mailer on, say, your UUCP host, it should get through. I've had > to use this on occassion. The uucp sites I used to set up did this > properly. That's my point. The mechanism such mailers use to get this through is not standardized. It is local information. Similarly, an IPv4 host could send to "foo@whatever.ip6.int". A properly configured mailer can get this through using local information. No need for MX or AAAA records in the DNS servers. All that is needed is a standardized syntax for the name. It is not necessary for the syntax to be one other than domain name syntax. With domain name syntax, the knowledge of such things can be localized to either the mail transport agent or its resolver library. With some other syntax, the knowledge of that syntax has to be coded all the way up and down the stack. Robert Elz writes: > I think the IPv4 domain literal > stuff in rfc822 worked just perfectly for this - it is possible > to use it, when you really need to, but it is so arcane that in > ordinary day to day use, no-one ever does. That is the perfect > outcome. "432100000001000200030004056789ab.ip6.int" isn't arcane? The syntax is sufficiently ugly and user-unfriendly to discourage day to day use. I dealt with a dead letter today that had a return address of "thrills1@204.157.172.151". That should say something about the success of IPv4 domain literal syntax. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 17 13:46:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09893; Wed, 17 Jan 96 13:46:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09887; Wed, 17 Jan 96 13:46:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18296; Wed, 17 Jan 1996 13:45:46 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id NAA25857; Wed, 17 Jan 1996 13:45:46 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16095(10)>; Wed, 17 Jan 1996 11:09:52 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 17 Jan 1996 11:09:39 -0800 To: Geert Jan de Groot Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1195) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: GeertJan.deGroot's message of Wed, 17 Jan 96 01:57:48 -0800. <199601170957.KAA00282@berklix.ripe.net> Date: Wed, 17 Jan 1996 11:09:29 PST From: Steve Deering Message-Id: <96Jan17.110939pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Recent mail on the IPng list suggested thatsome people felt that > renumbering had hard consequences and therefore should be put off. > This scares me, as *easy and automatic renumbering* is one of > the key properties of IPv6 and it should not be pushed off > as being 'hard'. Automatic renumbering is easy in IPv6, and has not been pushed off -- please see the addrconf spec. Whether or not upper layer protocols and applications can cope with having their IP addresses change out from under them is the PIER WG's problem. I happen to think they have a very tough problem, and until they have "solved" it (the definition of "solved" is rather complicated here), I have to wonder how much IPv6's easy and automatic renumbering capability will be exercised. 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 Jan 17 14:39:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09984; Wed, 17 Jan 96 14:39:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09975; Wed, 17 Jan 96 14:39:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26456; Wed, 17 Jan 1996 14:38:29 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id OAA10728; Wed, 17 Jan 1996 14:38:27 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA21636; Wed, 17 Jan 1996 14:38:25 -0800 Date: Wed, 17 Jan 1996 14:38:25 -0800 From: Ran Atkinson Message-Id: <199601172238.OAA21636@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1196) Re: Renumbering for IPv6 Newsgroups: cisco.external.ietf.ipng In-Reply-To: <96Jan17.110939pst.75270@digit.parc.xerox.com> References: <199601170957.KAA00282@berklix.ripe.net> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <96Jan17.110939pst.75270@digit.parc.xerox.com>, Steve Deering wrote: >Automatic renumbering is easy in IPv6, and has not been pushed off -- please >see the addrconf spec. Unfortunately, the stateful automatic renumbering mechanism (DHCP) does not appear close to having cryptographic authentication and is hence NOT a wise technique to deploy on any network/subnetwork connected to The Internet, unless a DHCP-filtering firewall is in place. The stateless automatic renumbering mechanism can be secured iff (1) Dynamic DNS Update gets cryptographic authentication added [this is a work item in DNS Security, I think] and DNS Security gets deployed AND (2) all of the nodes being renumbered and their first hop routers have preconfigured IPsec Security Associations so that the Routing Advertisements containing the new routing prefix can be authenticated upon reception by the nodes being renumbered. My conclusion is that the community is NOT at the point now where we can _assume_ that autorenumbering is feasible on networks connected to The Internet without using a firewall. Manual renumbering can work for relatively small sites (a few Class C sized subnets) but is not scalable for anything close a Class B size network. I agree that automatic renumbering is really important. I just don't think its fully done yet and it isn't clear to me when it will be done enough for us to assume that it is there and works well. 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 Wed Jan 17 15:07:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10001; Wed, 17 Jan 96 15:07:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09995; Wed, 17 Jan 96 15:07:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02108; Wed, 17 Jan 1996 15:07:01 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id PAA18493; Wed, 17 Jan 1996 15:07:02 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA23634; Wed, 17 Jan 1996 15:07:00 -0800 Date: Wed, 17 Jan 1996 15:07:00 -0800 From: Ran Atkinson Message-Id: <199601172307.PAA23634@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1197) Re: IPv6 over NBMA In-Reply-To: <9601162158.AA18315@dogfish.zk3.dec.com> References: <199601160235.VAA14037@borg.mindspring.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601162158.AA18315@dogfish.zk3.dec.com>, Peter Schulter wrote: >This is the same sort of thing we're tackling for ATM. My current approach >is to provide a mechanism which allows ND to operate unmodified (which I >think is manditory since ND is an integral part of the network layer protocol >and we can't/shouldn't change the network-layer protocol to compensate >for "short comings" of specific datalinks). I believe that the above clarifies much of the disagreement between me (and some others) and Peter/Grenville. I do not believe that there has ever been consensus that traditional ND should/must be used over any kind of link that lacks a native broadcast technique (e.g. MARS is not a native technique to ATM). Things that most folks think ND works well over include Ethernet, FDDI, Token Ring, and many types of radio links. Things that many folks (clearly not all, Peter and Grenville being examples in the set that disagree with me here :-) believe should NOT use the traditional ND include NBMA links and other media lacking any native broadcasting techniques. Reaching consensus on whether "Traditional ND should/must be used over all media." might be a starting point to resolving the disagreements over IPv6/ATM and the broader related question of IPv6/NBMA. 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 Wed Jan 17 15:51:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10110; Wed, 17 Jan 96 15:51:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10104; Wed, 17 Jan 96 15:51:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08693; Wed, 17 Jan 1996 15:51:01 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id PAA00167; Wed, 17 Jan 1996 15:51:01 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id SAA14555; Wed, 17 Jan 1996 18:50:53 -0500 Message-Id: <199601172350.SAA14555@thumper.bellcore.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1198) Re: IPv6 over NBMA In-Reply-To: Your message of Wed, 17 Jan 1996 15:07:00 -0800. <199601172307.PAA23634@puli.cisco.com> Date: Wed, 17 Jan 1996 18:50:51 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [..] >>Reaching consensus on whether "Traditional ND should/must be used over all >>media." might be a starting point to resolving the disagreements over >>IPv6/ATM and the broader related question of IPv6/NBMA. This is indeed a valid question. Interestingly, my reading of the ND docs didn't leave me with the impression there was anything optional about running ND. What you got when your underlying link network could natively multicast was subsets of ND service. The ND spec doesn't _seem_ to allow you to simply opt-out of ND and use something completely different on non-multicast-capable link interfaces. At least, that was my reading. (I'm assuming this is understood to be orthogonal to the token generation issue? NHRP instead of full-ND will still need to face questions of link-local address generation.) cheers, gja ------------------------------------------------------------------------------ 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 Jan 17 16:30:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10135; Wed, 17 Jan 96 16:30:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10129; Wed, 17 Jan 96 16:30:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14342; Wed, 17 Jan 1996 16:29:34 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id QAA09597; Wed, 17 Jan 1996 16:29:33 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25918; Wed, 17 Jan 96 19:28:23 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA15185; Wed, 17 Jan 96 19:29:14 EST Date: Wed, 17 Jan 96 19:29:14 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601180029.AA15185@pobox.BayNetworks.com> To: rja@cisco.com, gja@thumper.bellcore.com Subject: (IPng 1199) Re: IPv6 over NBMA Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > [..] > >>Reaching consensus on whether "Traditional ND should/must be used over all > >>media." might be a starting point to resolving the disagreements over > >>IPv6/ATM and the broader related question of IPv6/NBMA. > > This is indeed a valid question. Interestingly, my reading of the > ND docs didn't leave me with the impression there was anything > optional about running ND. What you got when your underlying link > network could natively multicast was subsets of ND service. The > ND spec doesn't _seem_ to allow you to simply opt-out of ND > and use something completely different on non-multicast-capable > link interfaces. At least, that was my reading. > I think that section 3.2 of the ND spec is quite clear that only a subset (including an empty one, I guess) of ND features may be applicable on certain medias. Specifically to NBMA: "non-broadcast multiple access (NBMA) - The only Neighbor Discovery mechanisms available on these links are Redirect handling and Neighbor Unreachability Detection. If the hosts support manual configuration of a list of default routers the hosts can dynamically acquire the link-layer addresses for their neighbors from Redirect messages." 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 Jan 17 16:45:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10211; Wed, 17 Jan 96 16:45:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10202; Wed, 17 Jan 96 16:45:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16106; Wed, 17 Jan 1996 16:45:03 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id QAA13023; Wed, 17 Jan 1996 16:45:01 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14620(11)>; Wed, 17 Jan 1996 16:44:41 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 17 Jan 1996 16:44:31 -0800 To: Robert Elz Cc: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1200) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: kre's message of Wed, 17 Jan 96 09:44:58 -0800. <5356.821900698@munnari.OZ.AU> Date: Wed, 17 Jan 1996 16:44:26 PST From: Steve Deering Message-Id: <96Jan17.164431pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, > No, for URLs the correct answer is to do nothing. There is no > need at all for a URL to contain a literal address, under any > circumstances (IPv6 or IPv4). I agree that stashing away URLs with address literals into your bookmark list is something to be avoided. However, a number of vendors are now using web browsers as network management interfaces, i.e., using HTTP instead of SNMP to manage boxes, which I think is pretty cool (perhaps the SNMP community thinks this is an abomination?). Anyway, it might be nice for that particular use of browsers to be able to express a URL with a literal address, say when remote debugging a DNS server. I think the ability of applications to work in the absence of a functioning DNS system was an important, valuable property of the Internet Architecture as it was. That part of the architecture is clearly under threat these days. Grumble. 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 Jan 17 16:57:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10227; Wed, 17 Jan 96 16:57:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10221; Wed, 17 Jan 96 16:57:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17275; Wed, 17 Jan 1996 16:56:59 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id QAA15013; Wed, 17 Jan 1996 16:56:33 -0800 From: schulter@zk3.dec.com Received: from rock.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA18415; Wed, 17 Jan 1996 19:51:03 -0500 Received: from dogfish.zk3.dec.com by quarry.zk3.dec.com; (5.65/1.1.8.2/13Feb95-0113PM) id AA14764; Wed, 17 Jan 1996 19:50:48 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA04732; Wed, 17 Jan 1996 19:51:23 -0500 Message-Id: <9601180051.AA04732@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1201) Re: IPv6 over NBMA In-Reply-To: Your message of "Wed, 17 Jan 96 15:07:00 PST." <199601172307.PAA23634@puli.cisco.com> Date: Wed, 17 Jan 96 19:51:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 17 Jan 96 15:07:00 PST Ran Atkinson wrote: > I believe that the above clarifies much of the disagreement between me > (and some others) and Peter/Grenville. > > I do not believe that there has ever been consensus that traditional ND > should/must be used over any kind of link that lacks a native broadcast > technique (e.g. MARS is not a native technique to ATM). Things that most > folks think ND works well over include Ethernet, FDDI, Token Ring, and many > types of radio links. Things that many folks (clearly not all, Peter and > Grenville being examples in the set that disagree with me here :-) believe > should NOT use the traditional ND include NBMA links and other media > lacking any native broadcasting techniques. This is certainly a point which should be discussed and consensus reached, both in the IP over ATM community, and the IPv6 community. I include the IPv6 community in this since I think that saying that ND is not to be used over NBMA media will have some affects on the network layer. I have added the IP over ATM mailing list to my reply since folks there are probably interested in this discussion. My current view of the IPv6 over ATM world is that, unlike IPv4, IPv6 has a built-in address resolution protocol in ND. That is, IPv4 choose to leave address resolution up to the datalink layer (i.e., ARP) and datalink protocols (well, this wasn't a choice as much as unecessary for what TCP/IP was originally intended to do; broadcast media were dealt with later). This is why the IP over ATM group could define new protocols like ATMARP and NHRP without requiring any changes to the network layer. The network layer simply left it up to the datalink layer to perform the address resolution approrpiate to the specific media. On the other hand, IPv6 has chosen to include address resolution as part of the base network layer protocol suite; that is, ND. ND is placed at the ICMP layer, rather than the datalink layer. ND uses IPv6 packet headers, IPv6 security, and manages the IPv6 prefix list and routing tables which are used by IPv6 to make routing decisions. Further, ND is meant to be media independent, so IPv6 expects to use ND for all these functions on all interfaces. >From reading the ND spec and listening to discussions at Dallas, it's my impression that ND can't be "turned off" or made "optional". Further, ND is used for much more than simply address resolution, it is also used for address autoconfiguration, router discovery, router redirects, and network configuration. Thus, it seems to me that it is very integral to IPv6 and simply can not be replaced with some other protocol on a media-by-media basis. Given this, my approach to IPv6 over ATM is to design something which will permit ND to work over ATM with no modification or changes of any sort to ND or the network layer. That is, the network layer should be able to treat all datalinks the same since this is what ND seems to want to do. This makes the IPv6 over X media problem exclusively a datalink layer problem, and this is where I think the problem should be solved. Of course, solving some of these problems in the datalink means that some datalinks (like ATM) must deal with a protocol which is inhierently mismatched to the characteristics of the datalink. To me, this means developing a way to adapt ND to the datalink layer rather than changing or replacing ND. Thus, my expectations have always been to try to accomodate ND over ATM rather than trying to bypass or replace ND. If ND is bypassed or replaced this would mean trying to specify a new network layer protocol that does address resolution, router discovery, address autoconfiguration, router redirection, and network configuration (all while trying to keep ND away from the network), all of which will have to be done if ND is not used on a specific media. Further, if one chooses to say "ND does not apply to media type X" then some changes to the way IPv6 and ND are currently defined must be made so that some other protocol can be plugged in where ND sits on a per-media basis (or so that ND can be unplugged on a per-media basis). So, ND over ATM may look like a mismatch (and it is), but I think it is quite possible to develop a method of adapting ND to ATM just as some method of adapting IP multicast to ATM had to be developed (another case in which a base feature of the network layer protocol was mismatched to the media characteristics). Further, I think adapting ND to ATM is a much simpler proposition that trying to come up with a new protocol that does what ND does, can be made fairly light weight, and can be made quick and easy to implement. And all this can be done without the network layer having to know anything about it. This is exactly the tact I'm taking in my I-D for IPv6 over ATM. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 17 17:04:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10239; Wed, 17 Jan 96 17:04:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10233; Wed, 17 Jan 96 17:04:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18212; Wed, 17 Jan 1996 17:04:12 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id RAA17025; Wed, 17 Jan 1996 17:04:11 -0800 From: schulter@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA04113; Wed, 17 Jan 1996 19:58:49 -0500 Received: from dogfish.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23014; Wed, 17 Jan 1996 19:58:48 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA04903; Wed, 17 Jan 1996 19:59:23 -0500 Message-Id: <9601180059.AA04903@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Grenville Armitage Cc: Ran Atkinson , ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1202) Re: IPv6 over NBMA In-Reply-To: Your message of "Wed, 17 Jan 96 18:50:51 EST." <199601172350.SAA14555@thumper.bellcore.com> Date: Wed, 17 Jan 96 19:59:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 17 Jan 96 18:50:51 EST Grenville Armitage wrote: > This is indeed a valid question. Interestingly, my reading of the > ND docs didn't leave me with the impression there was anything > optional about running ND. What you got when your underlying link > network could natively multicast was subsets of ND service. The > ND spec doesn't _seem_ to allow you to simply opt-out of ND > and use something completely different on non-multicast-capable > link interfaces. At least, that was my reading. Absolutely. This is exactly my reading to. I also belive Steve Deering commented at one of the IPng WG sessions in Dallas that ND is "not optional" ("but ATM is" ;-) > (I'm assuming this is understood to be orthogonal to the token > generation issue? NHRP instead of full-ND will still need to face > questions of link-local address generation.) Right. The choose of the network layer address token is completely independed of what address resolution mechanism is used to resolve the resulting network layer address into a datalink address. This discussion should be separate from any discussion of the applicability of ND to ATM. --- pete p.s. I've added the IP over ATM group back to the CC list for this. I think the ND discussions should take place in both IP over ATM and IPv6 lists, but the host token discussion can sort of go over to just the IP over ATM list (IMHO). Both may also be issues we want to schedule some time to discuss in the WG sessions in LA. ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 17 17:10:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10254; Wed, 17 Jan 96 17:10:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10248; Wed, 17 Jan 96 17:10:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18928; Wed, 17 Jan 1996 17:10:16 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id RAA18395; Wed, 17 Jan 1996 17:10:15 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14588(3)>; Wed, 17 Jan 1996 17:09:53 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 17 Jan 1996 17:09:47 -0800 To: Geert Jan de Groot Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1203) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: GeertJan.deGroot's message of Wed, 17 Jan 96 12:49:47 -0800. <9601172049.AA13856@ncc.ripe.net> Date: Wed, 17 Jan 1996 17:09:45 PST From: Steve Deering Message-Id: <96Jan17.170947pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > *However*, even if IEEE 802ng comes out with 64 bit addresses, I'd advocate > > simply hashing those longer addresses down to 48 bits for use in the > > lowest-order field of a statelessly-autoconfigured IPv6 address. It > > shouldn't be difficult to devise a hash from 64 bits to 48 bits that has > > negligible probability of collision -- probably just dropping the high- > > order bits would do. > > I'm happy with this if we can agree on the following: > If a collision happens nevertheless, that the spec will > allow for these machines to work (e.g. by having the > machine which detects the collision to take another number), > and not suggesting 'you have to return those cards as > they're broken' as both cards are fine and there is nothing > to return to nobody.. Geert Jan, The spec allows collisions to be detected (at start-up time only). The problem can be repaired by manually configuring all but one of the colliding interfaces to have non-colliding tokens. Though in the case of an IPv6 lightbulb, I think it makes more sense to take it back to the store and exchange it for another one. I am assuming that the probability of getting the collision in the first place is about the same as winning one of those $50,000,000 lotteries. (When you go to exchange your lightbub, buy another lottery ticket while you're there. :-) Note that, in the case of a collison between regular, old 48-bit Ethernet addresses, if you don't exchange the card, you'll have to manually configure what Ethernet address the colliding interface should use, rather than just configuring the token for the IPv6 addresses. 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 Jan 17 17:22:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10266; Wed, 17 Jan 96 17:22:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10260; Wed, 17 Jan 96 17:22:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20372; Wed, 17 Jan 1996 17:22:03 -0800 Received: from jekyll.piermont.com by mercury.Sun.COM (Sun.COM) id RAA21032; Wed, 17 Jan 1996 17:21:58 -0800 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.6.12/8.6.12) with SMTP id UAA00721; Wed, 17 Jan 1996 20:19:48 -0500 Message-Id: <199601180119.UAA00721@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Steve Deering Cc: Robert Elz , iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 1204) Re: clash between PS rfc1884 and PS rfc1783 In-Reply-To: Your message of "Wed, 17 Jan 1996 16:44:26 PST." <96Jan17.164431pst.75270@digit.parc.xerox.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 Jan 1996 20:19:42 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > > No, for URLs the correct answer is to do nothing. There is no > > need at all for a URL to contain a literal address, under any > > circumstances (IPv6 or IPv4). > > I agree that stashing away URLs with address literals into your bookmark > list is something to be avoided. However, a number of vendors are now using > web browsers as network management interfaces, i.e., using HTTP instead of > SNMP to manage boxes, which I think is pretty cool (perhaps the SNMP > community thinks this is an abomination?). Furthermore, regardless of our tastes, I routinely see lots of IP address literals show up in URLs on web pages. Maybe its not strictly needed, but they are there anyway regardless of our desires. The idea that we are going to break a bunch of things (like mailing to address literals or literals in URLs) just in order to avoid coping with the :'s in the chosen v6 address representation is a little silly. Perry ------------------------------------------------------------------------------ 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 Jan 17 17:26:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10278; Wed, 17 Jan 96 17:26:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10272; Wed, 17 Jan 96 17:26:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20819; Wed, 17 Jan 1996 17:26:11 -0800 Received: from jekyll.piermont.com by mercury.Sun.COM (Sun.COM) id RAA21961; Wed, 17 Jan 1996 17:26:09 -0800 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.6.12/8.6.12) with SMTP id UAA00732; Wed, 17 Jan 1996 20:25:52 -0500 Message-Id: <199601180125.UAA00732@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Steve Deering Cc: Geert Jan de Groot , ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1205) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Wed, 17 Jan 1996 17:09:45 PST." <96Jan17.170947pst.75270@digit.parc.xerox.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 Jan 1996 20:25:51 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > The spec allows collisions to be detected (at start-up time only). The > problem can be repaired by manually configuring all but one of the colliding > interfaces to have non-colliding tokens. Unfortunately, the naive will have great trouble figuring out what the problem is. Have the colliding interfaces do something smart, I say. > (When you go to exchange your lightbub, > buy another lottery ticket while you're there. :-) The problem will be something like this as I see it. Customer: This toaster doesn't work -- it doesn't show up on the home control panel. Store clerk: Well, lets check it out. Plug it in here. Nope, it works, you are nuts. No, you can't exchange it. Customer: This toaster doesn't work with my home control unit, but it seems that the toaster is okay. Guy in blue overalls: Well, the control unit is fine. Guess its just gremlins. Never did understand this stuff well anyway. Sorry, can't help you. In short, we shouldn't design a protocol that can fail, even rarely, under perfectly ordinary conditions, provided that there is a fairly simple and cheapo solution to fix things, and it appears that there is... Perry ------------------------------------------------------------------------------ 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 Jan 17 17:52:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10346; Wed, 17 Jan 96 17:52:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10340; Wed, 17 Jan 96 17:51:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23464; Wed, 17 Jan 1996 17:51:23 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id RAA26302; Wed, 17 Jan 1996 17:51:22 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14645(5)>; Wed, 17 Jan 1996 17:51:16 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 17 Jan 1996 17:51:05 -0800 To: perry@piermont.com Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1206) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: perry's message of Wed, 17 Jan 96 17:25:51 -0800. <199601180125.UAA00732@jekyll.piermont.com> Date: Wed, 17 Jan 1996 17:50:55 PST From: Steve Deering Message-Id: <96Jan17.175105pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perry, > Unfortunately, the naive will have great trouble figuring out what the > problem is. For anything with a display panel on it (an IPv6 wristwatch or bigger), the detecting node will display a message saying "duplicate address detected", or something like that. The IPv6 lightbulb will blink 3 times, and it will have a little label on it that explains what 3 blinks mean. > Have the colliding interfaces do something smart, I say. Like what? Generate a different token at random and DAD that? The importance of stability of tokens was mentioned earlier in this thread, which means you'd want some stable storage to save the generated token, so the same one would be used each time the device is subsequently powered up. Maybe your lightbulb will have a true random-number generator and stable storage space on it, and if that's true I suppose I could go along with "doing something smart". But sometimes it's not worth the cost and complexity to include mechanisms to deal with a problem that has 10^- probability of occuring. More than likely, the duplicate recovery code will fail on the one-in-a-billion occasion when it's finally needed, because it will never be exercised enough to reveal its bugs. > In short, we shouldn't design a protocol that can fail, even rarely, > under perfectly ordinary conditions, provided that there is a fairly > simple and cheapo solution to fix things, ... That much I agree with. > ...and it appears that there is... That's the part I'm not convinced of. But I'm listening. 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 Jan 17 18:13:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10373; Wed, 17 Jan 96 18:13:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10367; Wed, 17 Jan 96 18:13:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25457; Wed, 17 Jan 1996 18:12:33 -0800 Received: from jekyll.piermont.com by mercury.Sun.COM (Sun.COM) id SAA29929; Wed, 17 Jan 1996 18:12:31 -0800 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.6.12/8.6.12) with SMTP id VAA00846; Wed, 17 Jan 1996 21:12:16 -0500 Message-Id: <199601180212.VAA00846@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Steve Deering Cc: perry@piermont.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1207) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: Your message of "Wed, 17 Jan 1996 17:50:55 PST." <96Jan17.175105pst.75270@digit.parc.xerox.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 17 Jan 1996 21:11:52 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > > Unfortunately, the naive will have great trouble figuring out what the > > problem is. > > For anything with a display panel on it (an IPv6 wristwatch or bigger), > the detecting node will display a message saying "duplicate address > detected", or something like that. You noted below when I brought up the notion of generating a new token, the code to do this will rarely be exercised. Since both solutions suffer from the same flaw (and since putting up a message isn't that insignificant an effort) I don't think that particular argument works against my comments. > > Have the colliding interfaces do something smart, I say. > > Like what? Generate a different token at random and DAD that? The > importance of stability of tokens was mentioned earlier in this thread, > which means you'd want some stable storage to save the generated token, > so the same one would be used each time the device is subsequently powered > up. Maybe your lightbulb will have a true random-number generator and > stable storage space on it, and if that's true I suppose I could go along > with "doing something smart". You don't need a random number generator. Incrementing your token by 500 until you don't collide is probably sufficient. (Why 500? Maybe you bought a batch of lightbulbs that have sequential MAC addresses. Maybe 1000 or 10000 is a better number but the principle remains.) Since there is asymetry in between the host detecting the problem and the one that the problem is detected from, you don't need randomness. (Of course, you probably need a good RNG so that you can do Photuris keying with the lightbulb and then send IPsec packets to it telling it to switch to energy conservation mode five, but thats another story.) I agree that you need to store the new value, but that isn't so hard to do. > But sometimes it's not worth the cost and > complexity to include mechanisms to deal with a problem that has > 10^- probability of occuring. As I've noted, if you are going to have it detect the situation and print out an error, you might as well have done the autoreMAC code or whatever it would be called instead. > More than likely, the duplicate > recovery code will fail on the one-in-a-billion occasion when it's finally > needed, because it will never be exercised enough to reveal its bugs. Same could be said for the stuff that makes the bulb blink three times. Perry ------------------------------------------------------------------------------ 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 Jan 17 18:58:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10427; Wed, 17 Jan 96 18:58:42 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10421; Wed, 17 Jan 96 18:58:27 PST Received: from kandinsky.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA10610; Wed, 17 Jan 1996 18:57:22 -0800 Received: by kandinsky.eng.sun.com (5.x/SMI-SVR4) id AA01077; Wed, 17 Jan 1996 19:02:52 -0800 Date: Wed, 17 Jan 1996 19:02:52 -0800 From: gilligan@caribe.eng.sun.com (Bob Gilligan) Message-Id: <9601180302.AA01077@kandinsky.eng.sun.com> To: ipng@sunroof Subject: (IPng 1208) New draft of API spec is now available Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. We have put together a new draft of the IPv6 API spec. I have not seen the official announcement yet, but the document is now available in the internet-drafts directory with the name draft-ietf-ipngwg-bsd-api-04.txt. This version addresses the three issues that were brought up at the Dallas IETF meeting, which are (from the meeting minutes): - Matt Thomas suggested that in addition to the global variables ipv6addr_any and ipv6addr_loopback, systems should also provide constants for that can be used for initializing IPv6 address variables to these values. - A number of people suggested that systems should be allowed to use the all-zeros IPv6 address as the value for ipv6addr_any. - Erik Nordmark suggested that the return parameter to the hostname2addr() function be changed to include the address lifetime (TTL) which is stored with the address in the DNS. This would provide applications with the information they need to know when to stop using an address. This draft does not include the suggestion recently made on the list to use names or small integers, instead of IPv6 addresses, to identify interfaces in receiving interface determination and sending interface specification. I didn't get the feeling that there was consensus around that proposed change. The consensus at the Dallas meeting was that the draft would be put up for a working group last call once the three issues above are addresses. I'd like to propose that we do that now, address any additional issues that people bring up, and then move this document forward to Informational RFC. 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 Jan 18 03:06:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10820; Thu, 18 Jan 96 03:06:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10814; Thu, 18 Jan 96 03:06:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22417; Thu, 18 Jan 1996 03:06:13 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id DAA24032; Thu, 18 Jan 1996 03:06:10 -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 MAA15874; Thu, 18 Jan 1996 12:06:00 +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 MAA22949; Thu, 18 Jan 1996 12:05:59 +0100 Message-Id: <199601181105.MAA22949@givry.inria.fr> From: Francis Dupont To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1209) Re: IPv6 over NBMA In-Reply-To: Your message of Wed, 17 Jan 1996 15:07:00 PST. <199601172307.PAA23634@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <22943.821963133.1@givry.inria.fr> Date: Thu, 18 Jan 1996 12:05:45 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I do not believe that there has ever been consensus that traditional ND should/must be used over any kind of link that lacks a native broadcast technique (e.g. MARS is not a native technique to ATM). Things that most folks think ND works well over include Ethernet, FDDI, Token Ring, and many types of radio links. Things that many folks (clearly not all, Peter and Grenville being examples in the set that disagree with me here :-) believe should NOT use the traditional ND include NBMA links and other media lacking any native broadcasting techniques. => I agree that ND has not the ability to handle NBMA links itself. IP over ATM and Routing Over Large Clouds did a statement at the last IETF meeting about the migration from Classical IP to NHRP then now I believe the questions are: - is NHRP the solution to IPv* over NBMA with two interesting special cases: * IPv6 over ATM * IPv6 over IPv4 - how to put ND and NHRP together? - how to put NHRP and IPv6 routing protocols together? - how to handle IPv6 multicasts with NHRP I don't think these issues are simple then there is place for some RFC (BCP ?)... 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 Thu Jan 18 03:16:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10834; Thu, 18 Jan 96 03:16:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10828; Thu, 18 Jan 96 03:16:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22632; Thu, 18 Jan 1996 03:15:31 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id DAA24806; Thu, 18 Jan 1996 03:15:31 -0800 Received: from uvite56.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA13110; Thu, 18 Jan 1996 06:15:22 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jan 1996 06:15:28 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 1210) Re: ND Asst for Security Issue for DHCPv6? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:09 AM 1/9/96, Ralph Droms wrote: >At 10:58 PM 1/8/96, bound@zk3.dec.com wrote: >> 4. A new one per [DHCP authentication scheme] >> Ralph Droms talking with Christian Huitema and Jeff >> Schiller is to make IPSEC ignore the relay-agent field in the >> creation of the secured data. > >Small clarification here - Jeff and Christian suggested a DHCP-specific >scheme that ignores the relay-agent field, not (necessarily) a modified >version of IPSEC. Here's the proposal for a DHCP-specific authentication scheme. Since there has been significant discussion of other authentication schemes on this list, it seemed appropriate to post this proposal here. Jeff Schiller and Christian Huitema developed the following scheme in Dallas, which I've written up as an informal proposal. Thanks to Ran Atkinson and Thomas Narten for reviewing a draft of this proposal. - Ralph ===== Introduction ------------ DHCP transports protocol stack configuration parameters from centrally administered servers to TCP/IP hosts. Among those parameters are an IP address. DHCP servers can be configured to dynamically allocate addresses from a pool of addresses, eliminating a manual step in configuration of TCP/IP hosts. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Such constraint may be desirable in "hostile" enivronments where the network medium is not phsyically secured, such as wireless networks or college residence halls. Additionally, some network administrators may wish to provide authentication of DHCP messages from DHCP servers. In some environments, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. The goal of this proposal is to suggest a technique through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. Overview -------- The idea behind this proposal is to use well-known techniques to authenticate the source and contents of DHCP messages. Each authenticated DHCP message will include an encrypted value generated by the source as a message authentication code (MAC), and will contain a message digest confirming that the message contents have not been altered in transit. There is one "feature" of DHCP that complicates the authentication of DHCP messages. DHCP clients use limited broadcast for all messages. To allow for delivery of DHCP messages to servers that are not on the same subnet, a DHCP relay agent on the same subnet as the client receives the initial message and forwards the message on to the DHCP server. The relay agent changes the contents of one field - 'giaddr' - in the DHCP message. Thus, the message digest, which is to be computed by the client and confirmed by the server, cannot include the 'giaddr' field. Message authenticaion code -------------------------- Suppose the sender, S, and receiver, R, share a secret key, K, where K is unique to any messages exchanged between S and R. S and R are a DHCP client/server pair. S forms the MAC by encoding a counter value with K. This counter should be monotonically increasing and large enough to hold an NTP-format timestamp. The MAC: counter, f(K, MD(message + counter)) (where MD is a message digest function as specified below) is included in the DHCP message generated by S. Encoding function f must have the characteristics that K cannot be deduced from the MAC and f(K, MD(message + counter)) can't be guessed. R can then compute f(K, MD(message + counter)) to verify that S must have known K. Using a counter value such as the current time of day can reduce the danger of replay attacks. Key management -------------- Assume that the shared key, K, is distributed to the client through some out-of-band mechanism. The client must store K locally for use in all authenticated DHCP messages. The server must know the Ks for all authorized clients. To avoid centralized management of a list of random keys, suppose K for each client is generated from some value unique to that client. That is, K = f(MK, unique-id), where MK is a secret master key and f is an encoding function as described above. Each DHCP client must have a unique "client-id" through which its interactions with the DHCP server (specifically, the address currently allocated to the client) can be identified. This client-id may be a MAC address or a manufacturer's serial number; the specific choice of client-id is left to the network administrator. The client-id meets the requirements of the unique-id used to generate K in the previous paragraph. Without knowledge of the master key MK, an unauthorized client cannot generate its own key K. The server can quickly validate an incoming message from a new client by regenerating K from the client-id. For known clients, the server can choose to recover the client's K dynamically from the client-id in the DHCP message, or can choose to precompute and cache all of the Ks a priori. Selection of encoding function ------------------------------ The exact encoding function is TBD. One suggestion is to borrow from DNSSEC, in which the encoding function is designated by an identifier in the message. The identifier then selects no encoding, a default encoding (using the Public Key Cryptographic Standard as specified in DNSSEC) which must be provided, or one of several other optional encodings. Message contents verification ----------------------------- MD5 is a well-known mechanism for generating a digest that can confirm the the contents of a mesage have not been altered in transit. The only modification to MD5 for use in DHCP is to require that the 'giaddr' field be set to all 0s for the MD5 computation. Message contents ---------------- Putting all of this together, S builds: DHCP message, counter, f(K, MD5(message - 'giaddr' + counter)) where K is the client's key. R can then verify the contents of the message from the MD5 digest value, and verify that S must have held the shared secret key from the value of f(K, MD5(message - 'giaddr' + counter)) ------------------------------------------------------------------------------ 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 Jan 18 07:18:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10965; Thu, 18 Jan 96 07:18:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10959; Thu, 18 Jan 96 07:18:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01843; Thu, 18 Jan 1996 07:18:13 -0800 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id HAA21098; Thu, 18 Jan 1996 07:18:08 -0800 Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id QAA24274; Thu, 18 Jan 1996 16:16:50 +0100 Received: from nestvx.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id QAA22209; Thu, 18 Jan 1996 16:07:23 +0100 Message-Id: <199601181507.QAA22209@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Thu, 18 Jan 96 16:07:55 MET Date: Thu, 18 Jan 96 16:07:55 MET From: Markus Jork To: "francis.dupont@inria.fr"@vbormc.vbo.dec.com (francis dupont) Cc: "rja@cisco.com"@vbormc.vbo.dec.com, "ipng@sunroof.eng.sun.com"@vbormc.vbo.dec.com, "ip-atm@matmos.hpl.hp.com"@vbormc.vbo.dec.com, jork@nestvx.enet.dec.com Apparently-To: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.Sun.COM, rja@cisco.com, francis.dupont@inria.fr Subject: (IPng 1211) Re: IPv6 over NBMA Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In your previous mail you wrote: > > I do not believe that there has ever been consensus that traditional ND > should/must be used over any kind of link that lacks a native broadcast > technique (e.g. MARS is not a native technique to ATM). Things that most > folks think ND works well over include Ethernet, FDDI, Token Ring, and many > types of radio links. Things that many folks (clearly not all, Peter and > Grenville being examples in the set that disagree with me here :-) believe > should NOT use the traditional ND include NBMA links and other media > lacking any native broadcasting techniques. > > => I agree that ND has not the ability to handle NBMA links itself. Well, with a little bit of help from the datalink layer ND will do its job just fine, at least for ATM. Peter Schulter's I-D demonstrates that nicely. It contains a proposal for how to do ND over ATM, which I happen to like a lot. (This is no wonder because I contributed to the ideas.) Grenville's I-D describes an alternative proposal for ND over ATM. Given that two proposals are out there already, why do you and Ran think this won't work? I would be very interested in your opinion, especially on Peter's draft. I think this would be a very useful discussion. So far I haven't seen any technical arguments against the proposal. Why not just do it that way? It would preserve all the features of ND. As you write yourself, it is not at all clear how NHRP would be used with IPv6 and if this is going to work at all: > IP over ATM and Routing Over Large Clouds did a statement at the last > IETF meeting about the migration from Classical IP to NHRP then > now I believe the questions are: > - is NHRP the solution to IPv* over NBMA with two interesting > special cases: > * IPv6 over ATM > * IPv6 over IPv4 > - how to put ND and NHRP together? > - how to put NHRP and IPv6 routing protocols together? > - how to handle IPv6 multicasts with NHRP > I don't think these issues are simple then there is place for > some RFC (BCP ?)... It seems to me that NHRP is a really bad match for the IPv6 architecture. There is just one feature that ND and NHRP have in common: address resolution. As Peter pointed out in detail in a previous mail, trying to replace ND address resolution with NHRP would affect the whole IPv6 stack. ND is just too tightly woven into the IPv6 stack to be optional on a per-media basis. In addition to being an address resolution protocol, NHRP will also find the next hop towards some destination inside or even outside the NBMA network. Thus making it some kind of routing protocol used by hosts. This looks like another serious clash with the IPv6 architecture. In IPv6, ND maintains a next hop cache and router lists, handles router discovery and redirects. The underlying assumption is that the next hop is always on-link. Routers are identified by their link-local addresses, for example. NHRP, on the other hand, aims at finding a next-hop in another LIS (i. e. off- link). Note that Peter's draft provides a replacement for most of this NHRP functionality without modifying the existing ND mechanism. Shortcut VCs can be established to all destinations inside the ATM network. Markus ------------------------------------------------------------------------------ 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 Jan 18 07:33:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10994; Thu, 18 Jan 96 07:33:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10988; Thu, 18 Jan 96 07:33:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03147; Thu, 18 Jan 1996 07:32:30 -0800 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id HAA24977; Thu, 18 Jan 1996 07:32:30 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id KAA24190; Thu, 18 Jan 1996 10:32:29 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma024159; Thu Jan 18 10:32:05 1996 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id KAA03589; Thu, 18 Jan 1996 10:32:04 -0500 Received: from lobster.newbridge by mako.us.Newbridge.com (4.1/SMI-4.0) id AA20751; Thu, 18 Jan 96 10:25:03 EST Received: by lobster.newbridge (5.0/SMI-SVR4) id AA03876; Thu, 18 Jan 1996 10:30:30 +0500 Date: Thu, 18 Jan 1996 10:30:30 +0500 From: jhalpern@us.Newbridge.com (Joel Halpern) Message-Id: <9601181530.AA03876@lobster.newbridge> To: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1212) Re: IPv6 over NBMA X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In this discussion of ND, there seem to be several factors being confused. 1) IPng clearly requires the ND service. In particular, the methodology from the router advertisements which MAY provide prefixes, and the ability to attempt to resolve a "neighbor". 2) There is the underlying protocol which specifies how this is done. The ND document provides a way that this can be done over broadcast media. However, like all documents, it says: ~this is what this protocol is for, and if you want to use it, here is how~. An IETF protocol standard never says "you must use this document"> 3) To clarify the last sentence above, it is possible for the IPv6 baseline document to say that you must use the ND protocol. I do not believe that it says that. I woul dhope that what it says is that the ND service is necessary. If not, I believe we should fix it. 4) This leads us to a methodology for operating over NBMAs. Rather than trying to make them look like collections of ethernets, use the "locallity" notions that Yakov has been developing, the query mechanisms that ROLC has been working on, and provide the services which IPv6 requires (the ability to find routers and to receive redirects). The result is something which works. If we accidently wrote some overly restrictive words into a spec, let us NOT hang ourselves by them. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ 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 Jan 18 07:37:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11010; Thu, 18 Jan 96 07:37:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11004; Thu, 18 Jan 96 07:37:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03667; Thu, 18 Jan 1996 07:37:06 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id HAA26272; Thu, 18 Jan 1996 07:37:05 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA06034; Thu, 18 Jan 96 10:36:11 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA08565; Thu, 18 Jan 96 10:37:00 EST Date: Thu, 18 Jan 96 10:37:00 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601181537.AA08565@pobox.BayNetworks.com> To: deering@parc.xerox.com Subject: (IPng 1213) Re: [LONG] Random support for IPv6 auto configuration Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > Note that, in the case of a collison between regular, old 48-bit Ethernet > addresses, if you don't exchange the card, you'll have to manually configure > what Ethernet address the colliding interface should use, rather than just > configuring the token for the IPv6 addresses. > According to the IPv6-over-Ethernet spec a token should not be derived from a configured Ethernet address. There is a good reason for such a restriction. Should this rule be relaxed if the build-in mac address is found to be duplicate? 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 Jan 18 08:26:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11039; Thu, 18 Jan 96 08:26:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11033; Thu, 18 Jan 96 08:25:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08838; Thu, 18 Jan 1996 08:25:21 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id IAA09575; Thu, 18 Jan 1996 08:25:19 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA03374; Thu, 18 Jan 1996 11:12:25 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15426; Thu, 18 Jan 1996 11:12:23 -0500 Message-Id: <9601181612.AA15426@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1214) Re: Renumbering for IPv6 In-Reply-To: Your message of "Wed, 17 Jan 96 14:38:25 PST." <199601172238.OAA21636@puli.cisco.com> Date: Thu, 18 Jan 96 11:12:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Automatic renumbering is easy in IPv6, and has not been pushed off -- please >>see the addrconf spec. >Unfortunately, the stateful automatic renumbering mechanism (DHCP) does not >appear close to having cryptographic authentication and is hence NOT a wise >technique to deploy on any network/subnetwork connected to The Internet, >unless a DHCP-filtering firewall is in place. DHCP issue is on a relay-node not when the server is on the same link (at least in DHCPv6). The same mechanisms in ND or Stateless would use via IPSEC being in place. We have three alternatives on the table to solve the Relay-Node problem so IPSEC can be used, which will be discussed and resolved at the L.A. IETF meeting. >My conclusion is that the community is NOT at the point now where we >can _assume_ that autorenumbering is feasible on networks connected >to The Internet without using a firewall. Manual renumbering can >work for relatively small sites (a few Class C sized subnets) but >is not scalable for anything close a Class B size network. If the environment is an intranet (not on the internet) network I don't agree. In this case the security concerns are much different than you suggest. There is no access for or to the Internet, hence, the only insecure problem is an employee or internal issue which is much different. And quite frankly most revenue streams for many vendors will come from this environment for IPv6, DHCPv6, Dyn UPDs to DNS, and others. >I agree that automatic renumbering is really important. I just don't >think its fully done yet and it isn't clear to me when it will be done >enough for us to assume that it is there and works well. It will work at the UNH bake-off Feb 5-9. Not one vendor will be bringing a security implementation to the event as a note except Dan McDonald. Your point is that we need to make it secure. I agree with this for the Internet environment. But for many customers its done Ran. /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 Jan 18 09:47:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11178; Thu, 18 Jan 96 09:47:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11049; Thu, 18 Jan 96 08:45:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11466; Thu, 18 Jan 1996 08:45:15 -0800 Received: from a4.jck.com by mercury.Sun.COM (Sun.COM) id IAA15772; Thu, 18 Jan 1996 08:45:11 -0800 Received: from white-box.jck.com ("port 2039"@white-box.jck.com) by a4.jck.com (PMDF V5.0-5 #13246) id <0DLAM5Z0Y008ZW@a4.jck.com>; Tue, 16 Jan 1996 16:25 -0500 (EST) Date: Tue, 16 Jan 1996 16:25:24 -0500 (EST) From: John C Klensin Subject: (IPng 1215) Re: clash between PS rfc1884 and PS rfc1783 To: Matt Crawford Cc: iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 X-Mailer: Simeon for Windows Version 4.0 Beta 3 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Priority: NORMAL X-Authentication: none Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 16 Jan 1996 14:19:31 -0600 Matt Crawford wrote: > The text representation of IPv6 addresses specified in item 2 of > section 2.2 of RFC1884: > ... > results in a possible ambiguity if such an IPv6 address appears in a > URL constructed according to RFC1738 (section 3.1): >... Matt is of course correct, except that the applications problems extend far beyond URLs. I'd suggest that, basically, the syntax chosen may well be appropriate when talking about lower levels of the stack, but the presentation to applications-level tools is going to require major and traumatic changes to protocols and user interfaces that will, at best, slow the deployment of IPv6. >... > 3. Forbid the use of literal IPv6 addresses in URLs. More generally, forbidding the use of address literals in all applications (which I believe was under discussion at one point) is a good idea in theory, but impractical (at best) in practice. >... > All of these have drawbacks. I suggest that #1 is better than #2, > and #3 and #4 are out of the question. I have trouble disagreeing with this analysis, despite the fact that I inquired about this issue a while back and was told that it was too late to discuss it. john ------------------------------------------------------------------------------ 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 Jan 18 09:48:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11207; Thu, 18 Jan 96 09:48:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11055; Thu, 18 Jan 96 08:45:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11490; Thu, 18 Jan 1996 08:45:23 -0800 Received: from a4.jck.com by mercury.Sun.COM (Sun.COM) id IAA15818; Thu, 18 Jan 1996 08:45:18 -0800 Received: from tp.jck.com ("port 3121"@tp.jck.com) by a4.jck.com (PMDF V5.0-5 #13246) id <0DLC5Q5I0008ZW@a4.jck.com>; Wed, 17 Jan 1996 12:25 -0500 (EST) Date: Wed, 17 Jan 1996 12:24:24 -0500 From: John C Klensin Subject: (IPng 1216) Re: clash between PS rfc1884 and PS rfc1783 X-Sender: klensin@mail1.reston.mci.net To: Christian Huitema Cc: Robert Elz , Brian Carpenter CERN-CN , Matt Crawford , iesg@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Message-Id: <2.2.16.19960117172424.31cf0f64@mail1.reston.mci.net> Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 2.2 (16) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 14:40 96.01.17 +0100, Christian Huitema wrote: >I don't favor breaking rules in order to accomodate broken softwares. >Broken mailers are going to remain broken whatever we do. Some already do >a dull job of handling lists of IPv6 addresses in @x@y@z:t@u constructs, >some reply to lines like "To: mylist;". The question is not whether it >works today - it doesn't - but rather whether it can work. If you look at: > foo@[1:2:3::4:5:6] >then there is all reasons to believe that it can work, provided the mailer >is upgraded. The syntax of addresses has to be changed from: >... Christian, I think there are two important distinctions, one philosophical and one pragmatic, which we should keep in mind here: (1) There is a large difference between breaking (or making) rules to accomodate broken software and putting rules into place that breaks software that was perfectly conforming and acceptable prior to those rules. We've traditionally avoided the breaking valid things in the absence of compelling need and no plausible alternatives. IMO, compelling need has not been demonstrated here, and there are several plausible alternatives, including just extending the current dotted-octet notation for an extra several octets. (2) Presumably our shared goal here is to get IPv6 deployed as quickly as possible. While the volatility of the Web browser market is such that one can think about replacing all of them (note "think about"; I'm not certain it can be accomplished), email MUAs and gateways are many and complex and users are strongly attached to them. Many of them have, under customer pressure, provisions for servers to be configured by address. I think that is a terrible idea and have said so many times. But the important thing is that MUA software is widely deployed and the interfaces are very user-visible. Replacing a TCP/IPv4 stack with a TCP/IPv6 stack is going to be institutionally quite easy compared to replacing MUAs, precisely because the users are going to care (and care deeply) and because UI changes are going to require retraining end-users. In lots of organizations and companies, the requirement to replace or upgrade MUAs and to retrain users are going to be powerful obstacles to getting IPv6 deployed. I don't think doing that to ourselves in order to preserve a bit of fussy syntax is a good tradeoff. john ------------------------------------------------------------------------------ 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 Jan 18 09:52:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11220; Thu, 18 Jan 96 09:52:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11114; Thu, 18 Jan 96 09:31:25 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18887; Thu, 18 Jan 1996 09:30:51 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA00665; Thu, 18 Jan 1996 09:30:48 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA17079; Thu, 18 Jan 1996 09:30:41 -0800 Date: Thu, 18 Jan 1996 09:30:41 -0800 From: Ran Atkinson Message-Id: <199601181730.JAA17079@puli.cisco.com> To: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1217) Re: IPv6 over NBMA Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Well, with a little bit of help from the datalink layer ND will do its job % just fine, at least for ATM. Peter Schulter's I-D demonstrates that nicely. Peter's proposal is remarkably complex. MARS, while interesting, is also not trivial and I'd hardly call either one "a little bit of" anything. They might or might not work, but they are clearly very complex to build and simpler approaches exist that reuse more existing technology (NHRP) and are clearly easier to implement and make work. % It seems to me that NHRP is a really bad match for the IPv6 architecture. % There is just one feature that ND and NHRP have in common: address resolution. I hear that you dislike the NHRP/IPv6 combination. I don't see any explanation from you about _why_ you think this is so. Address Resolution is the -primary- purpose of ND after all. % As Peter pointed out in detail in a previous mail, trying to replace ND % address resolution with NHRP would affect the whole IPv6 stack. ND is just too % tightly woven into the IPv6 stack to be optional on a per-media basis. I can't speak for DEC's code, but that is proved to be false by looking at the NRL implementation. I could easily slip a solution based in part on NHRP into the NRL implementation (if there were BSD device drivers for some NBMA interface and I were still working on the NRL codebase :-). My current codebase makes it quite easy to use an NHRP-derived solution under IPv6 for NBMA interfaces. % In addition to being an address resolution protocol, NHRP will also find the % next hop towards some destination inside or even outside the NBMA network. % Thus making it some kind of routing protocol used by hosts. This looks like % another serious clash with the IPv6 architecture. I disagree that there is any architectural clash here. Further, I note that ATM, like most NBMA technologies, doesn't have any native concept of subnet that is very similar to the notion of an Ethernet/FDDI/T-R/Radio subnet. A certain amount of difference is inherent in using NBMA rather than traditional LAN media. Also, I believe it to be both desirable and possible to come up with a generic approach to IPv6/NBMA that would not be limited to ATM. This should be a goal IMHO. 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 Jan 18 10:54:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11318; Thu, 18 Jan 96 10:54:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11312; Thu, 18 Jan 96 10:53:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06242; Thu, 18 Jan 1996 10:53:23 -0800 Received: from domen.uninett.no by mercury.Sun.COM (Sun.COM) id KAA02628; Thu, 18 Jan 1996 10:53:17 -0800 From: Harald.T.Alvestrand@uninett.no Message-Id: <199601181853.KAA02628@mercury.Sun.COM> Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <19524-0@domen.uninett.no>; Thu, 18 Jan 1996 19:53:01 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: iesg@cnri.reston.va.us Cc: drums@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: (IPng 1218) A suggestion for IPv6 domain literals Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jan 1996 19:53:00 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ladies and Gentlemen, I've followed the debate on the IPNG list about the merits of notation for IPv6 addresses with great interest. It seems clear that: - Mail HAS to work when the DNS is down. In particular, you need to send mail with a source address that can be replied to *somehow* when you're= into such deep trouble that you don't find your own host's name. Addresses must then be such that they don't wreck mailers that have nev= er heard of IPv6; this is the "relay" and the "cc" problem. This was also the consensus from the DRUMS WG in Dallas. - In *all* other cases, it's either a strict local matter between source = and sink (telnet 1080:0:0:0:8:800:200C:417A) or inappropriate and should be= discouraged (http://1080:0:0:0:8:800:200C:417A:8000/weird-port-no.html)= =2E I have a trial suggestion for you, mostly based on Christian's suggestion= , but with a little spice added for variety. SUGGESTION 1: Add to the legal formats for writing IPv6 addresses in RFC 1884 section 2.2 a pure hex representation: 32 hex digits, no punctuation. SUGGESTION 2: Change the definition of "domain" in RFC 821 and 822 to be:= domain =3D domain-literal | dns-name dns-name =3D name *("." name) domain-literal =3D "[" name *("." name) "]" While this is somewhat more permissive than current RFC 821 syntax (it allows namelike objects inside a domain literal), it is much more restrictive than current RFC 822 syntax. Spice to taste. SUGGESTION 3: Write in the text (not grammar) rules that inside a domain literal, the following forms are acceptable: number "." number "." number "." number (IPv4 address) "ipv6" "." 32 hexchar (IPv6 address) DISCUSSION: In order to remain just a little compatible with the IPv6 decision to go with Hex rather than Decimal, I think we *have* to allow A-F in the domai= n literal. Extending this to handle A-Z is trivial, once you touch that par= t of the parsing code. The "ipv6" tag is left in to give surprised people an idea of what is goi= ng on, and on the general principle that "if you want two today, you'd bette= r leave an escape hatch in case you ever need a third". Comments? (I don't want to do much of this on 3 mailing lists, but I don't want either the IPv6 or the DRUMS people to feel left out, so I left both in. Sorry for those in the microscopic subset that are on both!) Harald A ------------------------------------------------------------------------------ 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 Jan 18 11:02:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11330; Thu, 18 Jan 96 11:02:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11324; Thu, 18 Jan 96 11:02:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07688; Thu, 18 Jan 1996 11:02:14 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id LAA05561; Thu, 18 Jan 1996 11:02:12 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5473; Thu, 18 Jan 96 14:01:20 EST Received: by RTP (XAGENTA 4.0) id 1918; Thu, 18 Jan 1996 14:00:51 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17010; Thu, 18 Jan 1996 14:01:13 -0500 Message-Id: <9601181901.AA17010@cichlid.raleigh.ibm.com> To: Craig Partridge Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1219) Re: Protocol Design Question In-Reply-To: Your message of "Thu, 18 Jan 1996 09:31:44 PST." <199601181731.JAA13301@aland.bbn.com> Date: Thu, 18 Jan 1996 14:01:10 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig Partridge writes: [note that I've redirected this to ipng] > It would be nice if the version number is in an information-rich part >of the packet header. By information rich, I mean it is in the part of >the packet header you are most likely to be examining when forwarding. >This comes from the simple fact that systems are typically designed around >blocks or cache lines, and there's time delay for getting each block or >cache line, and so when you access the version number, you'd like the rest >of the block it is in to also have useful information that you can process. >(As a side note, I realized about a month ago that, if I'd only known this >earlier, I would have suggested that IPv6 put the destination address first. >As the IPv6 header stands, the destination address is separated from the >other key fields, by the source address, which one rarely looks at). Don't lose too much sleep over your recent revelation. Routers are supposed to (in the MUST sense) check the source address, and if it is link-local, toss the packet. This was added for ND, to prevent ND packets from being forwarded by routers and then used for denial of service attacks. In retrospect, we didn't need it for ND after all, thanks to Bob Gilligan's suggestion that nodes check that the Hop Limit of received ND packets have a value of 255, i.e., they couldn't have been forwarded. Having said that, I think there are still compelling arguments for requiring that routers toss packets with link-local source addresses. Unfortunately, they get into the performance vs. good thing trade off, where the relative costs aren't straightforward to compare. 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 Jan 18 11:34:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11349; Thu, 18 Jan 96 11:34:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11343; Thu, 18 Jan 96 11:33:59 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12691; Thu, 18 Jan 1996 11:33:27 -0800 Received: from aland.bbn.com by mercury.Sun.COM (Sun.COM) id LAA15134; Thu, 18 Jan 1996 11:33:23 -0800 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id LAA13656; Thu, 18 Jan 1996 11:32:34 -0800 (PST) Message-Id: <199601181932.LAA13656@aland.bbn.com> To: "Thomas Narten" Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1220) Re: Protocol Design Question In-Reply-To: Your message of Thu, 18 Jan 96 14:01:10 -0400. <9601181901.AA17010@cichlid.raleigh.ibm.com> Date: Thu, 18 Jan 96 11:32:33 -0800 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Don't lose too much sleep over your recent revelation. Routers are supposed to (in the MUST sense) check the source address, and if it is link-local, toss the packet. Interesting -- I don't recall seeing this in router requirements. Is it there somewhere and I missed it? Others have noted that for multicast and IPv6 flows I'd need to look at the source address -- granted, but those packets are less common than zero flowid unicast packets. Craig ------------------------------------------------------------------------------ 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 Jan 18 12:34:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11383; Thu, 18 Jan 96 12:34:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11377; Thu, 18 Jan 96 12:34:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22511; Thu, 18 Jan 1996 12:33:28 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id MAA03014; Thu, 18 Jan 1996 12:33:24 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <53147(8)>; Thu, 18 Jan 1996 11:02:54 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 18 Jan 1996 11:02:33 -0800 To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1221) Re: [LONG] Random support for IPv6 auto configuration In-Reply-To: dhaskin's message of Thu, 18 Jan 96 07:37:00 -0800. <9601181537.AA08565@pobox.BayNetworks.com> Date: Thu, 18 Jan 1996 11:02:19 PST From: Steve Deering Message-Id: <96Jan18.110233pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, > According to the IPv6-over-Ethernet spec a token should not be derived > from a configured Ethernet address. There is a good reason for such > a restriction. Should this rule be relaxed if the build-in mac address > is found to be duplicate? Good point. How about if we say that, in the case of a duplicate hardware MAC address, you have to manually configure a new MAC address *and* manually configure a token. Generally, both would be configured to the same value (I can't think of a good reason for doing otherwise), but it does continue to respect the rule that the token not be automatically derived from a configured MAC address. 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 Jan 18 15:00:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11488; Thu, 18 Jan 96 15:00:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11482; Thu, 18 Jan 96 14:59:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15997; Thu, 18 Jan 1996 14:59:22 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id OAA16345; Thu, 18 Jan 1996 14:59:15 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <52636(5)>; Thu, 18 Jan 1996 14:58:50 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 18 Jan 1996 14:58:06 -0800 To: Craig Partridge Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1222) Re: Protocol Design Question In-Reply-To: craig's message of Thu, 18 Jan 96 09:31:44 -0800. <199601181731.JAA13301@aland.bbn.com> Date: Thu, 18 Jan 1996 14:58:05 PST From: Steve Deering Message-Id: <96Jan18.145806pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > (As a side note, I realized about a month ago that, if I'd only known this > earlier, I would have suggested that IPv6 put the destination address first. > As the IPv6 header stands, the destination address is separated from the > other key fields, by the source address, which one rarely looks at). I got this suggestion a number of times, for SIP and SIPP. What we could have done is put the fields in the following order: destination address source address flow label + priority length + next header + hop limit This would have given you your destination first, and would have made the source-address + flow-label a nice, contiguous field. The reason we didn't do that was the *honkin'* version number field, which had to be the first four bits, which for alignment reasons forced the addresses to follow all the other fields. The ironic part is that the version field has ended up being redundant, since we finally went back to using a separate link-layer type identifier for IPv6 (as originally proposed for SIP). However, as has already been pointed out, your router ends up having to look at almost all the fields anyway (the source address for multicast, for flows, and for prevent bogus source addresses from leaking out; the hop-limit to be decremented; the next header to see if there are any hop-by-hop options; and the length to know how many bytes to forward). I suppose you might get some parallelism benefit from starting the destination route lookup while still copying in the rest of the header. (Actually, if I undertsand what would make you happiest, it would probably be a layout like: destination address length + next header + hop limit priority + flow label source address so you could avoid even fetching the source address in some cases. That would certainly be novel, from a " header aesthetics" perspective.) > Don't lose too much sleep over your recent revelation. Routers are > supposed to (in the MUST sense) check the source address, and if it is > link-local, toss the packet. > > Interesting -- I don't recall seeing this in router requirements. Is it > there somewhere and I missed it? Router requirements won't say anything about link-local addresses, since they are new in IPv6. However, I would hope it would say something about not forwarding packets whose source addresses are from net 10, or broadcast, or multicast, etc. Certainly RReq's predecessor, Gateway Requirments, talked about this under the term "martian filtering". 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 Jan 18 15:45:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11528; Thu, 18 Jan 96 15:45:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11522; Thu, 18 Jan 96 15:45:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23272; Thu, 18 Jan 1996 15:44:35 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id PAA26706; Thu, 18 Jan 1996 15:44:36 -0800 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id PAA10242; Thu, 18 Jan 1996 15:44:01 -0800 Message-Id: <199601182344.PAA10242@mailhost.Ipsilon.COM> To: Craig Partridge Cc: "Thomas Narten" , ipng@sunroof.eng.sun.com Subject: (IPng 1223) Re: Protocol Design Question In-Reply-To: Your message of "Thu, 18 Jan 1996 11:32:33 PST." <199601181932.LAA13656@aland.bbn.com> Date: Thu, 18 Jan 1996 15:44:00 -0800 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig Partridge writes: > Don't lose too much sleep over your recent revelation. Routers are > supposed to (in the MUST sense) check the source address, and if it is > link-local, toss the packet. > > Interesting -- I don't recall seeing this in router requirements. Is it > there somewhere and I missed it? > > Others have noted that for multicast and IPv6 flows I'd need to look > at the source address -- granted, but those packets are less common than > zero flowid unicast packets. That is probably true now but note that a significant fraction of the traffic backbone routers see is IP-in-IP encapsulated, which might very well turn into true multicast traffic if the support existed. I don't think I'd want to count on what is true now remaining so forever. Because of this (though the reason is less compelling) I do think, all other things being equal, that it still would have been better to put the destination address in front of the source address in any case, for another reason. If you use a tree data structure to do route lookups (a good thing if you want to do a longest match route lookup with any efficiency) you start at the high order end of the destination address and work your way forward, moving into the source address if the destination is multicast or if the destination possibly matches a flow you have state for. Not having the source address after the destination puts a wart in the lookup code, when you get to the point where you've gone through the destination address and start testing bits in the source you have to shift to a different part of the header to find the bits you need. I'd note, however, that a full route lookup in a 30,000 route table is going to require about log(N), say 15 or 16, memory references semi-randomly scattered around a (probably) 0.5 Mbyte array. Unless you have a cache large enough to keep this all in fast memory (or unless you are assuming you can get by with some form of route cache, an assumption which is demonstrably false for Internet backbone routers, certainly) it is hard to see how a single extra cache line miss in the packet header is going to amount to that much extra work, relatively speaking. Dennis Ferguson ------------------------------------------------------------------------------ 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 Jan 18 16:15:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11548; Thu, 18 Jan 96 16:15:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11542; Thu, 18 Jan 96 16:14:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27763; Thu, 18 Jan 1996 16:14:22 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id QAA03628; Thu, 18 Jan 1996 16:14:23 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id TAA05534; Thu, 18 Jan 1996 19:13:55 -0500 (EST) Date: Thu, 18 Jan 1996 19:13:55 -0500 (EST) From: Scott Bradner Message-Id: <199601190013.TAA05534@newdev.harvard.edu> To: Harald.T.Alvestrand@uninett.no, iesg@CNRI.Reston.VA.US Subject: (IPng 1224) Re: A suggestion for IPv6 domain literals Cc: drums@cs.utk.edu, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this seems like a good way to deal with the issue to me 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 Thu Jan 18 18:23:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11663; Thu, 18 Jan 96 18:23:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11657; Thu, 18 Jan 96 18:23:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12574; Thu, 18 Jan 1996 18:22:44 -0800 Received: from zephyr.isi.edu by mercury.Sun.COM (Sun.COM) id SAA28080; Thu, 18 Jan 1996 18:22:43 -0800 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Thu, 18 Jan 1996 18:22:43 -0800 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199601190222.AA10588@zephyr.isi.edu> Subject: (IPng 1225) ip6.int To: ipng@sunroof.eng.sun.com Date: Thu, 18 Jan 1996 18:22:42 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The ip6.int zone is set up. I have a couple of concerns tho. nibble alignment of the address space will require the cname haq that is in use for IPv4. A better solution would be to use binary mappings. Sue et.al, would this be a real problem to convert to binary mappings of the ip6.int space? Also, without some promised enhancements to bind, fully expanded ip6.int lables seem to exceed the currenet packet size limits. And do we have a range mapped for ipv6 testing? -- --bill ------------------------------------------------------------------------------ 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 Jan 19 00:36:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11847; Fri, 19 Jan 96 00:36:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11841; Fri, 19 Jan 96 00:35:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07523; Fri, 19 Jan 1996 00:35:16 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id AAA07886; Fri, 19 Jan 1996 00:35:16 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA12223; Fri, 19 Jan 96 00:34:40 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA01243; Fri, 19 Jan 1996 00:34:53 -0800 Date: Fri, 19 Jan 1996 00:34:53 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601190834.AA01243@feller.mentat.com> To: Bob.Gilligan@Eng Subject: (IPng 1226) Re: New draft of API spec is now available Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I know your probably more than ready to get this thankless task over with but it seems like the API spec (or some information- al RFC) needs to say something about how to deal with the dreaded options. I realize that there currently are no defined options but it would be nice to have some guidelines in this area so when options begin to appear there there are not as many ways to deal with them as there are implementa- tions. > > The consensus at the Dallas meeting was that the draft would be put up > for a working group last call once the three issues above are > addresses. I'd like to propose that we do that now, address any > additional issues that people bring up, and then move this document > forward to Informational RFC. > Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 19 02:32:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11908; Fri, 19 Jan 96 02:32:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11902; Fri, 19 Jan 96 02:32:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14621; Fri, 19 Jan 1996 02:31:27 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id CAA23102; Fri, 19 Jan 1996 02:31:26 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA18335 Fri, 19 Jan 1996 21:30:37 +1100 (from kre@munnari.OZ.AU) To: Harald.T.Alvestrand@uninett.no Cc: iesg@cnri.reston.va.us, drums@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: (IPng 1227) Re: A suggestion for IPv6 domain literals In-Reply-To: Your message of "Thu, 18 Jan 1996 19:53:00 BST." <199601181853.NAA04647@CS.UTK.EDU> Date: Fri, 19 Jan 1996 21:30:52 +1100 Message-Id: <5705.822047452@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 18 Jan 1996 19:53:00 +0100 From: Message-ID: <199601181853.NAA04647@CS.UTK.EDU> Comments? Looks good to me. 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 Fri Jan 19 05:23:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11980; Fri, 19 Jan 96 05:23:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11974; Fri, 19 Jan 96 05:23:07 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23017; Fri, 19 Jan 1996 05:22:33 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id FAA08654; Fri, 19 Jan 1996 05:22:33 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA18618; Fri, 19 Jan 96 08:21:39 EST Received: from [192.32.150.210] (eng_ppp10) by pobox.BayNetworks.com (4.1/SMI-4.1) id AA19384; Fri, 19 Jan 96 08:22:11 EST Message-Id: <9601191322.AA19384@pobox.BayNetworks.com> To: Dennis Ferguson Subject: (IPng 1228) Re: Protocol Design Question Date: Fri, 19 Jan 96 08:25:25 -0500 From: Dimitry Haskin X-Mailer: E-Mail Connection v2.5.03 Cc: "ipng@sunroof.Eng.Sun.COM" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -- [ From: Dimitry Haskin * EMC.Ver #2.5.02 ] -- > I'd note, however, that a full route lookup in a 30,000 route table is going to > require about log(N), say 15 or 16, memory references semi-randomly scattered > around a (probably) 0.5 Mbyte array. Unless you have a cache large enough to If we've learned our lessons, this size route tables should not appear in Ipv6. Hopefully we manage to keep it under 1K (may be even under 100).. 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 Jan 19 06:55:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12000; Fri, 19 Jan 96 06:55:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11991; Fri, 19 Jan 96 06:54:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28648; Fri, 19 Jan 1996 06:54:00 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id GAA23391; Fri, 19 Jan 1996 06:53:58 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA06127; Fri, 19 Jan 1996 09:41:58 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16505; Fri, 19 Jan 1996 09:41:52 -0500 Message-Id: <9601191441.AA16505@fwasted.zk3.dec.com> To: jhalpern@us.newbridge.com (Joel Halpern) Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1229) Re: IPv6 over NBMA In-Reply-To: Your message of "Thu, 18 Jan 96 10:30:30 +0500." <9601181530.AA03876@lobster.newbridge> Date: Fri, 19 Jan 96 09:41:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joel, >4) This leads us to a methodology for operating over NBMAs. Rather than > trying to make them look like collections of ethernets, use the > "locallity" notions that Yakov has been developing, the query mechanisms > that ROLC has been working on, and provide the services which IPv6 > requires (the ability to find routers and to receive redirects). >The result is something which works. If we accidently wrote some overly >restrictive words into a spec, let us NOT hang ourselves by them. Maybe it does for routers! I would really appreciate you and others responding to the technical arguments presented in this mail. NHRP et al is not a done deal and other work is on the table as a replacement for NHRP for IPv6 over ATM at least. Lets have a fair and open technical discussion not that someone else has an idea and so we don't need to review anothers idea in the community. Talk to the issues. Several have proposed a way to make IPv6 work over ATM and completely support ND and the IPv6 methods of address autoconfiguration. It could be the authors of ND simply did not have the expertise or time to prove that it will work based on Peter, Markus, and Greenville comments. If thats the case then I don't want to not do ND over IPv6-ATM because folks won't "listen". One issue Peter brought up is the Internet Layer and ND. On a Host we process IPv6 ICMP, ND, Addr Conf at the Internet Layer now. I don't want to have to write one Internet Layer for ATM and one for Ethernet if Peter and Greenville ideas will work (or redo the multicast code at the Internet layer). So there is also an engineering cost issue here to for the way we do this standard. As an Area Director one part of your mail I found missing in addition to listening to Yakov's proposals is that the ideas of others should get a fair "hearing" in this WG mail list and others. Why is that Joel? I am beginning to think that some have a "vested" interest for NHRP maybe in products? If thats true too bad its only a draft spec and certainly we cannot be held captive in the IETF community if that is the case. More fool whoever if you built products based on draft specs. /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 Fri Jan 19 07:38:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12032; Fri, 19 Jan 96 07:38:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12026; Fri, 19 Jan 96 07:38:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02153; Fri, 19 Jan 1996 07:38:08 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id HAA02177; Fri, 19 Jan 1996 07:38:01 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA23830; Fri, 19 Jan 96 10:37:04 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA25493; Fri, 19 Jan 96 10:37:48 EST Date: Fri, 19 Jan 96 10:37:48 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601191537.AA25493@pobox.BayNetworks.com> To: dennis@Ipsilon.COM Subject: (IPng 1230) Re: Protocol Design Question Cc: narten@VNET.IBM.COM, craig@aland.bbn.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Dennis Ferguson > > Because of this (though the reason is less compelling) I do think, > all other things being equal, that it still would have been better to > put the destination address in front of the source address in any case, > for another reason. If you use a tree data structure to do route lookups > (a good thing if you want to do a longest match route lookup with any > efficiency) you start at the high order end of the destination address > and work your way forward, moving into the source address if the > destination is multicast or if the destination possibly matches a > flow you have state for. Not having the source address after the > destination puts a wart in the lookup code, when you get to the point > where you've gone through the destination address and start testing > bits in the source you have to shift to a different part of the header > to find the bits you need. > A good point which is quite compelling for me. In fact, the Bay's multicast forwarding table uses the search key that is a concatenation of the destination and source addresses, in that order. If the same address order were used in the packet header, no recomposition of the addresses to form the search key would be necessary -- a big savings in the fast forwarding path! Given that there is only a handful of IPv6 implementations with no field deployment yet, I think it is not late to consider switching the order of the address fields in the IPv6 header. It is a five minute change in our IPv6 implementation in this point. Positioning the flow label right after the source address would help for the same reason. But I frankly don't see how it can be done without getting rid of the Version field. Dimitry Haskin Wellfleet University ------------------------------------------------------------------------------ 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 Jan 19 10:08:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12147; Fri, 19 Jan 96 10:08:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12006; Fri, 19 Jan 96 07:04:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29452; Fri, 19 Jan 1996 07:03:57 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id HAA25528; Fri, 19 Jan 1996 07:03:56 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA09880; Fri, 19 Jan 1996 09:53:59 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09580; Fri, 19 Jan 1996 09:53:54 -0500 Message-Id: <9601191453.AA09580@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1231) Re: IPv6 over NBMA In-Reply-To: Your message of "Thu, 18 Jan 96 09:30:41 PST." <199601181730.JAA17079@puli.cisco.com> Date: Fri, 19 Jan 96 09:53:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >% Well, with a little bit of help from the datalink layer ND will do its job >% just fine, at least for ATM. Peter Schulter's I-D demonstrates that nicely. > >Peter's proposal is remarkably complex. MARS, while interesting, is also >not trivial and I'd hardly call either one "a little bit of" anything. > >They might or might not work, but they are clearly very complex to build >and simpler approaches exist that reuse more existing technology (NHRP) >and are clearly easier to implement and make work. Please provide technical comments to back up this claim and why it will not work for both MARS and IPv6 over ATM specs. >Also, I believe it to be both desirable and possible to come up with a >generic approach to IPv6/NBMA that would not be limited to ATM. This >should be a goal IMHO. I think a "fair" and "open" review of any work in the IETF should take place. Greenville and Peter are proposing new ideas and an approach to IPv6 over ATM and to "completely" support IPv6 specifications. Lets see if they have done it or not. /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 Fri Jan 19 14:46:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12576; Fri, 19 Jan 96 14:46:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12570; Fri, 19 Jan 96 14:46:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05296; Fri, 19 Jan 1996 14:45:58 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id OAA03842; Fri, 19 Jan 1996 14:45:57 -0800 From: schulter@zk3.dec.com Received: from ralpha.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA32439; Fri, 19 Jan 1996 17:17:34 -0500 Received: from dogfish.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA04334; Fri, 19 Jan 1996 17:17:29 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA01894; Fri, 19 Jan 1996 17:18:02 -0500 Message-Id: <9601192218.AA01894@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Ran Atkinson Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1232) Re: IPv6 over NBMA In-Reply-To: Your message of "Thu, 18 Jan 96 09:30:41 PST." <199601181730.JAA17079@puli.cisco.com> Date: Fri, 19 Jan 96 17:18:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 18 Jan 96 09:30:41 PST Ran Atkinson wrote: > Peter's proposal is remarkably complex. MARS, while interesting, is also > not trivial and I'd hardly call either one "a little bit of" anything. Well, in my own defence, this was a first cut at things, it wasn't intended to present an optimized mechanism, just the basic ideas of the architecture. This is why things go through discussion and revisions. I am currently working on the next revision which I want to have ready for LA (my "day job" is slowing me down on this ;-( which greatly simplifies everything while preserving the basic ideas and architecture. I've got the logical link totally stateless (which should make it remarkably easy to implement), and greately reduced complexity elsewhere. Basically, take the current draft and delete all mention of any caching within the LL. No more special handling of RA or RS within the LL. Rather than simply dismissing my proposal (or Grenvilles), I think we should discuss them. Maybe with some co-operative effort we can arrive at something which is not "remarkably complex", is easy to implement, and continues to use ND with no modifications. These have always been my goals. > simpler approaches exist that reuse more existing technology (NHRP) I'm not sure this is either simpler or already exists. I'm also not convinced that NHRP can replace or supliment ND. I think there are more issues with making ND and NHRP work together than with my approach. > I hear that you dislike the NHRP/IPv6 combination. I don't see any > explanation from you about _why_ you think this is so. On the other hand I've heard you and others say "just use NHRP" without saying how it can be made to work with ND, and can provide all the functions that ND must. It seems that NHRP can't, in it's current form, replace ND. I think extending NHRP to provide all the functions provided by ND may take more work than either of the other two proposals on the table. > Address Resolution is the -primary- purpose of ND after all Maybe, but still all functions provided by ND _must_ be provided by any other protocol, unless, of course, you're willing to settle for less functionality than is provided by ND (like autoconfiguration or router discovery). There are also some ND semantics I feel should be maintained. One of these is that it is up to each host (not some server), how it responds to solicitations. This make things like providing load balancing across multiple interfaces possible. > I can't speak for DEC's code, but that is proved to be false by looking > at the NRL implementation. I could easily slip a solution based in > part on NHRP into the NRL implementation (if there were BSD device > drivers for some NBMA interface and I were still working on the NRL > codebase :-). > > My current codebase makes it quite easy to use an NHRP-derived solution > under IPv6 for NBMA interfaces. I don't think it's simply a matter of being possible (and would your NHRP replacement for ND also provide router discovery and address autoconfiguration), but is it permitted by the IPv6 specs? Also, not all code is like the NRL code (like DEC's ;-), so it seems to me that requiring every implementation of IPv6 to have the ability to have per-media protocols in order to support ATM impacts more vendors than leaving the network layer untouched and putting all the work into the datalink. > Also, I believe it to be both desirable and possible to come up with a > generic approach to IPv6/NBMA that would not be limited to ATM. This > should be a goal IMHO. I don't see why either my approach or Grenville's wouldn't work with any NBMA over which multiple VCs between nodes can be established. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 19 14:58:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12646; Fri, 19 Jan 96 14:58:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12640; Fri, 19 Jan 96 14:58:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07139; Fri, 19 Jan 1996 14:57:51 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id OAA06949; Fri, 19 Jan 1996 14:57:50 -0800 From: schulter@zk3.dec.com Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA11824; Fri, 19 Jan 1996 17:42:09 -0500 Received: from dogfish.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA14083; Fri, 19 Jan 1996 17:41:33 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA02164; Fri, 19 Jan 1996 17:42:09 -0500 Message-Id: <9601192242.AA02164@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: rja@cisco.com, gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 1233) Re: IPv6 over NBMA In-Reply-To: Your message of "Wed, 17 Jan 96 19:29:14 EST." <9601180029.AA15185@pobox.BayNetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 96 17:42:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 17 Jan 96 19:29:14 EST Dimitry Haskin wrote: > I think that section 3.2 of the ND spec is quite clear that > only a subset (including an empty one, I guess) of ND features may > be applicable on certain medias. Specifically to NBMA: Yes, but I don't think that in these cases you can just replace ND (at the network layer) with something else, you just don't get these features. What I think we should be doing for ATM (and other NBMA media) is to provide a way to include _all_ the ND features over ATM (so that ATM does not end up being harder to use than other media while providing fewer IPv6 features). Further, I think we should be doing this without replacing ND if ND can be made to work over a specific media. That is, ND should always be the first choice for this functionality. I think it's very important to try to use ND whenever possible rather than do things to the network layer to solve datalink layer problems. However, the passage from ND that you sited still implies (states?) that ND is still being used, but some of it's features do not function. I don't think it states that you can replace ND on these media. Specifically, it says that redirect and NUD are still handled, and these are part of ND. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 19 16:02:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12764; Fri, 19 Jan 96 16:02:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12758; Fri, 19 Jan 96 16:01:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17052; Fri, 19 Jan 1996 16:01:20 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id QAA21332; Fri, 19 Jan 1996 16:01:19 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13904; Fri, 19 Jan 96 18:58:55 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA17736; Fri, 19 Jan 96 18:58:18 EST Date: Fri, 19 Jan 96 18:58:18 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601192358.AA17736@pobox.BayNetworks.com> To: schulter@zk3.dec.com Subject: (IPng 1234) Re: IPv6 over NBMA Cc: rja@cisco.com, gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pete, > > > I think that section 3.2 of the ND spec is quite clear that > > only a subset (including an empty one, I guess) of ND features may > > be applicable on certain medias. Specifically to NBMA: > > Yes, but I don't think that in these cases you can just replace > ND (at the network layer) with something else, you just don't > get these features. There is no need to replace ND where it can be effectively used. But ND can be supplemented with something else if that provides me with the needed functionality at a better cost. > What I think we should be doing for ATM > (and other NBMA media) is to provide a way to include _all_ the > ND features over ATM (so that ATM does not end up being harder > to use than other media while providing fewer IPv6 features). What we should be doing is look at _all_ proposed or yet to be proposed solutions and see which is a better value. Note that I'm not necessary against your or Greenville proposal, but I just don't buy your arguments that we should limit our choices to ND. > Further, > I think we should be doing this without replacing ND if ND can > be made to work over a specific media. That is, ND should always be > the first choice for this functionality. I think it's very important > to try to use ND whenever possible rather than do things to the > network layer to solve datalink layer problems. > Not at any cost. It might be possible but too expensive or impractical. I'd not feel guilty at all to adopt a non-ND solution if I felt it to be a superior approach. > However, the passage from ND that you sited still implies (states?) that > ND is still being used, but some of it's features do not function. > I don't think it states that you can replace ND on these media. > Specifically, it says that redirect and NUD are still handled, and > these are part of ND. Fine, but I don't believe there was any attempt to imply that a non-ND solution should not be considered for the ND features that don't function. 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 Sat Jan 20 05:14:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13163; Sat, 20 Jan 96 05:14:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13157; Sat, 20 Jan 96 05:14:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29968; Sat, 20 Jan 1996 05:13:57 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id FAA29984; Sat, 20 Jan 1996 05:13:57 -0800 Received: from uvite18.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA08723; Sat, 20 Jan 1996 08:13:43 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 20 Jan 1996 08:13:51 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 1235) Re: DISCUSSION: Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:41 PM 1/5/96, Ralph Droms wrote: >I'm still not clear on whether we can expect a client to initiate multiple >DHCP transactions; i.e., will a DHCP client ask for one address or >addresses at boot time, and then come back and ask for additional addresses >in a separate transaction at a later time? After perhaps one too many cups of coffee this AM, I knocked out the following note to the DHCP-v6@bucknell.edu mailing list. Although some of the message has to do with details of carrying multiple addresses around in DHCPv6, I think many of the issues related to the use of multiple addresses are general enough to be of interest to the ipng WG as a whole. If nothing else, the dhc WG needs a better definition of when and how applications would use multiple IPv6 addresses, so we can extend DHCPv6 to meet those needs. - Ralph ===== Excellent question, Charlie - you've gotten right to the heart of the issue: At 3:22 PM 1/18/96, Charlie Perkins wrote: >Can you identify exactly how the "laissez-faire" approach should >be modified to avoid the problem you see with letting clients ask >for addresses whenever they feel like it? Should the server keep >track of tuples and deallocate previously >allocated resources whenever a new request comes in for the same > tuple? Is this simpler server design, or >more complicated? I think, in fact, there's another function we have to add to the protocol before we get to this step. We need to make it explicit, so we can understand exactly how the protocol grows more complicated relative to the current draft and relative to DHCPv4. At present, the model for DHCP is that the server has a collection of parameters (call it a "config") for a client. For the sake of argument, let's suppose the config includes a network address (it doesn't have to; DHCP works with clients whose network addresses are manually configured). When a client runs DHCP, it contacts the server to ask for its config. The server checks for the config, makes up a new one and *allocates a network address if it has to*, and returns it to the client. I emphasized a clause in the previous sentence because, in this model, a client never asks for addresses, per se. The client asks for its config, and if the server needs to allocate an address to fill out the config, the server does so. Further, once the client has its config, it uses that config until it explicitly needs to change the config by extending its lease. Now, there's some futzing around here around the edges about the different message exchanges when a client "knows" it needs a new config (it doesn't have one cahced) or is simply checking its old config. The important issue is that there is no mechanism through which a client can explicitly ask for additional addresses once it has received the config. So, the first step in supporting multiple addresses is to extend the client-server protocol to pass multiple addresses (DHCPv4 only passes one). Easy enough, and we've agreed to include addresses as extensions (we used to call them options) so a message can carry 0, 1 or many addresses. But here's the first complexity with multiple addresses. Suppose a client wants some addresses in addition to those that the server wants to allocate? Easy enough for the client to say how many - just put some more empty addresses in the REQUEST message. But how does the client describe what those addresses should look like? Does the client want any available additional address, the address associated with a specific DNS name (e.g., www-server-2.generic-state-u.edu), an address with a specific prefix? Another problem with multiple addresses is in the communication between the client and server about how many addresses, which are in response to the client's request and which are from the server's config and what are the error semantics. So, suppose a client asks for 3 addresses - one "don't care", one for www-server-2.generic-state-u.edu and one from a prefix allocated from the Networks'R'Us ISP. But the server has been configured by the netadmin to return 3 specific addresses and doesn't know beans about Networks'R'Us. The protocol needs to include negotiation and error semantics for "Here's the one address you asked for, here are two more you didn't know you needed, here's the address for www-server-2.generic-state-u.edu and I can't help you with Networks'R'Us". OK, all I've talked about so far is *what we've already agreed to do in DHCPv6* by allocating multiple addresses through an initial DHCP conversation. At the risk of repeating myself, I'll make an editorial comment at this point - all of this resource specification, notification and error communication sounds a *lot* like something that would be included in a generic service location protocol; perhaps we ought to let DHCP get an initial config out to the client and let a heavyweight protocol do all the heavy lifting (end of digression). Now, we're to the point of being able to ask Charlie's question - suppose we let DHCP clients go back and ask for more addresses in subsequent requests. First, we have to invent some new messages that allow for explicit request of addresses. Not a big deal. And, we can probably use the same address description language I mentioned two paragraphs earlier. Here's where Charlie's question come into play - what, exactly, are the semantics of multiple requests and how does the server implement those semantics? If I understand the potential use for multiple addresses, we expect an application to come along and request to listen on some specific address. If that address is not available, the OS will use DHCP to go get the address and add it to the local list of addresses. Now, all the communication issues I talked about above move through to the API - how does the client specify the address it wants or describe the addresses it is willing to use; what are the error semantics. The question I don't know how to answer is how the server should manage these multiple requests. Should all requests from a single host be grouped together under a single "client-id" or should each request be managed separately? The next time the client comes back to the DHCP server asking about its config, should the server hand it all of its addresses - including the application-specific addresses - or just the initial configuration? Managing addresses on a per-application basis adds flexibility - but I don't have any idea how successive instantiations of a specific application would identify themselves (what's their client-id?) to a server. Perhaps if all of the addresses for one client were lumped together, the server could search through the current list of addresses allocated to a DHCP client and find any that match the selection criteria for a specific request. If the server hands back all the addresses collected through multiple requests when the client reboots, the client will have to search through its local list of addresses to find any that match an application's selection criteria before firing off a DHCP request. At this point, my head starts to hurt... - 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 Sat Jan 20 11:21:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13291; Sat, 20 Jan 96 11:21:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13285; Sat, 20 Jan 96 11:21:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB10420; Sat, 20 Jan 1996 11:20:59 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id LAA26335; Sat, 20 Jan 1996 11:20:58 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA03227; Sat, 20 Jan 1996 14:16:04 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29974; Sat, 20 Jan 1996 14:16:03 -0500 Message-Id: <9601201916.AA29974@fwasted.zk3.dec.com> To: droms@bucknell.edu (Ralph Droms) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1236) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Sat, 20 Jan 96 08:13:51 EST." Date: Sat, 20 Jan 96 14:16:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here was my response to Ralphs posting. As we figure out a better definition of multiple address use I am assuming we are not getting into the details of site vs global addresses and leaving that up to policy of set up as we have done with ND and addr conf? This is not the place to discuss the DHCPv6 protocol though IMHO. We can't keep track of two discussions. Its just too hard and too much work. /jim Return-Path: bound Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29628; Sat, 20 Jan 1996 14:06:00 -0500 Message-Id: <9601201906.AA29628@fwasted.zk3.dec.com> To: dhcp-v6@bucknell.edu Cc: bound@zk3.dec.com Subject: Re: When should DHCPv6 be used In-Reply-To: Your message of "Sat, 20 Jan 96 08:33:25 EST." Date: Sat, 20 Jan 96 14:06:00 -0500 From: bound X-Mts: smtp >I think, in fact, there's another function we have to add to the protocol >before we get to this step. We need to make it explicit, so we can >understand exactly how the protocol grows more complicated relative to the >current draft and relative to DHCPv4. OK. This is doable and necessary. I will give you an initial thoughts while responding to the mail. >At present, the model for DHCP is that the server has a collection of >parameters (call it a "config") for a client. For the sake of argument, >let's suppose the config includes a network address (it doesn't have to; >DHCP works with clients whose network addresses are manually configured). >When a client runs DHCP, it contacts the server to ask for its config. The >server checks for the config, makes up a new one and *allocates a network >address if it has to*, and returns it to the client. This is a subtle point I don't think I agree with it. I view DHCPv6 to be that: It is always asking for an address. If there is no address requested then it is just a request for config information. I agree DHCPv6 does leave your architectural premise above and has since Jan 95 prior to the Danvers meeting. Isn't this why DHCPv4 created DHCPINFORM? >I emphasized a clause in the previous sentence because, in this model, a >client never asks for addresses, per se. The client asks for its config, >and if the server needs to allocate an address to fill out the config, the >server does so. Further, once the client has its config, it uses that >config until it explicitly needs to change the config by extending its >lease. In every DHCPv6 draft for the past year it has been asking for addresses. Recall the discussion at Danvers regarding the "number-of-addresses" available which we updated and then took out of the spec before Dallas. Now we "may"??? need it put back in. >Now, there's some futzing around here around the edges about the different >message exchanges when a client "knows" it needs a new config (it doesn't >have one cahced) or is simply checking its old config. The important issue >is that there is no mechanism through which a client can explicitly ask for >additional addresses once it has received the config. >So, the first step in supporting multiple addresses is to extend the >client-server protocol to pass multiple addresses (DHCPv4 only passes one). >Easy enough, and we've agreed to include addresses as extensions (we used >to call them options) so a message can carry 0, 1 or many addresses. Yes thats part of it. But I would like to see this more optimized in the options so the client just says give me XX addresses rather than carrying around multiple slots of 16 octets which are blank or zero in a packet. >But here's the first complexity with multiple addresses. Suppose a client >wants some addresses in addition to those that the server wants to >allocate? Easy enough for the client to say how many - just put some more >empty addresses in the REQUEST message. But how does the client describe >what those addresses should look like? Does the client want any available >additional address, the address associated with a specific DNS name (e.g., >www-server-2.generic-state-u.edu), an address with a specific prefix? I don't believe the client needs to specify what type of addresses it wants. The client will always receive site or global addresses. If this is needed though its an option or even a flag we can put in the main DHCPv6 header. So I don't see this as a problem just a new parameter we need? Then implementors need to make sure the addresses provided to clients support the policy admins want. Same is true for prefixes on routers for stateless. >Another problem with multiple addresses is in the communication between the >client and server about how many addresses, which are in response to the >client's request and which are from the server's config and what are the >error semantics. So, suppose a client asks for 3 addresses - one "don't >care", one for www-server-2.generic-state-u.edu and one from a prefix >allocated from the Networks'R'Us ISP. But the server has been configured >by the netadmin to return 3 specific addresses and doesn't know beans about >Networks'R'Us. The protocol needs to include negotiation and error >semantics for "Here's the one address you asked for, here are two more you >didn't know you needed, here's the address for >www-server-2.generic-state-u.edu and I can't help you with Networks'R'Us". I see a much more simple model. The client asks for 3 addresses. The server gets the request. Now my view of the server is as follows: It maintains a pool of addresses. Those addresses are differentiated per IPv6 address spec as to different links (subnets) if the server is remote and handling different links. It has no bindings for any clients until the client contacts the server. Once the client contacts the server the server then provides back to the client the addresses requested. If for some policy reason (which will have a user interface for policy for DHCPv6) at a users site each client can only have two addresses the server will only respond with two addresses. A "notification" (not an error) will be returned to the client that they can only have two addresses. This is how the user may control the number of addresses any one client can have. How that is done is a policy issue and not a mechanism. We need to make sure any policy needed for DHCPv6 in fact can be implemented by vendors of DHCPv6. If a client does not get all the addresses it requested it may post a note to the user it can only have 2 out of 3 addresses. This would be the case if the client later asked for another address for its WWW server too. The client would have no choice at that point in time but to deal with this administratively. >OK, all I've talked about so far is *what we've already agreed to do in >DHCPv6* by allocating multiple addresses through an initial DHCP >conversation. At the risk of repeating myself, I'll make an editorial >comment at this point - all of this resource specification, notification >and error communication sounds a *lot* like something that would be >included in a generic service location protocol; perhaps we ought to let >DHCP get an initial config out to the client and let a heavyweight protocol >do all the heavy lifting (end of digression). I don't agree. I think extending this functionality is lightweight and was in my first spec reviewed at Danvers. We just never got to this degree of review of the initial design change from DHCPv4. I am very happy we are finally having this discussion to flush out what we want to do with this issue. >Now, we're to the point of being able to ask Charlie's question - suppose >we let DHCP clients go back and ask for more addresses in subsequent >requests. First, we have to invent some new messages that allow for >explicit request of addresses. Not a big deal. And, we can probably use >the same address description language I mentioned two paragraphs earlier. >Here's where Charlie's question come into play - what, exactly, are the >semantics of multiple requests and how does the server implement those >semantics? The semantics are not complex. Its the way one views DHCPv6 architecturally. All requests are for addresses and configuration data, just for configuration data, or just for addresses. We have enough room in the message-type field to even define all the possible combinations. I gave a rough idea of the semantics above and they are in the first draft. I will pull that draft out and check to see if it can be used to discuss this further. >If I understand the potential use for multiple addresses, we expect an >application to come along and request to listen on some specific address. >If that address is not available, the OS will use DHCP to go get the >address and add it to the local list of addresses. Now, all the >communication issues I talked about above move through to the API - how >does the client specify the address it wants or describe the addresses it >is willing to use; what are the error semantics. Let me share how I view this being used. First I see the client booting up and just requesting an address for an interface. So the client the first time it boots will not know how many addresses it needs. The server will know to return 1 or 2 or (...) to the client based on some policy it has been provided a priori via an admin (e.g. all clients get two addresses per interface). Now two days later a particular client wants to set up a WWW server and does not want to use the addresses it has received from the server. The client DHCPv6 application has a user interface the user can access and say "hey client go see if I can get another address". The client requests a new address with a DHCPv6 packet. This I believe does not need a new message-type in DHCPv6 but it can be and we can discuss that detail later. The server determines if it can give the client a new address. If it can't it just tells the client NO CAN DO with a notification-flag or other means. If the server can it gives the client the address back. The server then accesses the clients binding and adds this additional address to the clients binding. Now once the client has another address from this process if it revalidates at reboot/restart then it need say nothing about how many addresses are being revalidated because the server will revalidate the addresses against the clients bindings. >The question I don't know how to answer is how the server should manage >these multiple requests. Should all requests from a single host be grouped >together under a single "client-id" or should each request be managed >separately? The next time the client comes back to the DHCP server asking >about its config, should the server hand it all of its addresses - >including the application-specific addresses - or just the initial >configuration? I think we are now entering the realm of whats done in an implementation and what is specified in the DHCPv6 standard. I envision that it would be one client binding based on the interface-token, link (subnet prefix), and other such unique data from a client. The server would keep under that binding the addresses given out, timers, and the most recent trans-ID for that address communications with a client (to support client retransmissions). The database granularity would be two levels. The client binding and then the addresses for that client binding. But this really is an implementation manner. >Managing addresses on a per-application basis adds flexibility - but I >don't have any idea how successive instantiations of a specific application >would identify themselves (what's their client-id?) to a server. Perhaps >if all of the addresses for one client were lumped together, the server >could search through the current list of addresses allocated to a DHCP >client and find any that match the selection criteria for a specific >request. If the server hands back all the addresses collected through >multiple requests when the client reboots, the client will have to search >through its local list of addresses to find any that match an application's >selection criteria before firing off a DHCP request. Exactly. Its not that bad really. Plus implementors get to really compete as to who can build this in the most efficient manner and come to market with a user interface that supports the policy for the market. This is the fun part where we get to see how much we learned from implementing, being engineers, and studying computer science right? >At this point, my head starts to hurt... Mine too. But I think at least now you have put the core issues on the table so we can figure out if this is a direction to go or not? /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 Jan 20 16:09:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13444; Sat, 20 Jan 96 16:09:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13438; Sat, 20 Jan 96 16:08:59 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20382; Sat, 20 Jan 1996 16:08:22 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id QAA15489; Sat, 20 Jan 1996 16:08:23 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA13360; Sat, 20 Jan 96 16:07:47 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA01941; Sat, 20 Jan 1996 16:08:03 -0800 Date: Sat, 20 Jan 1996 16:08:03 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601210008.AA01941@feller.mentat.com> To: Bob.Gilligan@Eng Subject: (IPng 1237) API spec - Assignments to sin6_flowinfo Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, On page 11 of the 03 BSD API spec the following assignment is used in an example: sin6.sin6_flowinfo = IPV6_PRIORITY_UNATTENDED | (IPV6_FLOWINFO_FLOWLABLEL & send_flowlabel); Assuming that the sin6_flowinfo should be in network order the assign- ment should be something like. sin6.sin6_flowinfo = htonl(IPV6_PRIORITY_UNATTENDED | (IPV6_FLOWINFO_FLOWLABLEL & send_flowlabel)); Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 21 09:11:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13744; Sun, 21 Jan 96 09:11:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13738; Sun, 21 Jan 96 09:11:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17396; Sun, 21 Jan 1996 09:10:58 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id JAA03420; Sun, 21 Jan 1996 09:10:58 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA17926; Sun, 21 Jan 1996 12:07:45 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA18980; Sun, 21 Jan 1996 12:07:43 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id RAA02274; Sun, 21 Jan 1996 17:16:47 GMT Message-Id: <199601211716.RAA02274@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: thartric@mentat.com (Tim Hartrick) Cc: Bob.Gilligan@Eng, ipng@sunroof.eng.sun.com Subject: (IPng 1238) Re: API spec - Assignments to sin6_flowinfo In-Reply-To: Your message of "Sat, 20 Jan 1996 16:08:03 PST." <9601210008.AA01941@feller.mentat.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Sun, 21 Jan 1996 17:16:46 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In <9601210008.AA01941@feller.mentat.com> , you wrote: > On page 11 of the 03 BSD API spec the following assignment is used > in an example: > > sin6.sin6_flowinfo = IPV6_PRIORITY_UNATTENDED | > (IPV6_FLOWINFO_FLOWLABEL & send_flowlabel); > > Assuming that the sin6_flowinfo should be in network order the assign- > ment should be something like. > > > sin6.sin6_flowinfo = htonl(IPV6_PRIORITY_UNATTENDED | > (IPV6_FLOWINFO_FLOWLABEL & send_flowlabel)); > Not necessarily. One could implement it as requiring one to do: sin6.sin6_flowinfo = IPV6_PRIORITY_UNATTENDED | (IPV6_FLOWINFO_FLOWLABEL & htonl(send_flowlabel)); The fields for sin6_flowinfo are defined in network order and expect to operate on values in network order. This is currently how the API on Digital UNIX operates. This reduces the need for byte swapping until it's only required (ie. manipulating the flow label) but can avoid for checking priorities and source routing flags. 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 Sun Jan 21 10:39:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13819; Sun, 21 Jan 96 10:39:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13813; Sun, 21 Jan 96 10:39:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19819; Sun, 21 Jan 1996 10:38:51 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id KAA13761; Sun, 21 Jan 1996 10:38:52 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA26634; Sun, 21 Jan 1996 13:31:10 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA19074; Sun, 21 Jan 1996 13:31:09 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id SAA02560; Sun, 21 Jan 1996 18:40:14 GMT Message-Id: <199601211840.SAA02560@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: thartric@mentat.com (Tim Hartrick) Cc: Bob.Gilligan@Eng, ipng@sunroof.eng.sun.com Subject: (IPng 1239) Re: New draft of API spec is now available In-Reply-To: Your message of "Fri, 19 Jan 1996 00:34:53 PST." <9601190834.AA01243@feller.mentat.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Sun, 21 Jan 1996 18:40:12 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I know your probably more than ready to get this thankless > task over with but it seems like the API spec (or some information- > al RFC) needs to say something about how to deal with the dreaded options. > I realize that there currently are no defined options but it would be nice > to have some guidelines in this area so when options begin to appear there > there are not as many ways to deal with them as there are implementa- > tions. I assume you are talking about the Hop-By-Hop and Destination Node options. I don't any of us know enough about ESP and Authentication at this time point in time to define an interface to them in an RFC. This is an excerpt from the current Digital UNIX implementation which shows what we are calling the new IPv6 header values. (note that IPPROTO_IP is also defined as 0 is most (all?) BSD-derived implementations.) #define IPPROTO_HOPBYHOP 0 /* Hop-by-hop options */ #define IPPROTO_ROUTING 43 /* Routing header */ #define IPPROTO_FRAG 44 /* Fragmentation header */ #define IPPROTO_ESP 50 /* Encap. security payload */ #define IPPROTO_AUTH 51 /* Authentication header */ #define IPPROTO_ICMPV6 58 /* ICMPv6 */ #define IPPROTO_NONEXTHDR 59 /* No Next Header */ #define IPPROTO_DESTNODE 60 /* Destination Node header */ For Digital UNIX, I'm planning on using the "control data" ability which is part of BSD 4.3 Reno or later. Whenever a Hop-By-Hop or Destionation Node option is received (on an endpoint enabled to return options to the user), a control mbuf (MT_CONTROL) is allocated (if not already allocated) and the option is placed into it. When the user receives the message (note that to get control data, once MUST use recvmsg), the control messages will be returned to user along with the data. [This is, in my opinion, is a much better method of dealing with such things as source routes and "sedning/recieving interfaces" and uses already existing mechanisms in most implementations (unlike the current method in the API specification).] To enable reception of Hop-By-Hop (in this example) or Destination Node options, one simply does: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPPROTO_HOPBYHOP, &on, sizeof(on)); >From the recvmsg(2) man page: As an example, one could use this to learn of changes in the data-stream in XNS/SPP, or in ISO, to obtain user-connection-request data by request- ing a recvmsg with no data buffer provided immediately after an accept() call. so this can be equally used for TCP. In addition, for TCP you can set up the options for the connection via setsockopt(2). setsockopt(fd, IPPROTO_DESTNODE, option, optdata, optlen); (where options is 0..255, optdata is a pointer to the data, and optlen is the length of data. (alignment will be determined from the optlen)). That's my 2 bits worth. 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 Sun Jan 21 12:13:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13879; Sun, 21 Jan 96 12:13:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13873; Sun, 21 Jan 96 12:12:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22597; Sun, 21 Jan 1996 12:12:21 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id MAA19816; Sun, 21 Jan 1996 12:12:20 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA27397; Sun, 21 Jan 96 12:11:43 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA02239; Sun, 21 Jan 1996 12:11:59 -0800 Date: Sun, 21 Jan 1996 12:11:59 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601212011.AA02239@feller.mentat.com> To: matt@lkg.dec.com Subject: (IPng 1240) Re: New draft of API spec is now available Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Assuming that the sin6_flowinfo should be in network order the assign- > > ment should be something like. > > > > > > sin6.sin6_flowinfo = htonl(IPV6_PRIORITY_UNATTENDED | > > (IPV6_FLOWINFO_FLOWLABEL & send_flowlabel)); > > > > Not necessarily. One could implement it as requiring one to do: > > sin6.sin6_flowinfo = IPV6_PRIORITY_UNATTENDED | > (IPV6_FLOWINFO_FLOWLABEL & htonl(send_flowlabel)); > > The fields for sin6_flowinfo are defined in network order and expect > to operate on values in network order. This is currently how the > API on Digital UNIX operates. This reduces the need for byte swapping > until it's only required (ie. manipulating the flow label) but can > avoid for checking priorities and source routing flags. > > This is fine for Digital Unix which only runs on 64-bit little endian hardware. For vendors who need to use the same OS source base on multiple platforms (some little-endian and some big-endian) this re- quires a set of #ifdef's in in.h to switch on the little-endian vs big-endian versions of the defines. One could also use htonl on every flowinfo constant in the file. To me it seems more consistent to have the constants be in machine order and do the flipping when the values are inserted or removed from the sockaddr_in6 structure. Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 21 12:56:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13908; Sun, 21 Jan 96 12:56:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13898; Sun, 21 Jan 96 12:56:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23808; Sun, 21 Jan 1996 12:56:06 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id MAA22471; Sun, 21 Jan 1996 12:56:04 -0800 Received: from uvite62.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA02672; Sun, 21 Jan 1996 15:55:52 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 21 Jan 1996 15:56:00 -0500 To: ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 1241) Re: DISCUSSION: Use of multiple Addresses on Interfaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:16 PM 1/20/96, bound@zk3.dec.com wrote: >This is not the place to >discuss the DHCPv6 protocol though IMHO. We can't keep track of two >discussions. Its just too hard and too much work. My reason for bringing this thread to the ipng mailing list is that there is no clear consensus on the goals and constraints on allocation of multiple addresses. IMHO, we have consensus that IPv6 hosts will require multiple addresses per interface. We have some varying opinions about how those addresses will be specified, requested and managed. Once we've reached consensus on goals and constraints, the dhc WG can design the protocol to meet those requirements. Perhaps we should ask the WG - should we hold a conversation about the goals and constraints of multiple address allocation here on the ipng mailing list, or should we move it to the DHCPv6 mailing list? - 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 Sun Jan 21 12:57:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13920; Sun, 21 Jan 96 12:57:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13914; Sun, 21 Jan 96 12:57:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23838; Sun, 21 Jan 1996 12:56:58 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id MAA22534; Sun, 21 Jan 1996 12:56:57 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA28057; Sun, 21 Jan 96 12:56:21 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA02265; Sun, 21 Jan 1996 12:56:37 -0800 Date: Sun, 21 Jan 1996 12:56:37 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601212056.AA02265@feller.mentat.com> To: matt@lkg.dec.com Subject: (IPng 1242) Re: New draft of API spec is now available Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I assume you are talking about the Hop-By-Hop and Destination Node options. > I don't any of us know enough about ESP and Authentication at this time > point in time to define an interface to them in an RFC. Hop-by-Hop, destination node options which occur before the routing header and destination node options which occur after the routing header. Yes all of them. > > This is an excerpt from the current Digital UNIX implementation which shows > what we are calling the new IPv6 header values. (note that IPPROTO_IP is > also defined as 0 is most (all?) BSD-derived implementations.) > > #define IPPROTO_HOPBYHOP 0 /* Hop-by-hop options */ > #define IPPROTO_ROUTING 43 /* Routing header */ > #define IPPROTO_FRAG 44 /* Fragmentation header */ > #define IPPROTO_ESP 50 /* Encap. security payload */ > #define IPPROTO_AUTH 51 /* Authentication header */ > #define IPPROTO_ICMPV6 58 /* ICMPv6 */ > #define IPPROTO_NONEXTHDR 59 /* No Next Header */ > #define IPPROTO_DESTNODE 60 /* Destination Node header */ > Looks similar to mine. It might be a good idea to place names for the various IPv6 IPPROTO_xxx values in the API spec so everyones in.h looks the same. > For Digital UNIX, I'm planning on using the "control data" ability > which is part of BSD 4.3 Reno or later. > > Whenever a Hop-By-Hop or Destionation Node option is received (on an > endpoint enabled to return options to the user), a control mbuf > (MT_CONTROL) is allocated (if not already allocated) and the option > is placed into it. > > When the user receives the message (note that to get control data, once > MUST use recvmsg), the control messages will be returned to user along > with the data. > > [This is, in my opinion, is a much better method of dealing with such > things as source routes and "sedning/recieving interfaces" and uses > already existing mechanisms in most implementations (unlike the current > method in the API specification).] > > To enable reception of Hop-By-Hop (in this example) or Destination Node > options, one simply does: > > int on = 1; > setsockopt(fd, IPPROTO_IPV6, IPPROTO_HOPBYHOP, &on, sizeof(on)); > > >From the recvmsg(2) man page: > > As an example, one could use this to learn of changes in the data-stream > in XNS/SPP, or in ISO, to obtain user-connection-request data by request- > ing a recvmsg with no data buffer provided immediately after an accept() > call. > > so this can be equally used for TCP. > > In addition, for TCP you can set up the options for the connection > via setsockopt(2). > > setsockopt(fd, IPPROTO_DESTNODE, option, optdata, optlen); > (where options is 0..255, optdata is a pointer to the data, > and optlen is the length of data. (alignment will be > determined from the optlen)). > > That's my 2 bits worth. > After running around the office trying to find a manpage for the more recent incarnations of recvmsg this seems like a good proposal. Of course it requires those vendors who do not currently support the newer version of the msghdr structure some possible binary compatibility hardship. I really hate options. I am sorry I brought this up. :-) Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 21 13:16:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13956; Sun, 21 Jan 96 13:16:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13950; Sun, 21 Jan 96 13:16:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24424; Sun, 21 Jan 1996 13:15:55 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id NAA24086; Sun, 21 Jan 1996 13:15:54 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA30363; Sun, 21 Jan 1996 16:11:09 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA19280; Sun, 21 Jan 1996 16:11:08 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id VAA03137; Sun, 21 Jan 1996 21:20:17 GMT Message-Id: <199601212120.VAA03137@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1243) Re: New draft of API spec is now available In-Reply-To: Your message of "Sun, 21 Jan 1996 12:11:59 PST." <9601212011.AA02239@feller.mentat.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Sun, 21 Jan 1996 21:20:16 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [snip] > > The fields for sin6_flowinfo are defined in network order and expect > > to operate on values in network order. This is currently how the > > API on Digital UNIX operates. This reduces the need for byte swapping > > until it's only required (ie. manipulating the flow label) but can > > avoid for checking priorities and source routing flags. > > > > > > This is fine for Digital Unix which only runs on 64-bit little endian > hardware. For vendors who need to use the same OS source base on > multiple platforms (some little-endian and some big-endian) this re- > quires a set of #ifdef's in in.h to switch on the little-endian vs > big-endian versions of the defines. One could also use htonl on > every flowinfo constant in the file. For what it's worth, the Digital UNIX header file is not endian-dependent and defines the IPV6_FLOWINFO ... properly depending on the endian-ness of the machine. And it does it does without using ifdef's. (Our IPv6 code base is intended to run on multiple code-bases of which some our big-endian). > To me it seems more consistent to have the constants be in machine > order and do the flipping when the values are inserted or removed from > the sockaddr_in6 structure. I strongly disagree. In our implementation, except for the payload length field, all the IPv6 headers are dealt with in network order regardless of the endian-ness of the machine. I see no reason to force an implement- ation to do byteswapping just to save a few ifdef's in a header file. 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 Sun Jan 21 15:02:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14023; Sun, 21 Jan 96 15:02:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14013; Sun, 21 Jan 96 15:02:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28484; Sun, 21 Jan 1996 15:01:48 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id PAA01685; Sun, 21 Jan 1996 15:01:47 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA28654; Sun, 21 Jan 96 15:01:06 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA02303; Sun, 21 Jan 1996 15:01:23 -0800 Date: Sun, 21 Jan 1996 15:01:23 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601212301.AA02303@feller.mentat.com> To: matt@lkg.dec.com Subject: (IPng 1244) Re: New draft of API spec is now available Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > For what it's worth, the Digital UNIX header file is not endian-dependent > and defines the IPV6_FLOWINFO ... properly depending on the endian-ness > of the machine. And it does it does without using ifdef's. (Our IPv6 > code base is intended to run on multiple code-bases of which some our > big-endian). > No #if's or #ifdef's anywhere. Cool. > > I strongly disagree. In our implementation, except for the payload length > field, all the IPv6 headers are dealt with in network order regardless of > the endian-ness of the machine. I see no reason to force an implement- > ation to do byteswapping just to save a few ifdef's in a header file. > I don't understand what the internal representation of the IPv6 headers has to do with the way constants are handled by the API. If ports and addresses (in IPv4) need an hton[l|s] applied to them before they are inserted into a sockaddr_inx structure and passed through to the kernel, then what makes flowinfo different? Byte-swapping of constants using a macro is a 0 cost operation. So what we are talking about here is the difference between having byte-order dependent definitions in in.h (although you claim this is unnecessary) and having kernel implementations which use constants like IPV6_PRIORITY_8 having to apply a 0 cost macro based byte-swap to such usages. The former makes the sin6_flowinfo different from the majority of the other fields of the sockaddr_in[6] structures since the order of the constants is already in network order. In contrast constants like IPPORT- _TELNET INADDR_ANY are in machine order and must be flipped. You prefer not to have to remember to apply the 0 cost flip to usages of IPV6_PRIORITY_x in the kernel. I prefer some level consistency in the API. What is the (in)famous quote, something like "consistency is the hob-goblin of small minds".:-) I don't have any particular problems with things staying the way they are but I do reserve the right to say "I told you so" when application writers forget which fields need to be byte-swapped and which don't and produce a bunch of broken code as a result. Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 21 15:16:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14039; Sun, 21 Jan 96 15:16:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14033; Sun, 21 Jan 96 15:16:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29127; Sun, 21 Jan 1996 15:16:07 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id PAA02816; Sun, 21 Jan 1996 15:16:07 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA28822; Sun, 21 Jan 96 15:15:30 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA02309; Sun, 21 Jan 1996 15:15:48 -0800 Date: Sun, 21 Jan 1996 15:15:48 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601212315.AA02309@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1245) Re: New draft of API spec is now available X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The former makes the sin6_flowinfo different from the majority of the > other fields of the sockaddr_in[6] structures since the order of the > constants is already in network order. In contrast constants like IPPORT- > _TELNET and INADDR_ANY are in machine order and must be flipped. > Following up to my own post. INADDR_ANY ought to be something like INADDR_LOOPBACK some such. Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 21 19:44:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14126; Sun, 21 Jan 96 19:44:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14120; Sun, 21 Jan 96 19:43:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09078; Sun, 21 Jan 1996 19:43:20 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id TAA22899; Sun, 21 Jan 1996 19:43:20 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA06342; Sun, 21 Jan 1996 22:36:46 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22829; Sun, 21 Jan 1996 22:36:45 -0500 Message-Id: <9601220336.AA22829@fwasted.zk3.dec.com> To: droms@bucknell.edu (Ralph Droms) Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1246) Re: DISCUSSION: Use of multiple Addresses on Interfaces In-Reply-To: Your message of "Sun, 21 Jan 96 15:56:00 EST." Date: Sun, 21 Jan 96 22:36:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just want to check where I "believe" we have consensus on IPng: "Users will want at random times want to request an address for such things as WEB and NFS servers". "They will not want to use the addresses they presently have for their own reasons that will vary from user to user and from vendor machine to vendor machine". I believe the IPng WG mail list (and strong contributors to this list responded) found consensus to be that we should not do anything to prevent users from using DHCPv6 (statefull addr conf) in this manner. This also conincides with RFC 1681. As far as the question of multiple addresses per interface I am comfortable that we have that well specified in our Addr Arch specification for PS. I think we do need to further review and discuss anycast addresses and multihome nodes which I believe will happen at the L.A. and Montreal IETF meetings. /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 Jan 22 00:03:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14214; Mon, 22 Jan 96 00:03:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14208; Mon, 22 Jan 96 00:02:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20949; Mon, 22 Jan 1996 00:02:21 -0800 Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM) id AAA13793; Mon, 22 Jan 1996 00:02:19 -0800 Received: from [138.96.36.34] by pax.inria.fr (8.6.12/8.6.12) with SMTP id JAA08832; Mon, 22 Jan 1996 09:00:09 +0100 Date: Mon, 22 Jan 1996 09:00:09 +0100 X-Authentication-Warning: pax.inria.fr: Host huitema.inria.fr claimed to be [138.96.36.34] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bmanning@ISI.EDU (Bill Manning) From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1247) Re: ip6.int Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:22 PM 18/1/96, Bill Manning wrote: >Hi, > The ip6.int zone is set up. I have a couple of concerns tho. > nibble alignment of the address space will require the cname haq > that is in use for IPv4. A better solution would be to use > binary mappings. Sue et.al, would this be a real problem to > convert to binary mappings of the ip6.int space? Yes. A name with 128 tokens would be extremely hard to handle. Just contemplate the proposal to use this format for mail addresses, e.g. network-manager@x.x.x.x.ip6.int. The nibble choice is already a compromise. The "cname-haq" is hard in v4 because of the octet alignment - if you delegate a /17, you have to actually delegate 128 cnames. Nibble alignment minimizes the problem because you have at most to delegate 8 cnames (e.g. for a /17). Then, you may observe that the proposed formats separate providers, customers, subnets and stations on octet boundaries. 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 Mon Jan 22 05:02:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14310; Mon, 22 Jan 96 05:02:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14304; Mon, 22 Jan 96 05:02:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00667; Mon, 22 Jan 1996 05:01:38 -0800 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id FAA01960; Mon, 22 Jan 1996 05:01:40 -0800 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 Jan 1996 05:01:18 -0800 Posted-Date: Mon, 22 Jan 1996 04:56:07 -0800 (PST) Message-Id: <199601221256.AA05761@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 22 Jan 1996 04:56:07 -0800 Subject: (IPng 1248) Re: ip6.int To: huitema@pax.inria.fr (Christian Huitema) Date: Mon, 22 Jan 1996 04:56:07 -0800 (PST) Cc: bmanning@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: from "Christian Huitema" at Jan 22, 96 09:00:09 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > At 6:22 PM 18/1/96, Bill Manning wrote: > >Hi, > > The ip6.int zone is set up. I have a couple of concerns tho. > > nibble alignment of the address space will require the cname haq > > that is in use for IPv4. A better solution would be to use > > binary mappings. Sue et.al, would this be a real problem to > > convert to binary mappings of the ip6.int space? > > Yes. A name with 128 tokens would be extremely hard to handle. Just > contemplate the proposal to use this format for mail addresses, e.g. > network-manager@x.x.x.x.ip6.int. The nibble choice is already a > compromise. Which breaks cidr style assignments. Can we afford to be that wastefull again? Now I don't think that a 128 token name has to retain that number of tokens for sendmail. I expect that a clever haq will be able to collapse the large number of "real" lables into a human managable token for sendmail use. > The "cname-haq" is hard in v4 because of the octet alignment - if you > delegate a /17, you have to actually delegate 128 cnames. Nibble alignment > minimizes the problem because you have at most to delegate 8 cnames (e.g. > for a /17). Then, you may observe that the proposed formats separate > providers, customers, subnets and stations on octet boundaries. Making assumptions about how and where things are going to grow again? :) We've not had really good luck on this in the past. Perhaps we should give up on the idea of native labels that are humanly understandable with any sort of relative ease. I'm getting out my robes to re-join the HEX-dump reading priesthood and/or putting more effort into getting a "real" directory service running in this environment. --bill ------------------------------------------------------------------------------ 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 Jan 22 07:13:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14432; Mon, 22 Jan 96 07:13:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14426; Mon, 22 Jan 96 07:13:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08204; Mon, 22 Jan 1996 07:12:29 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id HAA28489; Mon, 22 Jan 1996 07:12:29 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00226 Tue, 23 Jan 1996 02:12:15 +1100 (from kre@munnari.OZ.AU) To: bmanning@ISI.EDU Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1249) Re: ip6.int In-Reply-To: Your message of "Mon, 22 Jan 1996 04:56:07 -0800." <199601221256.AA05761@zed.isi.edu> Date: Tue, 23 Jan 1996 02:12:31 +1100 Message-Id: <7197.822323551@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 22 Jan 1996 04:56:07 -0800 (PST) From: bmanning@ISI.EDU Message-ID: <199601221256.AA05761@zed.isi.edu> Now I don't think that a 128 token name has to retain that number of tokens for sendmail. sendmail (actually, just mail) has nothing relaly to do with this - but you simply cannot have a 128 token name (and you're actually proposing 130). The DNS has a 255 character limit on names (the length is a byte), and each token is 2 bytes mimimum (which you can consider to be the dot and the character, but is really one byte length, and one byte minimum). This produces an absolute limit of 127 labels in any DNS name. For IPv6 ip6.int names (in-addr.arpa) you could just make it fit by looking at which parts need to be binary, and which don't (there's no way you need binary at the most significant couple of octets, any more than we do in IPv4 for the first octet - similarly, the least significant octets are almost certainly going to be used for tokens, and so don't really need binary encoding). Personally I doubt that the problem is worth this mess. It seems probable that nybble breakdowns will be small enough for almost everyone, and where that fails, the CNAME hack will work at least as well for v6 as it will for v4 (better, both for the reason Christian said, and because all v6 implementations will necessarily be new - and can be built knowing that this need is a possibility). As for mail - that's a totally different issue, the plan there was just that using string.ip6.int where a hostname is normally required would be a signal to the mailer/resolver (something) that "string" should simply be converted into an IPv6 address by making an algorithmic transformation. The DNS would be totally irrelevant to this (must be, that is the point). It would be both consistent and convenient to use the same representation as is used for address->name mappings via the DNS, but there is no necessary condition there, anything would do. And all this assumes that you believe this is the right way to handle the problem here, which I don't. 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 Mon Jan 22 08:02:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14464; Mon, 22 Jan 96 08:02:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14458; Mon, 22 Jan 96 08:02:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12411; Mon, 22 Jan 1996 08:01:27 -0800 Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM) id IAA09497; Mon, 22 Jan 1996 08:01:27 -0800 Received: from [138.96.36.34] by pax.inria.fr (8.6.12/8.6.12) with SMTP id QAA14617; Mon, 22 Jan 1996 16:57:34 +0100 Date: Mon, 22 Jan 1996 16:57:34 +0100 X-Authentication-Warning: pax.inria.fr: Host huitema.inria.fr claimed to be [138.96.36.34] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bmanning@ISI.EDU From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1250) Re: ip6.int Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:56 AM 22/1/96, bmanning@ISI.EDU wrote: >> >> > The ip6.int zone is set up. I have a couple of concerns tho. >> > nibble alignment of the address space will require the cname haq >> > that is in use for IPv4. A better solution would be to use >> > binary mappings. Sue et.al, would this be a real problem to >> > convert to binary mappings of the ip6.int space? >> >> Yes. A name with 128 tokens would be extremely hard to handle. Just >> contemplate the proposal to use this format for mail addresses, e.g. >> network-manager@x.x.x.x.ip6.int. The nibble choice is already a >> compromise. > > Which breaks cidr style assignments. Can we afford to be > that wastefull again? We actually debated it. As I said, a compromise. Suppose you decide to grow one of the current zone, say the provider ID. The advantage of the "binary" decision is that whatever the length of the increase, you will have to only delegate one domain. With the "nibble" boundary, you will have to delegate 1, 2, 4 or 8 domains, depending on the alignment. This is sometimes more than just one, but not as terrible as the 16, 32, 64 or 128 delegations which may be required with the current octet boundaries of IPv4. Saying that this "breaks cidr style assignment" is somewhat of an exageration. On the other hand, writing an address as a succession of a 128 binary digits separated by dots would break other things. Like your fingers... 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 Mon Jan 22 10:23:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14590; Mon, 22 Jan 96 10:23:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13589; Sat, 20 Jan 96 22:50:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04373; Sat, 20 Jan 1996 22:49:45 -0800 Received: from snowcrash.cymru.net by mercury.Sun.COM (Sun.COM) id WAA07552; Sat, 20 Jan 1996 22:49:44 -0800 Received: from lxorguk.ukuu.org.uk (Ulxorguk@localhost) by snowcrash.cymru.net (8.7.1/8.7.1) with UUCP id GAA30178 for sunroof.Eng.Sun.COM!ipng; Sun, 21 Jan 1996 06:12:32 GMT Received: by lightning.swansea.linux.org.uk (Smail3.1.29.1 #1) id m0tdqi4-0005FXC; Sun, 21 Jan 96 03:44 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: (IPng 1251) Re: [LONG] Random support for IPv6 auto configuration To: schulzrinne@fokus.gmd.de (Henning Schulzrinne) Date: Sun, 21 Jan 1996 03:44:51 +0000 (GMT) Cc: bradw@netnet.net, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com In-Reply-To: <199601131714.JAA22037@mercury.Sun.COM> from "Henning Schulzrinne" at Jan 13, 96 06:11:21 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Given that more or more protocols need random numbers (PPP, RTP, IPv6 > autoconfig, almost all cryptographic protocols) and that an A/D > converter on a thermal noise source (being preferable for practical > reasons to the other source of true randomness, nuclear decay) occupies > a tiny chip area, maybe someday soon, systems will offer built-in > randomness, just like all systems have a time-of-day clock today. Ted Tso of the MIT kerberos project has been making a /dev/random device available for Linux and *BSD for a short while now. It builds randomness from keyboard and other fairly random interrupts off the hardware. Alan ------------------------------------------------------------------------------ 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 Jan 22 11:00:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14673; Mon, 22 Jan 96 11:00:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14666; Mon, 22 Jan 96 11:00:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10020; Mon, 22 Jan 1996 10:59:46 -0800 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id KAA14088; Mon, 22 Jan 1996 10:59:46 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id NAA27771; Mon, 22 Jan 1996 13:59:44 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma027707; Mon Jan 22 13:59:24 1996 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id NAA05370; Mon, 22 Jan 1996 13:59:15 -0500 Received: from lobster.newbridge by mako.us.Newbridge.com (4.1/SMI-4.0) id AA25525; Mon, 22 Jan 96 13:52:08 EST Received: by lobster.newbridge (5.0/SMI-SVR4) id AA04816; Mon, 22 Jan 1996 13:57:41 +0500 Date: Mon, 22 Jan 1996 13:57:41 +0500 From: jhalpern@us.Newbridge.com (Joel Halpern) Message-Id: <9601221857.AA04816@lobster.newbridge> To: schulter@zk3.dec.com Subject: (IPng 1252) Re: IPv6 over NBMA Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looking at this discussion, I think that part of the confusion stems from the fact that there are several problems. 1) Neighbor discovery: This can be done using existing NHRP 2) Router Discovery - Clearly something is needed here 3) Address Auto-Configuration - Clearly something is needed here. I have no problem with using the ND mechanisms to address items 2 and 3 above. In fact, the single thing in Peter's proposal that caused me concern was the creation of a parallel hierarchy, independent of the routing hierarchy, for support of ND. This was simply for the discovery of neighbors, exactly the problem NHRP addresses. NHRP avoids the need to create an additional hierarchy. The creation of a parrallel hierarchy is an extremely bad thing. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ 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 Jan 22 11:22:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14724; Mon, 22 Jan 96 11:22:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14704; Mon, 22 Jan 96 11:14:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB12301; Mon, 22 Jan 1996 11:13:49 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id LAA19225; Mon, 22 Jan 1996 11:13:31 -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 UAA14727; Mon, 22 Jan 1996 20:11:16 +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 UAA28577; Mon, 22 Jan 1996 20:11:14 +0100 Message-Id: <199601221911.UAA28577@givry.inria.fr> From: Francis Dupont To: Markus Jork Cc: francis.dupont@inria.fr (francis dupont), rja@cisco.com, ipng@sunroof.eng.sun.com, ip-atm@matmos.hpl.hp.com Subject: (IPng 1253) Re: IPv6 over NBMA In-Reply-To: Your message of Thu, 18 Jan 1996 16:07:55 +0700. <199601181507.QAA22209@vbormc.vbo.dec.com> Date: Mon, 22 Jan 1996 20:11:08 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Well, with a little bit of help from the datalink layer ND will do its job just fine, at least for ATM. Peter Schulter's I-D demonstrates that nicely. It contains a proposal for how to do ND over ATM, which I happen to like a lot. (This is no wonder because I contributed to the ideas.) Grenville's I-D describes an alternative proposal for ND over ATM. => I know these two proposals, as far as I know none is implemented yet? Given that two proposals are out there already, why do you and Ran think this won't work? I would be very interested in your opinion, especially on Peter's draft. I think this would be a very useful discussion. So far I haven't seen any technical arguments against the proposal. Why not just do it that way? It would preserve all the features of ND. As you write yourself, it is not at all clear how NHRP would be used with IPv6 and if this is going to work at all: => I have a big trouble with both proposals: they work only with ATM not with any NBMA. NHRP is a more general device and is far simpler. I really wonder whether potential benefits are greater than the implementation cost... It seems to me that NHRP is a really bad match for the IPv6 architecture. There is just one feature that ND and NHRP have in common: address resolution. As Peter pointed out in detail in a previous mail, trying to replace ND address resolution with NHRP would affect the whole IPv6 stack. ND is just too tightly woven into the IPv6 stack to be optional on a per-media basis. => according to the current draft, ND over NBMA should provide only NUD and Redirects. Do you claim that external redirect is better than NHRP? Note that Peter's draft provides a replacement for most of this NHRP functionality without modifying the existing ND mechanism. Shortcut VCs can be established to all destinations inside the ATM network. => Peter's draft is a nice proposal but it doesn't solve two problems today: - interaction with IPv6 routing protocols - handling of IPv6 multicasts Today they are not solved by NHRP too but NHRP is more general (it works with IPv4, IPv6 and other datagram networks over any NBMA) and is already available then I expect to implement NHRP with IPv6 before even Peter's draft is finished... 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 Jan 22 12:08:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14802; Mon, 22 Jan 96 12:08:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14792; Mon, 22 Jan 96 12:08:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22181; Mon, 22 Jan 1996 12:07:44 -0800 Received: from netnet1.netnet.net by mercury.Sun.COM (Sun.COM) id MAA06642; Mon, 22 Jan 1996 12:07:44 -0800 Received: from ruiner (ppp-pm01-dy-16.opr.oakland.edu [141.210.14.177]) by netnet1.netnet.net (8.6.9/8.6.9) with SMTP id IAA22015 for ; Mon, 22 Jan 1996 08:47:22 -0600 Message-Id: <3103A3CC.3A9@exptech.com> Date: Mon, 22 Jan 1996 09:48:44 -0500 From: Brad Wilson Organization: Express Technologies Corp. X-Mailer: Mozilla 2.0b5 (WinNT; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 1254) Re: New draft of API spec is now available References: <199601212120.VAA03137@whydos.lkg.dec.com> <31030E41.3FEA@exptech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Thomas wrote: > > This is fine for Digital Unix which only runs on 64-bit little endian > > hardware. For vendors who need to use the same OS source base on > > multiple platforms (some little-endian and some big-endian) this re- > > quires a set of #ifdef's in in.h to switch on the little-endian vs > > big-endian versions of the defines. One could also use htonl on > > every flowinfo constant in the file. > > For what it's worth, the Digital UNIX header file is not endian-dependent > and defines the IPV6_FLOWINFO ... properly depending on the endian-ness > of the machine. And it does it does without using ifdef's. (Our IPv6 > code base is intended to run on multiple code-bases of which some our > big-endian). I agree with Matt. Constants should always be in network byte order. -- class CBradWilson : public CWorldWatchProgrammingTeam { public: void GetInetAddr ( CString& s ) { s = "bradw@exptech.com"; } void GetE164Addr ( CString& s ) { s = "+1 (810) 620-9803"; } void GetURL ( CString& s ) { s = "http://www.exptech.com"; } void GetDisclaimer( CString& s ) { s = "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 Jan 22 14:20:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15032; Mon, 22 Jan 96 14:20:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15026; Mon, 22 Jan 96 14:20:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15244; Mon, 22 Jan 1996 14:19:59 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id OAA18213; Mon, 22 Jan 1996 14:19:59 -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 OAA27059; Mon, 22 Jan 1996 14:19:59 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jan 1996 14:21:39 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1255) Updated IPng WWW Pages Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I updated the IPng WWW pages. The URL is http://playground.sun.com/pub/ipng/html/ipng-main.html Update includes new implementations, IPng presentations, meeting minutes, and pointers to the latest RFC's and Internet Drafts. 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 Jan 22 15:48:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15279; Mon, 22 Jan 96 15:48:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15270; Mon, 22 Jan 96 15:48:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00613; Mon, 22 Jan 1996 15:47:51 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id PAA14790; Mon, 22 Jan 1996 15:47:52 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id SAA13697 for ; Mon, 22 Jan 1996 18:47:41 -0500 Date: Mon, 22 Jan 1996 18:47:41 -0500 Message-Id: <199601222347.SAA13697@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" To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 1256) IPv6-over-Token Ring Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gentle Readers: Here's another shot at the Token Ring draft. Since it incorporates all the changes from the last circulation, I'd like to issue a Working Group last call for the draft. Internet Engineering Task Force Stephen Thomas INTERNET DRAFT AT&T Tridom January 22, 1996 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. Acknowledgments Several members of the IEEE 802.5 Working Group contributed their knowledge and experience to the drafting of this specification, including Jim, Andrew Draper, George Lin, John Messenger, Kirk Preiss, and Trevor Warwick. The author would also like to thank many members of the IPng working group for their advice and suggestions, Thomas Expires July 1996 [Page 1] INTERNET-DRAFT IPv6 over Token Ring January 11, 1996 including Ran Atkinson, Scott Bradner, Matt Crawford, Steve Deering, Francis Dupont, Robert Elz, Thomnas Narten, and Matt Thomas. IPv6 Encapsulation IPv6 packets are transmitted in LLC/SNAP frames. The data field contains the IPv6 header and payload. The following figure shows a complete 802.5 frame containing an IPv6 datagram. +-------+-------+-------+-------+ | 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. (This is the bit whose position corresponds to that of the Individual/Group bit in the Destination Address.) Token Ring Header Fields SD - Starting Delimiter AC - Access Control FC - Frame Control Thomas Expires July 1996 [Page 2] INTERNET-DRAFT IPv6 over Token Ring January 11, 1996 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) 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 the absence of any other information, an implementation should use a default MTU of 1500 octets. This size offers compatibility with all common 802.5 defaults, as well as with Ethernet LANs in an environment using transparent bridging. 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 Thomas Expires July 1996 [Page 3] INTERNET-DRAFT IPv6 over Token Ring January 11, 1996 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. Note that some of the 802.1D LF values would result in an IP MTU less than 576 bytes. This size is less than the IPv6 minimum, and communication across paths with those MTUs is generally not possible using IPv6. LF (base) LF (extension) MAC MTU IP MTU 001 000 1470 1462 010 000 2052 2044 011 000 4399 4391 100 000 8130 8122 101 000 11407 11399 110 000 17749 17741 111 000 41600 41592 When presented with conflicting MTU values from several sources, an implementation should choose from those sources according to the following priorities: 1. Largest Frame values from source route bridging (only for specific, unicast destinations) 2. Router advertisements 3. Static configuration 4. Default of 1500 Stateless Autoconfiguration and Link-local Addresses The address token [CONF] for a Token Ring interface is the built-in 48-bit IEEE 802 address associated with that interface, in canonical bit order. (Note: multiple interfaces on a system may share the same IEEE 802 address.) 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. Thomas Expires July 1996 [Page 4] INTERNET-DRAFT IPv6 over Token Ring January 11, 1996 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 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. Thomas Expires July 1996 [Page 5] INTERNET-DRAFT IPv6 over Token Ring January 11, 1996 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 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. Thomas Expires July 1996 [Page 6] INTERNET-DRAFT IPv6 over Token Ring January 11, 1996 [802.5] IEEE Standards for Local and Metropolitan Area Networks: Token Ring Access Method and Physical Layer Specifications. IEEE Std 802.5-1995. [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. RFC 1884. [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. Currently draft-ietf-addrconf-ipv6-auto-07.txt. [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery for IP Version 6 (IPv6). Currently draft-ietf-ipngwg- discovery-03.txt. [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. RFC 1883. 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 July 1996 [Page 7] ________________________ 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 Mon Jan 22 19:22:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15502; Mon, 22 Jan 96 19:22:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15496; Mon, 22 Jan 96 19:22:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28334; Mon, 22 Jan 1996 19:21:52 -0800 Received: from greatdane.cisco.com by mercury.Sun.COM (Sun.COM) id TAA28588; Mon, 22 Jan 1996 19:21:53 -0800 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA05001; Mon, 22 Jan 1996 19:21:37 -0800 Date: Mon, 22 Jan 1996 19:21:37 -0800 From: Tony Li Message-Id: <199601230321.TAA05001@greatdane.cisco.com> To: ietf@CNRI.Reston.VA.US, deering@parc.xerox.com Cc: Tracy Mallory , , ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1257) Re: Protocol Design Question Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As someone else who has nightmares about D-cache misses, I'd like to strongly second this request. (Actually, if I understand what would make you happiest, it would probably be a layout like: destination address length + next header + hop limit priority + flow label source address so you could avoid even fetching the source address in some cases. That would certainly be novel, from a " header aesthetics" perspective.) However, as has already been pointed out, your router ends up having to look at almost all the fields anyway (the source address for multicast, for flows, and for preventing bogus source addresses from leaking out; the hop-limit to be decremented; the next header to see if there are any hop-by-hop options; and the length to know how many bytes to forward). I suppose you might get some parallelism benefit from starting the destination route lookup while still copying in the rest of the header. You might note that the source address is not necessary for normal unicast packets. Thus, the unicast switching path need not touch it. As to any suggestion of doing source address filtering by default, at rate... well... dream on. Certainly RReq's predecessor, Gateway Requirments, talked about this under the term "martian filtering". Yes, but did anyone implement it? Hee hee. Tony ------------------------------------------------------------------------------ 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 Jan 23 05:51:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15742; Tue, 23 Jan 96 05:51:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15736; Tue, 23 Jan 96 05:51:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28944; Tue, 23 Jan 1996 05:50:55 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id FAA02774; Tue, 23 Jan 1996 05:50:56 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4071; Tue, 23 Jan 96 08:50:58 EST Received: by RTP (XAGENTA 4.0) id 3559; Tue, 23 Jan 1996 08:50:00 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20297; Tue, 23 Jan 1996 08:49:51 -0500 Message-Id: <9601231349.AA20297@cichlid.raleigh.ibm.com> To: jhalpern@us.Newbridge.com (Joel Halpern) Cc: schulter@zk3.dec.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1258) Re: IPv6 over NBMA In-Reply-To: Your message of "Mon, 22 Jan 1996 13:57:41 +0500." <9601221857.AA04816@lobster.newbridge> Date: Tue, 23 Jan 1996 08:49:48 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joel, >Looking at this discussion, I think that part of the confusion stems >from the fact that there are several problems. >1) Neighbor discovery: > This can be done using existing NHRP >2) Router Discovery - Clearly something is needed here >3) Address Auto-Configuration - Clearly something is needed here. Don't forget to add Neighbor Unreachability Detection to the list. I also am not quite sure what "Neighbor Discovery" means in 1). Are you referring to just the address resolution component of ND? The term "discovering neighbors" also includes things like extracting on-link prefixes from RAs, which is part of Router Discovery, so I'm not sure it is really possible to have "neighbor discovery" be an independent component. Likewise Redirects can also have the semantics saying in effect "this destination is a neighbor". 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 Tue Jan 23 08:16:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15827; Tue, 23 Jan 96 08:16:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15821; Tue, 23 Jan 96 08:16:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11926; Tue, 23 Jan 1996 08:15:23 -0800 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id IAA02818; Tue, 23 Jan 1996 08:15:20 -0800 Received: from droms.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA23649; Tue, 23 Jan 1996 11:15:14 -0500 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jan 1996 11:15:16 -0500 To: dhcp-v6@bucknell.edu, ipng@sunroof.eng.sun.com From: droms@bucknell.edu (Ralph Droms) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From bound@zk3.dec.com Sat Jan 20 14:15:26 1996 >>But here's the first complexity with multiple addresses. Suppose a client >>wants some addresses in addition to those that the server wants to >>allocate? Easy enough for the client to say how many - just put some more >>empty addresses in the REQUEST message. But how does the client describe >>what those addresses should look like? Does the client want any available >>additional address, the address associated with a specific DNS name (e.g., >>www-server-2.generic-state-u.edu), an address with a specific prefix? > >I don't believe the client needs to specify what type of addresses it >wants. The client will always receive site or global addresses. If >this is needed though its an option or even a flag we can put in the >main DHCPv6 header. So I don't see this as a problem just a new >parameter we need? Then implementors need to make sure the addresses >provided to clients support the policy admins want. Same is true for >prefixes on routers for stateless. Perhaps this would be a useful simplification - the client can't say anything about *what* addresses it is asking for, just that it needs more addresses. But, you've already pointed out at least one qualification - site or global address. Are there other qualifications that a client would want to specify? For example, I think net admins might want to ask for addresses that somehow encode the ISP, thus allowing clients to select ISP much like telephone users select a long-distance provider. And, it would be nice if a specifc server, say www-server-2.generic-state-u.edu, could get back the same address at every reboot (minimizing gratuitous load on dynamic DNS). One of the examples from RFC1681 - IP address per user - would liekwise require either stable-ish allocation of addresses or a dynamic update mechanism. Either the user always uses the same IP address, or the distribution mechanism has to inform the accounting system of the user's IP address for each session. >Let me share how I view this being used. > >First I see the client booting up and just requesting an address for an >interface. So the client the first time it boots will not know how many >addresses it needs. The server will know to return 1 or 2 or (...) to the >client based on some policy it has been provided a priori via an admin >(e.g. all clients get two addresses per interface). How does the net admin describe how those addresses are to be used? How do the applications on the client select and reserve the addresses? >Now two days later a particular client wants to set up a WWW server and >does not want to use the addresses it has received from the server. The >client DHCPv6 application has a user interface the user can access and >say "hey client go see if I can get another address". How does the application decide when it needs another address? How does the application decide if one of the addresses already assigned to the client is OK? >Now once the client has another address from this process if it >revalidates at reboot/restart then it need say nothing about how many >addresses are being revalidated because the server will revalidate the >addresses against the clients bindings. > >[...] > >I think we are now entering the realm of whats done in an implementation >and what is specified in the DHCPv6 standard. At this point, we need to make sure we design the address allocation mechanism *as a system*, so we develop a functional system that meets the applications' needs. Here's where, perhaps, we need to be careful. If these multiple addresses are being used to support services, then, presumably, the services are to be identified through DNS. Unless the service gets back the same address each time it is instantiated, we will add load to the dynamic DNS system by rebinding the service to a new IP address. Is such a load on dynamic DNS acceptable? For the sake of argument, assume each service is to be assigned the same IP address wherever possible. That is, the application doesn't want just any available address; it wants a relatively stable address. The application providing the service will need some mechanism for identifying itself so that it can be determined (by the application or the client or ???) whether the application has a previously allocated address (represented by an entry in a database somewhere) and whether the local host has been configured with that address. The way in which the server returns addresses to the client has an impact on how the application checks the client's configuration for supporting that application. If the server returns ALL addresses at once, the application checks the client for the address it wants, and asks for a new one if necessary. If the server returns addreses for each application individually, the application must first check the client, then check with the server. I'm not sure, therefore, that the exchange of addresses between the client and server and the way in which addresses are managed by the server is an implementation detail. These decisions seem to have an effect on the application API, the way in which addresses are managed on a host and the structure and semantics of DHCP messages. Somehow, I feel like my layers have been violated... - 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 Jan 23 09:59:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15976; Tue, 23 Jan 96 09:59:40 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15521; Mon, 22 Jan 96 20:50:41 PST Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id UAA06388; Mon, 22 Jan 1996 20:49:26 -0800 (PST) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA13679; Mon, 22 Jan 1996 20:50:00 -0800 Date: Mon, 22 Jan 1996 20:50:00 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199601230450.UAA13679@bobo.eng.sun.com> To: jhalpern@us.Newbridge.com Subject: (IPng 1259) Re: IPv6 over NBMA Cc: ip-atm@matmos.hpl.hp.com, 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 > 3) To clarify the last sentence above, it is possible for the IPv6 baseline > document to say that you must use the ND protocol. I do not believe that > it says that. I woul dhope that what it says is that the ND service is > necessary. If not, I believe we should fix it. I don't know of any text in the ND specification that states that you must use the protocol for a particular link type. This should be rather obvious since the spec itself states that on NBMA it only provides the redirect service and the NUD service - the document is completely silent on how to provide e.g. router discovery and prefix discovery for NBMA links. I know that the ipatm and rolc work is moving towards having the host to router interaction use the same NHRP protocol as the router to router interaction. This seems contrary to the experience in IPv4 routing where the community realized that it was a good thing to use a separate protocol for host-router interaction (ICMP router discovery) than the router-router protocol to allow for evolution in the routing protocols. Wouldn't the same be true for NHRP? It might be possible to come up with a relatively simple and robust protocol for host-router interaction on NBMA, that could be coupled with an evolving NHRP-style protocol between routers. For instance, the redirect messages in ND can be used for address resolution since they carry the link-layer address of the target. And the Neighbor Unreachability Detection mechanism in ND would detect and recover from stale information learned from the redirects. Thus I think we need to determine if we want a separate (and hopefully simple) host-router protocol to allow for evolution in NHRP. If we find that such a split is useful we should look more closely at what the ND protocol can do "as is" and what extensions (i.e. new options) might make sense for NBMA links. 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 Jan 23 10:07:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16019; Tue, 23 Jan 96 10:07:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16012; Tue, 23 Jan 96 10:07:10 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28059; Tue, 23 Jan 1996 10:06:30 -0800 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id KAA06414; Tue, 23 Jan 1996 10:06:27 -0800 Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id TAA08104 for ; Tue, 23 Jan 1996 19:07:08 +0100 Received: from nestvx.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id SAA21724; Tue, 23 Jan 1996 18:56:14 +0100 Message-Id: <199601231756.SAA21724@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Tue, 23 Jan 96 18:57:18 MET Date: Tue, 23 Jan 96 18:57:18 MET From: Markus Jork To: "ip-atm@matmos.hpl.hp.com"@vbormc.vbo.dec.com, "ipng@sunroof.eng.sun.com"@vbormc.vbo.dec.com Cc: jork@nestvx.enet.dec.com Apparently-To: ipng@sunroof.eng.Sun.COM, ip-atm@matmos.hpl.hp.com Subject: (IPng 1260) Re: IPv6 over NBMA Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson wrote: > I can't speak for DEC's code, but that is proved to be false by looking > at the NRL implementation. I could easily slip a solution based in > part on NHRP into the NRL implementation (if there were BSD device > drivers for some NBMA interface and I were still working on the NRL > codebase :-). > > My current codebase makes it quite easy to use an NHRP-derived solution > under IPv6 for NBMA interfaces. And in another mail Francis Dupont said: > Today they are not solved by NHRP too but NHRP is more general (it > works with IPv4, IPv6 and other datagram networks over any NBMA) and > is already available then I expect to implement NHRP with IPv6 before > even Peter's draft is finished... So both of you say you could just plug in some NHRP code and IPv6 over NBMA is done. Isn't this a bit too simple? Correct me if I'm wrong but what you seem to propose is: - have a per-interface flag that says "this is a dumb NBMA interface, don't expect it to handle any multicast ND messages" - let the system manager do all the manual configuration he/she knows so well from IPv4 (IP address of the interface, default router and NHRP server, on-link prefixes) - because the IP layer knows it can't send NSs on this interface, it will pass down the destination IP address and let the data link resolve the link layer address. This is in contrast to "regular" interfaces for which the ND code at the IP layer keeps and acquires address resolution information and just passes down the destination link layer address. (You might invent some more sophisticated IP <-> data link interface but that won't change the basic principle.) This implies that you don't have (quoting from Erik's list of ND features): Router Discovery, Prefix Discovery, Parameter Discovery, Address Autoconfiguration and Duplicate Address Detection. I conclude the above architecture from your claims you could easily add NHRP to your IPv6 code. Is this a solution to the problem "IPv6 over NBMA"? >From most of the mail I've seen so far there seems to be consensus we should try to provide plug&play capabilities for NBMA networks. But only if that wouldn't be excessively expensive. Maybe I'm not seeing the obvious, but extending the above scenario in order to add the missing ND features requires quite some work and will result in lots of extra code. Besides, nobody has made a proposal or even has given a small hint how this could be achieved. Now, the good news is that there already is a proposal which provides all the features we might want. It's based on the existing ND code. And, despite some claims otherwise, I don't think it's too complex. On the contrary, as Peter already pointed out, it will be even more simplified in its next revision. I wouldn't mind discussing the pros&cons as compared to some NHRP based proposal. But so far there is none. It's not fair to say we shouldn't consider Peter's draft because "NHRP can be implemented easily". I just don't see that. And I also don't see why it shouldn't be applicable to non-ATM NBMA networks. Markus ------------------------------------------------------------------------------ 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 Jan 23 10:44:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16075; Tue, 23 Jan 96 10:44:16 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15540; Mon, 22 Jan 96 21:04:39 PST Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id VAA06519; Mon, 22 Jan 1996 21:03:25 -0800 (PST) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA13686; Mon, 22 Jan 1996 21:03:58 -0800 Date: Mon, 22 Jan 1996 21:03:58 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199601230503.VAA13686@bobo.eng.sun.com> To: rja@cisco.com Subject: (IPng 1261) Re: IPv6 over NBMA Cc: ip-atm@matmos.hpl.hp.com, 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 > Address Resolution is the -primary- purpose of ND after all. I must disagree - I don't think there is any PRIMARY purpose in ND. The protocol (together with addrconf) provides: - Router Discovery - Prefix Discovery - Parameter Discovery - Address Autoconfiguration - Duplicate Address Detection - Address Resolution - Next-hop Determination - Neighbor Unreachability Detection - Redirect If we want plug&play (or some close approximation) on NBMA links we somehow need to provide all of the above services. Note that the ND protocol as specified does not claim to solve all of the above problems on NBMA links since many of them require multicast support. Thus the issue (assuming we have consensus that we desire plug&play) is how to provide the above services. There is a number of possibilities: - Use ND for redirect and Neighbor Unreachability Detection. Use some other protocol for the rest. - Use the ND redirect message as an address resultion mechanism. - Extend ND for NBMA links by adding some new options. - Use ND servers (much like the ARP servers in IPv4). - Use multicast servers and run ND over the resulting multicast link. > Also, I believe it to be both desirable and possible to come up with a > generic approach to IPv6/NBMA that would not be limited to ATM. This > should be a goal IMHO. I agree completely. 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 Jan 23 13:20:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16153; Tue, 23 Jan 96 13:20:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16147; Tue, 23 Jan 96 13:20:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00580; Tue, 23 Jan 1996 13:19:40 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id NAA13313; Tue, 23 Jan 1996 13:19:40 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <53320(8)>; Tue, 23 Jan 1996 13:18:59 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 23 Jan 1996 13:18:47 -0800 To: ipng@sunroof.eng.sun.com Cc: deering@parc.xerox.com Subject: (IPng 1262) ipngwg scheduling for LA IETF Date: Tue, 23 Jan 1996 13:18:38 PST From: Steve Deering Message-Id: <96Jan23.131847pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We currently have two slots scheduled for ipngwg in LA: Monday, March 4 - 3:30-5:30pm (opposite trunkmib, cat, rolc,rps) Wednesday, March 6 - 1:00-3:00pm (opposite dnsind,ipatm,cidrd) Please send any requested agenda items to Bob and me. One item already: IPv6 issues of concern to the DHCPv6 effort will be on the agenda for the Monday session. 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 Jan 23 17:12:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16403; Tue, 23 Jan 96 17:12:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16383; Tue, 23 Jan 96 17:06:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04874; Tue, 23 Jan 1996 17:05:24 -0800 Received: from lightning.synoptics.com by mercury.Sun.COM (Sun.COM) id RAA12623; Tue, 23 Jan 1996 17:05:24 -0800 Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA14792; Tue, 23 Jan 96 16:48:10 PST Received: from milliways-le0.engwest by pobox (4.1/SMI-4.1) id AA25802; Tue, 23 Jan 96 16:49:32 PST Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA21248; Tue, 23 Jan 96 16:49:31 PST Date: Tue, 23 Jan 96 16:49:31 PST From: asmith@BayNetworks.COM (Andrew Smith) Message-Id: <9601240049.AA21248@milliways-le0.engwest> To: nordmark@caribe-86.eng.sun.com Subject: (IPng 1263) Re: IPv6 over NBMA Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From atmpost@matmos.hpl.hp.com Mon Jan 22 21:22:32 1996 > Date: Mon, 22 Jan 1996 20:50:00 -0800 > From: nordmark@caribe-86.Eng.Sun.COM (Erik Nordmark) > To: jhalpern@us.Newbridge.com > Subject: Re: (IPng 1212) Re: IPv6 over NBMA > Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.Eng.Sun.COM Erik, > I know that the ipatm and rolc work is moving towards having the host to > router interaction use the same NHRP protocol as the router to router > interaction. This seems contrary to the experience in IPv4 routing where > the community realized that it was a good thing to use a separate > protocol for host-router interaction (ICMP router discovery) than > the router-router protocol to allow for evolution in the routing > protocols. > > Wouldn't the same be true for NHRP? > > It might be possible to come up with a relatively simple and robust > protocol for host-router interaction on NBMA, that could be coupled > with an evolving NHRP-style protocol between routers. We had a discussion on this topic on the NHRP list (oops, I mean ROLC list) a while back and there seemed to be concensus that separation of the client-server and the server-server portions was a good thing. Nothing came of it in terms of hard text though, probably because it was sort of complex to do with an existing document and existing shipped implementations. > Erik > Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Technology Synergy FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ******************************************************************************** ------------------------------------------------------------------------------ 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 Jan 24 04:37:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16698; Wed, 24 Jan 96 04:37:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16692; Wed, 24 Jan 96 04:37:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21206; Wed, 24 Jan 1996 04:36:28 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id EAA08102; Wed, 24 Jan 1996 04:36:29 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA27786; Wed, 24 Jan 1996 07:34:26 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32373; Wed, 24 Jan 1996 07:34:24 -0500 Message-Id: <9601241234.AA32373@fwasted.zk3.dec.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: jhalpern@us.newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1264) Re: IPv6 over NBMA In-Reply-To: Your message of "Mon, 22 Jan 96 20:50:00 PST." <199601230450.UAA13679@bobo.eng.sun.com> Date: Wed, 24 Jan 96 07:34:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If we find that such a split is useful we should look more >closely at what the ND protocol can do "as is" and what extensions >(i.e. new options) might make sense for NBMA links. Read Peters draft spec as one starting point to see how he was able to use ND and Addr Conf for ATM. In addition with Peters model the ND code base and algorithms presently for IPv6 will stay in tact and this includes NUD. Read Greenvilles spec for ideas for Multicast using ATM. So we are not starting from scratch here we have some ideas on the table. Maybe this needs to be presented at the ATM Forum too. /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 Jan 24 10:40:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16919; Wed, 24 Jan 96 10:40:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16897; Wed, 24 Jan 96 10:23:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25556; Wed, 24 Jan 1996 10:22:55 -0800 Received: from guelah.nexen.com by mercury.Sun.COM (Sun.COM) id KAA24930; Wed, 24 Jan 1996 10:22:46 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA27044; Wed, 24 Jan 1996 13:16:43 -0500 Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id NAA26159; Wed, 24 Jan 1996 13:11:31 -0500 Received: from localhost (malis@localhost) by phish.nexen.com (8.6.12/8.6.12) with SMTP id NAA27560; Wed, 24 Jan 1996 13:22:26 -0500 Message-Id: <199601241822.NAA27560@phish.nexen.com> To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Cc: jhalpern@us.Newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, malis@nexen.com Subject: (IPng 1265) Re: IPv6 over NBMA In-Reply-To: Your message of "Mon, 22 Jan 1996 20:50:00 PST." <199601230450.UAA13679@bobo.eng.sun.com> Date: Wed, 24 Jan 1996 13:22:25 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, > I know that the ipatm and rolc work is moving towards having the host to > router interaction use the same NHRP protocol as the router to router > interaction. This seems contrary to the experience in IPv4 routing where > the community realized that it was a good thing to use a separate > protocol for host-router interaction (ICMP router discovery) than > the router-router protocol to allow for evolution in the routing > protocols. > > Wouldn't the same be true for NHRP? > > It might be possible to come up with a relatively simple and robust > protocol for host-router interaction on NBMA, that could be coupled > with an evolving NHRP-style protocol between routers. NHRP is not a routing protocol, but an address resolution protocol - in fact, the current plan is to use it to replace ATMARP as well as use it on other NBMA-style subnetwork technologies. Since it is intended for implementation on hosts, we really have tried to keep it as simple as possible while allowing it to do its job. The fact that NRHP servers don't need a SECOND protocol for forwarding the requests and responses is to me an advantage, not a disadvantage. We may find, in the future, that we've placed certain restrictions up the servers by forwarding the requests in this manner, and we may want to revisit the server-server forwarding as a result (without any changes to the hosts, of course). However, I'm not aware of any such restrictions in the current protocol. The place where you ARE going to see a second protocol in the servers is for the server-server synchronization. This is a database synchronization function, not an address resolution function, and it makes sense to use additional mechanisms and PDUs that aren't visible to the hosts. So in this respect, we actually are going to be using a separate protocol for the strict server-server interactions. Andy ------------------------------------------------------------------------------ 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 Jan 24 11:18:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16971; Wed, 24 Jan 96 11:18:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16965; Wed, 24 Jan 96 11:18:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05197; Wed, 24 Jan 1996 11:17:19 -0800 Received: from lightning.synoptics.com by mercury.Sun.COM (Sun.COM) id LAA16447; Wed, 24 Jan 1996 11:17:20 -0800 Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA02396; Wed, 24 Jan 96 11:10:56 PST Received: from milliways-le0.engwest by pobox (4.1/SMI-4.1) id AA18653; Wed, 24 Jan 96 11:12:09 PST Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA21896; Wed, 24 Jan 96 11:12:08 PST Date: Wed, 24 Jan 96 11:12:08 PST From: asmith@BayNetworks.COM (Andrew Smith) Message-Id: <9601241912.AA21896@milliways-le0.engwest> To: malis@nexen.com Subject: (IPng 1266) Re: IPv6 over NBMA Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To: nordmark@caribe-86.Eng.Sun.COM (Erik Nordmark) > Cc: jhalpern@us.Newbridge.com, ip-atm@matmos.hpl.hp.com, > ipng@sunroof.Eng.Sun.COM, malis@nexen.com > Subject: Re: (IPng 1212) Re: IPv6 over NBMA > Date: Wed, 24 Jan 1996 13:22:25 -0500 > From: "Andrew G. Malis" Andy, > The fact that > NRHP servers don't need a SECOND protocol for forwarding the requests > and responses is to me an advantage, not a disadvantage. The NHRP servers use the same *packet format* to relay to the next hop server which is a nice feature but incidental. The servers do, however, use different *protocol mechanisms* for deciding what to do with such messages. I think you are confusing syntax with semantics when you say that there is no second protocol. I think the current NHRP draft document also shares this same confusion. > Andy > Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Technology Synergy FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ******************************************************************************** ------------------------------------------------------------------------------ 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 Jan 24 11:52:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17016; Wed, 24 Jan 96 11:52:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17010; Wed, 24 Jan 96 11:52:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11312; Wed, 24 Jan 1996 11:52:03 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA27898; Wed, 24 Jan 1996 11:52:00 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09636; Wed, 24 Jan 96 14:51:04 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA16308; Wed, 24 Jan 96 14:51:54 EST Date: Wed, 24 Jan 96 14:51:54 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601241951.AA16308@pobox.BayNetworks.com> To: malis@nexen.com Subject: (IPng 1267) Re: IPv6 over NBMA Cc: jhalpern@us.Newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Wed, 24 Jan 1996 13:22:25 -0500 > From: "Andrew G. Malis" > > NHRP is not a routing protocol, but an address resolution protocol - > in fact, the current plan is to use it to replace ATMARP as well as > use it on other NBMA-style subnetwork technologies. Interesting.. Recently Yakov convincingly argued on the ip-atm list that NHRP may carry network layer reachability information. If it so, than NHRP can be legitimately classified as a routing protocol. In addition to an address resolution, NHRP may provide a mechanism of discovering the egress router toward a given destination. 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 Jan 24 13:01:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17081; Wed, 24 Jan 96 13:01:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17071; Wed, 24 Jan 96 13:01:10 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21484; Wed, 24 Jan 1996 13:00:28 -0800 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id NAA16316; Wed, 24 Jan 1996 13:00:26 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id MAA01629; Wed, 24 Jan 1996 12:56:43 -0800 Message-Id: <199601242056.MAA01629@hubbub.cisco.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: malis@nexen.com, jhalpern@us.newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1268) Re: IPv6 over NBMA In-Reply-To: Your message of "Wed, 24 Jan 96 14:51:54 EST." <9601241951.AA16308@pobox.BayNetworks.com> Date: Wed, 24 Jan 96 12:56:42 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, > > NHRP is not a routing protocol, but an address resolution protocol - > > in fact, the current plan is to use it to replace ATMARP as well as > > use it on other NBMA-style subnetwork technologies. > > Interesting.. Recently Yakov convincingly argued on the ip-atm list > that NHRP may carry network layer reachability information. If it so, > than NHRP can be legitimately classified as a routing protocol. In > addition to an address resolution, NHRP may provide a mechanism of > discovering the egress router toward a given destination. I would agree with you that the r2r NHRP is a routing protocol. But the protocol specified in draft-ietf-rolc-nhrp-07.txt could be viewed as just an address resolution protocol. Yakov. ------------------------------------------------------------------------------ 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 Jan 24 16:38:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17262; Wed, 24 Jan 96 16:38:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17256; Wed, 24 Jan 96 16:38:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26594; Wed, 24 Jan 1996 16:37:56 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id QAA16940; Wed, 24 Jan 1996 16:37:55 -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 QAA00981 for ; Wed, 24 Jan 1996 16:37:56 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jan 1996 16:39:37 -0800 To: ipng@sunroof.eng.sun.com From: "Joyce K. Reynolds" (by way of hinden@ipsilon.com (Bob Hinden)) Subject: (IPng 1269) RFC1897 on IPv6 Testing Address Allocation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 1897: Title: IPv6 Testing Address Allocation Author: R. Hinden & J. Postel Date: January 1996 Mailbox: hinden@ipsilon.com, postel@isi.edu Pages: 4 Characters: 6,643 Updates/Obsoletes: none URL: ftp://ds.internic.net/rfc/rfc1897.txt This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. This RFC is the product of the IPNG Working Group of the IETF. This document specifies an Experimental protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <960124145109.RFC@ISI.EDU> [This attachment must be fetched by mail. Open the stationery below and send the resulting message to get the attachment.] Attachment converted: Macintosh HD:Get RFC1897 on IPv6 Testing Add (EuSn/CSOm) (000076C6) Content-Type: Message/External-body; name="rfc1897.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" [This attachment must be fetched by ftp. Open the document below to ask your ftp client to fetch it.] Attachment converted: Macintosh HD:Get rfc1897.txt (AURL/Arch) (000076C7) Content-Type: text/plain Content-ID: <960124145109.RFC@ISI.EDU> ------------------------------------------------------------------------------ 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 Jan 24 18:58:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17336; Wed, 24 Jan 96 18:58:17 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17330; Wed, 24 Jan 96 18:58:00 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id SAA05086 for ; Wed, 24 Jan 1996 18:56:42 -0800 (PST) Date: Wed, 24 Jan 1996 19:02:35 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1270) Re: New draft of API spec is now available 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: "Tim Hartrick" > > > > I strongly disagree. In our implementation, except for the payload length > > field, all the IPv6 headers are dealt with in network order regardless of > > the endian-ness of the machine. I see no reason to force an implement- > > ation to do byteswapping just to save a few ifdef's in a header file. > > > > I don't understand what the internal representation of the IPv6 headers > has to do with the way constants are handled by the API. If ports and > addresses (in IPv4) need an hton[l|s] applied to them before they are > inserted into a sockaddr_inx structure and passed through to the kernel, > then what makes flowinfo different? > . . . > The former makes the sin6_flowinfo different from the majority of the > other fields of the sockaddr_in[6] structures since the order of the > constants is already in network order. Note that the IPv6 address in the sockaddr_in6 struct is stored in *network* byte order. So, the way things are defined now, the only element that is in host order is the port number. It strikes me as intuitive that only elements that hold numeric values that you might want to perform arithmetic on (like the port number) would be in host order. 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 Wed Jan 24 19:22:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17348; Wed, 24 Jan 96 19:22:54 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17342; Wed, 24 Jan 96 19:22:37 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id TAA05580 for ; Wed, 24 Jan 1996 19:21:19 -0800 (PST) Date: Wed, 24 Jan 1996 19:27:12 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1271) Re: New draft of API spec is now available 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: "Matt Thomas" > > > I know your probably more than ready to get this thankless > > task over with but it seems like the API spec (or some information- > > al RFC) needs to say something about how to deal with the dreaded options. > > I realize that there currently are no defined options but it would be nice > > to have some guidelines in this area so when options begin to appear there > > there are not as many ways to deal with them as there are implementa- > > tions. > > I assume you are talking about the Hop-By-Hop and Destination Node options. > I don't any of us know enough about ESP and Authentication at this time > point in time to define an interface to them in an RFC. > . . . > For Digital UNIX, I'm planning on using the "control data" ability > which is part of BSD 4.3 Reno or later. > . . . > so this can be equally used for TCP. First of all, I agree that the ESP and authentication options need some API extensions designed just for them. Dan McDonald did a draft of such a thing about a year ago, but no one has followed up on it yet. Regarding using the "control data" field via recvmsg() for the other options, I think that's an interesting idea. But I didn't follow exactly how this would work with TCP sockets. Is the thought that the application would use recvmsg() on the (AF_INET6, SOCK_STREAM) socket, and there would be a one-to-one correspondence between received TCP segments (and their associated IP options) and returns from recvmsg()? > [This is, in my opinion, is a much better method of dealing with such > things as source routes and "sending/receiving interfaces" and uses > already existing mechanisms in most implementations (unlike the current > method in the API specification).] While I think msg_control may be a natural field for conveying "optional" information, source routing and sending/receiving interface information have to do with addressing the packet, and so most naturally fit through the address arguments of the socket functions, in my opinion. 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 Wed Jan 24 19:33:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17360; Wed, 24 Jan 96 19:33:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17354; Wed, 24 Jan 96 19:32:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17637; Wed, 24 Jan 1996 19:32:10 -0800 Received: from vangogh.CS.Berkeley.EDU by mercury.Sun.COM (Sun.COM) id TAA20105; Wed, 24 Jan 1996 19:32:11 -0800 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id TAA00411 for ipng@sunroof.Eng.Sun.Com; Wed, 24 Jan 1996 19:30:39 -0800 (PST) Date: Wed, 24 Jan 1996 19:30:39 -0800 (PST) From: Keith Sklower Message-Id: <199601250330.TAA00411@vangogh.CS.Berkeley.EDU> To: ipng@sunroof.eng.sun.com Subject: (IPng 1272) Re: New draft of API spec is now available Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Gilligan writes: It strikes me as intuitive that only elements that hold numeric values that you might want to perform arithmetic on (like the port number) would be in host order. WHOAAA!!!! I didn't notice that the first time around ... If the port number is host byte order for IPv6 and in network byte order for IPv4 sockets, somebody is surely going to be confused. If this proposal were to come before posix and I were on the committee I sure as heck would make a stink about it. ------------------------------------------------------------------------------ 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 Jan 24 21:18:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17425; Wed, 24 Jan 96 21:18:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17419; Wed, 24 Jan 96 21:18:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27084; Wed, 24 Jan 1996 21:18:01 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id VAA03208; Wed, 24 Jan 1996 21:18:01 -0800 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id VAA07653; Wed, 24 Jan 1996 21:18:05 -0800 Message-Id: <199601250518.VAA07653@mailhost.Ipsilon.COM> To: Bob Gilligan Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1273) Re: New draft of API spec is now available In-Reply-To: Your message of "Wed, 24 Jan 1996 19:27:12 PST." Date: Wed, 24 Jan 1996 21:18:04 -0800 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> For Digital UNIX, I'm planning on using the "control data" ability >> which is part of BSD 4.3 Reno or later. >> . . . >> so this can be equally used for TCP. > > Regarding using the "control data" field via recvmsg() for the other > options, I think that's an interesting idea. But I didn't follow > exactly how this would work with TCP sockets. Is the thought that the > application would use recvmsg() on the (AF_INET6, SOCK_STREAM) socket, > and there would be a one-to-one correspondence between received TCP > segments (and their associated IP options) and returns from recvmsg()? Most of this information is often uninteresting to TCP applications since TCP automatically turns source routes around and the like. There is a getsockopt() call to determine the values associated with a connection, if you really want to know them, and a setsockopt() call to (re)set them to something else. This seems sufficient. >> [This is, in my opinion, is a much better method of dealing with such >> things as source routes and "sending/receiving interfaces" and uses >> already existing mechanisms in most implementations (unlike the current >> method in the API specification).] > > While I think msg_control may be a natural field for conveying > "optional" information, source routing and sending/receiving interface > information have to do with addressing the packet, and so most > naturally fit through the address arguments of the socket functions, > in my opinion. As far as I can tell source routing is no more "optional" in IPv4 than IPv6, and no less useful (despite text in the draft to the contrary). Your IPv6 applications (which, after all, should be the same applications as your IPv4 applications) have no greater or fewer reason to want to know this. I think the fact that there is an existing, widely deployed mechanism to handle this for IPv4 suggests that it might be easier all around for applications which already handle source routing to just use the same mechanism for IPv6. As for source routing being "addressing", this is hardly the case unless you either have a funny definition of "addressing" or you really do expect packets sent with a different source route to reach a different destination. In fact the view of source route information as "addressing" may have caused trouble for your API; there are very good reasons to want the ability to change or delete source routes from the return packets for established TCP connections, and this functionality exists for IPv4 (for example all the r* commands do this, for obvious reasons), but I don't see how you can do this. As for receiving interface, this information could be called "addressing" in the IPv6 context, I guess, since a link local address may reach different hosts on different interfaces. But again, as specified in your API, the mechanism you use to return this is unreliable. It demands that the system return an interface address which uniquely identifies the interface, but since link local addresses don't need to be unique, and interfaces are not required to have any address other than the link local address, then there is no guarantee that an interface address which uniquely identifies the interface actually exists (not to mention the difficulty of determining whether an address is unique if you have a very large number of interfaces). An unreliable way to identify the receiving interface is as bad as no way. If you are assuming additional constraints on interface configuration I think you need to write them down so they are understood by implementors, and can be examined to see if they are acceptable. Dennis Ferguson ------------------------------------------------------------------------------ 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 Jan 24 23:44:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17457; Wed, 24 Jan 96 23:44:15 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17451; Wed, 24 Jan 96 23:43:59 PST Received: from everglade ([192.9.213.1]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id XAA09339; Wed, 24 Jan 1996 23:42:38 -0800 (PST) Date: Wed, 24 Jan 1996 23:45:34 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1274) Re: New draft of API spec is now available To: Keith Sklower Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bob Gilligan writes: > It strikes me as intuitive that only elements that hold numeric > values that you might want to perform arithmetic on (like the > port number) would be in host order. > > WHOAAA!!!! I didn't notice that the first time around ... > If the port number is host byte order for IPv6 and in network byte > order for IPv4 sockets, somebody is surely going to be confused. > > If this proposal were to come before posix and I were on the committee > I sure as heck would make a stink about it. Ooops, my mistake. The sin6_port field is in network byte order, just like sin_port, and the API spec even says that. I wasn't thinking before typing. Sorry about that! 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 Jan 25 08:07:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17858; Thu, 25 Jan 96 08:07:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17852; Thu, 25 Jan 96 08:07:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06448; Thu, 25 Jan 1996 08:06:25 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id IAA29059; Thu, 25 Jan 1996 08:06:25 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03616; 25 Jan 96 10:19 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 1275) I-D ACTION:draft-ietf-ipngwg-token-ring-01.txt Date: Thu, 25 Jan 96 10:19:04 -0500 Message-Id: <9601251019.aa03616@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 Token Ring Networks Author(s) : S. Thomas Filename : draft-ietf-ipngwg-token-ring-01.txt Pages : 7 Date : 01/24/1996 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. 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-token-ring-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-token-ring-01.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-token-ring-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19960124084050.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-token-ring-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-token-ring-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960124084050.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 Jan 25 09:33:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17951; Thu, 25 Jan 96 09:33:16 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17945; Thu, 25 Jan 96 09:33:00 PST Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id JAA17660; Thu, 25 Jan 1996 09:31:41 -0800 (PST) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA25790; Thu, 25 Jan 1996 09:32:16 -0800 Date: Thu, 25 Jan 1996 09:32:16 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199601251732.JAA25790@bobo.eng.sun.com> To: gilligan@caribe.eng.sun.com Subject: (IPng 1276) Re: New draft of API spec is now available 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 Bob, > Note that the IPv6 address in the sockaddr_in6 struct is stored in > *network* byte order. So, the way things are defined now, the only > element that is in host order is the port number. It strikes me as This sounds broken. Today the port number (as well as the address) is in network byte order. All the getXbyY routines return them in network byte order and all the kernel code deal with them as such. Thus the only cases when byte swapping is needed is when using a constant (e.g. INADDR_LOOPBACK) and when handling e.g. command line arguments (using port "9999"). 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 Jan 25 10:32:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18052; Thu, 25 Jan 96 10:32:15 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18046; Thu, 25 Jan 96 10:31:58 PST Received: from everglade ([192.9.213.1]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id KAA20545; Thu, 25 Jan 1996 10:30:37 -0800 (PST) Date: Thu, 25 Jan 1996 10:33:33 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1277) Re: New draft of API spec is now available To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Bob, > > > Note that the IPv6 address in the sockaddr_in6 struct is stored in > > *network* byte order. So, the way things are defined now, the only > > element that is in host order is the port number. It strikes me as > > This sounds broken. > > Today the port number (as well as the address) is in network > byte order. All the getXbyY routines return them in network > byte order and all the kernel code deal with them as such. > > Thus the only cases when byte swapping is needed is when using > a constant (e.g. INADDR_LOOPBACK) and when handling e.g. command > line arguments (using port "9999"). > > Erik Yes, the obvious error in my e-mail was cuased by typing before thinking. Just to clarify, though, the API spec does now and always has defined the port field as being in network byte order. Here is the relevant paragraph from that spec: The sin6_port field is used to store the 16-bit UDP or TCP port number. This field is used in the same way as the sin_port field of sockaddr_in structure. The port number is stored in network byte order. 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 Jan 26 10:14:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18801; Fri, 26 Jan 96 10:14:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18775; Fri, 26 Jan 96 10:05:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19835; Fri, 26 Jan 1996 10:05:04 -0800 Received: from brookfield.ans.net by mercury.Sun.COM (Sun.COM) id KAA23858; Fri, 26 Jan 1996 10:04:59 -0800 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id NAA09468; Fri, 26 Jan 1996 13:00:54 -0500 Message-Id: <199601261800.NAA09468@brookfield.ans.net> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: malis@nexen.com, jhalpern@us.newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Reply-To: curtis@ans.net Subject: (IPng 1278) Re: IPv6 over NBMA In-Reply-To: Your message of "Wed, 24 Jan 1996 14:51:54 EST." <9601241951.AA16308@pobox.BayNetworks.com> Date: Fri, 26 Jan 1996 13:00:48 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9601241951.AA16308@pobox.BayNetworks.com>, Dimitry Haskin writes: > > > Date: Wed, 24 Jan 1996 13:22:25 -0500 > > From: "Andrew G. Malis" > > > > NHRP is not a routing protocol, but an address resolution protocol - > > in fact, the current plan is to use it to replace ATMARP as well as > > use it on other NBMA-style subnetwork technologies. > > Interesting.. Recently Yakov convincingly argued on the ip-atm list > that NHRP may carry network layer reachability information. If it so, > than NHRP can be legitimately classified as a routing protocol. In > addition to an address resolution, NHRP may provide a mechanism of > discovering the egress router toward a given destination. > > Dimitry Dimitry, You say "Yakov convincingly argued ...". I'm not sure that in this case everyone was convinced. In fact, I know I wasn't. :-) Later Yakov also stated that NHRP could only do this reliably in some topologies if it was used in conjunction with a routing protocol. "A routing protocol which requires another routing protocol to get it right" seems to me like a paradox. Are we arguing semantics? Is the issue whether we can list it under "routing protocols" in the marketing glossies and mislead the customers? ;-) Curtis ------------------------------------------------------------------------------ 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 Jan 26 10:16:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18839; Fri, 26 Jan 96 10:16:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18785; Fri, 26 Jan 96 10:12:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20948; Fri, 26 Jan 1996 10:11:24 -0800 Received: from brookfield.ans.net by mercury.Sun.COM (Sun.COM) id KAA26387; Fri, 26 Jan 1996 10:11:21 -0800 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id NAA09486; Fri, 26 Jan 1996 13:06:20 -0500 Message-Id: <199601261806.NAA09486@brookfield.ans.net> To: Yakov Rekhter Cc: dhaskin@baynetworks.com (Dimitry Haskin), malis@nexen.com, jhalpern@us.newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Reply-To: curtis@ans.net Subject: (IPng 1279) Re: IPv6 over NBMA In-Reply-To: Your message of "Wed, 24 Jan 1996 12:56:42 PST." <199601242056.MAA01629@hubbub.cisco.com> Date: Fri, 26 Jan 1996 13:06:19 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199601242056.MAA01629@hubbub.cisco.com>, Yakov Rekhter writes: > Dimitry, > > > > NHRP is not a routing protocol, but an address resolution protocol - > > > in fact, the current plan is to use it to replace ATMARP as well as > > > use it on other NBMA-style subnetwork technologies. > > > > Interesting.. Recently Yakov convincingly argued on the ip-atm list > > that NHRP may carry network layer reachability information. If it so, > > than NHRP can be legitimately classified as a routing protocol. In > > addition to an address resolution, NHRP may provide a mechanism of > > discovering the egress router toward a given destination. > > I would agree with you that the r2r NHRP is a routing protocol. > But the protocol specified in draft-ietf-rolc-nhrp-07.txt could > be viewed as just an address resolution protocol. > > Yakov. Yakov, er... excuse me but, r2r NHRP still requires use of a routing protocol to avoid loops in some topologies. right! Curtis ------------------------------------------------------------------------------ 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 Jan 26 11:39:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18960; Fri, 26 Jan 96 11:39:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18954; Fri, 26 Jan 96 11:39:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07189; Fri, 26 Jan 1996 11:38:40 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id LAA07036; Fri, 26 Jan 1996 11:38:38 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA17905; Fri, 26 Jan 1996 14:33:18 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09537; Fri, 26 Jan 1996 14:33:17 -0500 Message-Id: <9601261933.AA09537@fwasted.zk3.dec.com> To: curtis@ans.net Cc: dhaskin@baynetworks.com (Dimitry Haskin), malis@nexen.com, jhalpern@us.newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1280) Re: IPv6 over NBMA In-Reply-To: Your message of "Fri, 26 Jan 96 13:00:48 EST." <199601261800.NAA09468@brookfield.ans.net> Date: Fri, 26 Jan 96 14:33:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk %In message <9601241951.AA16308@pobox.BayNetworks.com>, Dimitry Haskin writes: %> %> > Date: Wed, 24 Jan 1996 13:22:25 -0500 %> > From: "Andrew G. Malis" %> > %> > NHRP is not a routing protocol, but an address resolution protocol - %> > in fact, the current plan is to use it to replace ATMARP as well as %> > use it on other NBMA-style subnetwork technologies. %> %> Interesting.. Recently Yakov convincingly argued on the ip-atm list %> that NHRP may carry network layer reachability information. If it so, %> than NHRP can be legitimately classified as a routing protocol. In %> addition to an address resolution, NHRP may provide a mechanism of %> discovering the egress router toward a given destination. %> %> Dimitry % % %Dimitry, % %You say "Yakov convincingly argued ...". I'm not sure that in this %case everyone was convinced. In fact, I know I wasn't. :-) I was not either. %Later Yakov also stated that NHRP could only do this reliably in some %topologies if it was used in conjunction with a routing protocol. "A %routing protocol which requires another routing protocol to get it %right" seems to me like a paradox. It is a paradox. This is a benefit of the Schulter/Jork/Armitage model that address resolution in fact can be done using IPv6 ND, which requires no routing protocols or routers in the case of ATM. One discussion of address resolution that needs to take place in depth is Peter Schulter/Markus Jork model vs NHRP before I believe or support any protocol on the table as "the" address resolution protocol for IPv6 NBMA, and specifically ATM. I know Peter was at USENIX this week and will be back next week. /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 Fri Jan 26 12:37:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19096; Fri, 26 Jan 96 12:37:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19090; Fri, 26 Jan 96 12:37:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16152; Fri, 26 Jan 1996 12:36:19 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id MAA27090; Fri, 26 Jan 1996 12:36:18 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA11598; Fri, 26 Jan 1996 15:21:09 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16709; Fri, 26 Jan 1996 15:20:39 -0500 Message-Id: <9601262020.AA16709@fwasted.zk3.dec.com> To: jhalpern@us.newbridge.com (Joel Halpern) Cc: ip-atm@matmos.hpl.hp, com@mako.us.newbridge.com, ipng@sunroof.eng.sun.com Subject: (IPng 1281) Re: IPv6 over NBMA In-Reply-To: Your message of "Fri, 26 Jan 96 14:50:01 +0500." <9601261950.AA06027@lobster.newbridge> Date: Fri, 26 Jan 96 15:20:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk from Joel Halpern >Unfortunately, what it requires instead is a fully configured hierarchy >of servers covering the entire ATM fabric. Given taht in this proposal >the servers are NOT running routing, there is complexity required to >maintain the heirarchy. With a heriarchy of routers, the routers maintain >the hierarchy themselves. In fact, there are even proposals to allow the >automatic formation of such a heirarchy. (No, said proposals are not >fully fleshed out. They need work. But the nature of routing gives one >hope that it can be done.) Using Schulter/Jork model the heirarchies are LLs based on sending the information to each Root for that leaf section in the tree. But I admit this is an oversimplification of the details which will be updated by Peter and Markus before L.A. There is no dependency on routing other than advertisements parts in ND. >In addition, in the absence of a set of routers, there is nothing to >serve as the default forwarding path. One of the relevant IPv4 >observations is also important here. ~You do not want to set up a VC >for a DNS query~. Therefore, there must be a connected heirarchy of >routers, so that packets can be default, connectionless, forwarded. This is all maintained in the ND destination cache (at least on a host) just as for Broadcast type media. Thats what I like about their model. I am not dependent on any egress node or routing infrastructure outside of my Host. Its just part of ND in IPv6 technology base. I realize that this will not work for IPv4. In cases where we can adapt a technology from IPv6 to IPv4 (e.g. IPSEC, Dynamic Updates to DNS) that is goodness. But as a principle we should not reduce the capabilities of IPv6 protocols because of IPv4 compatibility within the Internet Architecture Model. >Given that the routing heirarchy must exist, must be stable, and can >handle the query problem, why in heavens name would I want to invent >anything else? I believe our assumptions are different on what heirarchy must exist for NBMA at different points in the architecture. Hence, rather than me and you talking past each other (as our base assumptions are different) the WGs with a stake in this outcome need to contrast and compare each technical strategy for its ability to solve a set of problems. It might be worth listing that set of problems we are trying to solve for NBMA. But we do not have consensus in ipatm or ipng that NHRP should be used for IPv6 over ATM as one specific case of NBMA for IPv6. Once this discussion is done it may disprove the current wording in ND regarding NBMA that in fact much more of ND can in fact be done in NBMA. I even believe NUD can work. /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 Fri Jan 26 13:28:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19181; Fri, 26 Jan 96 13:28:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19175; Fri, 26 Jan 96 13:28:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24103; Fri, 26 Jan 1996 13:27:47 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id NAA13916; Fri, 26 Jan 1996 13:27:45 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id QAA01351; Fri, 26 Jan 1996 16:24:42 -0500 (EST) Date: Fri, 26 Jan 1996 16:24:42 -0500 (EST) From: Scott Bradner Message-Id: <199601262124.QAA01351@newdev.harvard.edu> To: bound@zk3.dec.com, jhalpern@us.newbridge.com Subject: (IPng 1282) Re: IPv6 over NBMA Cc: com@mako.us.newbridge.com, ip-atm@matmos.hpl.hp@Sun.COM, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Using Schulter/Jork model the heirarchies are LLs based on sending the > information to each Root for that leaf section in the tree. But I admit > this is an oversimplification of the details which will be updated by > Peter and Markus before L.A. Jim, I trust we are not trying to reach a conclusion on this topic before the LA meeting. It seems that there are enough lose ends & disagreements to require a carefull review and discussion during the LA meeting will be helpfull. One question though, where should such a discussion take place? in the Ingwg or in ip-over-atm? 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 Fri Jan 26 13:55:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19218; Fri, 26 Jan 96 13:55:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19058; Fri, 26 Jan 96 11:56:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09710; Fri, 26 Jan 1996 11:55:20 -0800 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id LAA13214; Fri, 26 Jan 1996 11:55:17 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA06182; Fri, 26 Jan 1996 14:52:39 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma006157; Fri Jan 26 14:52:16 1996 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA28578; Fri, 26 Jan 1996 14:52:15 -0500 Received: from lobster.newbridge by mako.us.Newbridge.com (4.1/SMI-4.0) id AA04714; Fri, 26 Jan 96 14:45:02 EST Received: by lobster.newbridge (5.0/SMI-SVR4) id AA06034; Fri, 26 Jan 1996 14:50:40 +0500 Date: Fri, 26 Jan 1996 14:50:40 +0500 From: jhalpern@us.Newbridge.com (Joel Halpern) Message-Id: <9601261950.AA06034@lobster.newbridge> To: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1283) Re: IPv6 over NBMA Cc: bound@zk3.dec.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quoting Jim Bound: "This is a benefit of the Schulter/Jork/Armitage model that address resolution in fact can be done using IPv6 ND, which requires no routing protocols or routers in the case of ATM." Unfortunately, what it requires instead is a fully configured hierarchy of servers covering the entire ATM fabric. Given taht in this proposal the servers are NOT running routing, there is complexity required to maintain the heirarchy. With a heriarchy of routers, the routers maintain the hierarchy themselves. In fact, there are even proposals to allow the automatic formation of such a heirarchy. (No, said proposals are not fully fleshed out. They need work. But the nature of routing gives one hope that it can be done.) In addition, in the absence of a set of routers, there is nothing to serve as the default forwarding path. One of the relevant IPv4 observations is also important here. ~You do not want to set up a VC for a DNS query~. Therefore, there must be a connected heirarchy of routers, so that packets can be default, connectionless, forwarded. Given that the routing heirarchy must exist, must be stable, and can handle the query problem, why in heavens name would I want to invent anything else? Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS Regardles of whether you consider the "ip/atm framework" statement about NHRP overstated, understated, or confusing, the same issues apply to any use of any address resolution / neighbor discovery mechanism if used by routers without suitable coupling to the underlying routing protocols. Such issues are NOT relevant to the discussion for ipng. PPS Sorry if you see this twice, my mailer complained the first time. ------------------------------------------------------------------------------ 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 Jan 26 14:57:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19339; Fri, 26 Jan 96 14:57:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19333; Fri, 26 Jan 96 14:57:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08778; Fri, 26 Jan 1996 14:56:54 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id OAA12464; Fri, 26 Jan 1996 14:56:53 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27637; Fri, 26 Jan 96 17:55:53 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA06648; Fri, 26 Jan 96 17:56:37 EST Date: Fri, 26 Jan 96 17:56:37 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9601262256.AA06648@pobox.BayNetworks.com> To: curtis@ans.net Subject: (IPng 1284) Re: IPv6 over NBMA Cc: malis@nexen.com, jhalpern@us.newbridge.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Curtis Villamizar > > Are we arguing semantics? Is the issue whether we can list it under > "routing protocols" in the marketing glossies and mislead the > customers? ;-) > Curtis, You found me! 8) I still hope that NHRP can be more that just an address resolution protocol. Subrouting protocol? ;-) 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 Sun Jan 28 11:12:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20043; Sun, 28 Jan 96 11:12:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20037; Sun, 28 Jan 96 11:12:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19170; Sun, 28 Jan 1996 11:11:29 -0800 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id LAA17312; Sun, 28 Jan 1996 11:11:29 -0800 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6137; Sun, 28 Jan 96 14:11:11 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 7542; Sun, 28 Jan 1996 14:11:11 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Sun, 28 Jan 96 14:11:10 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA37214; Sun, 28 Jan 1996 14:10:55 -0500 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9601281910.AA37214@hawpub1.watson.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1285) draft-ietf-mobileip-ipv6-00.txt Date: Sun, 28 Jan 96 14:10:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have submitted draft-ietf-mobileip-ipv6-00.txt, "Mobility Support in IPv6" to the Internet Drafts directory. This new version of the specification is intended to be detailed enough to encourage implementations and subsequent comments from implementors. It is important to get a mobility protocol beat into shape in time so that all IPv6 hosts can support the few operations required for scalable Internet-wide mobility. In order for the proposed protocol to work as intended, every IPv6 node will be expected to support a new Destination option, called "Binding Update" option. A mobile node sends this new option to inform another IPv6 node about which care-of address to use in a routing header when sending data to the mobile node. IPv6 routers are specified to return a ICMP Binding Acknowledgement in response to a Binding Update. In this way, every IPv6 router can be a home agent for every node with a home address on a network to which the router is attached. The only other requirement for routers is to support IP6-in-IP6 encapsulation. In fact, with only a few more required operations any IPv6 node can itself be a mobile node. Each mobile node must support decapsulation, and must also send Binding Updates upon changing its point of attachment to the Internet. That's almost all there is to it. The new draft is actually an updated version of "draft-perkins-ipv6-mobility-sup-02.txt". Upon the advice of my co-author Dave Johnson, I have changed the name of the Internet Draft to reflect its status as the product of the mobile-IP working group. The new draft is also available via anonymous FTP on software.watson.ibm.com Regards, Charles Perkins ------------------------------------------------------------------------------ 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 Jan 28 12:24:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20111; Sun, 28 Jan 96 12:24:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20105; Sun, 28 Jan 96 12:24:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21360; Sun, 28 Jan 1996 12:23:51 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id MAA21766; Sun, 28 Jan 1996 12:23:51 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA00329; Sun, 28 Jan 1996 15:15:54 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30640; Sun, 28 Jan 1996 15:15:47 -0500 Message-Id: <9601282015.AA30640@fwasted.zk3.dec.com> To: Scott Bradner Cc: bound@zk3.dec.com, jhalpern@us.newbridge.com, com@mako.us.newbridge.com, ip-atm%matmos.hpl.hp@Sun.COM, ipng@sunroof.eng.sun.com Subject: (IPng 1286) Re: IPv6 over NBMA In-Reply-To: Your message of "Fri, 26 Jan 96 16:24:42 EST." <199601262124.QAA01351@newdev.harvard.edu> Date: Sun, 28 Jan 96 15:15:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, > I trust we are not trying to reach a conclusion on this topic >before the LA meeting. It seems that there are enough lose ends & >disagreements to require a carefull review and discussion during the LA >meeting will be helpfull. Agreed at my end. > One question though, where should such a discussion take place? >in the Ingwg or in ip-over-atm? I think the ND and addr conf expertise is in IPng (includes implementors too as many of us are coding this presently for UNH interop testing next week). In addition at the Dallas meeting Peter did not get on until the very end of ipatm when we were all really burned out and hence a hearing of the ideas we very hard due to a very intense ipatm schedule. I would like to suggest we hammer out at an ipng meeting the differences for IPv6 over ATM in front of that expertise to provide or disprove ND can in fact work for IPv6 over ATM. But I think this subject needs some amount of time to have a solid discussion. Do we need a separate event in the evening for just this topic that does not overlap with ipng, ipatm, or rolc probably? Unless ipng can give it enough time for discussion. I tend to think we have some cycles for ipng in L.A.? /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 Sun Jan 28 12:54:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20152; Sun, 28 Jan 96 12:54:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20146; Sun, 28 Jan 96 12:53:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22373; Sun, 28 Jan 1996 12:53:07 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id MAA23459; Sun, 28 Jan 1996 12:53:06 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id PAA05474; Sun, 28 Jan 1996 15:50:06 -0500 (EST) Date: Sun, 28 Jan 1996 15:50:06 -0500 (EST) From: Scott Bradner Message-Id: <199601282050.PAA05474@newdev.harvard.edu> To: bound@zk3.dec.com, sob@newdev.harvard.edu Subject: (IPng 1287) Re: IPv6 over NBMA Cc: com@mako.us.newbridge.com, ip-atm%matmos.hpl.hp@Sun.COM, ipng@sunroof.eng.sun.com, jhalpern@us.newbridge.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would > like to suggest we hammer out at an ipng meeting the differences for > IPv6 over ATM in front of that expertise to provide or disprove ND can > in fact work for IPv6 over ATM. there is also the rolc people 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 Sun Jan 28 13:57:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20229; Sun, 28 Jan 96 13:57:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20223; Sun, 28 Jan 96 13:56:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24419; Sun, 28 Jan 1996 13:56:04 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id NAA27003; Sun, 28 Jan 1996 13:56:04 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA14451; Sun, 28 Jan 1996 16:52:55 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01488; Sun, 28 Jan 1996 16:52:54 -0500 Message-Id: <9601282152.AA01488@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1288) Implementation? on Addr Conf Section 5.5.3 Prefix Info - d) Date: Sun, 28 Jan 96 16:52:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Had sent this to addr conf but then I think we agreed we would combine addr conf within ipng WG? Anyway: On 5.5.3 Page 20 it states: d) If the advertised prefix matches the prefix of an autoconfigured address (i.e., obtained via stateless or stateful address autoconfiguration) in the list of addresses associated with the interface, set the preferred timer to that of the option's preferred lifetime, and set the valid lifetime to that of the option's valid lifetime. In the case where stateful has provided an address like 5CB6::4567. Then the router sends a new set of timers for 5CB6:: prefix the implementation will update the valid and preferred timers for prefix 5CB6. This is not good. The reason is that the stateful server is still using the lease times it sent out for the client, and now they have been changed. We don't want clients updating the servers timers per stateless RAs. I think the above needs some discussion. It seems to me if the Managed-bit is ON and the Autonomous-Bit is ON (meaning the client is using both stateless and stateful for addr conf via coexistence) then if the address was obtained via stateful server for addr conf the timers should not be updated and a system log error should be posted. But if the Managed-bit is set to OFF then the timers can replace the prefix address 5CB6 as stateful essentially has just been canceled as an addr conf mechanism for the client. Comments ???? /jim ------- End of Forwarded 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 Sun Jan 28 14:19:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20255; Sun, 28 Jan 96 14:19:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20249; Sun, 28 Jan 96 14:19:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25178; Sun, 28 Jan 1996 14:18:43 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id OAA28834; Sun, 28 Jan 1996 14:18:43 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA13770; Sun, 28 Jan 96 14:17:59 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA01066; Sun, 28 Jan 1996 14:18:20 -0800 Date: Sun, 28 Jan 1996 14:18:20 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601282218.AA01066@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 1289) Re: Implementation? on Addr Conf Section 5.5.3 Prefix Info - d) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, It seems like we could fix this problem by changing the para- graph below such that the timer updates would only apply to addresses which were configured based using stateless address autoconfiguration. Any other addresses (manually configured, statefully autoconfigured, or devinely configured :-)) would not be subject to the timeouts intervals in the RA. It also seems reasonable to log an warning message when the valid lifetime and the lease time of addresses using the same prefix are not in sync. > > On 5.5.3 Page 20 it states: > > > d) If the advertised prefix matches the prefix of an autoconfigured > address (i.e., obtained via stateless or stateful address > autoconfiguration) in the list of addresses associated with the > interface, set the preferred timer to that of the option's preferred > lifetime, and set the valid lifetime to that of the option's valid > lifetime. > ------------------------------------------------------------------------------ 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 Jan 29 04:52:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20680; Mon, 29 Jan 96 04:52:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20674; Mon, 29 Jan 96 04:52:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26618; Mon, 29 Jan 1996 04:51:21 -0800 Received: from POSTAL.CSELT.STET.IT by mercury.Sun.COM (Sun.COM) id EAA05134; Mon, 29 Jan 1996 04:51:14 -0800 Received: from [163.162.3.79] (apl0546.cselt.stet.it) by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01I0L29PG6M8004QMH@POSTAL.CSELT.STET.IT>; Mon, 29 Jan 1996 13:49:46 MET Date: Mon, 29 Jan 1996 15:02:28 +0100 From: Marco.Bernardi@cselt.stet.it (Marco Bernardi) Subject: (IPng 1290) X.121 and E.164 address To: ipng@sunroof.eng.sun.com Message-Id: X-Envelope-To: ipng@sunroof.Eng.Sun.Com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT X-Sender: Bernardi_EUD@POSTAL.CSELT.STET.IT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the Stockolm meeting (july 95) a request coming from SG7 to reserve a specific Format Prefix value to support X.121 Public Data Network Numbering Plan in the IPv6 address was presented. In the following (winter 95) , as far as I know, a request related to E.164 numbering was prepared by SG2. I'd like to know the "IPng feeling" on the possibility of having Format Prefixes reserved to X.121 and E.164. In particular I think the E.164 case may be particular important keeping in mind that the E.164 is one the addresses used to identify the ATM UNI interface. Thank you bye ------------------------------------------------------------------------------ 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 Jan 29 05:11:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20697; Mon, 29 Jan 96 05:11:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20691; Mon, 29 Jan 96 05:11:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27190; Mon, 29 Jan 1996 05:10:38 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id FAA07127; Mon, 29 Jan 1996 05:10:38 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id IAA06773; Mon, 29 Jan 1996 08:10:08 -0500 (EST) Date: Mon, 29 Jan 1996 08:10:08 -0500 (EST) From: Scott Bradner Message-Id: <199601291310.IAA06773@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, Marco.Bernardi@cselt.stet.it Subject: (IPng 1291) Re: X.121 and E.164 address Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marco, As ISOC VP for standards I did receive the request for X.121 code points, in which it said that a request for E.164 code points would follow soon but I never received the E.164 request. Bob Hinden and I have talked about this a number of times. Most reciently just after the basic IPv6 documents were finally finished up and published as RFCs. I expect that a proposal on how to deal with both X.121 and E.164 addresses in IPv6 will be ready soon for your review. 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 Mon Jan 29 09:25:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20759; Mon, 29 Jan 96 09:25:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20753; Mon, 29 Jan 96 09:24:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21337; Mon, 29 Jan 1996 09:24:07 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA29385; Mon, 29 Jan 1996 09:24:07 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA11454; Mon, 29 Jan 1996 09:24:07 -0800 Date: Mon, 29 Jan 1996 09:24:07 -0800 From: Ran Atkinson Message-Id: <199601291724.JAA11454@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1292) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: <9601281910.AA37214@hawpub1.watson.ibm.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't agree with the levying of these new requirements on all hosts/routers. Choice of implementation or not should be left to implementers. I note that a paper presented at USENIX last week showed that it is entirely possible to implement mobility without changing the IP implementation in nodes that aren't themselves moving. 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 Mon Jan 29 09:34:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20778; Mon, 29 Jan 96 09:34:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20772; Mon, 29 Jan 96 09:34:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23136; Mon, 29 Jan 1996 09:33:50 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA02899; Mon, 29 Jan 1996 09:33:45 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA11974; Mon, 29 Jan 1996 09:32:11 -0800 Date: Mon, 29 Jan 1996 09:32:11 -0800 From: Ran Atkinson Message-Id: <199601291732.JAA11974@puli.cisco.com> To: Marco.Bernardi@cselt.stet.it Subject: (IPng 1293) Re: X.121 and E.164 address Newsgroups: cisco.external.ietf.ipng In-Reply-To: Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article Marco Bernardi wrote: >In the Stockolm meeting (july 95) a request coming from SG7 to reserve a >specific Format Prefix value to support X.121 Public Data Network >Numbering Plan in the IPv6 address was presented. In the following (winter >95) , as far as I know, a request related to E.164 numbering was prepared >by SG2. >I'd like to know the "IPng feeling" on the possibility of having Format >Prefixes reserved to X.121 and E.164. In particular I think the E.164 case >may be particular important keeping in mind that the E.164 is one the >addresses used to identify the ATM UNI interface. The routable ATM address of the ATM UNI interface is orthogonal to the IP address associated with that interface, so I don't see why this matters. I consider it generally undesirable to embed routable lower-layer addresses within routable IP-layer addresses. It violates layering in a severe way. Also, this can lead to weird hard-to-diagnose routing/connectivity problems in operational networks. There are good reasons to use Neighbor Discovery or NHRP or whatever to map between IP addresses and lower-layer addresses INSTEAD OF embedding the routable lower layer address into the routable IP-layer address. Alternately put, could you please explain what technical problem SG7 thinks it is trying to solve ?? 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 Mon Jan 29 09:56:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20858; Mon, 29 Jan 96 09:56:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20847; Mon, 29 Jan 96 09:56:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27290; Mon, 29 Jan 1996 09:55:31 -0800 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id JAA10934; Mon, 29 Jan 1996 09:55:27 -0800 Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id SAA20129; Mon, 29 Jan 1996 18:56:17 +0100 Received: from nestvx.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id SAA03855; Mon, 29 Jan 1996 18:56:13 +0100 Message-Id: <199601291756.SAA03855@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Mon, 29 Jan 96 18:56:16 MET Date: Mon, 29 Jan 96 18:56:16 MET From: Markus Jork To: "ip-atm@matmos.hpl.hp.com"@vbormc.vbo.dec.com, "ipng@sunroof.eng.sun.com"@vbormc.vbo.dec.com Cc: jork@nestvx.enet.dec.com Apparently-To: ipng@sunroof.eng.Sun.COM, ip-atm@matmos.hpl.hp.com Subject: (IPng 1294) Re: IPv6 over NBMA Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Scott and Jim that we can't solve this issue in just a few days on the mailing list. Hopefully, there will be enough time for a discussion in Los Angeles. This topic should get a well-known place on the agenda of some wg, at a time when ipng, rolc and ipatm folks can attend. Or maybe a separate session just for this. But please: earlier than 9:45pm and more than 15 minutes (that's about the time we had in Dallas). Anyway, this shouldn't keep us from identifying the issues and starting to discuss things? Back to Joel Halpern's concern: [It's good you bring this up a second time. I almost forgot about your first mail because I've been away from my office for a few days.] > Unfortunately, what it requires instead is a fully configured > hierarchy of servers covering the entire ATM fabric. Given taht in > this proposal the servers are NOT running routing, there is > complexity required to maintain the heirarchy. With a heriarchy of > routers, the routers maintain the hierarchy themselves. In this regard, I don't see much of a difference to all existing or proposed IPv4 mechanisms. Basing the comparison on an ideal future NHRP-only IPv4 scenario, where all the NHRP servers have to be co-located with a router: you could do just the same with the ND servers proposed in Peter's draft. Start an ND server on each router. They will find each other automagically. I'm not saying this is necessarily a good idea, because it would increase the load on a single point: the router. In fact, I think we can even do better: > In fact, > there are even proposals to allow the automatic formation of such a > heirarchy. (No, said proposals are not fully fleshed out. They need > work. But the nature of routing gives one hope that it can be done.) Peter's draft contains a rather fleshy proposal for the automatic formation of the ND server hierarchy (using UNI 4.0 signalling). This includes automatic load sharing and error recovery. > In addition, in the absence of a set of routers, there is nothing to > serve as the default forwarding path. One of the relevant IPv4 > observations is also important here. ~You do not want to set up a VC > for a DNS query~. Therefore, there must be a connected heirarchy of > routers, so that packets can be default, connectionless, forwarded. It depends on your applications. My guess is that in most cases, there won't be a need for such a "connectionless" forwarding path. But it's probably not worth arguing about that. The point is, I consider it a feature of Peter's draft that you don't have to put a router inside your ATM network when it's not necessary. You could even run a large ATM network subdivided into multiple logical links without the need for routers inbetween. People spend lots of money for the ATM equipment. Why do you want to force them to fork out even more for a couple of routers that just route from ATM to ATM? Just to avoid misunderstandings for people who haven't read the draft so far: of course there's nothing in there that prevents you from installing routers inside the ATM network. There's just the option not to do so even for large ATM networks. > Given that the routing heirarchy must exist, must be stable, and can > handle the query problem, why in heavens name would I want to invent > anything else? I think I answered part of this question in this mail and the other, more important part, has already been addressed in the discussion so far (there is much more to ND than just address resolution). Markus ------------------------------------------------------------------------------ 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 Jan 29 10:21:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20935; Mon, 29 Jan 96 10:21:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20929; Mon, 29 Jan 96 10:21:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02751; Mon, 29 Jan 1996 10:20:40 -0800 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id KAA20302; Mon, 29 Jan 1996 10:20:34 -0800 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8415; Mon, 29 Jan 96 13:20:13 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 0874; Mon, 29 Jan 1996 13:20:13 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Mon, 29 Jan 96 13:20:12 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA20425; Mon, 29 Jan 1996 13:19:56 -0500 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9601291819.AA20425@hawpub1.watson.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1295) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: (Your message of Mon, 29 Jan 96 09:24:07 PST.) <199601291724.JAA11454@puli.cisco.com> Date: Mon, 29 Jan 96 13:19:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't agree with the levying of these new requirements on all > hosts/routers. Choice of implementation or not should be left > to implementers. Can you be more specific about which new requirements should be relaxed? I am more than willing to discover better approaches that will simplify implementation and eliminate requirements on router operation. > I note that a paper presented at USENIX last week showed that it is > entirely possible to implement mobility without changing the IP > implementation in nodes that aren't themselves moving. The IPv4 mobility specification proves that it is quite possible to implement mobility without changing the IP implementation in nodes that aren't themselves moving. The price, however, is a long list of evil effects that are outlined in the IPv6 mobility specification and have motivated the development of a set of Route Optimization techniques for IPv4, which cannot work with unmodified IPv4 correspondent hosts. The situation with IPv4 is sufficiently bad that we thought it was imperative to make things work better in IPv6. Can someone give me a pointer to the appropriate paper from UseNIX? I'll be happy to incorporate any techniques which are applicable to IPv6 mobility. > Ran > rja@cisco.com Thanks, Charlie 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 Jan 29 10:26:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20958; Mon, 29 Jan 96 10:26:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20952; Mon, 29 Jan 96 10:26:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03888; Mon, 29 Jan 1996 10:25:37 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id KAA21883; Mon, 29 Jan 1996 10:25:27 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA15589; Mon, 29 Jan 1996 13:16:31 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18306; Mon, 29 Jan 1996 13:16:29 -0500 Message-Id: <9601291816.AA18306@fwasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 1296) Re: Implementation? on Addr Conf Section 5.5.3 Prefix Info - d) In-Reply-To: Your message of "Sun, 28 Jan 96 14:18:20 PST." <9601282218.AA01066@feller.mentat.com> Date: Mon, 29 Jan 96 13:16:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, > It seems like we could fix this problem by changing the para- >graph below such that the timer updates would only apply to addresses >which were configured based using stateless address autoconfiguration. > >Any other addresses (manually configured, statefully autoconfigured, >or devinely configured :-)) would not be subject to the timeouts >intervals in the RA. > >It also seems reasonable to log an warning message when the valid >lifetime and the lease time of addresses using the same prefix are not >in sync. That would fix it for me. And Yes I think a warning message should be issued and logging it to the sys log file for addrconf. /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 Jan 29 10:43:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21022; Mon, 29 Jan 96 10:43:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21016; Mon, 29 Jan 96 10:43:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07192; Mon, 29 Jan 1996 10:42:47 -0800 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id KAA04426; Mon, 29 Jan 1996 10:42:46 -0800 From: bound@zk3.dec.com Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id TAA22655; Mon, 29 Jan 1996 19:43:27 +0100 Received: from fwasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id TAA08045; Mon, 29 Jan 1996 19:43:20 +0100 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21131; Mon, 29 Jan 1996 13:42:02 -0500 Message-Id: <9601291842.AA21131@fwasted.zk3.dec.com> To: Markus Jork Cc: "ip-atm@matmos.hpl.hp.com"@vbormc.vbo.dec.com, "ipng@sunroof.eng.sun.com"@vbormc.vbo.dec.com Subject: (IPng 1297) Re: IPv6 over NBMA In-Reply-To: Your message of "Mon, 29 Jan 96 18:56:16 +0700." <199601291756.SAA03855@vbormc.vbo.dec.com> Date: Mon, 29 Jan 96 13:41:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think it would be good to: 1. Identify the requirements for IPv6 over ATM 2. Differences and issues for NHRP vs Schulter-ND-ATM 3. Assmuptions about that market and what is needed I think we should be able to do this in a bi-partisian manner? /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 Jan 29 14:18:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21301; Mon, 29 Jan 96 14:18:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21295; Mon, 29 Jan 96 14:18:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16072; Mon, 29 Jan 1996 14:17:41 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id OAA11089; Mon, 29 Jan 1996 14:17:40 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA21592; Mon, 29 Jan 1996 17:13:42 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22421; Mon, 29 Jan 1996 17:13:40 -0500 Message-Id: <9601292213.AA22421@fwasted.zk3.dec.com> To: perk@watson.ibm.com (Charlie Perkins) Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 1298) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Mon, 29 Jan 96 13:19:56 EST." <9601291819.AA20425@hawpub1.watson.ibm.com> Date: Mon, 29 Jan 96 17:13:40 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I note that a paper presented at USENIX last week showed that it is >> entirely possible to implement mobility without changing the IP >> implementation in nodes that aren't themselves moving. >The IPv4 mobility specification proves that it is quite possible to >implement mobility without changing the IP implementation in nodes >that aren't themselves moving. The price, however, is a long list >of evil effects that are outlined in the IPv6 mobility specification >and have motivated the development of a set of Route Optimization >techniques for IPv4, which cannot work with unmodified IPv4 correspondent >hosts. The situation with IPv4 is sufficiently bad that we thought it >was imperative to make things work better in IPv6. As some input. I went off awhile ago and did an engineering trade-off design where to make the changes to provide the longest term benefit to mobile on a UNIX Host implementation based on the different modes available from IPv4 spec. After much study I decided that its best to bite the bullet and make the kernel "mobile enabled". So I too believe in the evil affects as outlined in IPv6 mobile spec. So I lean towards making the changes as outlined in IPv6 mobile. /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 Jan 29 15:34:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21362; Mon, 29 Jan 96 15:34:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21356; Mon, 29 Jan 96 15:34:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00900; Mon, 29 Jan 1996 15:33:47 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id PAA03292; Mon, 29 Jan 1996 15:33:48 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA12090; Mon, 29 Jan 1996 15:30:43 -0800 Date: Mon, 29 Jan 1996 15:30:43 -0800 From: Ran Atkinson Message-Id: <199601292330.PAA12090@puli.cisco.com> To: ipng@sunroof.eng.sun.com, rolc@nexen.com, ipatm@matmos.hpl.hp.com Subject: (IPng 1299) Re: IPv6 over NBMA In-Reply-To: <9601291842.AA21131@fwasted.zk3.dec.com> References: <199601291756.SAA03855@vbormc.vbo.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601291842.AA21131@fwasted.zk3.dec.com> you write: >I think it would be good to: > > 1. Identify the requirements for IPv6 over ATM I believe that we should be solving the general IPv6/NBMA problem with a single mechanism rather than having a specification that is unique to IPv6/ATM. I believe that use of NHRP to determine lower-layer addresses of NBMA neighbors permits such a general solution. NHRP is being worked on within ROLC. Consequently, I also think that ROLC folks might have some interest in this matter. I suspect this difference in perspective (IPv6/NBMA or IPv6/ATM) might be fundamental and that the other items listed in the previous note might well fall out naturally once this first question is resolved. 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 Mon Jan 29 17:10:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21476; Mon, 29 Jan 96 17:10:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21470; Mon, 29 Jan 96 17:10:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16627; Mon, 29 Jan 1996 17:09:37 -0800 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id RAA28418; Mon, 29 Jan 1996 17:09:34 -0800 From: schulter@zk3.dec.com Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id CAA07784; Tue, 30 Jan 1996 02:10:20 +0100 Received: from dogfish.zk3.dec.com (dogfish.zk3.dec.com [16.140.64.172]) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id CAA02919; Tue, 30 Jan 1996 02:10:17 +0100 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA16762; Mon, 29 Jan 1996 20:09:58 -0500 Message-Id: <9601300109.AA16762@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: bound@zk3.dec.com Cc: Markus Jork , "ip-atm@matmos.hpl.hp.com"@vbormc.vbo.dec.com, "ipng@sunroof.eng.sun.com"@vbormc.vbo.dec.com Subject: (IPng 1300) Re: IPv6 over NBMA In-Reply-To: Your message of "Mon, 29 Jan 96 13:41:59 EST." <9601291842.AA21131@fwasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jan 96 20:09:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Jan 96 13:41:59 EST Jim Bound Wrote: > I think it would be good to: > > 1. Identify the requirements for IPv6 over ATM Yes. > 2. Differences and issues for NHRP vs Schulter-ND-ATM and Grenville's draft-ietf-ipatm-ipv6nd-00.txt. > 3. Assmuptions about that market and what is needed I'm not sure we want to get down this hole, especially where ATM is involved ;-) I would prefer to focus on technical issues and requirements for now. > I think we should be able to do this in a bi-partisian manner? I would certainly hope so. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 29 17:50:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21564; Mon, 29 Jan 96 17:50:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21558; Mon, 29 Jan 96 17:50:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21465; Mon, 29 Jan 1996 17:49:50 -0800 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id RAA07948; Mon, 29 Jan 1996 17:49:48 -0800 From: schulter@zk3.dec.com Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id CAA08890; Tue, 30 Jan 1996 02:50:32 +0100 Received: from dogfish.zk3.dec.com (dogfish.zk3.dec.com [16.140.64.172]) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id CAA04769; Tue, 30 Jan 1996 02:50:28 +0100 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA17327; Mon, 29 Jan 1996 20:50:12 -0500 Message-Id: <9601300150.AA17327@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Markus Jork Cc: "ip-atm@matmos.hpl.hp.com"@vbormc.vbo.dec.com, "ipng@sunroof.eng.sun.com"@vbormc.vbo.dec.com Subject: (IPng 1301) Re: IPv6 over NBMA In-Reply-To: Your message of "Mon, 29 Jan 96 18:56:16 +0700." <199601291756.SAA03855@vbormc.vbo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jan 96 20:50:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just thought I would chime back in since I'm back from USENIX and catching up on things. Markus wrote: > I agree with Scott and Jim that we can't solve this issue in just a few days > on the mailing list. Hopefully, there will be enough time for a discussion > in Los Angeles. This topic should get a well-known place on the agenda of > some wg, at a time when ipng, rolc and ipatm folks can attend. Or maybe a > separate session just for this. But please: earlier than 9:45pm and more than > 15 minutes (that's about the time we had in Dallas). Yes. I think there has been enough discussion here and on the IPv6 mailing list to show that there's sufficient interest to justify spending a significant part of one session on IPv6 over ATM issues. > Anyway, this shouldn't keep us from identifying the issues and starting > to discuss things? Nope, we should be trying to come up with a list of issues to discuss. Good idea. > Back to Joel Halpern's concern: > > [It's good you bring this up a second time. I almost forgot about your first > mail because I've been away from my office for a few days.] > >> Unfortunately, what it requires instead is a fully configured >> hierarchy of servers covering the entire ATM fabric. Given taht in >> this proposal the servers are NOT running routing, there is >> complexity required to maintain the heirarchy. With a heriarchy of >> routers, the routers maintain the hierarchy themselves. And here's my response to Joel's concerns: First, lets take a look at my proposal, and my very brief presentation at Dallas. First, there is the hierarchy of NDS servers that form the Logical Link. These servers really do nothing more than provide a way for nodes to multicast. At his level (simply the subnet level), they are not involved in routing and are used to move ND packets between nodes. In fact, in the latest version of the draft which I'm working on I've got this entirely stateless, which means it's very easy to implement. These servers are not running any protocol, routing or otherwise, they just relay packets to make those parts of ND which require multicasting work. This completely maintains the ND and subnet semantics. There is also no need for address resolution servers or server synchronization since it is always the solicited node which replies to each solicitation. Further, when routers are introduced to the LL, they will function just as the do for IPv6 over legacy LANs and can use redirects where necessary. Finally, router discovery and address autoconfig continue to work with no changes to IPv6 and no requirements for any new protocol over ATM to perform these functions. Thus, 100% of ND is used without the introduction of any new protocols for ATM or any changes to IPv6 ND semantics. The second part is linking the Logical Links together to form a larger hierarchy through which prefix information is "leaked". The NDS servers outside the LL do not have a routing protocol, or any protocol. They simply relay packets. There is some optimization here to reduce the amount of traffic on the hierarchy, but the NDS servers never do anything other than relay ND packets. The entire hierarchy just defines a logical group of nodes which are permitted to directly communicate over ATM while still maintaining IPv6 addressing semantics and administrative grouping of nodes. There is really little complexity required to maintain the hierarchy other than establishing the logical boundaries of the LL, and Site (to provide proper scoping of the IPv6 addresses). >> ~You do not want to set up a VC >> for a DNS query~. Therefore, there must be a connected heirarchy of >> routers, so that packets can be default, connectionless, forwarded. Ok, but this hierarchy provides that by allowing us to define which packets are sent via the NDS tree. This is done by filtering packets to specific addresses to the node's connection to the tree. Thus, we can establish any connectionless forwarding policy we want. And back to Markus' comments: > Just to avoid misunderstandings for people who haven't read the draft so far: > of course there's nothing in there that prevents you from installing routers > inside the ATM network. There's just the option not to do so even for large > ATM networks. Exactly, and this is pointed out in the I-D and in my presentation at Dallas. Linking LLs together is one option, using routers is another. The point is ND is 100% maintained. The full hierarchy extension is an enhancement to allow more efficient uses of ATM resources without having to use or introduce any non-ND protocols to do so. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ 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 Jan 29 23:03:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21676; Mon, 29 Jan 96 23:03:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21670; Mon, 29 Jan 96 23:03:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10522; Mon, 29 Jan 1996 23:02:49 -0800 Received: from tera.csl.sony.co.jp by mercury.Sun.COM (Sun.COM) id XAA17307; Mon, 29 Jan 1996 23:02:31 -0800 Received: (from tera@localhost) by tera.csl.sony.co.jp (8.6.12+2.4W/3.3W3) id QAA08319; Tue, 30 Jan 1996 16:01:51 +0900 Message-Id: <199601300702.QAA08319@tera.csl.sony.co.jp> To: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 1302) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Sun, 28 Jan 96 12:31:06 EST." <9601281731.AA37522@hawpub1.watson.ibm.com> Date: Tue, 30 Jan 96 16:01:51 +0900 From: TERAOKA Fumio Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have submitted draft-ietf-mobileip-ipv6-00.txt, > "Mobility Support in IPv6" Enclosed are some comparisons between Charlie's proposal and mine (draft-teraoka-ipv6-mobility-sup-02.txt). The concept of both proposals are almost similar. In other words, the concept of Charlie's proposal is getting close to that of my proposal. In Charlie's proposal, FA no longer exists. COA of a MN specifies the current address of the MN, not the end point of tunnel. In my proposal, `ID' can also be called home address, and `address' can also be called temporary address or COA. The temporary address is used only for routing. The ID is used only for identifying a node. However, as shown in Table-3, Charlie's proposal has some problems with source address spoof filtering and multicast packet transmission. Table-4 shows the header of a packet sent by a MN to a mobile CN. In case of Charlie's proposal, SrcAddr does not specify the current point of attachment to the internet while DstAddr does. This inconsistency causes the problems with source address spoof filtering and multicast packet transmission. Teraoka (SonyCSL) ========================================================================== +-----------------------+-----------------------+ |draft-ietf-mobileip- |draft-teraoka-ipv6- | |ipv6-00 |mobility-sub-02 | +---------------+-----------------------+-----------------------+ |address |home address & |ID (home address) & | | |care-of address |Address (temp address) | +---------------+-----------------------+-----------------------+ |home agent |necessary |necessary | +---------------+-----------------------+-----------------------+ |route optim |possible |possible | +---------------+-----------------------+-----------------------+ |cache update |Binding Update Option |SrcID Option (dst opt) | | |(dst option) |& SrcAddr in basic hdr | +---------------+-----------------------+-----------------------+ |registration |Binding Update Option |Register Req/Ack Opt | |with HA |(dst option) |(dst option) | +---------------+-----------------------+-----------------------+ +---------------+-----------------------+-----------------------+ |CN without |encapsulated by HA |HA inserts DstID Opt | |cache | |(encaps also possible) | +---------------+-----------------------+-----------------------+ |CN with |COA in basic hdr |temp addr in basic hdr | |cache |home addr in route hdr |home addr in DstID opt | +---------------+-----------------------+-----------------------+ +---------------+-----------------------+-----------------------+ |SrcAddr field |home address |address (temp address) | +---------------+-----------------------+-----------------------+ |SrcID opt | --- |ID (home address) | +---------------+-----------------------+-----------------------+ |Binding opt |care-of address | --- | +---------------+-----------------------+-----------------------+ |auth hdr |guarantees home addr & |guarantees ID & addr | | |care-of address |(home addr & temp addr)| +---------------+-----------------------+-----------------------+ |src addr |might dicard packet |no problem | |spoofing filter|sent by NM | | +---------------+-----------------------+-----------------------+ |m-cast send |using COA as SrcAddr or|same as normal node | | |via home agent |(temp addr in SrcAddr) | +---------------+-----------------------+-----------------------+ |m-cast receive |join locally or |same as normal node | | |via home agent | | +---------------+-----------------------+-----------------------+ +-----------------------+-----------------------------+ |SrcAddr: MN's home addr|SrcAddr: MN's temp addr | |DstAddr: CN's COA |DstAddr: CN's temp addr | |RoutHdr: CN's home addr|SrcIdOpt: MN's home addr (ID)| |BindOpt: MN's COA |DstIdOpt: CN's home addr (ID)| +-----------------------+-----------------------------+ ------------------------------------------------------------------------------ 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 Jan 30 02:30:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21736; Tue, 30 Jan 96 02:30:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21730; Tue, 30 Jan 96 02:30:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20535; Tue, 30 Jan 1996 02:29:50 -0800 Received: from POSTAL.CSELT.STET.IT by mercury.Sun.COM (Sun.COM) id CAA13291; Tue, 30 Jan 1996 02:29:34 -0800 Received: from [163.162.3.79] (apl0546.cselt.stet.it) by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01I0MBMFX0Q8004WSF@POSTAL.CSELT.STET.IT>; Tue, 30 Jan 1996 11:28:49 MET Date: Tue, 30 Jan 1996 12:41:32 +0100 From: Marco.Bernardi@cselt.stet.it (Marco Bernardi) To: ipng@sunroof.eng.sun.com Message-Id: X-Envelope-To: ipng@sunroof.Eng.Sun.Com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT X-Sender: Bernardi_EUD@POSTAL.CSELT.STET.IT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Answering my E-mail asking comments on the defintion of a Format Prefix value reserved to support X.121 and E.164 address in the IPv6 Ran Atkinson wrote: >The routable ATM address of the ATM UNI interface is orthogonal to the IP >address associated with that interface, so I don't see why this matters. > >I consider it generally undesirable to embed routable lower-layer addresses >within routable IP-layer addresses. It violates layering in a severe way. >Also, this can lead to weird hard-to-diagnose routing/connectivity problems >in operational networks. There are good reasons to use Neighbor Discovery >or NHRP or whatever to map between IP addresses and lower-layer addresses >INSTEAD OF embedding the routable lower layer address into the routable >IP-layer address. > >Alternately put, could you please explain what technical problem SG7 thinks >it is trying to solve ?? I have a couple comments: 1) IP address and ATM address are orthogonal As far as I know in RFC 1884 "IPversion 6 addressing arcitecture" there is Prefix Format value reserved for NSAP and there is also an Internet Draft " OSI NSAP and IPv6" (expected to be published as an Experimental RFC) written by Brian Carpenter describing the support of NSAP in IPv6 Keeping in mind that, according to the ATM Forum, the Public UNI and the Private UNI ATM are identified by the AESA (the AESA is a kind of NSAP) it seems to me that IPV6 address can already support the address to identify an ATM interface 2) Embedding lower-layer address within IP-layer address is a bad practice In the Internet Draft "An IPv6 Provider based unicast address format" in the section describing the Intra Subscriber Part the authors recommend to use the 48 bit IEEE 802 MAC address in the Interface ID field. This seems to me a way to embed a lower layer address (a link address) within a IP-layer address. 3) Why X.121 and E.164? I agree with Alan Lloyd that without some notion of E.164 mapping we have a Intenet protocol that does not overlay well switched network using X.121 and E.164 numbering plans. (Alan thank you for your "moral support"). Last point. Someone mentioned possibile problems related to mobile IP in using IPv6 address based on E.164 number . Could you please discuss a little more this point. bye, Marco ------------------------------------------------------------------------------ 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 Jan 30 03:57:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21829; Tue, 30 Jan 96 03:57:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21823; Tue, 30 Jan 96 03:56:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23568; Tue, 30 Jan 1996 03:56:04 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id DAA20322; Tue, 30 Jan 1996 03:56:03 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id NAA24651; Tue, 30 Jan 1996 13:53:14 +0200 Date: Tue, 30 Jan 1996 13:53:14 +0200 Message-Id: <199601301153.NAA24651@lohi.dat.tele.fi> From: Juha Heinanen To: Marco.Bernardi@cselt.stet.it Cc: ipng@sunroof.eng.sun.com In-Reply-To: (Marco.Bernardi@cselt.stet.it) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As far as I know in RFC 1884 "IPversion 6 addressing arcitecture" there is Prefix Format value reserved for NSAP and there is also an Internet Draft " OSI NSAP and IPv6" (expected to be published as an Experimental RFC) written by Brian Carpenter describing the support of NSAP in IPv6 Keeping in mind that, according to the ATM Forum, the Public UNI and the Private UNI ATM are identified by the AESA (the AESA is a kind of NSAP) it seems to me that IPV6 address can already support the address to identify an ATM interface i'm suprised that brians frc would be experimental, since if someone really starts to use this rfc in big scale, would it mean that suddenly all his/her addresses may become invalid, if ietf decides that the rfc was not such a good idea. it would be the same as to publich the unicast addressa allocation spec as an experimental rfc. -- juha ------------------------------------------------------------------------------ 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 Jan 30 04:14:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21841; Tue, 30 Jan 96 04:14:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21835; Tue, 30 Jan 96 04:14:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24365; Tue, 30 Jan 1996 04:13:45 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id EAA22593; Tue, 30 Jan 1996 04:13:45 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id HAA10309; Tue, 30 Jan 1996 07:13:11 -0500 (EST) Date: Tue, 30 Jan 1996 07:13:11 -0500 (EST) From: Scott Bradner Message-Id: <199601301213.HAA10309@newdev.harvard.edu> To: jh@lohi.dat.tele.fi, Marco.Bernardi@cselt.stet.it Subject: (IPng 1303) Brian's RFC Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha, If the people who want to make use of this proposal (i.e. people like you) find that the RFC was a "good idea" then there is no reason not to mover it from Experimental to Proposed after some experience. It was set as an Experimental RFC because the people within the IETF did not have enough experience or knowledge in the field to be able to be sure that it was a "good idea", nor could we be sure as to the level of usefulness and deployment. 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 Tue Jan 30 04:45:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21869; Tue, 30 Jan 96 04:45:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21863; Tue, 30 Jan 96 04:45:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25763; Tue, 30 Jan 1996 04:44:41 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id EAA25510; Tue, 30 Jan 1996 04:44:39 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA04535; Tue, 30 Jan 1996 13:44:30 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA13871; Tue, 30 Jan 1996 13:44:28 +0100 Message-Id: <9601301244.AA13871@dxcoms.cern.ch> Subject: (IPng 1304) Re: Brian's RFC To: sob@newdev.harvard.edu (Scott Bradner) Date: Tue, 30 Jan 1996 13:44:28 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: jh@lohi.dat.tele.fi, Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <199601301213.HAA10309@newdev.harvard.edu> from "Scott Bradner" at Jan 30, 96 07:13:11 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha, The actual reason it was forwarded as "Experimental" is because of doubts whether the NSAP address formats will be globally routable in an IPv6 Internet. As long as these doubts exist, it is hard to think of it going onto the main standards track. (For those who may have forgotten, the document we are discussing is draft-ietf-ipngwg-nsap-ipv6-00.txt, currently in the RFC Editor queue.) Brian Carpenter >--------- Text sent by Scott Bradner follows: > > > Juha, > If the people who want to make use of this proposal > (i.e. people like you) find that the RFC was a "good idea" then there is no > reason not to mover it from Experimental to Proposed after some experience. > > It was set as an Experimental RFC because the people within > the IETF did not have enough experience or knowledge in the field to > be able to be sure that it was a "good idea", nor could we be > sure as to the level of usefulness and deployment. > > 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 > ------------------------------------------------------------------------------ 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 Jan 30 06:45:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21921; Tue, 30 Jan 96 06:45:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21915; Tue, 30 Jan 96 06:44:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02423; Tue, 30 Jan 1996 06:44:06 -0800 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id GAA12133; Tue, 30 Jan 1996 06:44:04 -0800 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5203; Tue, 30 Jan 96 09:43:47 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 0950; Tue, 30 Jan 1996 09:43:47 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Tue, 30 Jan 96 09:43:46 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA56977; Tue, 30 Jan 1996 09:43:30 -0500 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9601301443.AA56977@hawpub1.watson.ibm.com> To: mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com Subject: (IPng 1305) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: (Your message of Tue, 30 Jan 96 16:01:51 V.) <199601300702.QAA08319@tera.csl.sony.co.jp> Date: Tue, 30 Jan 96 09:43:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In draft-teraoka-ipv6-mobility-sup-02.txt, there is a proposal for a Source Address option. If it would work, it would be handy to allow mobile nodes to get packets past firewalls. It would also be handy for multicast transmission, as Teraoka points out. This proposal is not terribly new. If the IPv6 working group decides that it is a workable proposal, I would be happy to incorporate that option into my Internet Draft. However, it seems unlikely to me that such an approach can be relied on. If a Source Address option were used, I don't see what value could be placed on source address filtering by firewalls. In other words, the firewalls wouldn't be protecting against anything. Dave and I decided that it wouldn't be realistic to propose such an option as a solution to the firewall problem, because then firewalls would just start filtering out packets that contained Source Address Options. If there is a policy statement by the IPv6 working group in favor of Source Address options, then we will happily use them. If people agree that it's a strategy doomed to failure, then Teraoka's analysis is no longer valid. > Enclosed are some comparisons between Charlie's proposal and > mine (draft-teraoka-ipv6-mobility-sup-02.txt). The concept of > both proposals are almost similar. That's true enough. In fact, I thought your recent draft was a terrific improvement over draft-teraoka-ipv6-mobility-sup-01.txt > In other words, the concept > of Charlie's proposal is getting close to that of my proposal. In the first place, it's a proposal developed jointly by me and Dave Johnson. In the second place, we've been trying to incorporate suggestions from working group members over the last 15 months. In the third place, I am not really sure where to place this comment in the overall scheme of constructive conversation. > In Charlie's proposal, FA no longer exists. COA of a MN specifies > the current address of the MN, not the end point of tunnel. After going over the various scenarios dozens of times, it seemed to me that the foreign agent function only had usefulness in certain specialized situations, and then mainly because with a foreign agent there is need to send fewer bits over a possibly bandwith constrained medium. Allowing IPv6 routers to work (in the usual case) without having any knowledge whether the mobile node is a mobile node or not is a big win, I think. Also, the technique of automatic address autoconfiguration is very powerful and contributes to this elegant simplification. Too bad we couldn't rely on such techniques for IPv4. > ..... Analysis depending on Source Address Option deleted here ...... I can try to respond in more detail to the deleted analysis if there is demand and after I put out a raging fire in my work schedule. However, before doing so I would greatly appreciate it if people in the working group could discuss (and with luck even decide) about the viability of using such a Source Address option. Regards, Charlie 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 Tue Jan 30 07:25:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21942; Tue, 30 Jan 96 07:25:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21936; Tue, 30 Jan 96 07:25:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05970; Tue, 30 Jan 1996 07:24:22 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id HAA21182; Tue, 30 Jan 1996 07:24:21 -0800 Received: from munin.fnal.gov ("port 1653"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I0M7A5BEPK000K8U@FNAL.FNAL.GOV>; Tue, 30 Jan 1996 09:24:20 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA27679; Tue, 30 Jan 1996 09:24:17 -0600 (CST) Date: Tue, 30 Jan 1996 09:24:16 -0600 From: Matt Crawford In-Reply-To: "30 Jan 96 12:41:32 +0100." <"v01510100ad33a95823b9"@[163.162.3.79]> To: Marco.Bernardi@cselt.stet.it (Marco Bernardi) Cc: ipng@sunroof.eng.sun.com Message-Id: <9601301524.AA27679@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) Embedding lower-layer address within IP-layer address is a bad practice > > ... the authors recommend to use the 48 bit IEEE 802 MAC address in the > Interface ID field. This seems to me a way to embed a lower layer address > (a link address) within a IP-layer address. You distorted Ran's words just a bit, and he was speaking very precisely. He said, "a ROUTABLE lower-layer address." _________________________________________________________ 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 Tue Jan 30 07:41:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21957; Tue, 30 Jan 96 07:41:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21951; Tue, 30 Jan 96 07:40:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07582; Tue, 30 Jan 1996 07:40:10 -0800 Received: from POSTAL.CSELT.STET.IT by mercury.Sun.COM (Sun.COM) id HAA25105; Tue, 30 Jan 1996 07:39:58 -0800 Received: from [163.162.3.79] (apl0546.cselt.stet.it) by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01I0MMH7MRF4004ZN1@POSTAL.CSELT.STET.IT>; Tue, 30 Jan 1996 16:39:11 MET Date: Tue, 30 Jan 1996 17:51:54 +0100 From: Marco.Bernardi@cselt.stet.it (Marco Bernardi) Subject: (IPng 1306) RE: X.121 and E.164 address To: ipng@sunroof.eng.sun.com Message-Id: X-Envelope-To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT X-Sender: Bernardi_EUD@POSTAL.CSELT.STET.IT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Answering my E-mail asking comments on the defintion of a Format Prefix value reserved to support X.121 and E.164 address in the IPv6 Ran Atkinson wrote: >The routable ATM address of the ATM UNI interface is orthogonal to the IP >address associated with that interface, so I don't see why this matters. > >I consider it generally undesirable to embed routable lower-layer addresses >within routable IP-layer addresses. It violates layering in a severe way. >Also, this can lead to weird hard-to-diagnose routing/connectivity problems >in operational networks. There are good reasons to use Neighbor Discovery >or NHRP or whatever to map between IP addresses and lower-layer addresses >INSTEAD OF embedding the routable lower layer address into the routable >IP-layer address. > >Alternately put, could you please explain what technical problem SG7 thinks >it is trying to solve ?? I have a couple comments: 1) IP address and ATM address are orthogonal As far as I know in RFC 1884 "IPversion 6 addressing arcitecture" there is Prefix Format value reserved for NSAP and there is also an Internet Draft " OSI NSAP and IPv6" (expected to be published as an Experimental RFC) written by Brian Carpenter describing the support of NSAP in IPv6 Keeping in mind that, according to the ATM Forum, the Public UNI and the Private UNI ATM are identified by the AESA (the AESA is a kind of NSAP) it seems to me that IPV6 address can already support the address to identify an ATM interface 2) Embedding lower-layer address within IP-layer address is a bad practice In the Internet Draft "An IPv6 Provider based unicast address format" in the section describing the Intra Subscriber Part the authors recommend to use the 48 bit IEEE 802 MAC address in the Interface ID field. This seems to me a way to embed a lower layer address (a link address) within a IP-layer address. 3) Why X.121 and E.164? I agree with Alan Lloyd that without some notion of E.164 mapping we have a Internet protocol that does not overlay well switched network using X.121 and E.164 numbering plans. (Alan thank you for your "moral support"). Last point. Someone mentioned possibile problems related to mobile IP in using IPv6 address based on E.164 number. Could you please discuss a little more this point. bye, Marco ------------------------------------------------------------------------------ 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 Tue Jan 30 07:54:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21994; Tue, 30 Jan 96 07:54:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21988; Tue, 30 Jan 96 07:53:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08866; Tue, 30 Jan 1996 07:52:59 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id HAA28270; Tue, 30 Jan 1996 07:52:57 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id RAA25522; Tue, 30 Jan 1996 17:50:05 +0200 Date: Tue, 30 Jan 1996 17:50:05 +0200 Message-Id: <199601301550.RAA25522@lohi.dat.tele.fi> From: Juha Heinanen To: brian@dxcoms.cern.ch Cc: sob@newdev.harvard.edu, Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <9601301244.AA13871@dxcoms.cern.ch> (brian@dxcoms.cern.ch) Subject: (IPng 1307) Re: Brian's RFC Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The actual reason it was forwarded as "Experimental" is because of doubts whether the NSAP address formats will be globally routable in an IPv6 Internet. As long as these doubts exist, it is hard to think of it going onto the main standards track. brian, scott, first, thanks for your prompt answers. i'm only interested in that part of the nsap rfc draft that specifies, how one can map an ipv6 address to an nsap. the resulting nsap i can surely route, for example, using the pnni protocol or is-is or idrp. so your concern above doesn't apply to that part of the rfc. i therefore strongly urge you to split the rfc to two rfcs: an experimental one that maps nsaps to ipv6 addresses and a standards track one that maps ipv6 addresses to nsaps. i hope that this request doesn't come too late. if so, i guess i need to submit another internet draft that only covers the latter part. which way you prefer to handle this? -- juha ------------------------------------------------------------------------------ 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 Jan 30 08:03:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22006; Tue, 30 Jan 96 08:03:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22000; Tue, 30 Jan 96 08:03:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09942; Tue, 30 Jan 1996 08:02:40 -0800 Received: from POSTAL.CSELT.STET.IT by mercury.Sun.COM (Sun.COM) id IAA00850; Tue, 30 Jan 1996 08:02:33 -0800 Received: from [163.162.3.79] (apl0546.cselt.stet.it) by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01I0MN7VVGSW0050IA@POSTAL.CSELT.STET.IT>; Tue, 30 Jan 1996 17:00:41 MET Date: Tue, 30 Jan 1996 18:13:24 +0100 From: Marco.Bernardi@cselt.stet.it (Marco Bernardi) Subject: (IPng 1308) RE: X.121 and E.164 address and routable addresses To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com Message-Id: X-Envelope-To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT X-Sender: Bernardi_EUD@POSTAL.CSELT.STET.IT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt wrote: >You distorted Ran's words just a bit, and he was speaking very precisely. >He said, "a ROUTABLE lower-layer address." I am a little puzzled. As far as I know a IEEE-802 MAC address is a routable address at the lower layer ( the link layer). By routable I mean an address used to reach the interface identified by the address itself. Am I wrong? bye, marco ------------------------------------------------------------------------------ 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 Jan 30 08:30:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22038; Tue, 30 Jan 96 08:30:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22032; Tue, 30 Jan 96 08:30:21 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13123; Tue, 30 Jan 1996 08:29:31 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id IAA08237; Tue, 30 Jan 1996 08:29:30 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA04698; Tue, 30 Jan 1996 09:11:11 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22160; Tue, 30 Jan 1996 09:11:08 -0500 Message-Id: <9601301411.AA22160@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, rolc@nexen.com, ipatm@matmos.hpl.hp.com, bound@zk3.dec.com Subject: (IPng 1309) Re: IPv6 over NBMA In-Reply-To: Your message of "Mon, 29 Jan 96 15:30:43 PST." <199601292330.PAA12090@puli.cisco.com> Date: Tue, 30 Jan 96 09:11:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I think it would be good to: >> >> 1. Identify the requirements for IPv6 over ATM > > I believe that we should be solving the general IPv6/NBMA problem >with a single mechanism rather than having a specification that is unique >to IPv6/ATM. I believe that use of NHRP to determine lower-layer addresses >of NBMA neighbors permits such a general solution. NHRP is being worked on >within ROLC. Consequently, I also think that ROLC folks might have some >interest in this matter. > > I suspect this difference in perspective (IPv6/NBMA or IPv6/ATM) >might be fundamental and that the other items listed in the previous note >might well fall out naturally once this first question is resolved. After I sent my mail I wish I had used the word "goals" instead of "requirements". I would agree that IPv6/NBMA is clearly a good idea. But, I would like to state a caveat to that agreement. IPv6 over ATM is something we can and are doing today as part of the Digital UNIX IPv6 AD Prototype to understand the affect of IPv6. In addition we will be experimenting with the QOS/Flow-ID via RSVP for IPv6 over ATM. The reason for this AD as engineers is the underlying assumption while working on IPv6 that IPv6 is not just good for the industry, market, and Internet for the negative reasons of address space exhaustion or the routing table explosion, but also for some very valid "positive" reasons as there are features you can get which are better and more robust with IPv6 you can get, that you cannot get with IPv4. I do not want to see IPv6 over ATM (or NBMA) not be its very best because of potential "lazy-evaluation" of the most efficient means to architect NBMA for IPv6. I also believe we should "attempt" to take advantage of the core IPv6 protocols for IPv6 when architecting NBMA and ATM for IPv6. I do not believe that was an idea or even a thought when NHRP was invented for NMBA/ATM. Schulter/Jork/Armitage did take IPv6 into account in their "design goals" as engineers/architects. Their goals also have the benefit of IPv6 code-reusability on "HOSTS", that are implementing the IPv6 present "Proposed Standards" (including the soon to be PSs ND and Stateless Addr Conf). So I suggest we begin the discussion of the "goals" of IPv6/NBMA with ATM as a reality check for that discussion. In addition I believe the chairs of ipng, ipatm, or rolc get Schulter/Jork/Armitage folks some "prime time" and enough time somewhere in L.A. to state their case why they are proposing what they are stating for IPv6 over ATM, where they do not want to use NHRP and why, and their weaknesses in their strategy and NHRP (or NHRP authors can state their weaknesses). I highly suggest this discussion happen at the ipng wg sessions and those ipng sessions not run opposite rolc or ipatm from my experiences in the IETF with DHCPv6. The reason is that in the case where a question of goals for IPv6 becomes an issue the most number of folks who understand IPv6 and have implemented it in the IETF are part of ipng wg. Until this changes (and I hope soon) I think the core "goals" discussion must include the ipng wg experts. /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 Jan 30 09:37:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22119; Tue, 30 Jan 96 09:37:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22098; Tue, 30 Jan 96 09:37:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23255; Tue, 30 Jan 1996 09:36:15 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA29686; Tue, 30 Jan 1996 09:36:14 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA06170; Tue, 30 Jan 1996 09:35:40 -0800 Date: Tue, 30 Jan 1996 09:35:40 -0800 From: Ran Atkinson Message-Id: <199601301735.JAA06170@puli.cisco.com> To: Marco.Bernardi@cselt.stet.it Subject: (IPng 1310) Re: (none) In-Reply-To: Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article Marco wrote: Earlier,Ran Atkinson wrote: >>The routable ATM address of the ATM UNI interface is orthogonal to the IP >>address associated with that interface, so I don't see why this matters. >> >>I consider it generally undesirable to embed routable lower-layer addresses >>within routable IP-layer addresses. It violates layering in a severe way. >>Also, this can lead to weird hard-to-diagnose routing/connectivity problems >>in operational networks. There are good reasons to use Neighbor Discovery >>or NHRP or whatever to map between IP addresses and lower-layer addresses >>INSTEAD OF embedding the routable lower layer address into the routable >>IP-layer address. >> >>Alternately put, could you please explain what technical problem SG7 thinks >>it is trying to solve ?? > >I have a couple comments: > >1) IP address and ATM address are orthogonal > >As far as I know in RFC 1884 "IPversion 6 addressing arcitecture" there is >Prefix Format value reserved for NSAP and there is also an Internet Draft >" OSI NSAP and IPv6" (expected to be published as an Experimental RFC) >written by Brian Carpenter describing the support of NSAP in IPv6 >Keeping in mind that, according to the ATM Forum, the Public UNI and the >Private UNI ATM are identified by the AESA (the AESA is a kind of NSAP) it >seems to me that IPV6 address can already support the address to identify >an ATM interface My understanding has been that the use of the NSAP format in IPv6 was not encouraged because it tends to defeat CIDR and tends to cause a recurrance of the current routing table size explosion that is the current operational problem in the backbone. Further, my understanding has been that the NSAP was being specified primarily so that sites using ISO CLNP and having an ISO CLNP address plan already specified could reuse that address plan for their IPv6 networks. Sites doing this might well find that major backbone providers (e.g. Sprint) won't carry their routing prefix and hence they will not be reachable from all Internet sites. >2) Embedding lower-layer address within IP-layer address is a bad practice You didn't read my note very carefully. I was very careful to talk about "routable addresses" as distinguished from address tokens. Your comment below pertains to non-routable "address tokens" and does NOT pertain to "routable addresses". >In the Internet Draft "An IPv6 Provider based unicast address format" in >the section describing the Intra Subscriber Part the authors recommend to >use the 48 bit IEEE 802 MAC address in the Interface ID field. This seems >to me a way to embed a lower layer address (a link address) within a >IP-layer address. IEEE 802 MAC addresses are NOT routable. Please re-read my note. >3) Why X.121 and E.164? > >I agree with Alan Lloyd that without some notion of E.164 mapping we have a >Intenet protocol that does not overlay well switched network using X.121 >and E.164 numbering plans. There doesn't seem to be any overlay problem. One simply uses some IP-layer to lower-layer (e.g. E.164) address resolution mechanism just as we use IPv6 ND for IP-layer to LAN (e.g. IEEE 802) MAC address resolution on FDDI, Ethernet, and Token-Ring. I don't see the technical problem here, could you please explain further ? I'm very concerned with IPv6/NBMA issues and ensuring that this works well. 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 Tue Jan 30 09:46:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22131; Tue, 30 Jan 96 09:46:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22125; Tue, 30 Jan 96 09:46:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24569; Tue, 30 Jan 1996 09:45:14 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA02665; Tue, 30 Jan 1996 09:45:13 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA06973; Tue, 30 Jan 1996 09:45:11 -0800 Date: Tue, 30 Jan 1996 09:45:11 -0800 From: Ran Atkinson Message-Id: <199601301745.JAA06973@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1311) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: <9601301443.AA56977@hawpub1.watson.ibm.com> References: <199601300702.QAA08319@tera.csl.sony.co.jp> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9601301443.AA56977@hawpub1.watson.ibm.com>, Charlie Perkins wrote: >In draft-teraoka-ipv6-mobility-sup-02.txt, there is a proposal >for a Source Address option. If it would work, it would be >handy to allow mobile nodes to get packets past firewalls. >It would also be handy for multicast transmission, as Teraoka >points out. This proposal is not terribly new. If the IPv6 >working group decides that it is a workable proposal, I would >be happy to incorporate that option into my Internet Draft. > >However, it seems unlikely to me that such an approach can be >relied on. If a Source Address option were used, I don't see >what value could be placed on source address filtering by >firewalls. In other words, the firewalls wouldn't be protecting >against anything. Dave and I decided that it wouldn't be >realistic to propose such an option as a solution to the firewall >problem, because then firewalls would just start filtering out >packets that contained Source Address Options. Why couldn't the IP Authentication Header be used by the firewall to authenticate the validity of the Source Address Option in the packet ? It seems to me that Teraoka-san's comments are correct here. The ability to traverse firewalls seems to be operationally valuable. I'd still prefer use of something more like JI's original Mobile IP technology (from his PhD thesis) or the Stanford MosquitoNet approach because only the mobile node needed to be modified for mobility to work sufficiently. It has been a source of some mystery to me (and some others judging from recent private email) why the IETF didn't take JI's work on Mobile IP and just move it to Proposed Standard years ago. As an aside, the issue with reuse of JI's (and Phil Karn's and Matt Blaze's) SWIPE encryption approach was mainly the desire for crypto algorithm-independence. 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 Tue Jan 30 09:50:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22144; Tue, 30 Jan 96 09:50:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22137; Tue, 30 Jan 96 09:50:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25224; Tue, 30 Jan 1996 09:49:31 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA04137; Tue, 30 Jan 1996 09:49:27 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA07179; Tue, 30 Jan 1996 09:47:23 -0800 Date: Tue, 30 Jan 1996 09:47:23 -0800 From: Ran Atkinson Message-Id: <199601301747.JAA07179@puli.cisco.com> To: Marco.Bernardi@cselt.stet.it Subject: (IPng 1312) Re: X.121 and E.164 address and routable addresses Newsgroups: cisco.external.ietf.ipng In-Reply-To: Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article Marco wrote: >Matt wrote: > >>You distorted Ran's words just a bit, and he was speaking very precisely. >>He said, "a ROUTABLE lower-layer address." > >I am a little puzzled. As far as I know a IEEE-802 MAC address is a >routable address at the lower layer ( the link layer). By routable I mean >an address used to reach the interface identified by the address itself. An IEEE 802 MAC address can be bridged but is not routable. 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 Tue Jan 30 13:59:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22439; Tue, 30 Jan 96 13:59:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22433; Tue, 30 Jan 96 13:59:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10366; Tue, 30 Jan 1996 13:58:23 -0800 Received: from netra1 by mercury.Sun.COM (Sun.COM) id NAA27735; Tue, 30 Jan 1996 13:58:22 -0800 From: Alan.Lloyd@datacraft.com.au Received: from cms.datacraft.com.au by netra1.datacraft.com.au (SMI-8.6/SMI-SVR4) id JAA01481; Wed, 31 Jan 1996 09:05:04 +1100 Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA24143; Wed, 31 Jan 96 08:57:42 +1100 Received: by dcthq2.datacraft.com.au; Wed, 31 Jan 96 9:08:47 +1100 Date: Wed, 31 Jan 96 8:55:05 AUS Message-Id: X-Priority: 3 (Normal) To: Cc: Subject: (IPng 1313) Re: (none) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ran, re IP addressing and ATM/E.164. 802 addresses are not routable. IMHO no they are just a link address token as you describe. But if one builds a link based system with filtered bridges are these addresses implicitly routed? The next point is that E.164 is a routable address, the whole of the PSTN does this. So in one case IP4/6 over 802 is a link discovery problem and because it is a "link", the link connectivity spread should be limited to a site or small company or a plumbed up network. So address and "token" discovery mechanisms are reasonably simple. Whereas with ip4/6 over E.164 (which is a global routable addressing scheme which covers the planet), putting them together actually causes a multiplicity of routing hierarchies, overlays, allocation and mapping issues and connectivity issues because E.164 is country assigned and in most cases provides "switched" NETWORK circuits NOT links. There is a difference. It is pointless seeking shortest path routes at the internet layer if one does not realise that the switched circuit underneath it that supports it goes through 200 countries! Regards alan@Oz ------------------------------------------------------------------------------ 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 Jan 30 14:15:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22466; Tue, 30 Jan 96 14:15:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22460; Tue, 30 Jan 96 14:15:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13371; Tue, 30 Jan 1996 14:14:25 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id OAA03102; Tue, 30 Jan 1996 14:14:22 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0599; Tue, 30 Jan 96 17:14:14 EST Received: by RTP (XAGENTA 4.0) id 5270; Tue, 30 Jan 1996 15:50:25 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20355; Tue, 30 Jan 1996 15:50:16 -0500 Message-Id: <9601302050.AA20355@cichlid.raleigh.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1314) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Mon, 29 Jan 1996 09:24:07 PST." <199601291724.JAA11454@puli.cisco.com> Date: Tue, 30 Jan 1996 15:50:16 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >I don't agree with the levying of these new requirements on all >hosts/routers. Choice of implementation or not should be left >to implementers. Could you please be more specific about which requirements you feel are too onerous? If the requirement that all hosts implement binding updates (and tunnelto a mobile's COA [where tunnel may mean use Routing Header]) becomes an "implementation choice", there is the performance penalty that all traffic to the mobile must travel through the Home Agent. This makes mobility a lot less attractive IMO. Are you really advocating that this should be an implementation decision? >I note that a paper presented at USENIX last week showed that it is >entirely possible to implement mobility without changing the IP >implementation in nodes that aren't themselves moving. This is a Red Herring, IMO. Of course one can do mobility without chaning non-mobile hosts. IPv4 mobility is doing that, and I would argue, is paying a hefty price. Having the option to put base functionality in all IPv6 nodes presents an opportunity that we should not pass up lightly. 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 Tue Jan 30 15:39:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22606; Tue, 30 Jan 96 15:39:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22600; Tue, 30 Jan 96 15:39:07 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27206; Tue, 30 Jan 1996 15:38:18 -0800 Received: from ftp.com by mercury.Sun.COM (Sun.COM) id PAA26758; Tue, 30 Jan 1996 15:38:19 -0800 Received: from ftp.com by ftp.com ; Tue, 30 Jan 1996 18:38:12 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 30 Jan 1996 18:38:12 -0500 Received: from kasten.d-cell.ftp.com by MAILSERV-D.FTP.COM (5.x/SMI-SVR4) id AA26711; Tue, 30 Jan 1996 18:38:30 -0500 Date: Tue, 30 Jan 1996 18:38:30 -0500 Message-Id: <9601302338.AA26711@MAILSERV-D.FTP.COM> To: narten@VNET.IBM.COM Subject: (IPng 1315) Re: draft-ietf-mobileip-ipv6-00.txt From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: rja@cisco.com, ipng@sunroof.eng.sun.com Repository: mailserv-d.ftp.com, [message accepted at Tue Jan 30 18:38:25 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The list of things that are mandated to be implemented should be kept as small as possible. The smaller the list of musts, the lower the entry cost of implementing the protocol. The lower the entry cost of implementing the protocol, the more places it will be implemented. The more places it's implemented, the more ubiquitous the protocol, and The Internet, will be. The more it's ubiquitous, the more we win. The mobility code is not _required_ in order for any arbitrary pair of nodes to interoperate. It is only needed when one, or both, of those nodes hits the road. Ergo mobility support should not be mandatory of all nodes. > >I don't agree with the levying of these new requirements on all > >hosts/routers. Choice of implementation or not should be left > >to implementers. > > Could you please be more specific about which requirements you feel > are too onerous? > > If the requirement that all hosts implement binding updates (and > tunnelto a mobile's COA [where tunnel may mean use Routing Header]) > becomes an "implementation choice", there is the performance penalty > that all traffic to the mobile must travel through the Home > Agent. This makes mobility a lot less attractive IMO. Are you really > advocating that this should be an implementation decision? -- Frank Kastenholz ------------------------------------------------------------------------------ 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 Jan 30 17:29:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22764; Tue, 30 Jan 96 17:29:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22758; Tue, 30 Jan 96 17:29:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12640; Tue, 30 Jan 1996 17:28:35 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id RAA23537; Tue, 30 Jan 1996 17:28:34 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA13399 for ipng@sunroof.Eng.Sun.COM; Tue, 30 Jan 1996 20:28:01 -0500 (EST) Date: Tue, 30 Jan 1996 20:28:01 -0500 (EST) From: Scott Bradner Message-Id: <199601310128.UAA13399@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 1316) Re: draft-ietf-mobileip-ipv6-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ergo mobility support should not be > mandatory of all nodes this conflicts with much of the discussions on this topic in the past I would say that it is too early to make a judgement, we should wait and see what would be required to include the mobility support, if it is another 1/2 MB of code then I'd agree - if it means redefining a few pointers - it would be a shame to miss the chance. So lets see what is involved. > The smaller the list of musts, the lower the > entry cost of implementing the protocol we have to be sure it is not too small since that increases the chance of incompatable implementation 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 Tue Jan 30 18:30:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22898; Tue, 30 Jan 96 18:30:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22892; Tue, 30 Jan 96 18:29:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18956; Tue, 30 Jan 1996 18:29:06 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id SAA05932; Tue, 30 Jan 1996 18:29:05 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA00786; Tue, 30 Jan 1996 21:22:23 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30445; Tue, 30 Jan 1996 21:22:22 -0500 Message-Id: <9601310222.AA30445@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 1317) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Tue, 30 Jan 96 15:50:16 -0400." <9601302050.AA20355@cichlid.raleigh.ibm.com> Date: Tue, 30 Jan 96 21:22:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I note that a paper presented at USENIX last week showed that it is >>entirely possible to implement mobility without changing the IP >>implementation in nodes that aren't themselves moving. > >This is a Red Herring, IMO. Of course one can do mobility without >chaning non-mobile hosts. IPv4 mobility is doing that, and I would >argue, is paying a hefty price. Having the option to put base >functionality in all IPv6 nodes presents an opportunity that we should >not pass up lightly. I agree with Thomas that this is a great opportunity we should not pass up lightly. /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 Jan 30 19:27:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23030; Tue, 30 Jan 96 19:27:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23024; Tue, 30 Jan 96 19:27:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23328; Tue, 30 Jan 1996 19:26:17 -0800 Received: from wizard.gsfc.nasa.gov by mercury.Sun.COM (Sun.COM) id TAA14731; Tue, 30 Jan 1996 19:26:17 -0800 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA09497; Tue, 30 Jan 96 22:26:01 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9601310326.AA09497@wizard.gsfc.nasa.gov> Subject: (IPng 1318) Re: X.121 and E.164 address To: rja@cisco.com (Ran Atkinson) Date: Tue, 30 Jan 1996 22:26:01 -0500 (EST) Cc: Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <199601291732.JAA11974@puli.cisco.com> from "Ran Atkinson" at Jan 29, 96 09:32:11 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Mon, 29 Jan 1996 09:32:11 -0800 > From: Ran Atkinson > > The routable ATM address of the ATM UNI interface is orthogonal to the IP > address associated with that interface, so I don't see why this matters. > > I consider it generally undesirable to embed routable lower-layer addresses > within routable IP-layer addresses. It violates layering in a severe way. > Also, this can lead to weird hard-to-diagnose routing/connectivity problems > in operational networks. There are good reasons to use Neighbor Discovery > or NHRP or whatever to map between IP addresses and lower-layer addresses > INSTEAD OF embedding the routable lower layer address into the routable > IP-layer address. I agree with your general statement, but disagree with its application for ATM. Since ATM has a globally routable address structure just like IP4 or IP6, and there exists a trivial mapping from one to the other, it makes a lot of sense in many (but certainly not all) ATM environments to embed the IP4 or IP6 address in the ATM NSAP address. This allows the possibility of an integrated approach to IP and ATM routing and addressing in such environments, which could result in much simpler overall network management and operation. It provides for a trivial ATMARP mechanism, and eliminates the complexity of managing two sets of routing protocols for the ATM world, one at the ATM layer and another at the IP layer. If anything, having routing at both layers could potentially lead to weird, hard-to diagnose network problems, if the routing topologies at the two layers aren't congruent for any reason. The ATM PNNI routing protocol is already there, so why not just use it. One could simply map the IP4 or IP6 address to the equivalent ATM NSAP address, and connect directly to that ATM NSAP address. Minimal connection latency with no extra fuss. One could still use NHRP to connect across mutiple PNNI routing domains or to a non-PNNI domain such as a public carrier using E.164 addresses and whatever it is they use for a routing protocol. I'm describing a modification of a proposal I made called the Integrated Routing and Addressing (IRA) model (similar proposals have also been made by others). I will briefly describe the modification to the base IRA model. You start with the smallest unit of a LIS. You group the LISs together to form what I call a LIM (for Logical IP Mapping-region), the scope of which can be determined dynamically via the PNNI information, and over which the IRA model is used to perform the ATMARP service via the trivial mapping of IP to ATM NSAP addresses. If the LIMs are interconnected via IP routers, you're basically done. If multiple LIMs, and possibly non-LIMs (regions not using the IRA model), are directly connected at the ATM layer, you use NHRP to allow interoperation among the overall collection, which I call a LIR (for Logical IP Region). The LIRs can then be connected to the global Internet via normal IP routers. This is a very brief synopsis of what I am thinking of submitting as IRA2. I would be very much interested in any comments. -Bill ------------------------------------------------------------------------------ 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 Jan 30 19:45:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23042; Tue, 30 Jan 96 19:45:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23036; Tue, 30 Jan 96 19:45:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24648; Tue, 30 Jan 1996 19:44:15 -0800 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id TAA17248; Tue, 30 Jan 1996 19:44:12 -0800 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 31 Jan 1996 12:36:17 +0900 From: Masataka Ohta Message-Id: <199601310336.MAA11807@necom830.cc.titech.ac.jp> Subject: (IPng 1319) Re: X.121 and E.164 address To: ipng@sunroof.eng.sun.com Date: Wed, 31 Jan 96 12:36:14 JST X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk May I point out that, according to ITU, an address consists of an E.164 part to globally identify a site AND an NSAP subaddress part to locally identify a terminal equipment within the site? Masataka Ohta ------------------------------------------------------------------------------ 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 Jan 31 02:48:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23252; Wed, 31 Jan 96 02:48:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23246; Wed, 31 Jan 96 02:48:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17642; Wed, 31 Jan 1996 02:47:41 -0800 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id CAA01457; Wed, 31 Jan 1996 02:47:40 -0800 Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id LAA05278; Wed, 31 Jan 1996 11:48:33 +0100 Received: from nestvx.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id LAA06552; Wed, 31 Jan 1996 11:48:00 +0100 Message-Id: <199601311048.LAA06552@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Wed, 31 Jan 96 11:48:06 MET Date: Wed, 31 Jan 96 11:48:06 MET From: Markus Jork To: "jhalpern@us.newbridge.com"@vbormc.vbo.dec.com (joel halpern) Cc: jork@nestvx.enet.dec.com, "ip-atm@matmos.hpl.hp.com"@vbormc.vbo.dec.com, "ipng@sunroof.eng.sun.com"@vbormc.vbo.dec.com Apparently-To: ipng@sunroof.eng.Sun.COM, ip-atm@matmos.hpl.hp.com, jhalpern@us.newbridge.com Subject: (IPng 1320) Re: IPv6 over NBMA Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In the message I am replying to, Mr. Jork (Sorry if that is the wrong > form of reference, I am writing from home) suggests that one may not > need a complete, connected, routing overlay to support IPv6 over ATM. > There are at least two reasons why such an overlay is absoluately necessary. Mr. Halpern, [why not just use our given names, sounds much more friendly and that's what everybody else uses in the IETF] I'm afraid we are drifting into a discussion that is of not much interest to the ipng list. And I really don't think there is much of a disagreement here. > 1) As has been discussed in the IP/ATM group, in the ROLC group, and > at the ATM Forum MPOA group, there are definitely situations where > establishing a VC for a received packet is somewhere between > inefficient and extremely foolhardy. I agree that there are these situations. That's why I wrote "It depends on your applications". > 2) In order to be able to select ATM exits to reach networks behind > the ATM fabric, routing must be consulted. Therefore, one must have > access to routing. The size (number of stations) of the service area > of individual routers may be very large, but it MUST exist. Of course there must be routers to move packets from ATM to some other network. (Unless we forget about native IP and just use LAN emulation.) And these routers have to talk to each other. So there is a routing overlay. No disagreement here. I was referring to the rolc model of this large ATM cloud consisting of lots of LISs, interconnected by routers. Some of these routers will be at the "edge of the ATM cloud" (i.e. border routers connecting ATM to someting else), others just connecting two or more LISs. What I was trying to say: Peter's draft leaves network managers with the option not to install these "inside-the-cloud-only" routers. Maybe the whole discussion is pointless because in real-world networks, all routers will be border routers anyway. Because someone plugs in some Ethernet or whatever. Markus ------------------------------------------------------------------------------ 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 Jan 31 04:30:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23299; Wed, 31 Jan 96 04:30:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23293; Wed, 31 Jan 96 04:29:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21719; Wed, 31 Jan 1996 04:29:03 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id EAA11516; Wed, 31 Jan 1996 04:29:04 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2179; Wed, 31 Jan 96 07:28:59 EST Received: by RTP (XAGENTA 4.0) id 5476; Wed, 31 Jan 1996 07:28:40 -0500 Received: from hygro.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20165; Wed, 31 Jan 1996 07:28:56 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id WAA00197; Tue, 30 Jan 1996 22:41:46 -0500 Message-Id: <199601310341.WAA00197@hygro.raleigh.ibm.com> To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 1321) Re: Implementation? on Addr Conf Section 5.5.3 Prefix Info - d) In-Reply-To: Your message of "Sun, 28 Jan 1996 14:18:20 PST." <9601282218.AA01066@feller.mentat.com> Date: Tue, 30 Jan 1996 22:41:46 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >On 5.5.3 Page 20 it states: > d) If the advertised prefix matches the prefix of an autoconfigured > address (i.e., obtained via stateless or stateful address > autoconfiguration) in the list of addresses associated with the > interface, set the preferred timer to that of the option's preferred > lifetime, and set the valid lifetime to that of the option's valid > lifetime. >In the case where stateful has provided an address like 5CB6::4567. Then >the router sends a new set of timers for 5CB6:: prefix the >implementation will update the valid and preferred timers for prefix 5CB6. >This is not good. The reason is that the stateful server is still using >the lease times it sent out for the client, and now they have been >changed. We don't want clients updating the servers timers per >stateless RAs. The way I see it, the above scenario indicates that something is broken (i.e., sys admins have misconfigured something). Routers should not be advertising prefixes/addresses and at the same time give out the same (and conflicting) information via DHCP. It's not really clear to me what the "right" thing to do is in this case. The problem goes beyond just prefixes. There are other parameters that can both be obtained from RAs and DHCP. Thus, the addrconf wording is aimed at keeping implementations simple and not having detailed rules saying when to believe DHCP information vs. addrconf. Do you want to do it on a case-by-case basis for the "hop count" field in RAs? Other parameters? And when do you stop giving prefernce to the DHCP information if you've tried contacting the DHCP server recently, but didn't get a response? >It seems to me if the Managed-bit is ON and the Autonomous-Bit is ON >(meaning the client is using both stateless and stateful for addr conf >via coexistence) then if the address was obtained via stateful server >for addr conf the timers should not be updated and a system log error >should be posted. But if the Managed-bit is set to OFF then the timers >can replace the prefix address 5CB6 as stateful essentially has just >been canceled as an addr conf mechanism for the client. I just don't see there being a strong argument either way as to what the "right" way to solve this problem. We could add rules, but I think ultimately they would just complicate the code and not really matter in the overall scheme of things. The real problem is the misconfiguration that provides the conflicting information. thartric@mentat.com (Tim Hartrick) writes: > It seems like we could fix this problem by changing the para- >graph below such that the timer updates would only apply to addresses >which were configured based using stateless address autoconfiguration. But then we get into such details as suppose a DHCP-learned address's lease can't be renewed via DHCP (maybe DHCP is being turned off at the site). But the same address is being renewed per RAs. Do we ignore the new lifetimes advertised by RAs and delete the address (killing all connections) only to then reconfigure it when the first RA arrives after the DHCP lease expires? We could add more rules to try and massage this scenario, but I think the simple "believe the most recently received information" rule seems reasonable on balance. >It also seems reasonable to log an warning message when the valid >lifetime and the lease time of addresses using the same prefix are not >in sync. This is an interesting point. ND currently more or less doesn't encourage hosts to log errors (who would actually ever read the error log?), but does encourage routers to look for conflicting advertisements and log them (on the theory that router error logs would likely be scanned more often). But conflicts between DHCP-learned and RA-learned info can only be logged by hosts. And all 1000 of them would log the same error messages. Yikes! 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 Jan 31 04:59:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23316; Wed, 31 Jan 96 04:59:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23310; Wed, 31 Jan 96 04:58:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22877; Wed, 31 Jan 1996 04:58:06 -0800 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id EAA14252; Wed, 31 Jan 1996 04:58:07 -0800 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5067; Wed, 31 Jan 96 07:57:49 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 6965; Wed, 31 Jan 1996 07:57:49 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Wed, 31 Jan 96 07:57:48 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA28198; Wed, 31 Jan 1996 07:57:32 -0500 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9601311257.AA28198@hawpub1.watson.ibm.com> To: kasten@ftp.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1322) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: (Your message of Tue, 30 Jan 96 18:38:30 EST.) <9601302338.AA26711@MAILSERV-D.FTP.COM> Date: Wed, 31 Jan 96 07:57:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The list of things that are mandated to be implemented should be kept > as small as possible. The smaller the list of musts, the lower the > entry cost of implementing the protocol. The lower the entry cost of > implementing the protocol, the more places it will be implemented. > The more places it's implemented, the more ubiquitous the protocol, > and The Internet, will be. The more it's ubiquitous, the more we win. Does this apply to Neighbor Discovery? IP Security? I suggest that these protocols have been deemed necessary because they have wide applicability and great benefits. Consider mobility. Laptop sales continue to increase substantially, and I think will rise to dominate the market for computer sales. I also think the future will see many new kinds of even more mobile computers (say, in automobiles, pagers, personal computing devices, etc.) Think about the kinds of computers _you_ have ordered over the last year or so. I claim that the trend is even stronger among the general public, which is less concerned with routing and technical management. Unless you disagree with the coming age of mobility in computing, I can't see how you can neglect the Internet-wide protocol impact of insufficiencies in the way mobile computing devices connect to the Internet. We can make it easy or hard for the internet to handle these devices. The more mobility support is ubiquitous, the more we win. Besides, if you read the protocol, all the "hard work" is being done by the mobile nodes. The requirements for correspondent nodes and for routers are, as you desire, far less demanding. If nodes already are able to perform authentication, then all that's left is the ability to process a fancy kind of redirect, and to insert routing headers as needed. The latter should already be a required part of the IPv6 protocol anyway. Routers are asked to be able to do encapsulation. I can't see this as a big deal, especially when you compare it to the rest of the requirements. Just doing IP security is orders of magnitude more complicated than the little bit of mobility support that we specified. > The mobility code is not _required_ in order for any arbitrary pair > of nodes to interoperate. It is only needed when one, or both, of > those nodes hits the road. Ergo mobility support should not be > mandatory of all nodes. Yes, but I claim, and you can find numerous market studies to back me up, that the future Internet users will largely be equipped with exactly the kind of node that needs mobility support. Thus future Internet users will be best served by requiring mobility support in all IPv6 nodes, and it's just _not_ so hard to implement. > Frank Kastenholz Charles Perkins ------------------------------------------------------------------------------ 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 Jan 31 06:17:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23348; Wed, 31 Jan 96 06:17:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23342; Wed, 31 Jan 96 06:17:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27368; Wed, 31 Jan 1996 06:16:38 -0800 Received: from ftp.com by mercury.Sun.COM (Sun.COM) id GAA26084; Wed, 31 Jan 1996 06:16:37 -0800 Received: from ftp.com by ftp.com ; Wed, 31 Jan 1996 09:16:35 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 31 Jan 1996 09:16:35 -0500 Received: from kasten.d-cell.ftp.com by MAILSERV-D.FTP.COM (5.x/SMI-SVR4) id AA01965; Wed, 31 Jan 1996 09:17:00 -0500 Date: Wed, 31 Jan 1996 09:17:00 -0500 Message-Id: <9601311417.AA01965@MAILSERV-D.FTP.COM> To: perk@watson.ibm.com Subject: (IPng 1323) Re: draft-ietf-mobileip-ipv6-00.txt From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@sunroof.eng.sun.com Repository: mailserv-d.ftp.com, [message accepted at Wed Jan 31 09:16:44 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The list of things that are mandated to be implemented should be kept > > as small as possible. The smaller the list of musts, the lower the > > entry cost of implementing the protocol. The lower the entry cost of > > implementing the protocol, the more places it will be implemented. > > The more places it's implemented, the more ubiquitous the protocol, > > and The Internet, will be. The more it's ubiquitous, the more we win. > > Does this apply to Neighbor Discovery? IP Security? > > I suggest that these protocols have been deemed necessary because > they have wide applicability and great benefits. ND is needed to make IP6 work. Without ND everyone may as well go home. Security has, over the course of several years, been subject to community review and discussion and the conclusion is that we all want a safe, secure, network. This has been motivated, in part, by continuing attacks on the network and on network traffic. In other words, the overall consensus (though I will admit, not unanimous agreement) is that we should push security, even though it violates the KISS principle. I do consider that mobility is a major new piece of technology. It's in the criteria document. It's the technology that I've been developing at FTP for the past year. So I have a lot of interest in seeing mobility pushed far and wide over the network. However, I do not see it as falling into either of the two categories which NS and Security respectively fall into. -- Frank Kastenholz ------------------------------------------------------------------------------ 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 Jan 31 08:30:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23425; Wed, 31 Jan 96 08:30:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23419; Wed, 31 Jan 96 08:30:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10291; Wed, 31 Jan 1996 08:29:25 -0800 Received: from oberon.di.fc.ul.pt by mercury.Sun.COM (Sun.COM) id IAA26846; Wed, 31 Jan 1996 08:29:17 -0800 Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id RAA27946 for ; Wed, 31 Jan 1996 17:29:01 +0100 Message-Id: <199601311629.RAA27946@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs X-Mailer: exmh version 1.6.1 5/23/95 To: ipng@sunroof.eng.sun.com Reply-To: roque@di.fc.ul.pt From: roque@di.fc.ul.pt Subject: (IPng 1324) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Sun, 28 Jan 1996 14:10:54 EST." <9601281910.AA37214@hawpub1.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Jan 1996 17:28:52 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In order for the proposed protocol to work as intended, > every IPv6 node will be expected to support a new > Destination option, called "Binding Update" option. I do believe that this option (or something with a similar capability) is not necessary only for mobility and should be included in the base standard. a "Binding Update" might be necessary for every host that uses more than one address or more than one interface. and the current thread seams to be that there will be no host with a single address in the sense that address will have a much shorter livetime. For renumbering to be used it's IHMO necessary that there are means to maintain transport connections that where initiated with the original address that deprecates in periods like 8 hours. NFS for instance is used in a large number of large organizations that can't afford to manualy re-initiate all the mounts. My personal experience is that NFS tends to lock clients rock solid when the server is unavailiable. there are also 2 very important issues that could use (I would say need ) this kind of mecanism: - multihomed hosts, to support continued operation over a failed node/link - multihomed domains, so that an host with several prefixes will be allowed to choose the address he wants to use on communication. An exemple how that last feature is badly needed today is a host called phoenix.doc.ic.ac.uk that has 8 addresses, some of those, are topologicaly separated and originate from diferent networks. There is usualy no way that a client can choose the right address (clients shouldn't know about routing, right) and there is no way the server can select a new address to be used for the connection due the nature of tcp. I think that the support for this kind of capability should be designed with the full picture in mind and not just mobility. From what i read from the draft i'm fully convinced that is crucial for mobility to have this feature. I also do believe that the other issues i pointed are valid. What we're talking about here is an extension to IP that IMHO will be simple and easy to implement. regards, Pedro. ------------------------------------------------------------------------------ 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 Jan 31 10:24:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23527; Wed, 31 Jan 96 10:24:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23521; Wed, 31 Jan 96 10:24:25 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27078; Wed, 31 Jan 1996 10:23:28 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id KAA01479; Wed, 31 Jan 1996 10:23:18 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id UAA31516; Wed, 31 Jan 1996 20:19:59 +0200 Date: Wed, 31 Jan 1996 20:19:59 +0200 Message-Id: <199601311819.UAA31516@lohi.dat.tele.fi> From: Juha Heinanen To: bill@wizard.gsfc.nasa.gov Cc: rja@cisco.com, Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <9601310326.AA09497@wizard.gsfc.nasa.gov> (bill@wizard.gsfc.nasa.gov) Subject: (IPng 1325) Re: X.121 and E.164 address Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One could simply map the IP4 or IP6 address to the equivalent ATM NSAP address, and connect directly to that ATM NSAP address. the problem is that iana has not yet allocated an icd for this mapping. -- juha ------------------------------------------------------------------------------ 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 Jan 31 10:34:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23542; Wed, 31 Jan 96 10:34:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23536; Wed, 31 Jan 96 10:34:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29084; Wed, 31 Jan 1996 10:33:46 -0800 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id KAA05005; Wed, 31 Jan 1996 10:33:37 -0800 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 31 Jan 1996 10:33:33 -0800 Posted-Date: Wed, 31 Jan 1996 10:28:48 -0800 (PST) Message-Id: <199601311828.AA18378@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 31 Jan 1996 10:28:48 -0800 Subject: (IPng 1326) Re: X.121 and E.164 address To: jh@lohi.dat.tele.fi (Juha Heinanen) Date: Wed, 31 Jan 1996 10:28:48 -0800 (PST) Cc: bill@wizard.gsfc.nasa.gov, rja@cisco.com, Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <199601311819.UAA31516@lohi.dat.tele.fi> from "Juha Heinanen" at Jan 31, 96 08:19:59 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > One could simply map > the IP4 or IP6 address to the equivalent ATM NSAP address, and connect > directly to that ATM NSAP address. > > the problem is that iana has not yet allocated an icd for this mapping. > > -- juha Well, have you looked at draft-ietf-ipngwg-nsap-ipv6-00.txt? There is one ICD that the IANA has been allocated and this draft locks it up. There is an effort underway to get an AFI assigned to the IANA so that such mappings could be assigned. --bill ------------------------------------------------------------------------------ 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 Jan 31 10:50:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23554; Wed, 31 Jan 96 10:50:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23548; Wed, 31 Jan 96 10:49:47 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01562; Wed, 31 Jan 1996 10:48:56 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id KAA15859; Wed, 31 Jan 1996 10:48:57 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id UAA31607; Wed, 31 Jan 1996 20:45:51 +0200 Date: Wed, 31 Jan 1996 20:45:51 +0200 Message-Id: <199601311845.UAA31607@lohi.dat.tele.fi> From: Juha Heinanen To: bmanning@ISI.EDU Cc: bill@wizard.gsfc.nasa.gov, rja@cisco.com, Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <199601311828.AA18378@zed.isi.edu> (bmanning@ISI.EDU) Subject: (IPng 1327) Re: X.121 and E.164 address Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, have you looked at draft-ietf-ipngwg-nsap-ipv6-00.txt? yes, i have taken a look at it. the problem with that draft is that it is experimental and that iana ahs not allocated the suggested icd for that purpose. There is one ICD that the IANA has been allocated and this draft locks it up. There is an effort underway to get an AFI assigned to the IANA so that such mappings could be assigned. it would be nice if iana could gets own afi, but i think it would also possible to get one more icd for this purpose from bsi, if iana doesn't want to assign the one they have already got. -- juha ------------------------------------------------------------------------------ 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 Jan 31 10:53:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23570; Wed, 31 Jan 96 10:53:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23564; Wed, 31 Jan 96 10:53:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02276; Wed, 31 Jan 1996 10:52:53 -0800 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id KAA17535; Wed, 31 Jan 1996 10:52:53 -0800 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 31 Jan 1996 10:52:50 -0800 Posted-Date: Wed, 31 Jan 1996 10:48:24 -0800 (PST) Message-Id: <199601311848.AA18446@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 31 Jan 1996 10:48:24 -0800 Subject: (IPng 1328) Re: X.121 and E.164 address To: jh@lohi.dat.tele.fi (Juha Heinanen) Date: Wed, 31 Jan 1996 10:48:24 -0800 (PST) Cc: bmanning@ISI.EDU, bill@wizard.gsfc.nasa.gov, rja@cisco.com, Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <199601311845.UAA31607@lohi.dat.tele.fi> from "Juha Heinanen" at Jan 31, 96 08:45:51 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Well, have you looked at draft-ietf-ipngwg-nsap-ipv6-00.txt? > > yes, i have taken a look at it. the problem with that draft is that it > is experimental and that iana ahs not allocated the suggested icd for > that purpose. Not yet. Perhaps we ought to exert more "thrust" :) --bill ------------------------------------------------------------------------------ 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 Jan 31 13:22:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23729; Wed, 31 Jan 96 13:22:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23723; Wed, 31 Jan 96 13:22:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26044; Wed, 31 Jan 1996 13:21:54 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id NAA00013; Wed, 31 Jan 1996 13:21:51 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6328; Wed, 31 Jan 96 16:21:42 EST Received: by RTP (XAGENTA 4.0) id 5735; Wed, 31 Jan 1996 16:20:53 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15381; Wed, 31 Jan 1996 16:21:02 -0500 Message-Id: <9601312121.AA15381@cichlid.raleigh.ibm.com> To: TERAOKA Fumio Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 1329) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Tue, 30 Jan 1996 16:01:51 +0900." <199601300702.QAA08319@tera.csl.sony.co.jp> Date: Wed, 31 Jan 1996 16:21:01 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Teraoka & Ran: Teraoka writes: >However, as shown in Table-3, Charlie's proposal has some problems >with source address spoof filtering and multicast packet >transmission. Ran writes: > It seems to me that Teraoka-san's comments are correct here. >The ability to traverse firewalls seems to be operationally valuable. It took me some time to figure out what the source address spoofing problem was. The problem is at the mobile's *home* firewall, not the firewall at the site where the mobile node happens to be at the moment. Right? That is, the firewall at the mobile's home site sees a packet with a source address corresponding to an internal node arriving on an interface outside the site. Could be an intruder, so it it tosses the packet. Fair enough. What is not entirely clear to me is how much Teraoka's option helps here. At first glance, if a packet from the mobile node were sent back to a Home Agent with its Source Address set to the mobile's COA address, the mobile's home firewall could let the packet through. But this also now means that anyone else could get through the firewall using the same option. So it's not immediately clear that a firewall would allow such packets through either. If it did, it would have to rely on individual nodes within the site "doing the right thing" (e.g., requiring that any packet containing the option also include an AH). But one of the main points of a firewall is to *not* defer to internal nodes on such matters, since internal nodes can't be trusted in that regard. Another approach is to have the mobile node tunnel packets through the firewall using an SPI negotiated with the firewall. Would it be better to have the COA or the HA be the source address on such tunneled packets? A recent discussion on the IPSec list had some persons advocating that the IPSec engine on a node verify that the source address on a packet be the same as the one associated with the SPI when it was setup. If the host is mobile, it would be better then to always use the HA so that as it picks up a new COA, it doesn't need to renegotiate the SPI with the firewall. So again, the value of the option isn't entirely clear to me. If the SPI doesn't care which source address is used, then the option doesn't really buy anything. Is the above analysis correct, or am I still missing something? The point about multicasting is valid, but an orthogonal issue. 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 Jan 31 13:43:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23747; Wed, 31 Jan 96 13:43:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23741; Wed, 31 Jan 96 13:43:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29631; Wed, 31 Jan 1996 13:42:17 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id NAA06455; Wed, 31 Jan 1996 13:42:17 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA19395; Wed, 31 Jan 96 13:41:26 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA03313; Wed, 31 Jan 1996 13:41:48 -0800 Date: Wed, 31 Jan 1996 13:41:48 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9601312141.AA03313@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1330) The on-link flag. X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6'ers, In reading the ND and ADDRCONF specs I am a little con- fused about the purpose and semantics of the "on-link" flag in the prefix information option. In the ND spec it states that the on-link flag being zero indicates that some of the users of the prefix may actually reside off-link. In the ADDRCONF spec the purpose and semantics of the on- link flag are not discussed in the section which discusses the processing of prefix options. Here is the scenario I am concerned about. My node receives a prefix information option with the autonomous bit set to 1 and the on-link bit set to 0. I construct an address for my interface. As the ADDRCONF spec stands today I have the freedom not to perform DAD for this new address since my link-local address has already been validated. It turns out that indeed some of the users of this pre- fix reside behind a router which is proxying for those nodes on my node's link. Additionally it turns out that one of those nodes on the other side of the router shares a interface token with my node. We have an address collision which may be detected if my node has done DAD on the new address but could go undetected if I have chosen to not to do DAD. Now this problem is easily solved if the router which is handling the proxying responds to DAD and my node does DAD on any address which has the the on-link flag set to zero. We just need a caveat inserted in one of the documents so that the responsibilities of the members of this unholy proxy alliance are clear. This problem can also be solved by the node not assigning the prefix to one of his interfaces but simply adding a route for the prefix which uses his own interface as a gateway. This is more in keeping the how this type of arp hackery is done today (at least on BSD type systems). Comments? Tim Hartrick ------------------------------------------------------------------------------ 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 Jan 31 14:54:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23831; Wed, 31 Jan 96 14:54:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23825; Wed, 31 Jan 96 14:53:53 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13646; Wed, 31 Jan 1996 14:53:01 -0800 Received: from wizard.gsfc.nasa.gov by mercury.Sun.COM (Sun.COM) id OAA28995; Wed, 31 Jan 1996 14:53:01 -0800 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA10402; Wed, 31 Jan 96 17:51:23 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9601312251.AA10402@wizard.gsfc.nasa.gov> Subject: (IPng 1331) Re: X.121 and E.164 address To: jh@lohi.dat.tele.fi (Juha Heinanen) Date: Wed, 31 Jan 1996 17:51:22 -0500 (EST) Cc: bmanning@ISI.EDU, rja@cisco.com, Marco.Bernardi@cselt.stet.it, ipng@sunroof.eng.sun.com In-Reply-To: <199601311845.UAA31607@lohi.dat.tele.fi> from "Juha Heinanen" at Jan 31, 96 08:45:51 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well, have you looked at draft-ietf-ipngwg-nsap-ipv6-00.txt? > > yes, i have taken a look at it. the problem with that draft is that it > is experimental and that iana ahs not allocated the suggested icd for > that purpose. I agree with the suggestion of splitting out the part about embedding an IP6 address in an NSAP address, and trying to get that to Proposed Standard status. Since it's use for ATM is in specifying a MAC layer address (relative to IP anyway), I don't foresee any problems with using the suggested ICD even if the draft is in an experimental state. Still, it would be nice to have it blessed by the IETF to insure that everyone uses the same convention. > There is one ICD that the IANA has been allocated and this > draft locks it up. There is an effort underway to get an > AFI assigned to the IANA so that such mappings could be > assigned. > > it would be nice if iana could gets own afi, but i think it would also > possible to get one more icd for this purpose from bsi, if iana doesn't > want to assign the one they have already got. I don't think there's any need for a second ICD. We should just push to get the one that's there officially adopted, at least within the context of the IP-ATM efforts. > -- juha -Bill ------------------------------------------------------------------------------ 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 Jan 31 15:01:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23848; Wed, 31 Jan 96 15:01:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23842; Wed, 31 Jan 96 15:01:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15011; Wed, 31 Jan 1996 15:00:54 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id PAA01509; Wed, 31 Jan 1996 15:00:40 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8671; Wed, 31 Jan 96 18:00:33 EST Received: by RTP (XAGENTA 4.0) id 5762; Wed, 31 Jan 1996 17:59:57 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18525; Wed, 31 Jan 1996 18:00:11 -0500 Message-Id: <9601312300.AA18525@cichlid.raleigh.ibm.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1332) Re: The on-link flag. In-Reply-To: Your message of "Wed, 31 Jan 1996 13:41:48 PST." <9601312141.AA03313@feller.mentat.com> Date: Wed, 31 Jan 1996 18:00:10 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim: > In reading the ND and ADDRCONF specs I am a little con- >fused about the purpose and semantics of the "on-link" flag in >the prefix information option. What? After umpteen rewrites of this text, there can still be confusion? Say it ain't so! :-) > Now this problem is easily solved if the router which is >handling the proxying responds to DAD and my node does DAD on any >address which has the the on-link flag set to zero. Actually, I'm not sure the on-link bit is even important in this picture. The underlying problem is that there exist two nodes, both with the same interface token, both of which are connected to the same "home link". The first machine boots, runs DAD, etc., then goes mobile (i.e., moves elsewhere, leaving a proxy for it behind). The second machine (with the same interface token) then starts up, runs DAD, etc. The problem arises because both machines are running at the same time, but when the second machine runs DAD on its link-local address, the first one doesn't get the packets. This can happen when the link is temporarily partitioned, a node goes mobile, etc. >We just need a >caveat inserted in one of the documents so that the responsibilities >of the members of this unholy proxy alliance are clear. Require that the proxy-er proxy for all of the proxee's addresses, rather than just a subset? Or at the very least proxy for the link-local address? 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 Jan 31 16:11:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23957; Wed, 31 Jan 96 16:11:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23951; Wed, 31 Jan 96 16:11:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26843; Wed, 31 Jan 1996 16:10:47 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id QAA21251; Wed, 31 Jan 1996 16:10:47 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA21364; Wed, 31 Jan 96 16:09:24 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA03352; Wed, 31 Jan 1996 16:09:44 -0800 Date: Wed, 31 Jan 1996 16:09:44 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9602010009.AA03352@feller.mentat.com> To: narten@VNET.IBM.COM Subject: (IPng 1333) Re: The on-link flag. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >We just need a > >caveat inserted in one of the documents so that the responsibilities > >of the members of this unholy proxy alliance are clear. > > Require that the proxy-er proxy for all of the proxee's addresses, > rather than just a subset? Or at the very least proxy for the > link-local address? > The proxy-er should take on DAD duties for any address for which it is proxying. In general this would not include the link-local address since the link-local address is not intended to be globally unique. Addresses which are composed from an advertised prefix and a token are intended to be globally unique. If the nodes involved in this scenario have additional "on-link" prefixes then the router has no DAD responsibility. If there are additional "off-link" prefixes for which the router is not proxying then of course we end up with multiple machines with the same globally unique address. Just peachy. My suggestion of not configuring an address for an "off-link" prefix but merely adding a route to the prefix directed through the nodes own interface will solve the uniqueness problem. That is the way the ARP hack works today so why mess with tradition. Actually, my first preference is to disallow proxying entirely. It was a hack with ARP and this reincarnation of it is not an improvement. Given the problems with proxying in an environment where we are using link addresses as "unique" tokens I don't understand why we want to give anyone even a sliver of an oppurtunity to reproduce proxy ARP. So what does it mean for a prefix to be "off-link" when the only scope under which my token can be guaranteed unique (via DAD) is "on-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 Wed Jan 31 16:34:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23993; Wed, 31 Jan 96 16:34:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23987; Wed, 31 Jan 96 16:34:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00517; Wed, 31 Jan 1996 16:33:42 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id QAA27160; Wed, 31 Jan 1996 16:33:41 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id QAA00234; Wed, 31 Jan 1996 16:33:40 -0800 Date: Wed, 31 Jan 1996 16:33:40 -0800 From: Ran Atkinson Message-Id: <199602010033.QAA00234@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1334) Re: The on-link flag. In-Reply-To: <9602010009.AA03352@feller.mentat.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9602010009.AA03352@feller.mentat.com> thartric@mentat.com wrote: >Actually, my first preference is to disallow proxying entirely. It was >a hack with ARP and this reincarnation of it is not an improvement. >Given the problems with proxying in an environment where we are using >link addresses as "unique" tokens I don't understand why we want to give >anyone even a sliver of an oppurtunity to reproduce proxy ARP. Absolutely right. I've said this in the past and been shouted down by a vocal few, but I still think we really ought to be disallowing proxying. Getting rid of Proxy-ARP and similar behaviours would be A Good Thing. 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 Wed Jan 31 17:38:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24068; Wed, 31 Jan 96 17:38:37 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24062; Wed, 31 Jan 96 17:38:17 PST Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id RAA16646; Wed, 31 Jan 1996 17:36:43 -0800 (PST) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA24387; Wed, 31 Jan 1996 17:37:23 -0800 Date: Wed, 31 Jan 1996 17:37:23 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199602010137.RAA24387@bobo.eng.sun.com> To: thartric@mentat.com Subject: (IPng 1335) Re: The on-link flag. 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 > If there are additional "off-link" prefixes for which the router is > not proxying then of course we end up with multiple machines with the > same globally unique address. Just peachy. Just to (try to) clarify. There are no "off-link" prefixes advertised in Router Advertisements. Router advertisements list on-link prefixes (L flag set). A prefix with the L flag cleared does not mean that the prefix is off-link - it means that addresses in that prefix should be treated just like any address that the host does not know as being offlink. In the -03 spec: L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link. 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 Wed Jan 31 20:55:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24176; Wed, 31 Jan 96 20:55:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24170; Wed, 31 Jan 96 20:55:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28142; Wed, 31 Jan 1996 20:54:46 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id UAA13346; Wed, 31 Jan 1996 20:54:47 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA30646; Wed, 31 Jan 1996 23:46:28 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09595; Wed, 31 Jan 1996 23:46:27 -0500 Message-Id: <9602010446.AA09595@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: thartric@mentat.com (Tim Hartrick), bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 1336) Re: Implementation? on Addr Conf Section 5.5.3 Prefix Info - d) In-Reply-To: Your message of "Tue, 30 Jan 96 22:41:46 EST." <199601310341.WAA00197@hygro.raleigh.ibm.com> Date: Wed, 31 Jan 96 23:46:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I see your deliema architecturally clearly. But please also see mine as I just implemented the spec. The bottom line is if it happens I will overlay the timers for a DHCPv6 address at a minimum which alters the lease parameters of the server and in the worst case deprecate an address that has a ratified preferred timer (the stateless RA prefix sends me a preferred of all zeroes). And the worst case the RA prefix is killing the address by sending a valid_timer of all zeroes (which I will note is permited if the prefix previously was provided by the router). My issue with this is as follows: I agree with you the network was misconfigured. What I don't want to do is "propogate" that error throughout my implementation or the users network implementation. As Tim suggested I will set a flag in my implementation (once we are testing stateful which we are not at UNH next week) on the interface structure whether the address is stateful or stateless. This is very easy to do and a few lines of code whether you do it in the kernel or in user space as a daemon. /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 Jan 31 21:02:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24188; Wed, 31 Jan 96 21:02:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24182; Wed, 31 Jan 96 21:02:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28590; Wed, 31 Jan 1996 21:01:29 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id VAA14193; Wed, 31 Jan 1996 21:01:30 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA16373; Wed, 31 Jan 1996 23:55:46 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27073; Wed, 31 Jan 1996 23:55:46 -0500 Message-Id: <9602010455.AA27073@fwasted.zk3.dec.com> To: perk@watson.ibm.com (Charlie Perkins) Cc: kasten@ftp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1337) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Wed, 31 Jan 96 07:57:32 EST." <9601311257.AA28198@hawpub1.watson.ibm.com> Date: Wed, 31 Jan 96 23:55:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Yes, but I claim, and you can find numerous market studies to >back me up, that the future Internet users will largely be >equipped with exactly the kind of node that needs mobility >support. Thus future Internet users will be best served by >requiring mobility support in all IPv6 nodes, and it's just >_not_ so hard to implement. I asked this question of a person who does strategic planning for the Internet as a full time "job". They not only agree with Charlie but that also the type of devices that will be used for this will become common as lap tops are today (e.g. GPSs, Library Access Pads, Home Security Panels) in the market today. I think designing IPv6 mobile into the architecture of IPv6 as we have done Flows, QOS, Security, Dyanmic Renumbering, etc. is a wise architecture and engineering decision. I am going to answer Scotts question after next week (as the IPv6 implementors are all heads down now for UNH) as to "my opinion of lines of code". /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