Re: [homenet] tunnels as way to disambiguate .local

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Brian E Carpenter writes:
 
> On 07/08/2012 20:11, Michael Thomas wrote:
> > On 08/07/2012 11:46 AM, Kerry Lynn wrote:
> >> On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt <[e-mail]> wrote:
> >>>
> >>> Tunnels are okay, but to use them, but has to get the DNS search order
> >>> and the DNS server list right, and that's walled garden territory.
> >>> *If* we are going to turn each home into a walled garden, then let's be
> >>> aware that we are doing that.
> >> I'm of the opinion that in a "walled garden" scenario, the tunnel
> >> endpoint may
> >> be the only resource that needs a global name / address.
> > 
> > Just checking, but we all think that naming is a separate issue
> > from reachability, right?
>  
> It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps
> especially section 4.2 "FQDNs are not sufficient".
>  
>    Brian


Brian,

MIF may be trying to solve the problem the wrong way.  Providing a
mapping of DNS to loopback address has long been used (by routers) to
provide a stable reachable address.  The routing cost to reach that
loopback interface (which can change many times for an active
connection) is used to determine which physical interface gets used to
reach the loopback.  For example if one interface is connected to an
ethernet which gets isolated due to a router failure, the other
interface is used because routing tells us that one of them is
unreachable.

Multihoming of course pokes holes in the routing tables and causes
some routing table bloat.  This has always been a problem and IPv6
does nothing to improve the situation that existed in IPv4 two decades
ago with a lot of small providers and large enterprises using dual
provider multihoming.

If we are concerned with hosts that have multiple interfaces both
leading to parts of the homenet, that is easily solved.  Multihomed
homenets is a whole different problem, but solvable if redundancy is
to the same provider.  A conditional static route can be advertised
within the provider, with these routes having limited scope (for
example using BGP communities).  If this practice were to become
commonplace (I doubt it, no consumer provider has that sort of
redundancy in the last mile), then the provider would have to limit
the scope of these more specific routes to a small subset of their own
topology.

I get the impression that if NAT didn't exist, then
draft-carpenter-referral-ps would server no purpose.  Is this draft
entirely motivated by problems caused by NAT?

Curtis