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

[Alexandru Petrescu <[e-mail]>]

Le 05/11/2012 11:01, Romain KUNTZ a écrit :
> 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.

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