Le 19/02/2013 15:56, Brian E Carpenter a écrit :
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.
ULA prefixes are not to be routed externally, as long as we're clear
about what is external and internal.
In the vehicular communications scope, one often talks about 'inside a
vehicle' (V) and 'outside of vehicle' (V2V or V2I). But it's not clear
as of yet whether two vehicles form a domain ('inside the two vehicles')
or each vehicle is a domain in itself.
It's not clear whether the Border Router of ULAs is the same as the
Mobile Router in vehicular context (the Router deployed in a vehicle).
The number of IP devices in one vehicle is not that large as the number
of IP devices at a classical 'site', although several IP subnets may be
present in one vehicle.
One may see several such neighboring vehicles to form a 'domain'. This
may be even truer if none is connected to infrastructure.
At that point it may be that ULAs span several vehicles.
I dont see what may forbid the use of ULAs between several vehicles.
(although I may be wrong).
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.
I agree. We'll correct this.
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.
Yes, and if I am not wrong, ULAs are globally unique.
A ULA is not globally routable. We need to clarify this in the draft.
Alex
Regards
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
