Re: ipv6nd-02.txt & autoconfig

Grenville Armitage <gja@bellcore.com> Sun, 12 May 1996 21:30 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12351; 12 May 96 17:30 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12342; 12 May 96 17:30 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa10614; 12 May 96 17:30 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 RAA02284; Sun, 12 May 1996 17:29:57 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id QAA19953 for ip-atm-out; Sun, 12 May 1996 16:51:26 -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 QAA19944 for <ip-atm@nexen.com>; Sun, 12 May 1996 16:51:23 -0400 (EDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id QAA02192 for <ip-atm@nexen.com>; Sun, 12 May 1996 16:51:21 -0400 (EDT)
Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.12/8.6.11) with ESMTP id QAA01991; Sun, 12 May 1996 16:51:02 -0400
Message-Id: <199605122051.QAA01991@thumper.bellcore.com>
To: Andrew Smith <fddi1-ncd@baynetworks.com>
cc: ip-atm@nexen.com, gja@thumper.bellcore.com
Subject: Re: ipv6nd-02.txt & autoconfig
In-reply-to: Your message of Fri, 10 May 1996 14:31:18 -0700. <9605102131.AA05447@milliways-le0.engwest>
Date: Sun, 12 May 1996 16:50:59 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Grenville Armitage <gja@bellcore.com>
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

[Andrew wrote, in part...]

>>Now I appreciate that IPv6 might have some different requirements but it
>>would be a noble goal to try to keep any requirements on the internal 
>>structure of the ATM addresses as close to zero as possible.

Couldn't put it better. Discussing Bert's concerns over the SEL
field has confused the issues, and I think the above point needs
to be re-inforced for the entire WG's benefit:

	The internal structure of ATM addresses has no dependency
	on IPv6 addresses.

Sure, there are some neato tricks that we are considering for deriving
certain IPv6 addresses from information that is also shared by an
end system's ATM address(es). But it is _crucial_ that people keep
perspective on this. If we cannot do the desired neato tricks
easily, we should not be tempted to go back to munge the use
of the ATM addresses to solve the problem. We should simply look
for another neato trick.

Case in point is identifying multiple IPv6 interfaces residing
over a single ATM NIC, where two or more of these IPv6 interfaces
represent independent IPv6 nodes on the same LLG. How such multiple
interfaces are represented at the ATM level should not be casually
screwed around with just to allow a trivial derivation of IPv6
link local addresses. (whilst this may not quite be putting the
cart before the horse, they're becoming disconcertingly close
to running neck and neck.)

gja