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

[Brian E Carpenter <[e-mail]>]

Two quick comments, and then I suggest we drop this thread here.

On 12/08/2012 17:18, Curtis Villamizar wrote:
> 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.

Nevertheless, people do and will create islands, even very big ones,
with global-scope prefixes. Of course, if their *goal* is unreachability,
the reference problem doesn't matter.

> 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.

Which isn't, unfortunately, going to happen in our lifetimes.

   Brian

> 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
>