Alain, > Alain Durand wrote: > Oddly enough, from the same premises we arrived to opposite > conclusions! If you leave the space out of 2000::/3 as > 'unassigned' and I'm an implementor, I may put special > code when sending a Unicast packet to make sure that SRC & > DST addresses are within the valid range... > Once could then fear that an implementor might then interpret > that as "I'm going to hard code 2000::/3 as I do not know what > is going to happen with the rest of the space".
I don't see how one would reach that conclusion without figuring out that it would be a good way to shoot self in the foot later on. Besides, [ARCH] is clear enough about this topic: > [ARCH] > 2.4 Address Type Identification > The type of an IPv6 address is identified by the high-order bits of > the address, as follows: > Address type Binary prefix IPv6 notation Section > ------------ ------------- ------------- ------- > Unspecified 00...0 (128 bits) ::/128 2.5.2 > Loopback 00...1 (128 bits) ::1/128 2.5.3 > Multicast 11111111 FF00::/8 2.7 > Link-local unicast 1111111010 FE80::/10 2.5.6 > Site-local unicast 1111111011 FEC0::/10 2.5.6 > Global unicast (everything else) <<<=== already says this. I am not hot about putting "unassigned IPv6 address space should be treated as Global Unicast" in this text. It is clear that the end result will be the same for now, but what we really want is implementers *not* to hardcode anything and your text goes too far IMHO. Although I agree that treating unassigned space as Global Unicast is a good idea, there is no need to put it in the text. The rationale of this is that what we are contemplating now is that this doc will not make it to the standards track. It is permitted to think that future revisions of [ARCH] might change section 2.4 and it is possible (although not probable) that we might require later that unassigned space be treated as Multicast (or whatever). The point here is that if we need to modify [ARCH] later on, we don't want to have to modify this doc to sync it with the new [ARCH]. Your point is valid though, what about this: Proposed text: RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) which is formally made historic by this document. Although as specified in [ARCH] IANA should limit the IPv6 Global Unicast address space to 2000::/3 for now, IANA might later delegate currently unassigned parts of the IPv6 address space to the purpose of Global Unicast as well. Implementations MUST NOT make address range checks for Global Unicast addresses. (This would require to re-introduce a reference to RFC 2119 normative language, could be replaced by "must not" discretion of the authors). Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
