Re: ipv6nd-02.txt & autoconfig
schulter@zk3.dec.com Fri, 10 May 1996 20:02 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23772; 10 May 96 16:02 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23767; 10 May 96 16:02 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa15026; 10 May 96 16:02 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id PAA27228; Fri, 10 May 1996 15:49:55 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id PAA01861 for ip-atm-out; Fri, 10 May 1996 15:41:57 -0400 (EDT)
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id PAA01852 for <ip-atm@nexen.com>; Fri, 10 May 1996 15:41:54 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: schulter@zk3.dec.com
Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id PAA27137 for <ip-atm@nexen.com>; Fri, 10 May 1996 15:41:52 -0400 (EDT)
Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA07461; Fri, 10 May 1996 15:29:38 -0400 (EDT)
Received: from dogfish.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA01407; Fri, 10 May 1996 15:29:08 -0400
Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA04290; Fri, 10 May 1996 15:29:07 -0400
Message-Id: <9605101929.AA04290@dogfish.zk3.dec.com>
X-Mailer: exmh version 1.6.1 5/23/95
To: Albert Manfredi <manfredi@engr05.comsys.rockwell.com>
Cc: IP-ATM Working Group <ip-atm@nexen.com>
Subject: Re: ipv6nd-02.txt & autoconfig
In-Reply-To: Your message of "Fri, 10 May 96 13:48:49 PDT." <3193ABB1.69CD@engr05.comsys.rockwell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 10 May 1996 15:29:07 -0400
X-Mts: smtp
X-Orig-Sender: owner-ip-atm@nexen.com
Precedence: bulk
X-Info: Submissions to ip-atm@nexen.com
X-Info: [Un]Subscribe requests to majordomo@nexen.com
X-Info: Archives via http://cell-relay.indiana.edu/cell-relay/archives/IPATM/IPATM.html
On Fri, 10 May 96 13:48:49 PDT Albert Manfredi wrote: > 1. We want a good scheme to allow IPv6 autoconfiguration with ATM. Yes, but I think what we're talking about is actually stateless address configuration (or the great IPv6 ATM host-token debate ;-) > 2. Ethernet and FDDI use their MAC address as the unique ID field. And > they're happy with the 48 bits. Yes, but you have to keep in mind two things. First, these designs do not address virtual LANs since they're not as likely to occur on an Ethernet interface as they are on an ATM interface. Second, the user of the MAC address for the host token still doesn't require that the resulting host token be globally unique; it must only be unique on the IPv6 link. This is important. > 3. Does ATM have something similar to offer? Yes, the contiguous ESI > bytes. And also SEL, but then manufacturing a unique 48-bit ID out of > ESI + SEL gets messy. It's still not quite that easy, unless we're _requiring_ that ESIs have greater uniqueness that specified in the UNI specs, but I don't want to go down that hole again. Let's assume we can just use the ESI and that they will always satisfy the uniqueness requirement for host-tokens (for the sake of making the following description easier). > 4. So I proposed we require SEL to always have the same value when ATM > is used in IPv6. I don't see this as a necessary or useful restriction for the following reasons: First, let's define the problem, which is that we need to be able to pick a host-token for each virtual network (LLG, or Logical Link, or whatever you want to call it) that's attached to a physical NIC. The real requirement is that the host-token have per-link uniqueness. Note that this means that the same host token can be used on different logical links. So, as long as the node does not join the same logical link twice using the same MAC, things are mostly OK. I say mostly because there is one remaining problem, but as it turns out, this is not a problem that is unique to ATM. If the same node uses the same host-token on all its links, there are no conflicts in the global address space. However, this will result in each link configuring the exact same link-local address. Since an IPv6 address is suppose to uniquely identify an interface, this can cause problems. This is not unique to ATM because the same problem exists on SUNs which use the system ID (a MAC) to configure all their NICs (each NIC gets the same MAC). This was discussed on the IPv6 mailing list around the Dallas meeting, and the proposed solution is called Identifying Individual Devices (IID) and is being persued in the IPNG WG. Thus, there seems to be general way of handling this emerging. So, what can we do for ATM? Well, in the NSAPA case I propose the following: A node can use an ESI (mainly MAC, but other values would work) for the host token. The host must not attach to the same logical link more than once using the same host token. The node will use the SEL byte to identify the logical link, but this does not have to be included in the host token. IID must be used when creating link-local addresses. If a node also implements virtual hosts, then each virtual host must have its own ESI. This ESI is used when joining a logical link on behalf of the emulated host. The SEL byte is used to identify the logical link. IID is used when creating link-local addresses. Native E.164 addresses would have to be handled differently. I think that by putting in some small restrictions on how virtual networking is accomplished, we don't have to be wasteful with ESIs. The SEL bytes are only needed when routing calls. We still get 48 bit host-tokens. We don't create huge ESI spaces. BTW, I think LANE generally does what you have suggested. That is, use the ESI (MAC) for the NIC as the stations MAC address on the ELAN. This limits the number of ELANs a station can join. In the Digital case, our current adapters have 8 ROM MAC addresses to support up to 8 ELANs. However, using the same 8 MAC addresses we can get 2K LISs. Big difference. --- 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
- ipv6nd-02.txt & autoconfig Albert Manfredi
- Re: ipv6nd-02.txt & autoconfig Grenville Armitage
- Re: ipv6nd-02.txt & autoconfig schulter
- Re: ipv6nd-02.txt & autoconfig Albert Manfredi
- Re: ipv6nd-02.txt & autoconfig Grenville Armitage
- Re: ipv6nd-02.txt & autoconfig schulter
- Re: ipv6nd-02.txt & autoconfig Grenville Armitage
- Re: ipv6nd-02.txt & autoconfig Masataka Ohta
- Re: ipv6nd-02.txt & autoconfig Andrew Smith
- Re: ipv6nd-02.txt & autoconfig Albert Manfredi
- Re: ipv6nd-02.txt & autoconfig schulter
- Re: ipv6nd-02.txt & autoconfig Albert Manfredi
- Re: ipv6nd-02.txt & autoconfig Andrew Smith
- Re: ipv6nd-02.txt & autoconfig schulter
- Re: ipv6nd-02.txt & autoconfig Andrew Smith
- Re: ipv6nd-02.txt & autoconfig Albert Manfredi
- Re: ipv6nd-02.txt & autoconfig Andrew Smith
- Re: ipv6nd-02.txt & autoconfig Grenville Armitage
- Re: ipv6nd-02.txt & autoconfig Grenville Armitage
- Re: ipv6nd-02.txt & autoconfig Masataka Ohta
- Re: ipv6nd-02.txt & autoconfig Juha Heinanen
- Re: ipv6nd-02.txt & autoconfig Brian Carpenter CERN-CN
- Re: ipv6nd-02.txt & autoconfig Eric W. Gray
- Re: ipv6nd-02.txt & autoconfig Eric W. Gray
- Re: ipv6nd-02.txt & autoconfig Grenville Armitage