John/Mickey,
This is not my domain [ATM, draft-swallow], but if draft-swallow-pwe3-spvc-iw-01
"Mapping Addresses" is aligned with the ATM Forum specification "IP-Based Addressing
Version 1.0", would there be a need for a further format other than "IPv6 AESA
Compatible Format".
Brian Haberman,
Is the republication of section "IPv6 addresses inside an NSAPA" of RFC1888 required
to contain all additional formats of representing IPV6 inside an NSAPA like:
1. IPv6 AESA Compatible Format
2. OSI Directory Format - under works.
3. Others if any.
Regards,
Arun.
-----Original Message-----
From: Rutemiller, John [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 8:31 PM
To: Pandey, Arun; Brian E Carpenter
Cc: Matthew BOCCI; Townsend, Richard L, JR (Rick); Rutemiller, John;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Mickey Spiegel; Andrew G. Malis;
Brian Haberman; [EMAIL PROTECTED]
Subject: RE: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments
(status) (osi-nsapa-numbers)]]
Arun,
I'll offer to help work on this.
Something that needs to be pointed out before we get to much further into
this, and needs to be refected in draft-swallow-pwe3-spvc-iw-01, is:
In RFC-1888, the ICP code point 0x00 for IPv6 explicitly shows the selector
byte set to zero. Having the selector byte set to zero means it is possible
to directly map an IPv6 address into an NSAP address, and directly map an
NSAP address into an IPv6 address.
However, draft-swallow-pwe3-spvc-iw-01 does not retain this definition. This
draft uses the selector byte as a port identifier. This use is inconsistent
with the definition in RFC-1888.
The ATM Forum specification "IP-Based Addressing Version 1.0" retains the
RFC-1888 format and set the selector byte to zero. Also, the IPv4 format
used by this document also sets all bytes after the IPv4 address to zero,
again so that there is an unabiguous mapping from IP address to NSAP address
and from NSAP address to IP address.
If a format is desired in draft-swallow-pwe3-spvc-iw-01 that allows for the
use of the selector byte (or other bytes in the case of IPv4), then these
should be different ICP code points to distinguish them from a pure
IPv6-to-NSAP and IPv4-to-NSAP address mapping.
John
-----Original Message-----
From: Pandey, Arun [mailto:[EMAIL PROTECTED]
Sent: Friday, August 06, 2004 2:21 AM
To: Brian E Carpenter
Cc: Matthew BOCCI; Townsend, Richard L, JR (Rick);
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
Mickey Spiegel; Andrew G. Malis; Brian Haberman; [EMAIL PROTECTED]
Subject: RE: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments
(status) (osi-nsapa-numbers)]]
Brian,
Since I had promised some work on this, I have collected the following
information. It would be great to get your views on the same, before putting
further efforts.
>I think we will have to leave existing IANA assignments in place,
>but I will think a bit more about that.
Addressing this problem might require in the end to discuss IANA
assignments.
Please look at the end of this mail for 'Further Requirements for OSI
Directory' wherein a 'new special case format' of the IANA ICP has been
proposed. It would be great to get your views on the same, before putting
further efforts.
Below follows a discussion on:
------------------------------
1. Existing IANA assignments:
2. X.213 IANA ICP Proposal.
3. AESA Request for osi-nsapa-numbers Assignments +
draft-swallow-pwe3-spvc-iw-01.txt.
4. Summary of Assignments(assigned,proposed) till this point.
5. Further Requirements for OSI Directory. <---- Your views on its
acceptability to IANA required.
6. Summary of existing and required IANA ICP values.
Existing IANA assignments:
--------------------------
The AFI value 35 has been assigned to the IANA [IS 8348]. Within this format
a two octet
Internet Code Point (ICP) field is available for assignment by the IANA. All
ICP values
not listed below are reserved.
Assigned ICP Values
Value Meaning Reference
----- ------- ---------
0 Embedded IPv6 address [RFC1888]
In addition X.213 proposes:
---------------------------
At the time of publication of this annex, IANA had not allocated an ICP
value for IP
Version 4. In the absence of this allocation, the following value is
proposed:
ICP = 0001 IP Version 4 Address
NOTE 3 - An IPv4 address could be carried in the first 4 octets of the DSP.
The
remaining octets can be set to zero or a value as determined by the
application or
service required.
Also draft-swallow-pwe3-spvc-iw-01.txt section 6.3.1 'Mapping Addresses'
proposes:
----------------------------------------------------------------------------
------
|--AFI (Authority &
| Format Identifier) Selector
| |--IDP (Initial Domain Part) |
V V |<---- HO-DSP ----->|<-- ESI -->|V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|3|0 0|I P v 4|0 0 0 0 0 0| |0|
|5|0 1|Address|0 0 0 0 0 0| |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HO-DSP High Order Domain Specific Part
ESI End System Identifier
Figure 3: NSAP with Embedded IPv4 Address
|--AFI (Authority &
| Format Identifier) Selector
| |--IDP (Initial Domain Part) |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|3|0 0| I P v 6 A d d r e s s | |
|5|0 0| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NSAP with Embedded IPv6 Address
This allows for the identification of 256 ports. If more
ports are needed, multiple addresses must be assigned.
NOTE: the ICP=0000 is used for NSAP with Embedded IPv6 Address in this
active draft.
This is in slight variance with the earlier request for assignments from
AESA and X.213.
AESA Earlier Request:
>>>>> Two new (revised) ICP values for
>>>>> - IPv6 AESA Compatible Format (suggested value =2) <---- the
draft uses ICP=0000 for this.
>>>>> - IPv4 address Format (suggested value =1)
Summary Till this point:
------------------------
ICP = 0000 IP Version 6 Address [Embedded IPV6 Address]
ICP = 0001 IP Version 4 Address [Agrees with X.213 and can also carry
NSAP with
Embedded IPv4 Address as per
draft-swallow-pwe3-spvc-iw-01.txt]
ICP = 0002 IPv6 AESA Compatible Format
[As requested earlier by AESA but
draft-swallow-pwe3-spvc-iw-01.txt seems to use ICP=0000 for this purpose.]
Further Requirements for OSI Directory:
---------------------------------------
OSI Directory Service would require a SPECIAL ONE OCTET ICP, if at all a
provision was to be made to carry the tcp port number along with the IPV6
address inside an NSAP.
Wherein if the first Octet had the following value:
0000 1010 it would imply an OSI Directory format NSAP with an 16 octet IPV6
address and a 2 octet (16 bit) port number.
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 = 0A | IPv6 (byte 0)| IPv6 (byte 1)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv6 (bytes 2-5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | IPv6 (bytes 6-9) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| IPv6 (bytes 10-13) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| IPv6 (bytes 14-15) |tcp port number max val=65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This would leave the IANA ICP 4 digit values untouched. In the special case
of Directory services the special value of 0A in the first octect of the ICP
would mean that this is a restricted ICP [one octect long] the second octect
of the ICP being used in the DSP to allow carriage of the IPV6 address and
the tcp port number.
Where the following encoding rules will apply:
1. using two semi-octets to represent the two digits of the AFI, yielding a
value for
each semi-octet in the range 0000-1111.
2. using two semi-octets to represent the two digits of the special ICP 0A,
yielding a
value for the octet to be 0000-1010.
3. Representing a IPV6 binary syntax (IPV6 address) DSP directly as binary
octets;
4. Representing the tcp port number in 16 bits to have the values in the
range
0-65535 for example port number 102 would be represented as
00000000001100110.
The reason for choosing value ICP=0A for the restricted 2 digit ICP is that
if a decimal value was chosen to mean a 2 digit ICP it would waste a minimum
of 99 future IANA assignments (if they ever happen), for example if the
value ICP=01 meant a restricted two digit ICP then the values ICP=0100 to
0199 would not be assignable in future by IANA.
Also this new format could then be used by others also (IPv6 AESA Compatible
Format), who want to carry more information (bigger port numbers) along with
the IPV6 address inside an NSAP.
Summary of IANA ICP values required:
------------------------------------
ICP = 0000 IP Version 6 Address [Embedded IPV6 Address]
ICP = 0001 IP Version 4 Address [Agrees with X.213 and can also carry
NSAP with
Embedded IPv4 Address as per
draft-swallow-pwe3-spvc-iw-01.txt]
ICP = 0002 IPv6 AESA Compatible Format <--- Does AESA still want it, in
the background of draft-swallow-pwe3-spvc-iw-01.txt
ICP = 0A IPv6 OSI Directry Compatible Format [embedded IPV6 address and
tcp port number]
Regards,
Arun.
-----Original Message-----
From: Mickey Spiegel [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 9:54 PM
To: Andrew G. Malis
Cc: Matthew BOCCI; Townsend, Richard L, JR (Rick);
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
Pandey, Arun; [EMAIL PROTECTED]
Subject: Re: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments
(status) (osi-nsapa-numbers)]]
It is clear from the thread below that the replacement RFC should
contain (corrected) text from RFC 1888 on IPv6 addresses inside an
NSAP address (ICP codepoint 0, as defined in section 6 of RFC 1888).
Does the replacement RFC need to contain descriptions of the newly
requested codepoints for IPv4 and IPv6 AESA compatible formats, in
order to obtain the codepoints from IANA?
Note that the ATM Forum has not expressed any interest to date in
putting NSAP addresses inside IPv6 addresses (sections 3 through 5
of RFC 1888).
Mickey
> This is email 2 of 2. Brian said that he is working on having RFC 1888
> reclassified as historical, which will open the way for a short internet
> draft to make the assignments as requested by the ATM Forum. However, an
> editor will still be needed for that draft.
>
> Cheers,
> Andy
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
