who gets a /32 [Re: IPV6 renumbering painless?]

Iljitsch van Beijnum iljitsch at muada.com
Fri Nov 26 14:39:04 UTC 2004


On 25-nov-04, at 21:16, Stephen Sprunk wrote:

>>>> if you don't connect to the internet you don't contribute to the
>>>> global routing table so there is no issue.  :-)

> There is an issue of uniqueness.  Those hosts that can't reach the 
> Internet
> typically can talk to other hosts that can, and even multiple private
> networks often link to each other.  At a minimum, statistical 
> uniqueness is
> necessary to avoid collisions between business partners even on a 
> totally
> disconnected network.

Yes, this is why we need ULAs.

> ULAs do not contribute to the global routing table unless ISPs allow 
> them to in violation of the draft's wording and intent.

Well, seeing how difficult it is to get legitimate address space routed 
(see bogon thread) I don't see how all ISPs in the world are going to 
route this space unless some significant blackmail is involved (such as 
the likes of Google using this address space exclusively).

And don't forget that this is IPv6. Today, and for the forseeable 
future, you can filter out all IPv6 routes that you don't like without 
breaking any connectivity as everything is reachable over IPv4 anyway. 
So people who don't want to see the ULAs in their routing table can 
just filter them out. (Although it works both ways: people can choose 
to do IPv6 using ULAs only without having to suffer unreachability.)

> The WG welcomes input on how to prevent this from occurring without 
> invoking restraint of trade concerns.

How about this: we all start announcing a few hundred random ULAs. This 
will make the v6 table too large to carry without filtering ULAs. I 
don't expect ISPs who aren't opposed to carrying ULAs for other ISP's 
customers to be willing to create filters that only let these specific 
ones through but not the background noise.

It would probably also help if the ICANN directs all registries that 
glue records towards ULA space aren't allowed.




More information about the NANOG mailing list