Re: using "reserved" IPv6 space

[Mark Andrews <marka () isc org>]

In message <20120718180735.GA11403 () pob ytti fi>, Saku Ytti writes:
> 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.
>
> -- 
>   ++ytti
 
The point of the algorithm was to have something which would do a
reasonable job in a CPE router without a hardware source of randomness.
CPE devices have access to a EUI-64/EUI-48 and often have ntp support
or a way of setting the current time. Combining the two gives enough
uniqueness.  Just the EUI-64/EUI-48 should be enough but duplicates
have been known to occur so adding in a timestamp accounts for that
rare case.

It is a "SAMPLE" routinue.  It is not "YOU MUST DO IT THIS WAY OR
ELSE".  Anything that meets the requirements of RFC 4086 is fine.
/dev/random on by laptop meets the requirements of RFC 4086.  I
read 40 bits from /dev/random and converted them hex them appended
them to fd to produce my prefix.

        dd bs=5 count=1 if=/dev/random | od -txC | \
        awk 'NF == 6 {print "fd" $2 ":" $3 $4 ":" $5 $6}'

and a sample of prefixes generated this way:

        fd3d:6385:e4b3
        fdf8:462a:6474
        fd7b:2bdf:7ed6
        fd75:b2b0:9ba2
        fd04:4c74:87c0
        fd77:948a:2c39
        fde5:41f9:95f6
        fd00:74a5:e5ad
        fd36:827f:ee5f
        fd39:d806:5994
        fd23:d147:8ff9
        fd36:a032:8a09
        fde8:6992:d8f9

There is no "I used this method so I win".  As long as you choose
a random value, using a method that uniformly covers the entire
space, you meet the requirements.  Toss a coin for each bit.  Heads
= 1, tails = 0.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org