Subject: Scoping Scoped Addresses

From: Bob Hinden <[email-masked]>
Date: Mon, 04 Nov 2002 13:43:32 -0800

Please excuse the pun in the title, but I wanted to get your attention :-)

[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.

--------------------------------------------------------------------
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: Wed, 06 Nov 2002 13:55:37 +1100

Bob Hinden wrote:

> 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.

Here is my summary of how site local prefixes might be used, written from a
high level perspective.  Constructive criticism and additional use cases
welcome.

Purpose:

The site local prefix is designed to allow numbering of leaf sites
independent from the global internet.

Three particular uses are envisaged:
- Experimental networks without connectivity to the global internet.
- Unconnected leaf networks
- Networks with intermittent connectivity (eg dial-up networks)

If a network has a sufficiently persistent globally assigned prefix, this
should be used instead of site local prefixes.  Site locals should only be
used if the network has no globally assigned prefix or if the global prefix
is unreliable (dial-up with dynamically assigned prefix, roving hotspot
device).

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.

Most of the complications with site local prefixes occur when a leaf network
attempts to support both site local and global addresses.

Routing:

Within a "site", site-local addresses are propagated as any other unicast
prefix.  The boundaries of a site are marked by site border routers, which
do not forward site local traffic from interfaces within a given site to
other interfaces.

Routers that are not intended to be part of a site should drop any
site-local traffic.

Scope:

Site-local addresses are only valid within their site (as defined by border
routers).  Site local addresses that leak outside this scope may or may not
be meaningful, and probably won't do what was expected or desired.

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.

Scope and Address selection:

Address selection for hosts is a difficult issue.

Destinations with only a global address (and hence probably outside the
site) should be addressed using that address, and the source address should
also be global.  Traffic destined for outside the site should fail if a
site-local source address is used.

Destinations with both global and site local addresses (internal hosts) can
be accessed using either.  Assuming that a site local exists because the
global address is not persistent, internal only applications should favour
site local addresses.  Applications that may include external hosts need to
use global addresses.

Note: This is IMO the real sticking point of site locals.  Globally unique
non-routeable addresses have exactly the same problem.  Filtering globally
unique routeable addresses is worse, since the reduced scope is hidden from
the application.

Merging:

If two sites using site locals merge, renumbering may be required (since the
addresses are not globally unique).  IPv6 networks should be designed to
support renumbering, and various mechanisms exist to do this.

Security:

Site local addresses provide no inherent security benefits, except that
hosts "know" that site local traffic shouldn't be router outside the site.

A variety of tunnelling mechanisms can break scoping, and thus this
security.

Naming:

I have some ideas, but for now see:
  draft-williams-dnsext-private-namespace-01.txt
for a site-scoped naming proposal.

This can easily be integrated with scoped addressing, where queries to a
site-local domain (hosted on a site-local nameserver) provide both local and
global addresses, while queries to a global domain provide only global
addresses.

-- 
Andrew White                [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 05 Nov 2002 22:59:36 -0500

this summary is a good start, IMHO.

> site local addresses.  Applications that may include external hosts need to

I think it's fairly arbitrary to distinguish "internal-only" applications
from "applications that may include external hosts".  How will the 
application know which category it is in?  What if different components 
of the application have different ideas about this?

> non-routeable addresses have exactly the same problem.  

I disagree here for what may be subtle reasons.  forgive me for trying
to explain them again.

My assumption is that if sites expect apps to use site-locals (and 
especially if we don't provide them with good alternatives) then customers 
will demand that many apps be able to operate across site boundaries using 
those addresses, adding considerable complexity to those apps and degrading 
their performance and reliability.   

OTOH if non-routable globals are available (except perhaps in isolated
sites where it doesn' t matter) then it becomes much more reasonable for 
many apps to simply use global addresses whenever they are available.
The app no longer needs to define its own addressing (at least not for
the purpose of working around SLs).  And it is no longer the app's 
responsibility to know about sites or to try to route between those sites.
If the network designers had wanted to provide a connection between 
those networks they would have done so.

(non-routable really means non-routable in the public internet - it
doesn't preclude routing via private connections)

> Filtering globally

My assumption is that the prefixes for non-routable global addresses 
would be well known, so they are as easily filtered as site locals.

However it would not really be valid for an app to assume that a
non-routable address had a reduced scope in comparison to a 
global address, or that such an address was less likely to work. 
On a network with extensive private connections to other networks but
lots of filtering on its connections to the public internet the app
might do better with the non-routable address.

Keith

---

From: Andrew White <[email-masked]>
Date: Thu, 07 Nov 2002 11:05:55 +1100

> of the application have different ideas about this?

Any application involving transactions between two hosts that doesn't want
to pass name or address information to a third party shouldn't have
problems.  In this situation, it's probably safe to pick a site-local if
it's mutually available.

The problem comes if machines A and B start talking, and then machine B
decides to forward A's address (or name) to C, who is outside the site.  If
B forwards a site scoped identifier, we've got a problem.

The simplest solution I can see is to make it a user problem - if you want
global connectivity, connect using a global name and thus force a global
address.  See notes on DNS.

Alternatively, an application that tries to forward a scoped identifier to a
target outside scope could:
  (1) Fail
  (2) Attempt to re-establish the session with a more suitable scope.

> > Note: This is IMO the real sticking point of site locals.  Globally
> > unique non-routeable addresses have exactly the same problem.
> 
> especially if we don't provide them with good alternatives) then
> customers will demand that many apps be able to operate across site
> boundaries using those addresses, adding considerable complexity to
> those apps and degrading their performance and reliability.

Hmm.  I think this assumption is not as robust as it should be.  The
presence of a site local prefix could mean:

- There is no global connection, at which point the very concept of
operating across site boundaries is meaningless.

- There is also a global connection, at which point the address selection
rules should use this for external connection.

The case of two disconnected sites merging is handled in the discussion on
renumbering.

IMO, we want to push site local addressing as a (2nd line) mechanism for
internal addressing independent of the global address space.  At the point a
network connects to the global internet, a set of global prefixes should be
distributed also.  The address selection rules are in place precisely to
deal with this multi-addressed situation.

In fact, once global connectivity exists, site local addresses should be
deprecated and eventually removed, unless the allocating authority (human or
automated) has reason to consider that the global prefix allocation is
"transient".

> those networks they would have done so.

For clarity, let's talk about restricted scope and global scope [unique]
addresses.  (Site local are restricted scope non-unique addresses.)

I must be missing something.  I read this several times, and it still seems
to be one of two situations:

- If apps can tell the difference in scope, then there is functionally no
difference a restricted scope unique or non-unique address.
Except:
  - restricted scope unique addresses can site merge, but I have already
    suggested that all sites should be configured to handle renumbering
    (which is particularly necessary if global prefixes may come and go).
  - non-unique addresses don't require a global allocating authority.

- If apps can't tell the difference, then your unique restricted scope
address is from the apps' perspective an unrestricted scope address, which
could lead to some "unexpected" failures due to filtering.

Alternatively, you could instantaneously deprecate all those restricted
scope unique addresses as soon as a global scope address became available,
but that is exactly the reason a network might run site locals and globals
in parallel - to maintain address persistence independent of a dynamic
global address.

What have I missed?

> might do better with the non-routable address.

So not a site, but a mesh of sites with arbitrary connectivity?

At this level of complexity, why not just use globally routeable prefixes
and configure the routers and filters to pass or block packets correctly?

If the sites were truly "disconnected", or someone particularly wanted to
use a private address space in parallel to the global one, the fec0:.../48
address space has plenty of room for bits 17-32 to be used as "site
identifiers".

Note that I am /not/ working on a model of an isolated network connected to
the global internet via a proxying mechanism (think NAT).  I'm assuming that
global connectivity is via true global addressing, and that hosts need to be
able to play nice in a situation where they have both site (restricted) and
global (unrestricted) scoped addresses available.

---

From: Keith Moore <[email-masked]>
Date: Wed, 06 Nov 2002 20:10:22 -0500

> problems.  In this situation, it's probably safe to pick a site-local if

people made similar incorrect generalizations about NATs.  
see http://www.cs.utk.edu/~moore/what-nats-break.html for a
list of the kinds of practices/assumptions broken by NATs.
many of these would also be broken by SLs.

> address.  See notes on DNS.

well, you might not want global connectivity but still want the
app to span site boundaries.  but yes, this works fine - provided, 
of course, that globals are available to such apps, and that people
don't expect such apps to function with only site locals.

>   (2) Attempt to re-establish the session with a more suitable scope.

again, (2) presumes that an address pair with "a more suitable scope"
is available and known to the app.  a big part of the problem is that 
lots of people will think that they can just assign SLs on their net 
and expect apps to work.  some apps will work, of course.

> rules should use this for external connection.

the presence of a site local isn't as significant as the absence of
a global address.  but the presence of a global address doesn't imply
a global connection.

the address selection rules won't save us for lots of reasons - 
one of which is that they favor SLs over globals even for apps
that will fail if they try to use SLs.

> deal with this multi-addressed situation.

except that they don't deal with this.  they assume that the only parties
concerned with use of an IP address are the immediate source and destination.
they assume that all applications have the same needs from addresses.
they assume that all networks have the same preference as to which 
addresses should be used.  etc.

> automated) has reason to consider that the global prefix allocation is

again, connectivity isn't necessarily either global or nonexistent.

and deprecating the site locals when globals are available would be fine 
with me, but lots of people claim that there are good reasons to keep them.

> addresses.  (Site local are restricted scope non-unique addresses.)

no, that's not clearer.  non-routable globals still have global scope.

don't confuse addres scope with connectivity.

> difference a restricted scope unique or non-unique address.

false.  non-routable globals are still useful as host/node identification
even in the (possibly temporary) absence of connectivity to that host.
 
> could lead to some "unexpected" failures due to filtering.

no, those kinds of failures should not be unexpected - every app should
be able to deal with them.  (particiularly if the right ICMP messages
result from trying to send traffic to those addresses).  "you can't
get there from here" is a perfectly valid error condition, since
it's a reflection of the underlying network's routing policy.
this is not a condition that the app should be trying to work around - 
it should simply report it.  

it's much harder to try to cleanly detect errors that result from trying 
to use ambiguous addresses.  but if globals are't available to 
non-globally-connected networks they'll use SLs and expect apps to 
route between them, and that's a mess.
 
> So not a site, but a mesh of sites with arbitrary connectivity?

right.  there's a lot of that going around.

> and configure the routers and filters to pass or block packets correctly?

that requires each network to have a connection through an ISP.
many networks don't want to do that.

Keith

---

From: Andrew White <[email-masked]>
Date: Thu, 07 Nov 2002 13:22:00 +1100

I apologise for the length - for the 8 line summary, skip to the bottom.

> many of these would also be broken by SLs.

Within a site, no.  Externally, of course.

A large number of your objections seem to boil down to "SLs break if people
try to use them for global connectivity".  This seems an education problem -
site locals are site local, which means exactly what it says.

NAT is a nasty kludge to give private addresses non-private connectivity.

A few of the notes on your list are are multi-homing issues.  These exist
independent of site-locals.

> > - There is also a global connection, at which point the address
> > selection rules should use this for external connection.
> 

Can you give me an example of an application that will fail if two (or more)
nodes in the same site attempt to communicate using site locals instead of
globals?

Of course, the instant you try to connect external to the site, things
/will/ (or SHOULD) fail if site locals are involved.

DNS is part of a solution.  Maintain two namespaces, one local (eg
private.arpa), one global.  If you want your application to play globally,
make sure they use the global names.

The app that comes to mind as a potential problem case is a broker for a
peer-peer mesh (eg game or teleconferencing client).  If A is the server,
and B (a machine in the same site) and C (an external machine) both try to
connect to it, it needs to be smart enough to obtain B's global address
(and/or name) so B and C can meaningfully communicate.

On the other hand, it's entirely possible that A, B and D (another local
machine) want to communicate locally, and the global address is "transient",
thus the local address is to be preferred.  User intervention is the only
way to solve this problem, as far as I can see.

> > IMO, we want to push site local addressing as a (2nd line) mechanism
> > for internal addressing independent of the global address space.  At
> > the point a network connects to the global internet, a set of global
> > prefixes should be distributed also.  The address selection rules are
> > in place precisely to deal with this multi-addressed situation.
> 
> except that they don't deal with this.  they assume that the only
> parties concerned with use of an IP address are the immediate source
> and destination.  they assume that all applications have the same needs
> from addresses.  they assume that all networks have the same preference
> as to which addresses should be used.  etc.

Agreed.  Which is why applications should be able to acquire a list of
addresses and meaningfully obtain information about their scope.  Not all
applications will approve of the default recommendation.

Note that this is not specifically a site-local issue, it is a multi-homing
and scoped addressing issue.

> don't confuse addres scope with connectivity.

For 99% of applications, connectivity is the issue.  I don't do an app any
favours if I say:

"Here are four candidate destination addresses, and you have three source
addresses.  I can't provide any hints about which combinations might work."

At least a site local says:

"To another site local, this as likely to work as any.  To anywhere else, I
can almost promise you it will fail."

In both cases the app should probably try all combinations, but at least we
can help it pick right the first time.

The assumption of course is that the site local destination address is 'in
scope'.  Hence the stress on not leaking addresses.  Within scope, a site
local provides as much information as any other address.  Outside scope, the
address is meaningless and any packet found with one should be discarded as
soon as possible.

> route between them, and that's a mess.

I find this argument specious.  It's about as much sense as saying "walk
into your local bookshop and buy me the third book in the fiction section",
and then complaining because you give me a different book than what I
expected from my bookshop.

From my original summary:

> Further subdivision of a site local address space should be done using
> the site local aggregate portion of the SLA address.

Or: "If you want to connect multiple networks, either configure them as a
single site, or use a bigger scoped address"

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.

---

From: Keith Moore <[email-masked]>
Date: Wed, 06 Nov 2002 22:23:54 -0500

> Within a site, no.  Externally, of course.

of course, for an isolated site they cause no problems at all.
but if the site has any external connections there will be apps
that are expected to take advantage of those external connections.

> try to use them for global connectivity".  

close.   SLs break if people expect apps that use them to communicate
with nodes that are off-site.    global connectivity is not a necessary
condition.

> This seems an education problem -

well, in an sense, education is what IETF does.  we need to educate
people so that they don't misuse SLs.

> independent of site-locals.

multi-homing issues won't go away entirely, but their effects can be 
minimized.  over-use of SLs will contribute to the problem.  
 
> nodes in the same site attempt to communicate using site locals instead of

when they learn of each other's addresses through an intermediary
which might not be in the same site.  the intermediary has no idea whether
those nodes are in the same site or not. 

> /will/ (or SHOULD) fail if site locals are involved.

no, it won't fail the *instant* you connect - it will fail in 
mysterious and unpredictable (to users) ways at some later time.

> make sure they use the global names.

I've seen this used as an attempt to try to cope with multihoming in 
IPv4 where not all interfaces were globally accessible.  my experience 
is that people have trouble remembering to use different sets of names 
for different purposes.

> (and/or name) so B and C can meaningfully communicate.

easliy done, *if* B has a global address.  I don't think everyone is 
assuming that it necessarily has or needs one.
 
> way to solve this problem, as far as I can see.

actually, not using limited-scope addresses helps a lot.   B and D
might still have to try multiple addresses, and if B tries the
transient address first it will have to time out.  but at least 
when B tries D's other address it doesn't reach a different host.

> addresses and meaningfully obtain information about their scope.  

no.  there's no way in general that an app can 'meaningfully obtain 
obtain information about their scope' if the absence of a global
set of scope names.  and if you do that you might as well embed the
scope name in the address - which gets you back to non-routable globals.

> Not all

true.  personally I like to think of it as an issue resulting from an 
over-dependence on address selection.  but it's really hard to talk 
about all of these issues at once - you have to pick one angle or 
another for the sake of a particular conversation.  

> addresses.  I can't provide any hints about which combinations might work."

so don't provide so many addresses unless it's absolutely necessary.
don't expect the app or the host to make such choices.
don't promote the idea that you can assign as many addresses to a host
as you want and expect apps to work.  finding a path through the network
from point A to point B is the network's job, not the job of applications.
and the network can do a better job if we at least try to have distinguished
names for points, even if not all points are reachable from all other points.

> can almost promise you it will fail."

the problem is, an app has no way of knowing whether it's local to that
site, or "anywhere else".  so it has nothing to inform that choice.
at least with NR globals the app has a chance of getting immediate
feedback (either from lack of a route or an ICMP message) if it tries
to send to an address that isn't reachable.   

> can help it pick right the first time.

site locals make this harder, not easier.

> address is meaningless and any packet found with one should be discarded as

nodes have no idea what scope they are in.  
 
> expected from my bookshop.

I don't follow your analogy.  Let me try one of my own.  Expecting 
apps to use SLs is like expecting that someone who is married to
a person named "mary" will be equally satisfied with the person 
named "mary" in whatever town he happens to be in (if there is one), 
or that he'll be satisfied if he cannot telephone his wife (or reaches
a different person) if he isn't in his hometown.  

> single site, or use a bigger scoped address"

better yet, use a scopeless address. scopes are too much trouble to deal with.
 
> (a) Within a "site", a site local address works at least as well as a global

true, but apps don't know when they're crossing site boundaries.

> WORK", but that is a little hard to enforce.

true.

> some strong cues about when the addresses will fail.

the last part is false - the app gets more cues if the addresses can at
least potentially be routed.   as for "these issues exist with any
multi-homed host"  pretending that it's a different (or somebody else's)
problem won't help minimize it.

Keith

---

From: Andrew White <[email-masked]>
Date: Thu, 07 Nov 2002 17:30:53 +1100

So, lets summarise again:

- In isolated and unconnected networks, site locals work fine.

- If a stable global prefix is available, we strongly recommend using that
and not using site locals.

- Site locals and global addresses can exist in parallel on the same
network, but this is likely to cause address selection problems for
applications.

- A site is demarcated by the presence of routers that will not forward
packets using site-local addresses (in source or destination).  Routers that
are not part of a site should not forward such packets.

- If multiple networks are to be connected using site local addresses, they
must be configured to be a single site.

- Site local addresses are explicitly invalid outside their site. 
Connectivity external to a site MUST NOT be done with site local addresses.
Sites MUST NOT route packets with site local addresses outside the site.

- Proxying or otherwise attempting to connect site local addresses to the
global internet (eg NAT) is explicitly discouraged.

Note: It might be possible to have site local traffic sent over a tunnel (eg
a VPN).  In such a situation, the VPN should be treated virtually as part of
the site.  Site local addresses must not leak outside the tunnel.  Though
there are probably better ways to do this than using site locals.

Does this seem a fair summary of principles thus far?

---

From: Andrew White <[email-masked]>
Date: Thu, 07 Nov 2002 17:47:46 +1100

> a different person) if he isn't in his hometown.

Ah.  I understand now, and this does highlight a potential problem.  It's
not just about filtering traffic between sites.  In the case where a node
leaves one site and moves to another, all site-scoped references to the old
site must be invalidated too.

If I have a cached reference to "mary" in my original site, it is unlikely
to do what I expect in my new site.

The presence of the interface id will help reduce this problem, but will not
eliminate it.

So a problem with site locals is that applications must not pass these
addresses (and perhaps names) around as if they were globally scoped, which
means that any application that could distribute or store addresses should
be aware of them and behave accordingly.  Alternatively, the user has to
make sure that the purity of the site is preserved.  Both options have
drawbacks.

Using unique addresses and prefixes removes the non-uniqueness problem
(addresses moved outside their intended scope simply fail), but reintroduces
the need for administration.

Do you agree?

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Nov 2002 08:30:48 -0500

This seems like a good start.

I think it would help to provide some advice to applications regarding
site-locals (and for that matter link-locals).  e.g.

- don't use site-locals in referrals unless you have no global addresses.
- use global addresses in preference to site-locals when opening new 
  connections.

I think there will be enough desire to use site-locals at least for
limited-purposes in networks that also have stable globals, and that
it will be useful to provide some advice on how to constrain such use.

I think there is a need for sites to acquire globals even if they do
not connect to the public Internet.  I don't think coordinating use
of site-locals will scale.

I think it needs to be explained that site-locals don't really provide 
a security benefit.

What did I miss?

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Nov 2002 08:39:35 -0500

> site must be invalidated too.

I hadn't thought of that case, but you are right. For a host using mobile-ip
the site-local address is not necessarily more stable than the global 
address.

> The presence of the interface id will help reduce this problem, but will not

Well, the host knows that it has moved, and any processes on that host
can figure it out by various means.  With some work the host and 
applications could invalidate their own references to site locals
from the old site.  However the host may not be able to invalidate other 
hosts' or processes' references to that hosts's old site-local address.
 
> make sure that the purity of the site is preserved.  Both options have

Seems right.  And one of my primary goals here is to relieve applications
of the burden of trying to deal with site-locals when those applications
cross site boundaries.  Having those apps refuse to use SLs  and LLs in
referrals (when globals are available) is a reasonable strategy as long 
as those apps have global addresses to use instead.

> the need for administration.

I'm not sure what you mean by 'the need for administration'.  Or are you just
saying that we need a way to assign unique prefixes for those sites?

Keith

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Nov 2002 15:12:56 +0000

> This seems like a good start.

Indeed, shame it didn't come 200 emails ago ;-)  It seems some concensus
can be reached on the assumption that site locals will continue to exist,
although many of us may be happy to not use them.   Darwinism may 
prevail here.

> - use global addresses in preference to site-locals when opening new 

Although that removes the advantage of site local addressing allowing
long-lived connections (e.g. NFS) to survive renumbering, or temporary or
permanent removal of external connectivity.   The implications on
deprecation of the global prefix differ depending on whether the site can 
reconnect later with the same global prefix (ie. the ISP uses static /48 
assignments or not), but maybe that is a dangerous path to explore.

The applications advice also implies some note required for DNS behaviour, 
in terms of what is offered in response to a remote query and how it is 
handled (or not).
 
> it will be useful to provide some advice on how to constrain such use.

Maybe add a note that well-known site locals may be recommended or suggested 
for service discovery for certain services (witness the recent DNS discussion),
so there's one use (which is in the spirit of site locals, and where cross-
site connectivity is probably not rquired).

