Subject: Consensus on Site-Local Addressing

From: Bob Hinden & Margaret Wasserman <[email-masked]>
Date: Wed, 09 Apr 2003 15:11:04 -0700

Hi All,

Well, that was fun!  :-)

All told, there were over 200 responses to the consensus call on IPv6 
site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 
site-local unicast addressing.  The final count (including the room and the 
mailing list) was:  155 YES, 56 NO (211 Total).

There were also a significant number of the people on both sides of this 
issue that voiced (in their original responses, or in subsequent messages) 
a strong belief that we should investigate alternative mechanisms for local 
addressing and local access control.

The chairs have read all of the messages on the list, and based on your 
considerable input, we have determined that the IPv6 WG does have rough 
consensus to deprecate the usage of IPv6 site-local unicast addressing AND 
to investigate alternative mechanisms for local addressing and local access 
control.

In particular, the IPv6 WG will work to accomplish the following things in 
parallel:

   (1) Publish an informational document that explains the issues
       encountered with site-local addressing and our reasons
       for deprecating IPv6 site-local unicast addresses.  This
       document will officially deprecate site-local addressing.

   (2) Remove site-local unicast addressing from the IPv6
       scoped addressing architecture I-D, and publish the
       parts of the document on which we do have consensus
       (i.e., link local addresses, multicast, etc.).  This
       will include a note that the IPv6 working group is
       investigating other forms of local IPv6 addressing and
       that the usage of any new forms of local addresses will be
       documented elsewhere.

   (3) Update the IPv6 addressing architecture to indicate that the
       usage of the FECO::/10 prefix for site-local addressing is
       deprecated.  To maintain backward compatibility with existing
       implementations the prefix should be reserved and should not
       be allocated for other purposes.

   (4) Define and publish the requirements for a local addressing
       mechanism to provide:
         - Addresses for disconnected networks.
         - Addresses for intermittently connected networks.
         - Addresses that support merging of sites.
         - Stable local addresses for changing ISPs without
           disrupting local communication.
       Once we have consensus on the requirements, the IPv6
       WG will work on solutions for local addressing that
       meet those requirements.

   (5) Define and publish the requirements for a local access
       control mechanism, then work on a solution that meets
       those requirements.

Each of these new work items will need to be added to the IPv6 WG charter 
and will go through the normal IETF document processes.  For (4) and (5) it 
is important to make the rest of the IETF community aware that the IPv6 WG 
is undertaking these tasks, so we will consider methods to invite wider 
review and discussion of these problems.

IPv6 site-local addressing has been a contentious issue in the IPv6 WG for 
some time, and we are both glad to see the WG reach consensus on this 
issue.  This will allow us to complete and publish the IPv6 scoped 
addressing architecture document, an important part of the IPv6 specification.

We hope that people on all sides of this issue will respect the rough 
consensus of the WG, and will work with us to achieve the goals outlined above.

Thanks to everyone who expressed an opinion during this discussion.

Bob Hinden & Margaret Wasserman
IPv6 WG 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]
--------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Thu, 10 Apr 2003 00:11:02 +0100

[...]

what do you propose to do with existing RFCs/drafts which refers
to/uses site-local addresses? RFC2894 comes to mind.

/ot

> In particular, the IPv6 WG will work to accomplish the following
> things in parallel:
>
> Each of these new work items will need to be added to the IPv6 WG
> charter and will go through the normal IETF document processes.  For
> (4) and (5) it is important to make the rest of the IETF community
> aware that the IPv6 WG is undertaking these tasks, so we will consider
> methods to invite wider review and discussion of these problems.
>
> IPv6 site-local addressing has been a contentious issue in the IPv6 WG
> for some time, and we are both glad to see the WG reach consensus on
> this issue.  This will allow us to complete and publish the IPv6
> scoped addressing architecture document, an important part of the IPv6
> specification.
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 09 Apr 2003 16:31:22 -0700

Ole,

>to/uses site-local addresses? RFC2894 comes to mind.

