Subject: Re: Regarding site-local addresses

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Dec 1999 23:45:40 -0800 (PST)

Christian,

> I tend to believe that the site-local addresses, as currently defined, will
> come out to hurt us in the future. I agree with Brian Zill that we have to
> provide a solution for the autoconfiguration of non connected sites, e.g. a
> home network with a mix of wireless, firewire, IP over the electric mesh,
> and what else. I am not sure, however, that the existence of the site
> address per se solves the problem.  If I am not mistaken, a host will only
> start configuring site addresses if a router advertizes a site address
> prefix. This router will have to be somehow configured, and prefixes will
> have to be allocated to the various LANs. From an operational point of
> view, configuring the router with a "uniquely tagged" site local address
> would be no harder than using a "zero-tagged" address. The specific
> experiment I would like is to insert an optional site-id, or site
> signature, in the site-local address format. 

This has been discussed a tad in the zeroconf WG.
I agree that there has to be a router advertising prefixes
to get site-local addresses.
But it is not infeasible to have the few routers in a home automatically
number the links - it is trivial if the home^H^H^H^Hzerconf environment
only contains one router (which routes between the wireless link, the Ethernet,
and whatever other link-layer technologies are used in the house).

But the key difference in having architected a site-local scope
has to do with what happens when a zerconf environment gets attached to
the Internet.
In IPv4 the only choice today is to force all the hosts to renumber
(using DHCP?) since the hosts can not know which source address they
can use for local communication vs. global communication.
This will of course break all local connections when the house is connected and
disconnected from the Internet.

In IPv6 with site-local scope and the source/dest address selection rules
the hosts can handle retaining the site-local address as they acquire global
addresses thus local connections will not break.

   Erik

--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 1999 22:42:33 +0100

In your previous mail you wrote:

   I changed the subject line to better reflect the issue.

=> thanks

   I think site-local addresses, or something very much like them,
   is useful and will work fine.

=> I believe they are useful (ie. there are some needs for them)
but I have a concern about multi-sited nodes because sites and
site-IDs are not fully defined (but this was worse in the past)
and because of the current intrinsic ambiguity of a site-local
address in a multi-sited context.
In most cases there is no multi-sited monster then I vote yes for
site-locals.
   
   I believe that if we do not specify site-local addresses specifically, we
   will end up with the equivalent of IPv4's net 10 anyway, due to marketplace
   pressures.

=> we need net 10 because it is too long, too expensive, ... to get
a global prefix in every cases and net 10/site-locals have the good
property they will *not* be routed across the site boundary.
(again the same argument I'm afraid :-)

   No, a single-sited end node doesn't need to know anything about site
   identifiers.
   
=> it is a reason to avoid multi-sited nodes until we fully understand them.

   No, a site-specific directory can hold site-local addresses.
   
=> I'll answer to Steve about this because I disagree.

   > >3) It should not be routed, but then it has
   > >   to be propagated for the needs of mobile nodes,
   > 
   > Exactly.
   
   I don't claim to be a mobile-IP expert, but I thought this was a solved
   problem in the mobile-IP draft.
   
=> I am afraid this is today the main problem with site-locals
because a mobile node will become a multi-sited node in the worst
conditions you can imagine... There are some parts of a solution
(without running code?) and it is not a surprise than mobility
and scope/zone idea don't fit well together.

   > >4) It is very hard to handle in multisited nodes.
   > 
   > Exactly.
   
=> I agree.

   I don't see this either, but I guess it depends upon your definition of
   "very hard".

=> "very hard": there is no consensus about how to do it nor running
codes which can show what are good solutions.

   Tagging every interface in a routing node with a node-specific
   site-id and then only forwarding between like site-ids seems pretty
   straight-forward.

=> this seems reasonable but restricts possible topologies: I am trying
to show that there still are some problems.

   So does only allowing end node originated packets to go
   out via interfaces with a site-id that matches the one in the sin6_scope_id
   field.  Our implementation does both of these today.
   
=> this is a working solution of a host (ie. end node) but in fact this is
exactly the strong model which is not very user friendly (ie. without
a scope ID you'll reject packets).

   Everything else is UI/API.

=> the whole problem is UI/API...
   
Thanks

[email-masked]