Re: ipv6nd-02.txt & autoconfig

Albert Manfredi <manfredi@engr05.comsys.rockwell.com> Fri, 10 May 1996 22:55 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27082; 10 May 96 18:55 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27078; 10 May 96 18:55 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa17706; 10 May 96 18:55 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 SAA29002; Fri, 10 May 1996 18:45:55 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id SAA03972 for ip-atm-out; Fri, 10 May 1996 18:39:48 -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 SAA03963 for <ip-atm@nexen.com>; Fri, 10 May 1996 18:39:44 -0400 (EDT)
Received: from ENGR05 (engr05.comsys.rockwell.com [199.191.48.132]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id SAA28953 for <ip-atm@nexen.com>; Fri, 10 May 1996 18:39:42 -0400 (EDT)
Received: by engr05.comsys.rockwell.com (UCX V4.0-10B, OpenVMS V6.1 VAX); Fri, 10 May 1996 18:40:15 -0400
Message-ID: <3193F050.6880@engr05.comsys.rockwell.com>
Date: Fri, 10 May 1996 18:41:36 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Albert Manfredi <manfredi@engr05.comsys.rockwell.com>
Organization: Rockwell Defense Electronics - Collins
X-Mailer: Mozilla 2.01 (Win16; I)
MIME-Version: 1.0
To: fddi1-ncd@baynetworks.com
CC: IP-ATM Working Group <ip-atm@nexen.com>
Subject: Re: ipv6nd-02.txt & autoconfig
References: <md5:10AE5309BE7543A3CF8F84CF20CE7C1E>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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

fddi1-ncd@baynetworks.com wrote:

> LANE did not seem to need any mention of what was inside the NSAPA: nowhere
> in the protocol is any structure assumed and the only requirements that
> LANE imposes are that clients have uniqueness in the complete opaque bitstring.
> 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.

Noble, perhaps, from the point of view of IP. Especially if we further
expect to use IP routers between all LLGs (LISs, whatever).

But insisting on useful ATM addresses is noble from the ATM perspective,
to facilitate cut-through, native ATM effectiveness, and so forth.

So overall, it's best to worry both address formats to death.

> BTW, in LANE, a client can use whatever MAC address it wants to to be bound
> to its "primary ATM address" - there is no requirement for ESIs to match
> the declared MAC address. Also, a client can use as many other ATM addresses or
> MAC addresses as it wants (the bindings between them must be relatively
> static of course) although that is probably not relevant here.

I agree. We need something to support autoconfiguration here. LANE is not
relevant.

Bert
manfredi@engr05.comsys.rockwell.com