Re: draft-kaiser-nd-pd-00.txt

[Romain KUNTZ <[e-mail]>]

On Nov 3, 2012, at 19:25 , Alexandru Petrescu <[e-mail]> wrote:

> Le 03/11/2012 18:54, Romain KUNTZ a écrit :
>> Hello Alex,
>> 
>> On Nov 3, 2012, at 17:41 , Alexandru Petrescu
>> <[e-mail]> 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 <[e-mail]> 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.

> 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. 

Before discussing solutions, I think there are probably a number of questions to answer about the ITS 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.

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
>>> [e-mail] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>>> 
>>> 
>> 
>> 
> 
>