> 3.3. Examples of use > > The Mobile Router (MR) that executes the previous algorithm, is > capable of announcing the generated prefix on one or several internal > interfaces and configure one or several external interfaces, > depending on the scenario. For instance, under some conditions, > knowing the VIN code of a vehicle, one can deduce the internally > advertised prefix and remotely access a well-known internal device > (with a certain MAC address). This access might be possible for > vehicle manufacturers in order to perform remote diagnostic, or other > car rental companies depending on the application. > > Using the vehicle's VIN and the above method, the MR can deduce the > same VULA prefix and advertise it internally or use it to configure > its own external interfaces.
By definition, any prefix that can be used like this is not a ULA prefix, and has no place under fc00::/7. ULA prefixes are not to be routed externally. > 4.1. Method 1: RFC 4193 compliant Unique Local IPv6 Unicast Address > generation > > The VIN is, according to section 3.2.2 of RFC 4193, a suitably unique > identifier that could be used locally to the MR for the generation of > an IPv6 ULA prefix and can thus be used in the algorithm described in > the same section. Basically, step 2 of the aforementioned algorithm > is transformed in order to take the local VIN code as input. The > resulting ULA prefix is advertised on MR's ingress interface, or used > to configure any other local interface. > > Since RFC 4193 algorithm relies on a pseudo-random generation method > for the ULA prefix, and introduces, for example, the timestamp at the > moment of the execution, two different instances of the same > algorithm given the same VIN code, will result in two different > prefixes. Yes. That's why, in any ULA deployment where some stability is needed, you will only regenerate the ULA prefix in extreme circumstances (typically a "factory reset"). ... > Also, the VIN code is hashed and > partly present in the Global ID, which makes it impossible to guess > from a given ULA prefix. Yes, which is a very good thing from the privacy point of view. > 4.2. Method 2: VIN-based Unique Local IPv6 Unicast Address generation > > The conversion method described in Section 3.2 defines a new VULA > prefix format (as depicted in Figure 5) which is guaranteed unique > amongst the VIN-based generated prefixes. Knowing a VIN code, it is > possible to derive the related ULA prefix and use this information > for a remote access. This is completely unacceptable as it contradicts the most basic aspect of ULAs: the L stands for Local. > This subtype of ULA prefixes which has enhanced uniqueness guarantees > may be defined in a separate category that requests specific /8 > prefix (for example) that are expected to be globally routed. Something that is globally routed or externally accessible is by definition not a ULA. Regards Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------