Subject: Current Results from Poll

From: Bob Hinden <[email-masked]>
Date: Wed, 27 Aug 2003 15:26:59 -0700

The current results of the poll (appended below) started early in August are:

     Preference A       21
     Preference B       13
     Preference C        7
                     ------
     Total              41

If you missed this and want to express a preference, please do so.  41 
isn't a large number given the size of the working group.  The chairs 
wanted to give folks who might have missed this due to being on vacation or 
who were overwhelmed by the amount of email a chance to respond.  You can 
send your responses directly to the chairs or to the list. We plan to send 
a final summary (including the actual results to make sure we got them 
correctly) in a few weeks.

Thanks,
Bob

>Date: Mon, 04 Aug 2003 11:06:55 -0700
>To: [email-masked]
>From: Bob Hinden <[email-masked]>
>Subject: Moving forward on Site-Local and Local Addressing
>Cc: [email-masked]
>
>[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 
>addresses.
>
>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.
>
>Thanks,
>Bob

--------------------------------------------------------------------
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: Andrew White <[email-masked]>
Date: Thu, 28 Aug 2003 09:48:00 +1000

Standardise a good local addressing solution as soon as responsibly
possible.  Some people seem to want to get rid of site locals.  I want to
achieve a local addressing solution that (as far as we can) removes the
perceived faults.

In practice, I think this is probably B, though might be C.  What I can say
is that it is not-A.

-- 
Andrew White

---

From: Greg Daley <[email-masked]>
Date: Thu, 28 Aug 2003 09:38:17 +1000

Hi Bob,

I know I'm late, but I vote for B.

Greg Daley

Bob Hinden wrote:
> wanted to give folks who might have missed this due to being on vacation 
> or who were overwhelmed by the amount of email a chance to respond.  You 
> can send your responses directly to the chairs or to the list. We plan 
> to send a final summary (including the actual results to make sure we 
> got them correctly) in a few weeks.
> 
> Thanks,
> Bob
> 
>> 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.
>>
>> <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 
>> 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.
>>
>> 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.
>>
>> 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 addresses.
>>
>> alternative approach that is an improvement from the ones I outlined.  
>> I hope that many of you will respond.
>>
>> Thanks,
>> Bob
> 
>

---

From: Mika Liljeberg <[email-masked]>
Date: Thu, 28 Aug 2003 08:59:13 +0300

I vote for B or C.

	MikaL

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Aug 2003 11:45:38 +0200

The deprecation text in draft-ietf-ipv6-deprecate-site-local-00.txt
was very carefully drafted after observing the mailing list debate,
including the earlier poll reponses. While I don't want to complicate 
the discussion further, I would like to suggest that people read
Section 4 of the draft very closely, before making their choice.

To save you some bother, here is that section in its entirety,
with a silly typo corrected:

4	Deprecation
   
   This document formally deprecates the IPv6 site-local unicast prefix
   defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The
   special behavior of this prefix MUST no longer be supported in new
   implementations. The prefix MUST NOT be reassigned for other use
   except by a future IETF standards action. Future versions of the
   addressing architecture [RFC3513] will include this information.
   
   However, router implementations SHOULD be configured to prevent
   routing of this prefix by default.
   
   Existing implementations and deployments MAY continue to use this
   prefix.

       Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Scott Bradner <[email-masked]>
Date: Thu, 28 Aug 2003 08:10:58 -0400 (EDT)

> If you missed this and want to express a preference, please do so.

B

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 28 Aug 2003 11:48:20 -0400

>    implementations. 

Does this imply "but SHOULD otherwise be treated like a global unicast
prefix"? 

>    routing of this prefix by default.

in the interests of increased precision, by "routing", do you mean:

	(distributing routing information relating to fec0::/10) or 
	(forwarding packets with destination in fec0::/10) or 
	(forwarding packets with source or destination in fec0::/10)

or some combination thereof?

						- Bill

---

From: Alain Durand <[email-masked]>
Date: Thu, 28 Aug 2003 10:24:18 -0700

>    special behavior of this prefix MUST no longer be supported in new

What does this last sentence exactly means? no special rules in address 
selection?
no special site ID treatment? It would be better to reference 
particular sections
of existing RFCs that gets obsoleted.

Btw, how can an IETF document say: an  MUST not support X" ? This makes 
little sense to me...
Now, what is a new implementation?

I would rather like to see some text like:
The following section of RFC x,y,z.... are obsoleted:

section a.b.c of RFC XXXX
.....

>  The prefix MUST NOT be reassigned for other use

This seems to contradict the initial sentence I have just commented on.

	- Alain.

---

From: "Alan E. Beard" <[email-masked]>
Date: Thu, 28 Aug 2003 22:33:29 -0400 (EDT)

Bob:

I've tried to duck this poll, but to no avail.

I prefer option A: deprecate SL, then go to work on defining suitable
alternatives. If we can't get concensus on one or more alternatives, we
punt.  8-(

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

---

From: "Chirayu Patel" <[email-masked]>
Date: Fri, 29 Aug 2003 09:19:05 +0530

> section a.b.c of RFC XXXX

That would be difficult. Text about Site-locals not localized. Maybe we can
rephrase the last sentence to

"Henceforth the prefix MUST be treated as an unassigned prefix by new IPv6
implementations."

> This seems to contradict the initial sentence I have just commented on.

RFC 3513 states - "Routers must not forward any packets with site-local source
or destination addresses outside of the site." (Note the "must")

On further thought, we can probably reorganize the section as:
 
"This document formally deprecates the IPv6 site-local unicast prefix defined
in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The prefix MUST NOT be
reassigned for other use except by a future IETF standards action. Future
versions of the addressing architecture [RFC3513] will include this
information.

Henceforth FEC0::/10 prefix MUST be treated as an unassigned prefix by new
IPv6 (for hosts as well as routers) implementations."

I also think that we need to have a line that says something like:

"The deprecation of IPv6 site-local unicast addresses is applicable to all the
usages as specified in RFC A, B, C, D... . Future versions of these RFC's will
remove information about site-locals".

---

From: Pekka Savola <[email-masked]>
Date: Fri, 29 Aug 2003 08:22:57 +0300 (EEST)

> The current results of the poll (appended below) started early in August are:

A.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Aug 2003 14:05:13 +0200

Thanks for this and the other comments. So far I detect broad agreement
with what the text is trying to achieve, since all the comments are
about how to make it clearer. That being so, I won't respond
individually, but I will stack up all these comments ready for the
next draft.

   Brian

---

From: stanislav shalunov <[email-masked]>
Date: 29 Aug 2003 10:34:01 -0400

I prefer option A.  (Having a local addressing scheme is preferred,
but deprecation of SL should go forward independently.)

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed upside down.

---

From: "Chirayu Patel" <[email-masked]>
Date: Fri, 29 Aug 2003 09:19:05 +0530

---

From: Alain Durand <[email-masked]>
Date: Fri, 29 Aug 2003 14:25:50 -0700

Chirayu Patel wrote:

>That would be difficult. Text about Site-locals not localized.
>
I just did a grep if the RFC database of "site local" and feco
I found only few meaningful references:

RFC2772, 6bone routing practise
RFC2894, router renumbering  (an example contains FEC0)
RFC3111, SLP (an example contains FEC0)
RFC3142, TRT (an example contains FEC0)
RFC3177, recommendation on /48, some text about site local beeing /48
RFC3082, Notification and Subscription for SLP, an example talks about 
site local
RFC3484, default address selection
RFC3513, IPv6 addr architecture

It seems to me that the main one to revisit is 3483.

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 29 Aug 2003 14:54:17 -0700

> It seems to me that the main one to revisit is 3483. 

oops... 3484. bad typo.

    - Alain.

---

From: Raul Rivero <[email-masked]>
Date: Sat, 30 Aug 2003 10:53:50 +0200 (CEST)

Hi all,

I vote for B.

--
Raul Rivero       | Mundinteractivos - El Mundo |
Director Tecnico  | Pradillo, 42                |
[email-masked] | 28002 - Madrid (SPAIN, EU)  |
www.elmundo.es    | Tel: (+34) 915856018        |
--------------------------------------------------------------------
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]
--------------------------------------------------------------------