In message <20120718180735.ga11...@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: ma...@isc.org
