(sipp) are you doing IPX mapping?

[Brian Carpenter CERN-CN <[e-mail]>]

Greg,

Will you do the IPX address mapping for IP6? I've started
seriously on the NSAP mapping with Jim Bound et al.
Just FYI, this is the current version (feel free to ignore it)

  Brian

Recommendations for OSI NSAP usage in IP6
=========================================

[Editorial note: Internet Draft boilerplate and formatting
will be added]

Abstract
--------
[TBD]

General recommendations
-----------------------

This document is principally addressed to network implementors who have
already planned or deployed an OSI NSAP addressing plan for
the usage of OSI CLNP [IS8473] according to the OSI network layer
addressing plan [IS8348]. It recommends how they should adapt their
addressing plan for use with IP6 [IP6].

The majority of CLNP addressing plans use either the Digital Country
Code (DCC) or the International Code Designator (ICD) formats
defined in [IS8348]. A particular example of this is the US
Government OSI Profile Version 2 (GOSIP) addressing plan [RFC1629].
Most of the present document refers to these address plans, which are
essentially binary byte-sequence plans. Brief reference is made
to decimal digit-sequence plans as used for ISDN and X.25.

The general recommendation is that organizations SHOULD remap their
CLNP addressing plans in the most natural way into native IP6
addressing plans according to [Rekhter]. While it is impossible 
to give a general recipe for this, CLNP addresses in DCC or ICD format
can normally be split into two parts: the high order part relating to the
network service provider and the low order part relating to the user
network topology and host computers. For example, in US GOSIP the high
order part is the AFI, ICD, DFI, AA and RD fields, together occupying
9 bytes. The low order part is the Area and ID fields, together
occupying 8 bytes. (The selector byte and the two reserved bytes
are not part of the addressing plan.)

Thus, for US GOSIP, the high-order part SHOULD be replaced by
the provider part of an IP6 provider-based addressing plan. 
An 8-byte provider prefix is recommended for this case and [Rekhter]
MUST be followed in planning such a replacement. The low
order part SHOULD then be mapped directly in the low-order half of
the IP6 address space, and user address plans are unchanged.
A 6-byte ID field mapped from US GOSIP will be acceptable for
IP6 autoconfiguration [Katz].

Analogous rules SHOULD be applied to other addressing plans similar
to US GOSIP.

Some organizations may decide for various reasons not to follow
the above recommendation and may wish to use their existing OSI NSAP
addressing plan unchanged for IP6. It should be noted that such
a decision has serious implications for routing, since it implies
that routing between such organizations and the rest of the Internet
can only occur at inter-domain level using IDRP. An organization
using both native IP6 addresses and NSAP addresses for IP6 would be
obliged to run two independent routing systems interconnected by IDRP.
Nevertheless, to cover this eventuality, the present document
defines a way to map a subset of the NSAP address space into the IP6
address space. The mapping is algorithmic and reversible within
this subset of NSAP address space.

Certain other uses of this algorithmic mapping could be envisaged.
It could be used as an intermediate addressing plan for a network
making a transition from CLNP to IPv6. It could be used in a
header translation scheme for dynamic translation between IPv6
and CLNP. It could be used to allow CLNP and IPv6 traffic to
share the same routing architecture within an organization (Ships
in the Day). It could possibly be used in an encapsulation scheme.

All these uses are DEPRECATED but if any of them are implemented,
or any other use of mapping, then the mapping defined below 
MUST be used.

NSAPA mapping into a 16-byte IP6 address for ICD and DCC cases
--------------------------------------------------------------
 

       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  |1 1 1 0 0 0|G|R| AFcode| IDI (last 3 digits)   |Prefix(octet 0)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4-7  |             Prefix (octets 1 through 4)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8-11 | Area (octets 0 and 1)         |  ID (octets 0 and 1)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12-15|             ID (octets 2 through 5)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The G bit is 1 for a group address, 0 for an individual address.

The R bit is reserved and must be set to 0.

The AFcode nibble is encoded as follows

    0000-1001      AFI value is 47 (ICD)
    (0-9 decimal)  AFcode is first BCD digit of the ICD 
                   IDI is last three BCD digits of the ICD

    1111           AFI value is 39 (DCC)
    (hex. F)       IDI is the three BCD digits of the DCC
 


