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

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 16 Sep 2004 08:22:48 -0400

Sorry for the delayed response.

First off, in reviewing RFC-1888 I made an error. I had thought this
document had limited the selector byte to zero because this is what was
reflected in the diagrams. After reading the RFC again, I discovered they
intended for zero to be the default value and they did allow for other
selector bytes (the diagram should have reflected this).

Now to the point.

My goal in the ATM Forum document was to have a one-to-one mapping between
an ATM address and an IPv6 address. Given nothing more than an IPv6 address,
you would know exactly how to create all 20 bytes of the ATM address, and
given the 20-bytes of the ATM address you would know exactly what IPv6
address it represented.

The same goes for IPv4 addresses, with the added caveat that the result
could potentially be routable in a PNNI network using address prefix lengths
that correlate to the IPv4 CIDR prefix lengths in use in a network. This is
why the format where the IPv4 address is left justfied rather than simply
embedding the IPv4 address in an IPv6 address first.

The primary reason for doing this was to make it possible to use IPv6 (or
IPv4) over ATM networks without requiring any type of address translation
server. Given an IPv6 desination address, it would be possible to
algorithmically create the appropriate ATM address. This eliminates the need
for an address resolution server, such as what is required with CLIP.

This is why I restricted the value to zero. If you have non-zero selector
bytes, then you cannot determine the ATM address from the IPv6 address
without first having to perform an address translation.

I understand that the selector byte is nothing more than a multiplexing ID,
similar to a TCP or UDP port number, with no defined well-known values.

I've been thinking about how to accomplish my goal of being able to support
IPv6/IPv4 over ATM without the need for address translation servers, and at
the same time avoiding over restricting the usage of the selector byte. I
also wanted to make sure I did not fundamentally break anything. 

The answer I've come up with is to define one well-known selector byte
value. That is value 0. The only protocol allowed to use a connection
established with SEL=0 when using the IPv6 encoding is an IPv6 stack with
the same IPv6 address as what is encoded in the ATM address.

For IPv4, an ATM address with all zeros after the encoded IPv4 address,
including the selector byte shall only be used for referencing an IPv4 stack
with the same IPv4 address as what is encoded in the ATM address. Non-zero
values after the encoded IPv4 address can be used however the end-systems
see fit.

This simple restriction preserves the behavior I was after, and preserves
the behavior defined in draft-swallow-pwe3-spvc-iw-01. It also does not
prevent the use of address translation servers, if that is what is desired.

I know that we've never defined well-know values for the selector byte in
the past. However, there is no reason we can't do this. As was pointed out,
the selector byte is similar to a TCP or UDP port number. These have
well-known values.

John

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Thursday, August 12, 2004 1:34 PM
To: Pandey, Arun
Cc: Rutemiller, John; Brian Haberman; Matthew BOCCI; Townsend, Richard
L, JR (Rick); [email-masked]; Mickey Spiegel; Andrew G. Malis;
[email-masked]; [email-masked]
Subject: Re: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments
(status) (osi-nsapa-numbers)]] 

> 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".

Yes it is aligned.  There was some discussion as to whether any other
information might have to be carried in the HO-DSP, but currently
none is.  If that were to change then I can see John R's point.  

I don't agree on the use of the Select Byte requiring a new format.
Always use zero.  If there is something other than zero, then that's
some additional information that is know to the hosts at each end.  
IP doesn't have this level of demux.  It uses protocol numbers and port
numbers (not physical ports) instead.  But unless something changed in
the last decade (which is how long it's been since I considered myself
expert in NSAPs) then there is no "well known" or reserved usage of
Select Bytes.  So I don't think the format has to constrain that.  

But we also have yet to say that we need to change the select byte.

As long as they remain aligned, we only need one ICP.  And I would
further argue that if only the select byte is modified, then we still
only need one.

At the momenent, my draft has not been formally accepted.  My suggestion
would be that I co-author a draft with someone from the ATM Forum to
secure the codepoint from IANA.  The codepoint 0000 is alread assinged
by IANA.  

...George

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: George Swallow <[email-masked]>
Date: Thu, 16 Sep 2004 11:07:20 -0400

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