[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Moving forward on Site-Local and Local Addressing

[IPv6 working group chair hat on]

I think the working group has been making good progress on replacing 
site-local addresses and wanted to get feed back from the working group on 
how we should move forward.  This is not intended to directly relate to the 
ongoing appeal of the working groups decision to deprecate the usage 
site-local addresses, but to get feedback on how to proceed.  I think it is 
very important that we move forward on this issue and not rehash what has 
happened in the past.

We now have a combined local addressing requirements document 
<draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative to 
site-local addresses draft <draft-hinden-ipv6-global-local-addr-02.txt> 
(accepted as a working group item at the Vienna IETF), and will soon have a 
draft describing why site-local addresses are being deprecated and doing 
the formal deprecation (authors identified and outline discussed at the 
Vienna IETF).  Note that all of these documents will proceed through the 
normal working group and IETF processes of last calls and review.

I think legitimate questions have been raised about how the working group 
should go about deprecating site-local addresses given their maturity in 
the current specifications and use in deployed products.  Specifically 
should they be deprecated independently from having an alternative solution 
available, at the same time an alternative is available, or sometime after 
an alternative is available.  A forth alternative is to not replace 
site-local addresses in any form, but I think the working group has made it 
clear that this is not a reasonable alternative.

I would like to hear from the working group on how we should proceed.  I 
think the choices are:

A) Deprecate Site-Local addresses independently from having an alternative 
solution available.  This would mean that the working group should treat 
the deprecation, and requirements and solution documents outlined above 
independently from each other.  If there was no consensus on an alternative 
a replacement would not happen.

B) Deprecate Site-Local addresses at the same time as a alternative 
solution is agreed to.  This would mean advancing both documents at the 
same time and making them include normative references to each other to 
insure that they were published at the same time.  This would result in the 
deprecation only happening if a consensus was reached on an alternative.

C) Deprecate Site-Local addresses after an alternative is defined, 
standardized, and in operational practice.  This would mean not advancing a 
deprecation document until there was operational evidence that the 
alternative was working and shown to be an improvement over Site-Local 

Note:  In the above choices "Deprecate Site-Local addresses" means 
publishing an RFC that does the formal deprecation.

Please respond to the list with your preference, or if there is an 
alternative approach that is an improvement from the ones I outlined.  I 
hope that many of you will respond.


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 majordomo@sunroof.eng.sun.com