Subject: Consensus on Site-Local Discussion

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Jun 2002 08:29:02 -0700

The IPv6 working group chairs reading of the mailing list discussion 
regarding removing site-local addresses from the IPv6 architecture is that 
there is not a consensus to make this change.

 From the email discussion we also believe there is a consensus to not 
require IPv6 implementations to support connectivity to multiple 
sites.  The suggestion made by Tim Hartrick on the list is a reasonable way 
to resolve the requirement level of site-local.  Specifically:

 >What I would like to see come out of this long discussion is simply some text
 >in the in progress "Node Requirements" document that specifies how much 
of the
 >scoped address architecture MUST be implemented and that that text would say
 >that the rules specified in Draves' draft are the only MUST implement portion
 >of the architecture.  There should be no requirement that a node be able 
to be
 >part of more than one zone.

We believe the resulting actions from this discussion are:

  - No change to the IPv6 address architecture regarding site local
  - No change to the "Default Address Selection for IPv6" draft
  - Text to be added to the "IPv6 Node Requirements" draft as outlined by
    Tim Hartrick text (above).
  - The working group should complete the Scoped Address Architecture draft.

Bob Hinden, Steve Deering, Margaret Wasserman
IPv6 working group 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: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 12:29:39 -0400

I agree that there's probably not consensus to deprecate SL,
but I think we should consider finding ways to discourage its use,
and to remove the burden from apps of having to support it specially.

I don't agree that the Default Address Selection document should
be published without change, and I don't think we have consensus on
that at all.  though perhaps the sections on SL are okay.
(not sure what you meant here by "no change")

the introduction of scoped addresses into the Internet architecture 
has caused several problems for apps which are difficult to solve .
even if there's not consensus to do away with them entirely,
we need to understand how to minimize the damage, and that probably
means minimizing the use of limited-scope addresses.  So it's not
clear to me that having the WG complete the current Scoped Address
Architecture document is an appropriate goal.

Keith

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Jun 2002 10:45:23 -0700

Keith,

>(not sure what you meant here by "no change")

The intent of the line was regarding site-local only, specifically not the 
current discussion on permanent/temporary preferences.

>Architecture document is an appropriate goal.

The intent behind the "complete the Scoped Address Architecture" action was 
that if we are going to have site-local we need to define how they work.  I 
think you are suggesting that will need to do additional work to provide 
guidance as to the appropriate use of limited scope addresses, specifically 
including application considerations.  Agree?

Bob

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 14:40:26 -0400

> including application considerations.  Agree?

more or less agree.  and I still think we are better off providing a better 
alternative to SL addresses, even if we don't completely deprecate them. 

in other words, I think we need to seriously question some of the assumptions
behind the scoped addressing architecture, and I'm not confident that 
"completing the work on the Scoped Address Architecture document" will
accomplish that.

Keith

---

From: Brian Haberman <[email-masked]>
Date: Fri, 21 Jun 2002 17:10:19 -0400

Keith,

> "completing the work on the Scoped Address Architecture document" will

Can you enumerate what assumptions you are concerned about?  That would
give us the authors a better understanding of your concerns.

Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 17:21:19 -0400

> give us the authors a better understanding of your concerns.

I've about decided to write up an I-D before 9 AM Monday on this topic,
but here's the capsule summary:

the basic problem with limited-scope addresses is that they force some 
kinds of apps (in particular those that need to do referrals) to 

a) know about network topology and/or 
b) to provide lists of addresses in referrals and do trial-and-failure 
   to determine which address works (best or at all) in any context
   to which a referral might be propagated.

limited-duration addresses (such as v6 temporary addresses or v4 LLs) 
impose other problems - apps that use them have to recover from 
address changes.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Jun 2002 20:47:56 -0400

>but here's the capsule summary:

It would be great if you can get a draft out.  I'd like to understand
these issues better, and I think that it would be good for the group to
discuss them once the issues are better understood.

Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Jun 2002 16:04:40 +0200 (CEST)

Keith,

Would it make sense to add the issues that limited-scoped addresses 
create for applications as issues to the scoped address architecture?

I think having both this, plus the implementation issues for multi-sited nodes,
listed in that document would provide useful information to the community.

Another thing that can be contemplated relates to the "zeroconf" case 
(where some implementations might end up unnecessarily using smaller scope
addresses when the "home" temporarily is disconnected) would be a
recommendation that implementations try to provide address stability using
stable storage. For instance, I think it is quite reasoanble that
implementations that have stable storage retain their addresses and expiry
times (preferred and valid) whether the addresses were acquired using RFC 2462
or DHCP. Assuming the lifetimes used are reasonable this techniques implies
that a temporary outage (less than the preferred lifetime) will
never result in the node loosing its global address even if the 
node were to reboot.
Having said that, it isn't obvious to me in which document it would make
sense to add such a recommendation. RFC2462bis? The scoped address architecture
document?

   Erik

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 10:17:30 -0400

> create for applications as issues to the scoped address architecture?

maybe, but it's an issue for both v4 and v6, and it ties in with 
issues related to limited-duration addresses.  it's kind of a mess,
actually, both in that the issues are thorny and not easily
reasolved, and in that the topic touches on so many different areas.

I started working on a document to describe the problems that 
limited-scope addresses cause for apps, but I didn't finish by
today's deadline.  

Keith

---

From: Thomas Narten <[email-masked]>
Date: Mon, 24 Jun 2002 22:13:39 -0400

Keith,

> (not sure what you meant here by "no change")

Could you please be clear on what you mean above? A revised version of
draft-ietf-ipv6-default-addr-select-08.txt was submitted last week
with a note summarizing changes to the list. If you (or anyone) has
issues with that document, please be specific about what wording you
disagree with and how you think it needs changing. 

Thomas

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Jun 2002 16:43:11 +0200

In your previous mail you wrote:

   
   of the
   to be

   
   
=> I officially support this consensus (modulo the default address
selection document, I believe my opinion about it is already well-known).
I congratulate the chairs on this attempt to clarify the site-local
discussion.

Thanks

[email-masked]