Le 05/11/2012 11:01, Romain KUNTZ a écrit :
On Nov 3, 2012, at 19:25 , Alexandru Petrescu
<[email protected]> wrote:
Le 03/11/2012 18:54, Romain KUNTZ a écrit :
Hello Alex,
On Nov 3, 2012, at 17:41 , Alexandru Petrescu
<[email protected]> wrote:
Le 25/10/2012 15:52, Michael Richardson a écrit :
ralph> Why wouldn't RPL be used for such networks? It has
built-in PD for ralph> dynamic networks, if I understand it
correctly, with RA used at the ralph> subnet level.
Alexandru Petrescu <[email protected]> wrote: AP>
RA used to exchange routes - if this is what you mean, and
yes it may be AP> used by RPL (last time I read it).
AP> If the question is about this, then I think it is
pertinent. One may AP> imagine a way to use RPL on the MRs
for that purpose.
AP> However, I doubt RPL can Delegate Prefixes (in the pure
sense of Prefix AP> Delegation).
RPL doesn't do this in protocol, but then, neither does ND.
I wouldn't extend RPL to do this, however, I'd send a DHCPv6
PD format message. It can be a single exchange, and nobody
said a single program can't speak multiple protocols.
Yes, but consider that DHCPv6-PD is already used in a rather
complicated way on the MR of an IV (Internet Vehicle). It is
used according to rfc6276, to obtain a prefix from home. In
that it is specified that MR should be both a Requesting Router
and a Relay for that tunnel interface.
On another hand, if the MR of LV requests a Prefix from the
IV's MR then this latter should also be a Relay, but on a real
interface as well.
One ends up with two Relay software on the same machine. I am
afraid this is next to impossible to configure with some
existing software.
Why two Relays? I believe one relay listening to multiple
interface is enough.
Yes, a Relay I guess could listen on two interfaces (to be
checked?).
From what I understand, RFC3315 does not forbid it.
Yes, I think Relqy could listen on several interfaces on which Clients
connect.
But I mean the Relay's interface towards the other end, the one
towards the Server. I think, if I'm not wrong, that's only one
interface possible. MIP-NEMO-DHCP-PD would use it to talk to HA.
The MR-IV would need this additional Relay's interface towards the
immediate fixed infrastructure (not the remote tunnelled HA). In
the case one would want direct IV-LV communications without HA.
In the scenario from your draft, it seems that the DHCPv6 server that
delegates prefix to the MR-IV and to the MR-LV is the same, so why
would that interface be different? In both cases the DHCPv6 messages
would go through the MR-IV - HA tunnel, or did I miss something?
But even you use different interfaces, I believe nothing prevent a
DHCPv6 relay to do so. There is no considerations on the number of
interfaces to send/receive messages in RFC3315. Sending or relaying
messages to a server is just a matter of knowing the server address
and having a route for it.
Right, I meant that interface towards the Server. Ok, it is a matter of
knowing the server's address and having a route for it.
There may be two problems: (1) the Server to which Relay should connect
may be different from place to place and (2) in case MIP-NEMO-DHCP-PD is
run on MR then there should be two different Relays - one that uses the
Server in the immediately available infrastructure and the second for
the HA. (I ma not sure whether two different Relays can be run
independently on same machine, probably they could).
Before discussing solutions, I think there are probably a number of
questions to answer about the ITS scenarios.
I agree with you that before discussing solutions we may need to better
describe the scenarios.
For example, would the DHCPv6 server delegating prefixes for the
MR-IV and the MR-LV be the same or not? Each would probably belong
to the provider affiliated with the vehicle.
This may be a perspective.
We also consider only the IV (Internet Vehicle) has a SIM card and a
provider. The LV (Leaf Vehicle) is not billed by that provider since it
has no SIM. This may be a problem per se, in that its operator would
likely avoid allowing IV to sub-delegate further the prefixes it obtained.
Alex
Thank you, Romain
I may be wrong though about Relays' capabilities. It just that it
looks complex to me to set up, rather than using ND on the link
between IV and LV looks simpler.
Alex
Romain
But, I question whether one always needs to get address
space, vs announce it. I don't know the answer: it really
depends upon who your second vehicle needs to talk to, and
why it thinks that vehicle one (and vehicle one's ISP) is
willing to give it bandwidth.
I think both tools of announcing address space, and obtaining
address space, should be available to vehicles, and applied
depending on whether the communication is between two vehicle
devices only, or not, whether the infrastructure is available,
or not.
It is viable that an LV self-configures ULAs based on VIN and
announces them only to vehicles nearby (not to
infrastructure).
It is viable that an LV to get globally routable address space
from an IV.
If you don't want to speak RPL, then you need to pick the
TBD homenet-routing-protocol. We don't need a third.
Needing a third or not - I don't know. But picking homenet
protocol, or RPL for vehicles would probably involve a large
change in requirements of either.
Alex
--------------------------------------------------------------------
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
--------------------------------------------------------------------
