Subject: Re: Request to Advance "IP Version 6 Addressing Architecture"

From: Keith Knightson <[email-masked]>
Date: Sun, 5 Nov 2000 15:05:12 -0500

Gentlemen,

I notice that many of previously assigned values for other address 
schemes have been removed and replaced by "unassigned".

I am not sure I fully understand the distinction between reserved and 
unassigned. It would seem to me that in neither case is it safe to 
use one of the values for any purpose whatsoever, since a reserved 
value might subsequently become unreserved, and an unassigned value 
might subsequently become assigned.  In either case, any intermediate 
use will lead to a potential encoding clash.

I see that the IPX class has been replaced by unassigned, also some 
other previous classes like geographic and provider-based have also 
been removed.

This seems to imply that these schemes are not seen as being used in 
the foreseeable future, and even their use as previously specified 
might lead to an encoding clash at some later date. Presumably these 
values could be used for some other completely different scheme in 
the future, unrelated to their previous incarnation.

Is my interpretation and conclusion correct?

On the other hand, I could see how these values might say reserved 
rather than unassigned. If a value is reserved is interpreted as 
never will be assigned, then it would be safe to use in its original 
context. But if this were the case why not leave them in as before?

Regards

Keith

At 1:57 PM -0700 06/10/2000, Bob Hinden wrote:
>Erik, Thomas,
>
>The chairs of the IP Next Generation working group, on behalf of the 
>working group, request that the following document be published as 
>an Draft Standard:
>
>	Title		: IP Version 6 Addressing Architecture
>	Author(s)	: B. Hinden, S. Deering
>	Filename	: draft-ietf-ipngwg-addr-arch-v3-02.txt
>	Pages		: 25
>	Date		: 05-Oct-00
>
>A working group last call for this document was completed on April 
>10, 2000 and the document was discussed at the Adelaide IETF 
>meeting.  The -02 version of the draft resolves issues raised during 
>the working group last call and subsequent discussion.
>
>This document will obsolete RFC2373.  Changes from RFC2373 are 
>listed in Appendix B.
>
>Bob Hinden / Steve Deering
>IPng Working Group Co-Chairs
>
>--------------------------------------------------------------------
>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]
>--------------------------------------------------------------------

--------------------------------------------------------------------
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: Bob Hinden <[email-masked]>
Date: Mon, 06 Nov 2000 02:12:33 -0800

Keith,

>unassigned. It would seem to me that in neither case is it safe to use one 
>of the values for any purpose whatsoever, since a reserved value might 
>subsequently become unreserved, and an unassigned value might subsequently 
>become assigned.  In either case, any intermediate use will lead to a 
>potential encoding clash.

Correct.

>I see that the IPX class has been replaced by unassigned, also some other 
>previous classes like geographic and provider-based have also been removed.

The geographic and provider-based were removed sometime ago when the 
current document (RFC2373) was published and was replaced by the 
Aggregatable Global Unicast Addresses format.  The IPX block was removed in 
the current draft after checking that there no intended usage planned.

>This seems to imply that these schemes are not seen as being used in the 
>foreseeable future, and even their use as previously specified might lead 
>to an encoding clash at some later date. Presumably these values could be 
>used for some other completely different scheme in the future, unrelated 
>to their previous incarnation.
>

The currently published document, RFC2373, in the IETF standard definition 
of the IPv6 address blocks.   When the current draft is published as an RFC 
it will obsolete RFC2373.  Any use of the address blocks outside of the 
current assignments are likely to conflict with future assignments and 
would be outside of IETF defined usage.

>On the other hand, I could see how these values might say reserved rather 
>than unassigned. If a value is reserved is interpreted as never will be 
>assigned, then it would be safe to use in its original context. But if 
>this were the case why not leave them in as before?

Reserved means that the block is intended for a particular usage or should 
not be used.  Unassigned means that it is open for future definition and 
usage.  The IPX block was changed from reserved to unassigned because it 
was no longer going to be used for IPX and is now available for future 
definition.

Hope this helps.

Regards,
Bob

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 07 Nov 2000 08:14:01 -0500

Hi,
	would it be relevant to now push RFC 2073 to historic at the same time as 
the new RFC replacing RFC2374?

 From RFC 2374:

    This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
    Address Format".  RFC 2073 will become historic.  The Aggregatable
    Global Unicast Address Format is an improvement over RFC 2073 in a

Marc.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 07 Nov 2000 14:12:35 -0800

Marc,

>         would it be relevant to now push RFC 2073 to historic at the same 
> time as the new RFC replacing RFC2374?

Thanks for pointing this out.  I agree it should be historic and have 
started talking to the Internet AD's to see how to proceed.

Bob