[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of <draft-hinden-ipv6-global-local-addr-00.txt>



Pekka Savola wrote:
> 
> That's not the complete picture.  Addresses leak.  They leak to others
> using the local scope, but without connectivity.  I'd much prefer using
> globals first, because falling back to globals from first trying locals
> could take a long time (consider e.g. stupid firewalls who silently drop
> packets).
> 
> This should not be an important issue, but I fear in practice, it is..

Agreed.  There could be a long timeout on connection if we use an invalid
address (local or global) as our first choice, and an out-of-scope local is
theoretically guaranteed to be invalid.

Does that mean that routers that blackhole local addresses (or filters doing
the same thing) SHOULD (or MUST) return 'destination unreachable' messages? 
I'd previously thought MAY.


However, the counter-argument is stability.  IF my local network uses local
addresses and IF another local network leaks their local addresses and IF
these don't get filtered correctly then I get a long timeout.

In contrast, IF my local network uses local addresses then it implicitly
says 'my global address is less "robust"' (for some definition of robust). 
If your global address is more robust then WHY are you using locals?

Again, what is the scenario where you enable local addressing and then
expect applications not to use it for local communication?


Quote from a draft I've been fiddling with for the last couple of months...

   The IPv6 working group has identified three scenarios that would
   benefit from the existence of a local addressing scheme.

   o  Disconnected networks.

   o  Intermittently connected networks.

   o  Stable local addresses for changing ISPs without disrupting local
      communication.

   If we consider a disconnected network to be an intermittently
   connected network that has not been connected yet, all three resolve
   to a single scenario: a network that wishes to maintain a stable
   local address space regardless of the presence or absence of one or
   more ISPs.

Unless I'm missing something obvious, you use a local addressing scheme so
that your local connections can operate independently of the global
internet.  Where is the benefit in making these connections prefer global
addressing?


> > In a multi-addressing environment, applications must be ready to try
> > multiple source-destination address pairs until one succeeds.  A source
> > address selection compliant gethostbyname will return the destinations in
> > preferred order (taking into account available source addresses).  There is
> > an implementation question on what order the two dimensional destination and
> > source space should be searched.
> 
> I think the order is specified: destination first, unless the application
> specified the source address explicitly.

Checked RFC3484 - source address selection returns exactly one (the "best")
source address for a given destination address.

This leaves an operational quirk.  In general, I want to rank the array in
BOTH dimensions.  For example, I might prefer local-local to global-global,
but I certainly want to try both of them before trying something ugly like
global-local.  However, if I have three local sources, I might want to try
each against the local destination before trying the global destination with
a global source.

This implies some sort of two-dimensional ranking.  It seems the sensible
default is for the application to simply make a connection request using the
domain name and for the host to rank all source-dest pairs and then iterate
in order.  The app may wish to specify some timeouts (eg try no more than 3
dest addrs and no more than 3 sources per addr).

(Note: this latter problem is orthogonal to the local addressing issue, but
is necessary to solve decently if we want more than one address per node).

-- 
Andrew White                Andrew.E.White@motorola.com
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------