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