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