On 2011-09-29 09:20 , Roland Bless wrote: > Hi Brian, > > Am 28.09.2011 23:07, schrieb Brian E Carpenter: >> On 2011-09-28 23:08, Roland Bless wrote: >> ... >>> The current ULA-C... >> >> What do you mean? There is no current definition of ULA-C. > > That's right :-) > I was referring to the definition in RFC 4193 with L=0, i.e., > centrally assigned ULAs. I know that the registry and assignment > procedure for ULA-C are not defined yet, but the basic format will be > the same as in RFC 4193. The few I-D proposals for ULA-Cs seemed > to suggest allocating /48s and not larger address blocks and I could > very well imagine, that this will be the case if we ever define ULA-Cs.
You do realize that the RIRs are providing exactly what you describe? :) - globally guaranteed unique (due to registry) large address prefixes Which is why from my information ULA-C has also been abandoned, as it already is something that has already been resolved. What makes me wonder though, is why you would want to have different prefixes in different locations that never ever ever will talk to each other directly using those prefixes. At least I hope to never have a car that gets chatted up by the car next to it to suddenly pull on the handbreak. Any car-2-car communication IMHO would happen with a different global prefix, likely dynamically assigned to a 'gateway' function that has proper security properties (call it a 'car rest interface or so). That security gateway will then relay commands to it's internal network. That internal network can thus have the same prefix as the other car. This thus allows one to simply take a random /48 (likely ULA) and pre-program them in all the systems. Though it would be a cool idea, dynamically assigning addresses to random components in a car where one actually needs to also then maintain a registry of which components are where, will effectively mean that there will be a DNS server too of sorts to map 'engine' to 2001:db8:.....x and the left-mirror to 2001:db8:... Will be a lot of fun to build I guess, but debugging that will be horrible and overly complex. Then again, some times that is the fun in things right ;) Greets, Jeroen -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
