Two quick comments, and then I suggest we drop this thread here. On 12/08/2012 17:18, Curtis Villamizar wrote: > In message <[email protected]> > 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 <[email protected]> >>> 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 <[email protected]> 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 > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
