Le 03/04/2013 07:40, Fernando Gont a écrit :
Hi, Alex,
On 04/02/2013 12:55 PM, Alexandru Petrescu wrote:
IMO, you should follow what appears to be the consensus on the
subject: set the IID in whatever way you want,
About this there is a tendency to agreement. The privacy aspect
should be considered, balanced by a privacy-to-mobility tradeoff.
Which privacy aspect?
Offer privacy by default: avoid a reversible mapping VIN-to-
InterfaceID. Because, if a reversible mapping VIN-to-InterfaceID
existed, then it could be exploited by attackers by reversing the
InterfaceID back into VIN, and exposing this personal information to
anyone listening the IP traffic of a vehicle.
But this VIN topic is also about how to generate an ULA prefix
when no EUI-64 is available. (if ULAs are good to be used in a
vehicle).
The ULA spec relies on that?
Yes, the ULA prefix (RFC 4193 section 3.2.2) generates a 48bit prefix
randomly. That suggested algorithm is seeded by time, EUI-64 into a
key, and then SHA-1.
Anyway.. the idea is that you randomize the prefix...
Yes. We may need to say how.
Just saying RNG may not be enough, I dont know.
This Router sold by the third-party needs to know what IPv6
addresses are or should there be in the vehicle.
Isn't this a case of network mobility?
YEs it is. Network mobility has a means to dynamically acquire a
prefix for the moving network, from the HA. But it doesnt say
whether that prefix could be used for direct vehicle-to-vehicle
communications, or shouldnt.
Not sure what you mean....
I mean Network mobility as the RFCs describe them dont say whether the
prefix assigned to a moving network is ULA or GUA, PI or PA.
Also, that Network mobility doesnt prohibit neither suggests that the
prefix of a moving network (MNP: Mobile Network Prefix) be exchanged
between two distinct moving networks such as to establish routes between
them (route exchange).
I am discussing this because you seemed to ask whether this is a case of
Network mobility: yes and no.
_If_ ULA space may be used then one wonders how to generate one
ULA prefix for one vehicle. The RFC ULA does suggest an
example algorithm, but it says other algorithms may be
possible.
The idea is that the prefix is randomized, as to reduce
colisions, IIRC.
Yes, and it suggests an algorithm for doing so. That algorithm
uses EUI-64. Some MRs may have several such, or none. What to
use in these case?
OK. Lt me take a look -- anyway, my rough guess is that you'd be
fine by just randomizing the prefix part. (i.e., the router).
Just randomize but how?
Just randomize without saying how may lead to everybody outputting same
number. One may need to use a detail about generating
uniqueness. The RFC ULA suggests that detail to be time and EUI-64.
A mobile router in a vehicle may not always have a EUI-64 (yet it has
LTE interface, CAN, USB, etc). Or it may have several such
EUI-64-interfaces; and a rule may say 'pick any one of the available
EUI-64 on this computer'.
Or it may say to use the EUI-64 of another interface of another computer
in that same vehicle. (there are several distinct such computers, like
the 'TCU', the 'ECU', the OBU, the Switch, the App server, and so on).
Or it may say just use the VIN because that covers the entire vehicle
and whatever computers are inside there's only one VIN.
I'm not arguing that you're the only guy working on this, nor
that this VIN->IPv6 mapping might be useful to those working on
VIN-IPv6 topic -- I'm rather arguing that IPv6 address should
be... IPv6 addresses
Yes. Precisely as IPv6 addresses are IPv6 addresses and sometimes
contain EUI-64 identifiers in clear.
We should eventually move away from that. See
draft-ietf-6man-stable-privacy-addresses.
Well yes I read it and understand it from a privacy perspective. It is
very good in that sense because whenever changing the subnet the IID
changes, so attacker can not track the user by its IID.
However, it may be less attractive to a mobility-inclined reader,
because whenever changing the entire address (not only the IID), some of
the ongoing communications may break., I think.
If your point is "We are not intending to introduce any
additional semantics to the IPv6 addresses/IIDs, but rather are
not sure how we should implement RFC XXXX in our specific case",
please do let me know, and I'll look further into this.
Provided that the use of ULA in a vehicle is acceptable, one
would try to find out how to generate a ULA prefix in a vehicle,
and maybe on a Mobile Router which has several EUI-64, or none.
If you expect communication across vehicles, then your upstream
router should be the one generating the prefix.
'Upstream router' - the topmost router in the vehicle (there are
several). Or the first-hop router in the fixed infrastructure?
If the first-hop router in the fixed infrastructure - if it's a cellular
Access Router it may not have EUI-64 either, or have several.
If only in-vehicle communication is expected, you'd be okay by just
randomizing the prefix.
Well, I think that for only in-vehicle communication, random ULA may
not be necessary - using the same ULA fd00:1::/64 in every other vehicle
will work.
The random part of the ULA may be needed for inter-vehicle
communications. I.e. use fd00:fef2:3214::/64 inside one vehicle,
and fd00:fff2:3214::/64 in the other vehicle. Use no prefix on the
ad-hoc link between the two egress interfaces of the mobile router (use
their link-local addresses there).
If those two prefixes were not random, then collision between prefixes
may occur the moment the routes are exchanged between the vehicles.
-- But I'll double-check with the UA spec and come back to you --
please feel free to ping me if I forget.
Ok will do, thanks.
Alex
Cheers,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
