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

[Alexandru Petrescu <[e-mail]>]

Le 03/11/2012 19:05, Romain KUNTZ a écrit :
> Hello Alex,
>
> On Nov 3, 2012, at 17:53 , Alexandru Petrescu
> <[e-mail]> wrote:
>> Le 02/11/2012 20:59, Michael Richardson a écrit :
>>>
>>> Alexandru Petrescu <[e-mail]> wrote: AP> Well
>>> yes, the prefix allocated to a vehicle when using NEMO is AP>
>>> actually DHCPv6 Prefix Delegation RFC6276.  In that RFC the AP>
>>> presence of HA is mandatory.
>>>
>>> AP> But some times HA may not be available, e.g. in remote areas
>>> or AP> uncovered areas.  There, one would still want vehicles to
>>> AP> inter-communicate.
>>>
>>> Yes, so if there is no uplink, then there is no addresses, so
>>> really, it's not an address allocation problem, it's a routing
>>> problem.
>>
>> In a sense yes.
>>
>> But let me try to present this better.
>>
>> I think you agree that, in general, one wouldn't forbid two nearby
>>  vehicles to communicate to each other, even though infrastructure
>>  may not be available in that area.  If you differ on this aspect
>> (like assuming pervasive WMAN everywhere) then please let me know.
>>
>> When there is no uplink (no WMAN) the negative aspect is that
>> vehicles can not use MIP-NEMO nor NEMO-DHCP-PD to dynamically
>> obtain prefixes. The positive aspect is that they can self form
>> whatever but unique addresses they want, or assign whatever but
>> routed addresses among them, without fear of disturbing
>> infrastructure routing, and happily without tunnels either.
>
> Sorry to jump into the discussion. In the case there is no uplink
> connectivity, I would tend to say that vehicles would use the prefix
> that had been assigned to them previously (when infrastructure was
> available and they had connectivity to run NEMO/DHCPv6-PD). Or do
> you consider that the LV would never have the capability to connect
> to the infrastructure?

HEllo Romain and thank you for discussion.

LV may connect to e.g. house network some times, yes, because it has a
WiFi egress interface.  At that point it may acquire a prefix using
MIP-NEMO-DHCP-PD.  But would it stay valid after a long disconnection
period?  I guess this allocation will behave just like an address
allocated by DHCP - expire after some time.  If yes, then the MR-LV
would be prohibited from advertising the prefix inside the vehicle.

(I am not sure this prohibition of advertising an expired prefix is
specified or coded, I just suppose it as natural).

Alex

>
> Thank you, Romain
>
>> Whether vehicles self-form addresses and inform each other about
>> them, or otherwise use a central vehicle to allocate addresses to
>> each other, is indeed debatable.
>>
>> I think both paths should be pursued.  (I mean I have a draft for
>> each, and there's a competitor draft for one of them, and I plan
>> to write another one about self-forming ULAs from VIN and there's
>> competitor activity on this VIN-ULA.)
>>
>>>
>>> AP> Direct communication between vehicles in the absence from AP>
>>> infrastructure is what is being experimented in some settings,
>>> AP> although I agree they may not be reflected in ISO works.  I
>>> can AP> speak of the EU project I work on with these V2V and
>>> V2V2I AP> use-cases.
>>>
>>>>> For the scenario involving the roadside and the vehicle, the
>>>>>  prefix can be exchanged as proposed by Lee
>>>>> (draft-jhlee-mext-mnpp). The solution from Lee is being
>>>>> integrated in the ISO TC204 standards related to ISO 21210.
>>>
>>> AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP>
>>> integrated in ISO TC204 work.
>>>
>>> Can you tell us how/if we can view this TC204 work?
>>
>> Yes, I wonder about this as well.  I think Thierry or Jong-Hyouk
>> are in best position to briefly describe this.
>>
>>> Also, I can not find draft-jhlee-mext-mnpp. Is there a typo?
>>
>> I think it is http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00
>> (it may look expired but there is intention on continuing it, I
>> believe) Is this pointer working for you?
>>
>> Alex
>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
IETF IPv6 working group mailing list [e-mail] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>>
>>>
>>>
>>>
>>>
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>>
>>
>>
>
>