Subject: RE: Scoping Scoped Addresses

From: "Michel Py" <[email-masked]>
Date: Thu, 7 Nov 2002 22:12:02 -0800

Andrew,

> Andrew White wrote:
> Note that site local prefixes have no requirement for
> global administration or registration, but are likewise
> not guaranteed unique, nor expected to be routeable
> outside the site.

I disagree with the wording of this. Site-locals MUST NOT be routable
outside the site, and the use of "expected" does not reflect this.

> Routers and hosts are only expected to support one site
> local scope. Further subdivision of a site local address
> space should be done using the site local aggregate
> portion of the SLA address.
> Optional: can also subdivide based on bits 17-48.

This is not optional. Some organizations will require more than a /48
for public space, it is highly likely that they would require more than
a /48 for site-locals as well. Site-locals are FEC0::/10.

Michel.

--------------------------------------------------------------------
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: "Michel Py" <[email-masked]>
Date: Thu, 7 Nov 2002 22:18:32 -0800

> Andrew White wrote:
> My short summary:
> (a) Within a "site", a site local address works at least
> as well as a global address.
> (b) Outside a site, a site local address DOES NOT WORK.
> I'd say "MUST NOT WORK", but that is a little hard to enforce.
> (c) Given (b), the issues with site locals are about address
> selection where there are both global and local addresses
> available.  However, these issues exist with any multi-homed
> host, and site locals at least offer applications some strong
> cues about when the addresses will fail.

I very much agree with this.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 14 Nov 2002 07:55:30 -0800

Ipv6 folk,

I think there are some of you that need to re-read what Bob Hinden post
here ten days and several hundreds email ago.

I support Bob in the statement he made as chair and I will continue to
work within the framework outlined below.

Michel

> Bob Hinden wrote:
[Working group chair hat on]

I have been trying to make some sense of this discussion.  The only
obvious 
conclusion is that there is not a consensus in the working group on how 
site-local addresses should be used.

Some people think that site-local is an important feature with many
uses, 
others think they are bad and should not be used.  Some think they
provide 
security, some do not.  Some thing they help with renumbering, some do 
not.  Some thing they help avoid IPv6 NAT's, some think they encourage
IPv6 
NAT's. Etc., etc.  The only thing that is clear is there are a
significant 
number of people who have different views on this topic.  It's doubtful 
that one group will convince the other group.  One positive result of
the 
discussion was that the issues and benefits are better understood.  The 
real question for the working group is what to do next.

Now that the IPv6 Address Architecture was approved as a Draft Standard
and 
the Default Address Selection document was previously approved, we have 
site-local addresses in IPv6 and a set of default rules for how an 
implementation selects them.  What we don't have is how they should be
used 
or not-used.

Even though there is no consensus on how site-local addresses should be 
used, I think there is enough people who want to use site-local that it
is 
reasonable that the w.g. should continue trying to flesh out site-local 
usage as well as pitfalls of usage.

Here is a proposal for how to proceed from here that tries to take into 
account both sides of the discussion.

1) Node Requirements should not require any multi-site 
implementations.  The only site-local requirement should be limited to
what 
is currently in the address selection rules and for routers to configure

site-locals just like any other unicast prefix.  Vendors are free to go 
beyond this in their products, but the IETF won't require it.

2) People who think the usage of site-local is harmful should write a
draft 
titled something like "Use of Site-local Addresses Considered 
Harmful".  The people in the other camp can comment to make sure the 
arguments are accurate.

3) People who want to use site-local addresses should work on completing

the "IPv6 Scoped Address Architecture" document (and other docs if 
needed).  I think a good focus for this would be to focus on the
simplest 
cases.  Topics to cover need to include site border routers, adding 
site-local addresses in the DNS, routing protocols, the use of firewalls
to 
enforce site boundaries, and guidelines on how applications might want
to 
select between global and site-local addresses.  The people in the other

camp can review this work and make sure the technical content is
accurate.

I believe this approach should help provide the larger community (e.g., 
vendors, ISP's, enterprise operators, etc.) the information they need to

make an informed decision on the usage of site-locals.

Bob

p.s. I will also send out a few personal comments on site-locals in a 
separate email.

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 15 Nov 2002 15:30:18 -0800

Rich,

 > I do not advocate requiring every host and router implementation to have
 > multi-site support. I think all that's required for host implementations
 > is the default address selection rules, and all that's required for
 > router implementations is to have two modes (either all interfaces are
 > in the same site so site-locals are treated like globals, or all
 > interfaces are in different sites so site-locals are filtered). This is
 > really very little burden for host and router implementations.

Sounds like you're referring here to the case of multilink subnets, as
in Dave and Christian's draft. Having multiple interfaces attached to the
same site vs. one interface per site is a design consideration we were
investigating for MANET applications at SRI shortly prior to my departure
6mos ago, but we didn't come to any firm conclusions.

I have been unable to find time to review that draft recently (let's just
say I've been off chasing wild geese), but I'm planning to take a look at
it today with two design points in mind:

  - does it scale to 10,000+ nodes? 100,000+ nodes? etc?
  - does it truly make life easier than multi-homing?

Thanks,

Fred Templin
[email-masked]

---

From: "Richard Draves" <[email-masked]>
Date: Fri, 15 Nov 2002 15:44:51 -0800

>  > I do not advocate requiring every host and router 
> implementation to have  > multi-site support. I think all 
> that's required for host implementations  > is the default 
> address selection rules, and all that's required for  > 
> router implementations is to have two modes (either all 
> interfaces are  > in the same site so site-locals are treated 
> like globals, or all  > interfaces are in different sites so 
> site-locals are filtered). This is  > really very little 
> burden for host and router implementations.
> 
> Sounds like you're referring here to the case of multilink 
> subnets, as in Dave and Christian's draft. Having multiple 
> interfaces attached to the same site vs. one interface per 
> site is a design consideration we were investigating for 
> MANET applications at SRI shortly prior to my departure 6mos 
> ago, but we didn't come to any firm conclusions.

Actually no, I was not referring to multilink subnets. I think they are
entirely unrelated.

Rich