In the short term nothing.  There are existing implementations that use 
site-local.  Once (4) is further along we will likely have a better idea of 
how to update these documents.

Bob

---

From: Ralph Droms <[email-masked]>
Date: Wed, 9 Apr 2003 19:38:21 -0400 (EDT)

Bob - not to be difficult...by "implementations that use" do you mean
"devices that implement" or "deployments that use" site-locals?

- Ralph

---

From: Bob Hinden <[email-masked]>
Date: Wed, 09 Apr 2003 16:50:47 -0700

Ralph,

There are devices that implement site-locals and I would assume there is 
some usage as well.

Bob

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 09 Apr 2003 17:06:46 -0700

Bob,

>       WG will work on solutions for local addressing that

A fundamental question here is whether the disconnected/intermittently
connected networks will require subnetting internally. When subnetting
is not required, link-local addressing (i.e., FE80::/10) may be enough.

Fred
[email-masked]

---

From: Andrew White <[email-masked]>
Date: Thu, 10 Apr 2003 10:44:31 +1000

Bob Hinden wrote:
> site-local.

There's also the question of what you mean by 'implement site local'.  As I
see it, there are 5 aspects of 'site local' as defined in the architecture:

(1) Scopes and scope ids.
(2) The FEC0::/10 prefix.
(3) Ambiguity.
(4) Non-routeability of SL addresses beyond 'site' (more implicit than
explicit).
(5) The name 'site-local'.

Most people seemed happy to lose (1).  There are concerns about (3), but we
have several proposals to compensate.  Most "don't deprectate" people wanted
something that met (4).  (2) and (5) are details.

What did come out clearly (to me) is that there is a demand for
non-routeable provider independent (NRPI) address space, and site locals
were seen as providing that.

My summary of the NRPI requirements is:

- NRPIs must be optional.

- Non-routeability must be enforced
  - Routers by default black hole NRPI destinations.
  - Networks using NRPI must implement some form of NRPI border that
    drops NRPI destinations AND sources and prevents NRPI from being
    added to the global routing tables.

- NPRI prefixes must operationally be as unique as practical.
  - NRPI prefixes may be registered
  - It must be possible to get good-enough unique NRPI prefixes
    without a registration process.

And my contentious requirement:

- Unless otherwise configured, hosts / applications should favour
  NRPI-NRPI over global-global communication, and should disfavour
  NRPI-global communication.

>           disrupting local communication.

Looks a lot like the moderate SL proposal with mechanisms to prevent
ambiguity.

-- 
Andrew White                [email-masked]

---

From: Andrew White <[email-masked]>
Date: Thu, 10 Apr 2003 12:23:01 +1000

Greg Daley wrote:

> I'm just thinking that Ambiguity is more
> important to get rid of than scoping.

Greg,

I suppose what I'm saying is that the idea of multiple ambiguous overlapping
'sites' identified by some additional scoping mechanism (the 'full' model)
was generally seen as bad.  If your identifiers (NRPI or otherwise) are
unique enough, you don't need additional scope information to disambiguate
them.

Is that clearer, or am I getting messed up in terminology again?

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Apr 2003 02:46:24 -0400

Hi Fred,

>is not required, link-local addressing (i.e., FE80::/10) may be enough.

This is a good question for the requirements definition, and an
indication of why we think that we need to better understand the
requirements before specifying a solution.

Margaret

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 Apr 2003 16:44:06 +0700

Date:        Wed, 09 Apr 2003 15:11:04 -0700
    From:        Bob Hinden & Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | All told, there were over 200 responses to the consensus call on IPv6 
  | site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 
  | site-local unicast addressing.  The final count (including the room and the 
  | mailing list) was:  155 YES, 56 NO (211 Total).

As I just said in another message, I haven't been following what has been
going on here for some time, so I wasn't aware you were voting (which is
something the IETF doesn't normally do).

You can add me to the "no" list.

