Le 25/10/2012 13:14, Michael Richardson a écrit :
Ralph Droms <rdroms.i...@gmail.com> wrote:
But with vehicles, one connects a vehicle here and gets a
prefix, then moves in that area and gets another prefix. At
that point, if the router obtaining a prefix wants to delegate
further to another vehicle needs to change the delegated
prefix.
Why wouldn't RPL be used for such networks? It has built-in PD
for dynamic networks, if I understand it correctly, with RA used
at the subnet level.
RD> My understanding is that RPL assumes a multi-link subnet, with a
RD> single prefix used across the entire network and source routing
or RD> host-specific routing.
RPL doesn't care. It's all /128 routes to anything not on the local
(physical) link.
That is with route exxchange, right? Something like Router1 informs
Router2 about a prefix and a next-hop, and Router2 informs Router1 about
the other prefix and next-hop.
But with ND-PD and PD in general one contemplates the assignment of
prefix (maybe accompanied by modifying routing tables), instead of route
exchange.
Whether it's source routes or hop-by-hop LPM depends upon whether
the mode of operation is storing or not.
Ok, that is the way of forwarding application data packets. But it's
not a way to attribute prefixes.
RPL does not seem to assign neither addresses nor prefixes, which is
good, if I am not mistaken.
They don't have to come from the same subnet. The RPL Target
Option, contained in the DAO that travels up the tree, has a prefix
and length. In typical layer-3 subnet mesh networks, it contains
/128 prefixes.
Is that for communicating the prefix in the sense of 'route exchange' or
in the sense of 'prefix delegation'?
Like others on this thread, I'd like to know how real this vehicle
use case is. Is CAE really working on such a thing?
CAE... Computer-Assisted Engineering? I know not.
My opinion is that vendor of vehicles should obtain a Non-Connected
Network prefix from a suitable registry,
In the vehicle industry there may exist such registry already which
distributes VINs (Vehicle Identifier Numbers). But not IP addresses.
Is there another such vehicular specific registry?
or from not-yet-agreed-to-be-useful ULA-Central, and have the the
MR-IV and MR-LV (permanently) number the LFNs.
Or, have a method to convert from VIN to a ULA address or prefix. Like
when converting MAC addresses to Interface Identifiers.
When two cars connect for some non-Internet access reason (including
to talk into the homenet), they should speak RPL to each other
across the E1 link(s).
Well, we can discuss this. As much as RPL can be seen as a routing
protocol for many things, hence maybe useful for vehicles too, and for
homenets, it may also be seen as dedicated to Low-Power and Lossy
Networks, which LTE and intra-vehicular WiFi and CAN networks are less.
The DAG would not be grounded. Like all the other home LLNs, the
gateway into the homenet would need to run RPL on one side, and
homenet-routing-protocol on the other side (zOSPF, whatever). It
would announce the prefixes of the vehicle into the homenet (another
kind of "walled garden"!!), just like the lighting system does.
I read.
If Internet connectivity is available/desired, then one of two
things occur (not both): 1) the Internet connected vehicle obtains
topologically significant (PA) address via homenet-routing-protocol,
and then forms a new (grounded) DODAG which can be shared with
adjacent vehicles that want connectivity. This solution is probably
more secure and probably will work in many non-homenet environments,
since homenet-routing-protocol isn't the only way to get prefixes,
and even if you get only a single /64, RPL will let you "share" it.
2) the Internet connected vehicle becomes a homenet router, and
speaks homenet-routing-protocol on E1 link and enough address space
for all vehicles is obtained.
The PA addresses live only for the duration that the vehicle(s) are
connected.
I agree that IV should obtain topologically significant prefixes.
Supposedly giving some of them to others interested.
I doubt though RPL could do this?
Again, maybe I missed the bigger picture: who is building these IPv6
enabled vehicles? (And where can I get one?)
It's hard to answer straight without doubt. It's not my specialty, I am
coming more from networks research than from vehicle field.
But I couldn't imagine a connected vehicle manufacturer not considering
IPv6, especially when IPv4 space has run out and NAT would make
impossible the new applications querying data from vehicle, etc.
And I am listening too about this.
A vehicle which is IPv6 does not exist probably on the market, as we speak.
What one can buy right now is equipment that is dedicated to vehicles
and add it, (like in "tuning a vehicle"). This includes ruggedized
linux computers, dedicated linux boards, antennas. For connection
inside, one widely used CAN access is OBD-II cheap. In addition the
classic short-range WiFi/Bluetooth/ZigBee could be deployed
intra-vehicle, provided their chipsets can be powered on 12-24V or so.
For outside vehicle one may consider 3G, GPS, DVB, LTE cheap devices and
maybe cheap 802.11p although not as widely available.
Having all that one faces the problem of how to assign addresses and
establish routes.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
