> 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
--------------------------------------------------------------------

Reply via email to