The longest CLNP routing prefixes known today are 5 octets
(subdivided into AA and RD fields in US GOSIP version 2). Thus the
semantics of existing 20-octet NSAPAs can be fully mapped.
DECnet/OSI (R) address semantics are also fully mapped.

The NSEL octet is not included. It is of no use for TCP and UDP traffic,
but would be needed if a future revision of CLNP used the same format.
In this case it could be encoded as an end-to-end IP6 option.

A network using such addresses could route using suitably adapted
implementations of ES-IS, IS-IS and IDRP. It is expected that
hosts using such addresses could be auto-configured using [Katz].


NSAPA mapping into a 16-byte IP6 address for other formats
----------------------------------------------------------
 

       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  |1 1 1 0 0 0|G|R| AFcode| Start of IDI (N digits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4-7  |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8-11 |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12-15|             End of DSP (29-N digits)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 The G bit is reserved and must be set to 0.

 The R bit is reserved and must be set to 0.

 The AFcode nibble is encoded as follows

    
    1010           AFI value is 37 or 53 (X.121 binary)
    (hex. A)       IDI is the 14 BCD digits of X.121 address
                   DSP is up to 15 BCD digits 

         
    1011           AFI value is 45 or 59 (E.164 binary)
    (hex. B)       IDI is the 15 BCD digits of E.164 address
                   DSP is up to 14 BCD digits

    1100-1110      Reserved, not to be used.
    (hex. C, D, E)

The padding rules defined in [IS8348] are MODIFIED since only
BCD digits are used. All pads to IDI and DSP digit strings
consist of trailing ones (hex. F nibbles).

Restrictions in the NSAPA mappings
----------------------------------

Restrictions compared to [IS8348] are:

1. F.69 (Telex), E.163 (telephone) and Local formats cannot be mapped. 
It is not widely expected that IP6 will need to run with a Telex 
or POTS addressing plan. IP6 has a native method of supporting Local
addressing plans.

2. The DSP lengths for X.121 and E.164 are shorter than allowed
in [IS8348], where they are 24 and 23 digits respectively.  

3. Only the binary encodings of [IS8348] are supported.

Another restriction, for the US GOSIP case, is that that
the DFI byte (DSP Format Indentifier) is not mapped. It is
deemed to be 80 hexadecimal.

Annex: 16-byte IP6 addresses inside a 20-octet NSAPA
---------------------------------------------------

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

Use of this embedding is not specifically recommended, nor is it
deprecated. A possible goal would be to allow CLNP packets that 
encapsulate IP6 packets to be routed in a CLNP network using the IP6
address architecture. Several leading bytes of the IP6 address could be
used as a CLNP routing prefix. However, in general routing between
CLNP end-systems using this address format and those using another
format would require use of IDRP.

The first three octets are an IDP meaning "this NSAPA embeds a
16 byte IP6 address" and the last octet is a dummy selector.
It is considered unwise to overload the selector octet.

       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 = 47     |   ICD = ISoc (TBD)            | IP6  (byte 0) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4-7  |             IP6  (bytes 1-4)                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8-11 |             IP6  (bytes 5-8)                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12-15|             IP6  (bytes 9-12)                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16-19|       IP6  (bytes 13-15)                      |  NSEL = dummy |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Acknowledgements/co-authors [your name could go here!]: 
---------------------------

Scott Bradner, Richard Collella, John Curran, Bob Hinden, Cyndi Jung, 
Yakov Rekhter. 

References
----------

[IS8473] 

[IS8348] Annex A, Network Layer Addressing, and Annex B, Rationale
for the material in Annex A, of ISO/IEC 8348, 1993 (identical
to CCITT Recommendation X.213, 1992).

[IP6] The IP6 base documents

[RFC1629] The one that explains GOSIPv2 addressing

[Rekhter] Yakov told me that he and Peter Lothberg will
write a concrete address allocation document.

[Katz] Dave and Sue's autoconfig document.

---
 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to [e-mail]