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