Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"

From: "Michel Py" <[email-masked]>
Date: Fri, 21 Feb 2003 00:47:25 -0800

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-masked]
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Fri, 21 Feb 2003 00:52:20 -0800

> RFC2374 was the definition of addresses for Format Prefix 001 

Fine by me.

	- Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 11:10:36 +0100 (CET)

> Implementations MUST NOT make address range checks for Global Unicast

I'm missing the association with this document.

If we need to have a document which restates the instructions to the IANA
to allocate IPv6 addresses, can't we make that a separate exercise?

I'm not sure we need one, since IANA seems have enough information
at the moment.
 
  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Feb 2003 14:27:17 +0100

This is good. It leaves some more tricky options open for
later if we turn out to need tham.

   Brian