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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Brian E Carpenter writes:
 
> > 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?
>  
> I don't think so. There are other causes of disjoint address space,
> which existed even before we had NAT or specialised firewalls -
> router ACLs for example. Certainly NAT is the major cause today (and
> NPTv6 will propagate the problem into IPv6). v4-only and v6-only
> islands will probably arise too.
>  
> Regards
>    Brian


Brian,

Without NAT there is no good reason to have an island.  If you create
an island (in IPv6) where none was needed, you get what you deserve.

NAT64 and DNS64 support v6-only islands.  The tide seems to be turning
on v4-only islands.  For example, I can fetch and build FreeBSD and
fetch all of the ports source for ports I use (>500 ports including
libraries, etc) on an IPv6 only host.  I'm confident the same would be
true of most Linux distributions.

Hosts are all dual stack.  They may end up roaming to a v4-only (or
less likely today v6-only) part of the network.  In that case a tunnel
to a DS network is needed and all is fine, performance suffering a
bit.  For example, an enterprise could go v6-only and allow either v4
or v6 tunneling (which is done today for VPN) from roaming employees
who end up in a v4 only place.  The same enterprise could do NAT64 and
DNS64 or could just set up a DS http/https proxy and mail relay at a
DS border.

I still see no purpose for draft-carpenter-referral-ps if NAT is
removed.

Curtis


> On 08/08/2012 19:39, Curtis Villamizar wrote:
> > 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