On Nov 3, 2012, at 19:29 , Alexandru Petrescu <alexandru.petre...@gmail.com> wrote: > Le 03/11/2012 19:05, Romain KUNTZ a écrit : >> Hello Alex, >> >> On Nov 3, 2012, at 17:53 , Alexandru Petrescu >> <alexandru.petre...@gmail.com> wrote: >>> Le 02/11/2012 20:59, Michael Richardson a écrit : >>>> >>>> Alexandru Petrescu <alexandru.petre...@gmail.com> 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.
This is a valid question and I think this depends on how the MSP (mobility service provider) is configured and how it provides the service (e.g. whether it allocates short-term or long-term prefixes). Disconnection periods can happen in ITS so we should certainly consider such cases and amend existing specifications for the ITS case if needed. I think that scenarios, goals and requirements for ITS should be agreed before proceeding to the solution space. Romain > (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 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 >>> -------------------------------------------------------------------- >> >>> >>> >>> >>> >> >> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
