[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)]]
- To: "'George Swallow'" <swallow@xxxxxxxxx>, "Pandey, Arun" <pandey.arun@xxxxxx>
- Subject: RE: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments (status) (osi-nsapa-numbers)]]
- From: "Rutemiller, John" <John.Rutemiller@xxxxxxxxxxx>
- Date: Thu, 16 Sep 2004 08:22:48 -0400
- Cc: Brian Haberman <brian@xxxxxxxxxxxxxxxxxx>,Mickey Spiegel <mspiegel@xxxxxxxxx>, "Townsend, Richard L,JR \(Rick\)" <rltownsend@xxxxxxxxxx>,"Andrew G. Malis" <andy.malis@xxxxxxxxxxx>, ipv6@xxxxxxxx,brc@xxxxxxxxxxxxxx, "Rutemiller, John" <John.Rutemiller@xxxxxxxxxxx>,Matthew BOCCI <Matthew.Bocci@xxxxxxxxxxxxx>
- Delivery-date: Thu, 16 Sep 2004 16:07:59 +0300
- Envelope-to: email@example.com
- List-help: <mailto:firstname.lastname@example.org?subject=help>
- List-id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
- List-post: <mailto:email@example.com>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,<mailto:firstname.lastname@example.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,<mailto:email@example.com?subject=unsubscribe>
- Sender: ipv6-bounces@xxxxxxxx
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
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
From: George Swallow [mailto:firstname.lastname@example.org]
Sent: Thursday, August 12, 2004 1:34 PM
To: Pandey, Arun
Cc: Rutemiller, John; Brian Haberman; Matthew BOCCI; Townsend, Richard
L, JR (Rick); email@example.com; Mickey Spiegel; Andrew G. Malis;
Subject: Re: [Fwd: [Fwd: Re: FWD: FW: General Request for Assignments
> 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
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
George Swallow Cisco Systems (978) 936-1398
1414 Massachusetts Avenue
Boxborough, MA 01719
IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6