using "reserved" IPv6 space

Saku Ytti saku at
Wed Jul 18 18:07:35 UTC 2012

On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
> On 18-Jul-12 08:48, Saku Ytti wrote:

> Why would they do that?  SPs should only be assigning (and routing) GUAs.

Because SP might be tasked to provide network plan for customers L3 MPLS
VPN and customer might get INET from different SP and might not want those
to be used for L3 MPLS VPN.

> ULAs are for /local/ use within the customer site, so customers can and
> should generate their own locally.  An SP should never see those

You make assumption that customer does not buy everything as service.
RFC1918 is local, yet often IP plan comes as a service from someone who
does it for many companies.

> Those were not considered requirements for the algorithm in RFC 4193
> since there is no scenario /where RFC 4193 addresses are a valid
> solution in the first place/ for which testability or provability of the
> algorithm's results are important or even useful.

If collision occurs, if dispute occurs, provability that one party did not
use BCP method can be useful to solve dispute and decide who renumbers.
Other potential problem with RFC, if you have software to generate two, if
software runs parallel, it may generate same prefixes.
IEEE decided 2008 or 2009 to start allocation OUIs randomly, since some
cheapskates were assigning themselves 'free' OUIs from end of the space,
confident it'll never collide. So duplicate OUIs can happen. Also some NIC
vendors ship with non-unique MAC.

What makes RFC method good? Would provability make it worse? Would simply
drawing 40b of random from known implementation (openssl?) be worse or
better? Random as generated by some known/common implementation wouldn't
suffer risk of collisions as described above.


More information about the NANOG mailing list