ULA Registry

[Mark Smith]

Hi,

Can we also do one for RFC1918, private AS numbers and reserved IANA
address space ? One of my employer's very large upstream transit
providers is using all of those for services they provide to us and
many other downstream wholesale customers of their services, for things
such as L2TP LAC addresses, monitoring the status of a BGP session for
delivery of L2TP traffic or IPsec for access to wholesale admin
systems. It would be great to be sure that we don't use those private
addresses/numbers ourselves and then have a conflict when they deliver
us a service that's using them.

Thanks,
Mark.

(p.s., I know exactly what I'm asking, why it is rediculous, and why I
also think creating a registry for ULAs is even more rediculous
- it creates an amount of legitimacy for big ISPs etc. to say,
"it's ours because that list over there says it is, and you have to
renumber - and it's your problem to do that". That doesn't exist for
RFC1918 etc., and yet they're still doing it)

On Tue, 29 May 2007 18:51:19 +0100
Jeroen Massar <jeroen at unfix.org> wrote:

> [Major cross post, set reply-to to NANOG, please honor it... ]
> [Note: I am not talking about ULA Central here, though it could apply]
> 
> To stop the pesky emails about ULA, I hereby present a (partial)
> solution to this problem.
> 
> We have ULA as per RFC4193. With a little math one can generate a ULA
> prefix sized /48 which is most likely globally unique. According to
> the RFC with 10.000 connections the collision probability is still a
> huge 4.54*10^-05.
> 
> Some people have expressed a problem with this, especially when they
> want to use the generated ULA prefix for their large organization.
> 
> The simple, cheap and quick solution: a ULA registry.
> 
> This comes close to ULA-Central, but what we do is simply make a list
> of the "in use" ULA's, without any allocation policies whatsoever
> except: first come first serve and no cash to pay.
> 
> The tool is here: http://www.sixxs.net/tools/grh/ula/
> 
> The page allows one to generate a ULA based on a given MAC address
> (multicast + locally defined + unregistered are not accepted) and then
> register it. The Name + Email are mandatory to restrict abuse a little
> bit. Email is not shown, except in whois and can be used to possible
> contact people who are leaking ULA prefixes.
> 
> Note, it is indeed a _partial_ solution. When somebody still generates
> the same ULA prefix and does not check the list you can still collide.
> As this is primarily a problem for big organizations, they should be
> checking this list for collisions and registering their prefix when
> they see that they have a need for that.
> 
> The list is available from the website, but also per whois.sixxs.net
> which is now serving up fd00::/8. It does not cover ULA-C (fc00::/8).
> 
> As SixXS is a private hobbyproject kind of thing, we of course are not
> liable for anything that this might cause to you, your family, company
> etc. But enjoy it nevertheless. Full copies of the list in inet6num
> format are available from the site.
> 
> Greets,
>  Jeroen
> 
> PS: GRH still classifies ULA's as "BAD" of course
> PPS: Thanks to Peter van Dijk for the multicast/locally defined MACs
> PPPS: Folks registering prefixes like crazy will nicely get locked out
> automatically, so don't even try...
> PPPPS: Thanks to SUZUKI Shinsuke and Holger Zuleger for the generator.
> 
>