[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments (status) (osi-nsapa-numbers)]]



Using different ICP values is what I originally suggested. If you are OK
with this, I have no problems and we can proceed with this approach.

I would add one additional ICP, so that there are two types of IPv6
end-system addresses. 

The first format would retain the 6-byte ESI value currently defined for ATM
networks. This is necessary because the IPv6 end-system ID is 8 bytes and if
mapped directly could cause problems. Although this format does not all you
to drop in any IPv6 address, you can still retain the 8-byte prefix for IPv6
global addresses. This porpose of this format would be to ensure than any
existing ATM system could at least use an IPv6 based network prefix in the
address.

The second format would not place any significance on the 6 bytes normally
used by the ESI. The 16 bytes of IPv6 address can be any IPv6 address
format, no restrictions.

This would give us the following:

0000 Embedded IPv6 Address (SEL must be 0)
0001 Embedded IPv6 ATM End System Address (any valid IPv6 address + any SEL)
0002 IPv6 ATM End System Address (requires the 6 byte ESI)
0003 Embedded IPv4 Address (all remaining bytes = 0)
0004 IPv4 ATM End System Address


The final issue is the existing ITU X.213 document. They've guessed at
ICP=0001 for IPv4. However, they also allow either the Embedded format or
the IPv4 AESA you've described. Fortunately, they did indicate that the code
point had not been allocated and value was "proposed".

We've got two options. Either 1) retain code point 0001 for embedded IPv4,
or 2) include some text referencing the ITU documents and noting that the
values in this new RFC are different than what was indicated in those
documents. We probably need to do (2) regardless just to make sure it is
clear how X.213 relates to these definitions. If this is the case, then it
doesn't really matter if we keep 0001 for IPv4 or use it for IPv6.

John 



-----Original Message-----
From: George Swallow [mailto:swallow@cisco.com]
Sent: Thursday, September 16, 2004 11:07 AM
To: Rutemiller, John
Cc: Pandey, Arun; Brian Haberman; Matthew BOCCI; Townsend, Richard L, JR
(Rick); brc@zurich.ibm.com; Mickey Spiegel; Andrew G. Malis;
ipv6@ietf.org; swallow@cisco.com
Subject: Re: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments
(sta tus) (osi-nsapa-numbers)]] 


John -

I'd prefer not to define well known values.  I think I have another way
to avoid your issue.

Define four ICP values.

00 Embedded IPv6 Address
01 IPv6 ATM End System Address
02 Embedded IPv4 Address
03 IPv4 ATM End System Address

The encodings for the addresses remain the same.  For formats 00 and 02,
the unused fields Must be Zero on transmission and ignored on receipt.
For 01, 03 the unused fields may contain further identification relavant
to the application.  In both formats the last byte remains a selector.  In
03 the ESI exists as in any other AESA.

...George


========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------