Re: ipv6nd-02.txt & autoconfig

Brian Carpenter CERN-CN <brian@dxcoms.cern.ch> Mon, 13 May 1996 14:25 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11503; 13 May 96 10:25 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11499; 13 May 96 10:25 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa07538; 13 May 96 10:25 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 KAA05019; Mon, 13 May 1996 10:19:32 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id KAA26417 for ip-atm-out; Mon, 13 May 1996 10:08:26 -0400 (EDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA26408 for <ip-atm@nexen.com>; Mon, 13 May 1996 10:08:22 -0400 (EDT)
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id KAA12074 for <ip-atm@nexen.com>; Mon, 13 May 1996 10:08:18 -0400 (EDT)
Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18215; Mon, 13 May 1996 16:08:12 +0200
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA17263; Mon, 13 May 1996 16:08:11 +0200
Message-Id: <9605131408.AA17263@dxcoms.cern.ch>
Subject: Re: ipv6nd-02.txt & autoconfig
To: ip-atm@nexen.com
Date: Mon, 13 May 1996 16:08:11 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Brian Carpenter CERN-CN <brian@dxcoms.cern.ch>
In-Reply-To: <199605122054.QAA02195@thumper.bellcore.com> from "Grenville Armitage" at May 12, 96 04:54:13 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
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

With respect to dead horses, I'll just remind you that
the Experimental RFC that defines the mapping of IPv6
addresses into NSAP format is stuck in the publication
queue (having been approved by the IESG but held up for
good reasons by the IANA).

The *current* text defining the mapping is attached FYI;
a revised I-D containing this text is coming RSN.

And think carefully before assuming that this has anything to do
with interface tokens for ND or autoconfig.

   Brian Carpenter

Extract from forthcoming draft-ietf-ipngwg-nsap-ipv6-01.txt:


6. IPv6 addresses inside an NSAPA

   If it is required, for whatever reason, to embed an IPv6 address
   inside a 20-octet NSAP address, then the following format MUST be
   used.

   A specific possible use of this embedding is to express an IP address
   within the ATM Forum address format.  Another  possible use would be
   to allow CLNP packets that encapsulate IPv6 packets to be routed in a
   CLNP network using the IPv6 address architecture. Several leading
   bytes of the IPv6 address could be used as a CLNP routing prefix.

   The first three octets are an IDP in binary format, using the AFI
   code in the process of being allocated to the IANA. The AFI value
   provisionally allocated is 35, but this requires a formal
   modification to [IS8348].  The encoding format is as for AFI value 47
   [IS8348]. The third octet of the IDP is known as the ICP (Internet
   Code Point) and its value must be zero. All other values are reserved
   for allocation by the IANA.

   Thus an AFI value of 35 with an ICP value of zero means that "this
   NSAPA embeds a 16 byte IPv6 address".

   The last octet is a selector.  To maintain compatibility with both
   NSAP format and IPv6 addressing, this octet must be present, but it
   has no significance for IPv6. Its default value is zero.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    0-3  |  AFI = 35     |   ICP = 0000                  | IPv6  (byte 0)|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    4-7  |             IPv6  (bytes 1-4)                                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    8-11 |             IPv6  (bytes 5-8)                                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    12-15|             IPv6  (bytes 9-12)                                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    16-19|       IPv6  (bytes 13-15)                     |0 0 0 0 0 0 0 0|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Theoretically this format would allow recursive address embedding.


Bound et al              Expires November 1996                 [Page 11]

Internet Draft            OSI NSAPs and IPv6                    May 1996


   However, this is considered dangerous since it might lead to routing
   table anomalies or to loops (compare [RFC1326]).  Thus embedded IPv6
   address MUST NOT have the prefixes 0x02 or 0x03, and an NSAPA with
   the IANA AFI code MUST NOT be embedded in an IPv6 header.

   An NSAPA with the IANA AFI code and ICP set to zero is converted to
   an IPv6 address by stripping off the first three and the twentieth
   octets. All other formats of NSAPA are handled according to the
   previous Chapters of this document.