Le 05/11/2012 11:12, Romain KUNTZ a écrit :
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.
I agree that is a good engineering approach.
We started in July writing a draft in that space
draft-petrescu-its-scenarios-reqs-01.txt.
I am interested in all discussion in ITS towards refining scenarios,
goals and requirements drafts. There is also an email list i...@ietf.org.
Alex
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
--------------------------------------------------------------------
