Re: IPv6 fc00::/7 — Unique local addresses

Mark Andrews marka at isc.org
Thu Oct 21 22:15:39 UTC 2010


In message <E22A56B3-68F1-4A75-A091-E416800C485B at delong.com>, Owen DeLong write
s:
> >>> 
> >> Which is part one of the three things that have to happen to make ULA
> >> really bad for the internet.
> >> 
> >> Part 2 will be when the first provider accepts a large sum of money to
> >> route it within their public network between multiple sites owned by
> >> the same customer.
> >> 
> > 
> > That same customer is also going to have enough global address
> > space to be able to reach other global destinations, at least enough
> > space for all nodes that are permitted to access the Internet, if not
> > more. Proper global address space ensures that if a global destination
> > is reachable, then there is a high probability of successfully reaching
> > it. The scope of external ULA reachability, regardless of how much
> > money is thrown at the problem, isn't going to be as good as proper
> > global addresses.
> > 
> _IF_ they implement as intended and as documented. As you've
> noted there's a lot of confusion and a lot of people not reading the
> documents, latching onto ULA and deciding ti's good.
> 
> It's not a big leap for some company to do a huge ULA deployment
> saying "this will never connect to the intarweb thingy" and 5-10 years
> later not want to redeploy all their addressing, so, they start throwing
> money at getting providers to do what they shouldn't instead of
> readdressing their networks.

IPv4 think.

You don't re-address you add a new address to every node.  IPv6 is
designed for multiple addresses.

> > For private site interconnect, I'd think it more likely that the
> > provider would isolate the customers traffic and ULA address space via
> > something like a VPN service e.g. MPLS, IPsec.
> > 
> One would hope, but, I bet laziness and misunderstanding trumps
> reason and adherence to RFCs over the long term. Since ULA
> won't get hard-coded into routers as unroutable (it can't),

Actually it can be.  You just need a easy switch to turn it off.  The
router can even work itself out many times.  Configure multiple interfaces
from the same ULA /48 and you pass traffic for the /48 between those
interfaces.  You also pass routes for that /48 via those interfaces.

> when
> people do bad stuff with it, it will work and since it works, they won't
> go read the documentation explaining that what works is a bad
> idea.
> 
> >> Part 3 will be when that same provider (or some other provider in the
> >> same boat) takes the next step and starts trading routes of ULA space
> >> with other provider(s).
> >> 
> >> At that point, ULA = GUA without policy = very bad thing (tm).
> >> 
> >> Since feature creep of this form is kind of a given in internet history,
> >> I have no reason to believe it won't happen eventually with ULA.
> >> 
> > 
> > So I'm not sure I can see much benefit would be of paying a
> > huge amount of money to have ULA address space put in only a
> > limited part/domain of the global route table. The only way to
> > have ULA = GUA is to pay everybody on the Internet to carry it, and
> > that is assuming that everybody would be willing to accept the money
> > in the first place. That'd be far more expensive than just using GUA
> > addresses for global reachability.
> > 
> 
> No... The way it will work is that use of ULA as pseudo-GUA will
> spread slowly like cancer through the network.
> 
> When provider A and provider B both have customers throwing lots
> of money at them to route their ULA, provider A and provider B will
> swallow hard and agree to exchange those routes in both directions.
> 
> I wish I had your confidence in people doing the right thing, but,
> there are enough examples of RFC-1918 space in the GRT that
> I simply can't share your belief that it won't happen with ULA
> which doesn't have the reliability problems that RFC-1918 had.
> 
> Owen
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org




More information about the NANOG mailing list