Re: ipv6nd-02.txt & autoconfig

Juha Heinanen <jh@lohi.dat.tele.fi> Mon, 13 May 1996 05:26 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06161; 13 May 96 1:26 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06156; 13 May 96 1:26 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa01811; 13 May 96 1:26 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 BAA03523; Mon, 13 May 1996 01:26:14 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id BAA22251 for ip-atm-out; Mon, 13 May 1996 01:15:06 -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 BAA22241 for <ip-atm@nexen.com>; Mon, 13 May 1996 01:15:02 -0400 (EDT)
Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id BAA03473 for <ip-atm@nexen.com>; Mon, 13 May 1996 01:15:00 -0400 (EDT)
Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id IAA08870; Mon, 13 May 1996 08:14:34 +0300
Date: Mon, 13 May 1996 08:14:34 +0300
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Juha Heinanen <jh@lohi.dat.tele.fi>
Message-Id: <199605130514.IAA08870@lohi.dat.tele.fi>
To: gja@bellcore.com
CC: fddi1-ncd@baynetworks.com, ip-atm@nexen.com, gja@thumper.bellcore.com
In-reply-to: <199605122051.QAA01991@thumper.bellcore.com> (gja@bellcore.com)
Subject: Re: ipv6nd-02.txt & autoconfig
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 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.)

when ieee gets there virtual lan stuff defined and 1 gb ethernets become
available, we'll definitely start to see single physical ethernet
interfaces with multiple logical ip interfaces in the same way that
people are using atm interfaces today.  in case of ethernet, one can
tell the logical interfaces apart if each is assigned its own mac
address, but nothing would prevent inventing a trick to derive the link
local address from a single mac address.  in case of atm, the sel can be
used, since it is there, but it doesn't need to be used.

so my summary is: make derivation of link local address plug and play by
either using multiple esis or invent a trick that maps esi+sel to link
local address.  no matter which method is chosen, the important thing is
plug and play.  if that can't be achieved, the whole issue is not worth
standardizing.

-- juha