Subject: RE: My Thoughts on Site-Locals

From: "Christian Huitema" <[email-masked]>
Date: Fri, 4 Apr 2003 08:58:52 -0800

> This should not be surprising. Given that the applications community
> blindly assumes there is a single addressing scope, when they bump
into
> the reality of the deployed network there will be problems.
Proclaiming
> that scopes are bad for applications does not make the filtering that
> causes scopes go away.

Bad, bad application developers. We should really punish them! :-)

Seriously, application developers face some very real problems. The
issues are uniqueness in space and uniqueness in time. 

The space dimension is experienced when a host is connected to several
sites, e.g. home network and VPN. If the application receives a site
local address from a local name service or a local discovery service, it
must associate that address with a site identifier. The first stumbling
block is that most applications don't have this concept, they just copy
the address. 

The second stumbling block is that there are no readily available site
identifiers -- you would need to manage a unique name space, which is
precisely what you don't get from FFC0::/10. In the absence of site
identifier, the routing of connections to the proper site is haphazard.
The application is supposed to remember that the site local address was
learned through a specific site, i.e. only use in site X the site local
addresses learned from site X's DNS service. This become quickly very
hairy, as the DNS does not in fact have a concept of site.

Restricting hosts to handle exactly one site removes some of the
problem. But you then bump into the time dimension. Hosts may become
members of different sites at different times, e.g. a laptop moving from
the office to the airport or to the home. Addresses learned in one site
should not be used in the next, but for that you must have an easy way
to tell that you have changed sites. Without a site identifier, that can
be real hard.

Tony, these problems are not theoretical. They come very much on top of
the issues encountered by developers porting applications to IPv6.

Using unambiguous addresses solves a lot of the problems: a multi homed
site can route connections to the proper site, source address selection
can work, and moves to another site can be detected. There are remaining
issues, notably dealing with intermittent connectivity, but these issues
are inherent to any mobility scenario.

By the way, link local addresses tend to suffer from much of the same
issue. However, it is easier for applications to deal with LL addresses,
as there is a clear linkage between addresses and discovery protocols
operating in a single link.

-- Christian Huitema

--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Fri, 4 Apr 2003 10:16:45 -0800

Christian Huitema wrote:
> ...

Recognizing the smile, punishment was not my point. What many are
missing here is that the perspective of a single address scope does not,
and will not match the reality of the deployed network. 

> 
> Seriously, application developers face some very real 
> problems. The issues are uniqueness in space and uniqueness in time. 
> 
> The space dimension is experienced when a host is connected 
> to several sites, e.g. home network and VPN. If the 
> application receives a site local address from a local name 
> service or a local discovery service, it must associate that 
> address with a site identifier. The first stumbling block is 
> that most applications don't have this concept, they just 
> copy the address. 
> 
> The second stumbling block is that there are no readily 
> available site identifiers -- you would need to manage a 
> unique name space, which is precisely what you don't get from 
> FFC0::/10. In the absence of site identifier, the routing of 
> connections to the proper site is haphazard. The application 
> is supposed to remember that the site local address was 
> learned through a specific site, i.e. only use in site X the 
> site local addresses learned from site X's DNS service. This 
> become quickly very hairy, as the DNS does not in fact have a 
> concept of site.
> 
> Restricting hosts to handle exactly one site removes some of 
> the problem. But you then bump into the time dimension. Hosts 
> may become members of different sites at different times, 
> e.g. a laptop moving from the office to the airport or to the 
> home. Addresses learned in one site should not be used in the 
> next, but for that you must have an easy way to tell that you 
> have changed sites. Without a site identifier, that can be real hard.
> 
> Tony, these problems are not theoretical. They come very much 
> on top of the issues encountered by developers porting 
> applications to IPv6.

I have never argued that the problems are theoretical, just that it is
unreasonable for applications to blindly pass addresses outside the
context where they make sense. The problems you list do raise the bar
for application developers, but they are solvable. The other
unreasonable point is insisting that the one-time/app cost of a
developer dealing with complexity is more expensive than the continual
operational costs for the network manager when the complexity is pushed
there.

> 
> Using unambiguous addresses solves a lot of the problems: a 
> multi homed site can route connections to the proper site, 
> source address selection can work, and moves to another site 
> can be detected. There are remaining issues, notably dealing 
> with intermittent connectivity, but these issues are inherent 
> to any mobility scenario.

I agree, but we need to provide the alternatives first. Deprecating SL
without providing alternatives for all the requirements will lead us to
reinstating them when one of the requirements can't be met. 

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Apr 2003 11:01:53 +0200

> and will not match the reality of the deployed network.

Which means we need to give the middleware community good tools
for dealing with scope, and the reality of scope is more like
a Venn diagram than concentric circles. And as Tony has been saying,
this is a fact of life, and little to do with how we structure the
IPv6 addressing architecture.

The same is true of 2-faced or rather multi-faced DNS, however
much this may offend some people. It's a fact of life that middleware
needs to deal with.

I think this is largely an issue that has nothing to do with IPv6
at all, in fact. It's an issue of what kind of API is needed to expose
scope choices to middleware, even with IPv4.

   Brian