Le 03/04/2013 21:36, Manfredi, Albert E a écrit :
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Alexandru Petrescu
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.
I really don't put much weight on this. It's just one suggestion. I
dare say, pick a decent PRNG, pick a seed out of the air, and for all
intents and purposes, you have your ULA prefix.
I agree, this is feasible.
After all, this use of ULA is only for in-vehicle comms, and should
not transit through any car-Internet router.
YEs and no.
Within a vehicle, it's not sufficient to just use link-local addresses,
because it is highly likely that at least two different subnets are
present inside (roughly 'safety' and 'entertainment', but just roughly).
So one needs addresses inside a vehicle with a scope larger than link.
These may be ULAs, or not ULAs, yet they must be larger than link scope.
Between vehicles - it may be that one vehicle needs to inform the nearby
vehicle about the prefix(es) it holds inside, and vice-versa. If these
prefixes are ULA, then this prefix exchange should work. This direct
vehicle-to-vehicle communication may not need any car-to-Internet
connection - it's a sort of 'peer-to-peer' communication. (WiFi adhoc
mode of egress ifaces, or 802.11p - both may establish connections
between vehicles without using infrastructure).
About the straightedness of connectivity, this V2V acronym is generally
understood by IP people by a number of degrees of variation: there is
(1) direct vehicle-to-vehicle communication without infrastructure
whatsoever, (2) vehicle-to-AP-to-vehicle communication (AP is a fixed
router along the roadside, but disconnected from Internet), (3)
vehicle-to-AP-to-Internet-to-AP-to-vehicle, (4) V-to-HA-to-HA-to-V and
so on (HA is the Home Agent hosted by the vehicle manufacturer, not by
the cellular operator).
Randomness is only a safety net, in case a ULA sneaks out of the
local router.
YEs.
I don't think we should tie the VIN or any EUI-64 strictly to this
idea of using ULAs.
I agree as well. VIN could be used in a Internet setting in a variety
of ways.
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).
Well, I have a question about this. I've seen mobility done in a
number of ways. Move individual interfaces, using the home agent
approach; move entire address blocks, where the routing protocol
keeps track of subnet location; or use a link layer that always ties
the moving subnet(s) to the same geographic location "back home,"
making the job easier for the IP layer.
Added to this, for a vehicle scenario, we may (probably will) also
need something along the lines of 802.11 ad-hoc networks, for those
tactical car-car and car-road comms.
YEs 802.11 ad-hoc but between the egress interfaces of vehicles, not
between the inside1 of vehicle1 and inside2 of vehicle2.
With that distinction, it appears to me that IP routing should be
performed between inside1 and outside of the car. This is ok, because a
car Router interface may be Ethernet (ingress) and another may be WiFi
(egress).
In principle, can't a combination of all of these schemes be used in
vehicles? For instance, if your IP service is the type that replaces
the OnStar scheme (used by GM in the US), a lot of that information
is not overly time constrained. And since OnStar is a 3G system, it
"knows" what each client's home network is.
The OnStar system as I understand it is a good deployment success
showing IP is possible in vehicles at a large scale. It is mostly the
success of deployment of the cellular network and certain PHY encoding
schemes. I compare it to eCall in Europe (which is regulated
differently in different countries).
But we look here at a much deeper penetration of IP than just one IP
address per vehicle and a single interface.
It is considered further that several IPv4 and IPv6 addresses _and_
subnets are inter connected inside a vehicle. Many of the typical
actions (open window) move from pressing an electrical switch to tapping
a circle drawned by PC on LCD screen. There is not one but several
Ethernet cables inside. The vehicle has a large number of egress
interfaces to the outside world. Just like with mobile phones, recent
antenna designs of vehicle are increasingly complex: cellular on
frequencies of different countries, GPS of different continents, WiFi at
various freq ranges, 802.11p and more.
One approach to manage IP mobility of these complex systems is the use
of protocol Mobile IP which has extensions to consider all IP addresses
inside a vehicle to move as a whole. Conceptually the Mobile IP
approach is a 'tunnelling' approach (there's a tunnel between the MR and
an anchor - the Home Agent), as opposed to route updates as may be seen
with BGP updates. It is an IP-layer mobility protocol (as opposed to
link-layer mobility used by e.g. cellular systems). It is a
map-and-encap as opposed to rewrite. Other protocols which may be used
to do mobility of groups of IP devices may be considered to be LISP and
SHIM6.
Mobile IP has advantages and inconvenients for vehicular communications.
One of the inconvenients is that its perspective is not much that of V2V
communications: can't just consider the other vehicle to be one
vehicle's HA.
On another hand, MIP could very well be used in a V2I setting.
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.
No, I would not contaminate the Internet deliberately this way. It
seems to me that each car should be assigned a /64 prefix which is
globally unique, for this sort of use.
There is need of more than just one /64 in a vehicle, or otherwise DHCP
must be used. There are several subnets in a vehicle and many devices
are Ethernet-like. SLAAC can not work with a /65 and Ethernet devices.
Just like every household.
There is a well sensed tendency to move towards deployment giving more
than one /64 to a household - in France there this OVH and Nerim
operators I believe giving shorter len than /64 to households.
I really don't see why this type of inter-car communications should
be thought of as any different from home nets.
For one, homenets don't move or at least not as fast as cars. A homenet
may change its attachment every year or so, whereas a car may change it
every 10 minutes or so.
Depends what kind of inter-car communications.
Direct car-to-car without any assistance may not be a good candidate
for Mobile IP protocol, nor for BGP route updates, nor for link layer
communications.
For Mobile IP perspective: it's hard for a vehcile's MR to consider
every other vehicles' MR to be its HA. Typically a MR has a single HA.
For BGP updates perspective: this could be discussed and should be
analyzed at length. BGP is one and then there's OSPF RIP and MANET and
RPL. Each has peculiarities (e.g. RPL may be designed low power links
whereas V2V would be designed for high power links like .11p).
For each of these one needs to give properconsideration of the IPv6
addressing architecture to be deployed in vehicles, and the subnet
structure.
And again, the mobility aspect can be resolved in at least two
different ways that I believe to be in common use already.
Yes, the mobility aspect of vehicles could be resolved in at least two
different ways: link-layer mobility and route updates.
Link layer mobility works with just one kind of link. But could be used
to enhanced the overall mobility support of vehicle.
Route updates: could work for small networks of vehicles, as long as one
avoids to insert routes in the Internet.
Alex
Bert
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