But 155 to 57 (or anything else like that) isn't consensus, or rough
consensus, for anything.   It is lack of consensus.   That's clear.

What's more, on another issue, 8-9 months again, where there was a
similar ratio in favour of a change, the chairs ruled that there was
no consensus, and so the change wouldn't be made.   Of course, that
was an issue where those opposed included one chair, and one AD,
and almost no-one else, so clearly there there could not be consensus
for a change could there?

Without consensus for a change, the docs should stay as they are,
just as was done last time.

  | There were also a significant number of the people on both sides of this 
  | issue that voiced (in their original responses, or in subsequent messages) 
  | a strong belief that we should investigate alternative mechanisms for local 
  | addressing and local access control.

This is just fine, the WG can certainly do that.   But the right thing
to do is to leave SL addressing in the spec now, until there is something
better to replace it.

Why would anyone want to take something that works just fine, within its
scope of usefulness, and discard it, and then go looking for a mechanism
to achieve all the same functions as the first offers.   What do we do
if after all that searching, we just return to where we are now?

  | The chairs have read all of the messages on the list, and based on your 
  | considerable input, we have determined that the IPv6 WG does have rough 
  | consensus to deprecate the usage of IPv6 site-local unicast addressing AND 
  | to investigate alternative mechanisms for local addressing and local access 
  | control.

You can expect an appeal against the decision that there is rough
consensus here.   What there is, is a debate.    You can treat this
message as an official request to the WG chairs that they reconsider
the stated position.   That's the first step ...

  | In particular, the IPv6 WG will work to accomplish the following things in 
  | parallel:
  | 
  |    (1) Publish an informational document that explains the issues
  |        encountered with site-local addressing and our reasons
  |        for deprecating IPv6 site-local unicast addresses.  This
  |        document will officially deprecate site-local addressing.

  |    (2) Remove site-local unicast addressing from the IPv6
  |        scoped addressing architecture I-D, and publish the
  |        parts of the document on which we do have consensus
  |        (i.e., link local addresses, multicast, etc.).  This
  |        will include a note that the IPv6 working group is
  |        investigating other forms of local IPv6 addressing and
  |        that the usage of any new forms of local addresses will be
  |        documented elsewhere.

  |    (3) Update the IPv6 addressing architecture to indicate that the
  |        usage of the FECO::/10 prefix for site-local addressing is
  |        deprecated.  To maintain backward compatibility with existing
  |        implementations the prefix should be reserved and should not
  |        be allocated for other purposes.

Those three should be deferred until after some other solution has
been found.   After all, that solution may result in none of the above
being required.

  |    (4) Define and publish the requirements for a local addressing
  |        mechanism to provide:
  |          - Addresses for disconnected networks.
  |          - Addresses for intermittently connected networks.
  |          - Addresses that support merging of sites.
  |          - Stable local addresses for changing ISPs without
  |            disrupting local communication.
  |        Once we have consensus on the requirements, the IPv6
  |        WG will work on solutions for local addressing that
  |        meet those requirements.
  | 
  |    (5) Define and publish the requirements for a local access
  |        control mechanism, then work on a solution that meets
  |        those requirements.

This is just fine, let the WG do just that.   If something results which
achieves all of what SL addressing accomplishes, with less imagined
problems, then it will make sense to deprecate SL addressing, and you
should find it fairly easy to obtain some kind of consensus to do that.

If no-one is able to find a better solution, then we'll at least have
one method for stable addressing which works (and even supports site
merging if the sites planned ahead and didn't just use 0 in the upper
38 bits, but put some random number there, which is trivial to do).

  | We hope that people on all sides of this issue will respect the rough 
  | consensus of the WG,

Sorry, I cannot believe there is any even rough consensus here.
Majority votes is not the way the IETF is supposed to operate.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Apr 2003 08:57:39 -0400

Hi Robert,

>just as was done last time.

What do you think it means for the documents to 'stay as they are'?

Right now, we have three Internet-Drafts that define different
options for the usage of site-local addressing.  One is a WG I-D,
the scoped addressing architecture, and two are individual.