Many networks use private IP space for network management (in or out of
band); site locals may (will?) have a similar popular use in IPv6.  Of
course at the moment IPv4 access is used for most IPv6 network management(!).

We may find that site-locals offer some use in future renumbering, multihoming 
or other service solutions, that have not been foreseen yet.  

> of site-locals will scale.

The question then is who maintains the "site-local global"(sic) address 
space?   If it is not coordinated and unique, do you really buy much over 
site locals which are only unique to the site?  Or are you suggesting to go
to an ISP for a /48 and a 0Mbps link? :)  Site locals can allow more than
/48's to be used for a "super site".  What size allocations would you
advocate for "site-local globals"?  Maybe this is a service an exchange
can offer, on a regional basis, to cater for the bulk of (non-international)
cases.

> I think it needs to be explained that site-locals don't really provide 

I think this is very important.   But people will be free to 
 
> What did I miss?
 
I think you've been quite thorough :)  Pekka's concerns are also very valid.

Tim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Nov 2002 10:44:36 -0500

>the site-local address is not necessarily more stable than the global

Is this situation - a mobile node using site-local addresses moving to a 
new "site" - an opportunity for inadvertent (or possibly even malicious) 
TCP session hijacking?  I.e., is the problem worse in the case of active 
applications that may be affected by the move to a new site?

