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 PROTECTED] Sent: Thursday, August 12, 2004 1:34 PM To: Pandey, Arun Cc: Rutemiller, John; Brian Haberman; Matthew BOCCI; Townsend, Richard L, JR (Rick); [EMAIL PROTECTED]; Mickey Spiegel; Andrew G. Malis; [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