We established in Yokohama (Summer 2002) that there was no consensus
to send the WG I-D, in its current form, to the IESG because of
unresolved issues with site-local addressing.  In Atlanta (fall 2002),
we established that the WG did not have consensus to pursue the
"full" usage model for site-locals currently documented in the WG
I-D.  In San Francisco (Spring 2003), it was quite clear that there
is no WG consensus to pursue any of the other usage models for
site-local ("moderate", "exclusive" or "limited").

So, I _think_ that leaving documents 'as they are' means leaving
the prefix in the addressing architecture and allowing all of the
I-Ds that specify any usage of it to expire as there is no consensus
to advance any of them.  Is that what you are proposing?

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Apr 2003 15:09:33 +0200

I'd like to reply to kre that IMHO the chairs are perfectly entitled
to declare a consensus on the basis of this straw poll. If you'd been
following the debate, you would realise that there is in fact a large
measure of agreement between the Nos and Yeses about the end goal (a
workable solution for stable addressing for fully or intermittently
disconnected sites). There's a smaller measure of disagreement about 
how the WG should proceed to find this solution. I don't think many
of the people engaged in the debate want the final result to be
today's SL definition. And given the way we use the word "deprecate"
in standards, deprecating and reserving FEC0::/10 won't break
anything that runs today, if we get Last Call consensus on doing so.

All we have now is a declared consensus on a direction of work,
and given the months of debate that led to this straw poll, I
think we should respect the result. 

So I specifically request the chairs *not* to reconsider their
stated position. Please maintain current course and speed.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 02:26:29 +0700

Date:        Thu, 10 Apr 2003 15:09:33 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | And given the way we use the word "deprecate"
  | in standards, deprecating and reserving FEC0::/10 won't break
  | anything that runs today, if we get Last Call consensus on doing so.

Only if you assume that implementors keep implementing what is
currently defined, and if you're assuming that, why "deprecate" anything,
what would that mean.

  | All we have now is a declared consensus on a direction of work,
  | and given the months of debate that led to this straw poll, I
  | think we should respect the result.

For the direction of work, I have no problem, as I said.   But there's
no need to go ripping anything out of the docs that are currently
published RFCs until there is something ready to replace it.

There's no need for that - unless there's some background assumption
that nothing will ever be produced to replace it, but SL addresses still
have to go anyway.

That is, SL addresses as we have them might not be perfect, but the
overall spec is much better with them than with nothing at all to
replace them.

kre

ps: there really is no need to quote my entire message in your reply,
that is an evil habit to get into.

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 02:18:49 +0700

Date:        Thu, 10 Apr 2003 08:57:39 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | What do you think it means for the documents to 'stay as they are'?

Site locals remain in the addressing architecture, as defined.

  | So, I _think_ that leaving documents 'as they are' means leaving
  | the prefix in the addressing architecture and allowing all of the
  | I-Ds that specify any usage of it to expire as there is no consensus
  | to advance any of them.  Is that what you are proposing?

That's just fine.   I don't need something to tell me the one true blessed
way to use the things, I can (and do) manage to use the things all by myself.

Others do the same, I expect.   The ways they use them, and the way I do,
are most likely not the same.   Who cares?

I just need implementations that implement what the address architecture
says should be done, not forwarding FEC0::/10 packets from one site to
another, which means, with the ability to specify what is one site, and
what is another.

Personally, I don't have much need (or any real need, other than for
experimentation) for multi-site nodes, so just "link in the site" and
"link not in the site" would be enough for me (but I also see no compelling
need to deprive others of multi-site nodes if they want them).

But if SL addresses are removed from the architecture, implementors will
quite likely start yanking the code that handles all of this, requiring
filters to block packets (which is possible) which are unlikely to then
send the ICMP "out of scope" type (which I hope by now has been returned
to the specs - Steve Deering did say that it just got accidentally
omitted, it is needed for LL's as well).

kre