- Ralph

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 7 Nov 2002 17:10:03 +0100

Hi,

> applications that may be affected by the move to a new site?

Shouldn't DAD detect this?

	-is

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Nov 2002 11:20:49 -0500

> although many of us may be happy to not use them.   Darwinism may 

aside: I realize that evolutionary theory has taken on almost axiomatic
status for many people,  but it's not clear to me that Darwinian selection 
really does select the fittest candidate for the long term in a global 
environment, any more than hill-climbing methods of optimization produce 
the best solution over an entire solution-space.   

> permanent removal of external connectivity.   

right.  it would still be possible to explicitly specify SLs, though 
explicitly specifying any IPv6 address seems likely to be viewed as painful.

> The implications on

right.  you really want to treat stable prefixes differently from unstable
ones, but how is the application to know which are which?
 
> in terms of what is offered in response to a remote query and how it is 

what is a remote query?  DNS needs to produce consistent results no matter
where the request comes from.

I don't really think that DNS should be treated any differently than any 
other app that performs referrals.  If we find ourselves wanting/needing 
to make special exceptions for DNS in order to accomodate scoped addresses
that is a sign that we're probably breaking other apps. 

> for service discovery for certain services (witness the recent DNS 
> discussion), so there's one use (which is in the spirit of site locals, 
> and where cross-site connectivity is probably not rquired).
> 

they could.  though again, specifying IP address literals will probably
seem painful.  of course, in the case of SLs, that might be a Good Thing.

> We may find that site-locals offer some use in future renumbering, 
> multihoming or other service solutions, that have not been foreseen yet.  

certainly they could be useful in renumbering.

> space?   

I have several (possibly lame) ideas:

- IANA and/or RIRs delegate prefix blocks to the registrars that are already
  qualified to sell domain names, who can then sell such prefixes.

- we find some way to derive a unique 48-bit prefix from an Ethernet address
  which doesn't eat up all of the v6 address space and doesn't conflict
  with existing address allocations.   then, any site can take an Ethernet
  address and derive a prefix from it.

  (I don't remember how many bits of Ethernet address space are reserved 
  for things like global/private or unicast/multicast, so I don't know 
  how much we can shrink down a 48 bit Ethernet address and still be 
  assured of having a unique bit pattern.  and this doesn't solve the problem
  for interfaces that use 64 bit hardware addresses)

  a site could continue to use that prefix as long as it kept the hardware
  with that ethernet interface in its possession.  (so you could sell the
  router but keep the ethernet card.  or you could sell the card but keep 
  the address rom. :)
  
- IANA delegates prefix blocks to router vendors, who assign them to their
  customers by means of their choosing (provided that at most one 
  prefix is assigned per router).   for instance, a prefix might be included 
  with each router, and printed on a label on the side of the box.  
  (the router should not expect that prefix to actually be used)

  a site could continue to use that prefix as long as it kept that label :)

offhand, the last idea seems the most attractive, but I don't claim to 
be aware of all of the implications.

Ideally allocations of globally-unique private addresses (GUPAs?)
would be /48s, as this would simplify renumbering and having
multiple prefixes when it was necessary to do so.

Keith