Hello Thierry,
Le 27/10/2012 11:30, Thierry Ernst a écrit :
Many thanks to John for his post. Yes, what is the problem we are
trying to solve here ? With NEMO, there is no problem related to
changing IP addresses ? NEMO is the solution for that. The
in-vehicle router would still get a new CoA while in the in-vehicle
nodes would keep the prefix initially allocated.
Well yes, the prefix allocated to a vehicle when using NEMO is actually
DHCPv6 Prefix Delegation RFC6276. In that RFC the presence of HA is
mandatory.
But some times HA may not be available, e.g. in remote areas or
uncovered areas. There, one would still want vehicles to inter-communicate.
When HA is not available, there is a need to allocate addresses to
vehicles. NEMO MIP, RFC6276 and draft-jhlee-mext-mnpp and can not be
used in these cases.
There can be several new ways of doing this allocation, one being this
ND-PD, or DHCPv6-PD, or address generation based on VIN (Vehicle Id No).
This is the solution adopted by ISO TC204 (technical committee
working on ITS), see the published standard ISO 21210. This is also
what is being experimented in ITS field operational tests.
I am happy to learn ISO recommends NEMO extensions of Mobile IP and that
is being experimented in ITS field operational tests.
Where does this recommendation stand with respect to the absence of NEMO
RFC from "IPv6 Node Requirements" RFC6434?
I am unhappy to having to pay to download that ISO spec.
Of course, with a solution like NEMO the route is not optimized, but
the scenarios currently being considered for deployment from the
automotive industry wouldn't require direct routing between two
vehicles nor would require optimized routing between a vehicle and a
correspondent in the Internet. The scenarios where we really need
direct communications are when an in-vehicle node need to speak with
a roadside node that is attached to the access router. Other
scenarios depicted by Alexandru are good for research.
Direct communication between vehicles in the absence from infrastructure
is what is being experimented in some settings, although I agree they
may not be reflected in ISO works. I can speak of the EU project I work
on with these V2V and V2V2I 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.
I am happy to learn that draft-jhlee-mext-mnpp work is integrated in ISO
TC204 work.
Additionally, ISO should know that that draft is an individual
submission at IETF - it does not have backing from any WG at this time.
And that an alternative exists, as another individual submission:
draft-petrescu-autoconf-ra-based-routing.
Yours,
Alex
Regards, Thierry.
On 24/10/12 02:56, John Mann wrote:
Hi,
On 23 October 2012 03:54, Alexandru Petrescu
<alexandru.petre...@gmail.com
<mailto:alexandru.petre...@gmail.com>> wrote:
Le 20/10/2012 23:51, Thierry Ernst a écrit :
Dear Alex,
Would you explain why the vehicle would need to get a new prefix
(and thus I assume configure all the nodes in the vehicle) every
time it enters a new area ?
Well, whenever MR of a vehicle changes its attachment point it
would get a new different address, right? I can only suppose it
would get a different delegated prefix as well. It's hard to
imagine that it would get a different address but a same delegated
prefix, no? (it's hard to make same prefix valid at so many
different places, harder than doing it with addresses and it's not
done with them).
Or do you ask why LV gets a new prefix when IV changes its prefix?
I think this is obvious, no? (for topological correctness, right?)
Or do you ask from the NEMO perspective?
In this V2V2I work we first consider there's no MIP nor NEMO
neither on IV nor on LV. We'll see later about adding MIP. We
can discuss it as well, see how MIP would fit in this.
Is this answering in the direction you made the question?
Alex
I'm confused about what problems are being solved / created here.
I assume V2V2I is vehicle-to-vehicle-to-Internet.
Why do you _want_ the LFN end devices to change IPv6 address as
the vehicles move around?
How about if you one-off assign prefixes to the in-car subnets,
and then one-off assign host addresses to the LFNs. Then use
tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to the
Internet. The LFNs having stable addresses would facilitate
connections to and from the Internet.
Is there some soft of association between IVs and LVs? - are they
owned / managed by the same people? - is there guaranteed to
always be a IV in range of every LV? - are the IV's happy that the
LVs are using their bandwidth to the Internet? - is there any need
for the LFNs on IVs and LVs to communicate with each other?
locally? Do e.g. cellular or satellite networks used for connecting
IVs to the Internet give out different IPv6 address or delegate
different prefixes as you move around? Or does it take a roam plus
a "reboot" to get a new address and prefix?
Thanks, John
Thierry
On 20/10/12 20:10, Alexandru Petrescu wrote:
Le 20/10/2012 18:42, Mikael Abrahamsson a écrit :
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:
One point that guided towards choosing ND over DHCP is topology.
DHCP topology can be relatively complex with Client/Relay/Server,
whereas ND is simpler one-on-one.
There is nothing saying DHCPv6-PD can't be done in a single device
(the router itself). That's what I do in my home, cisco router,
local DHCPv6-PD pool, local DHCPv6-PD server, also installing
routes into RIB.
YEs, because at home one typically puts up the interface once a
month and gets typically the same prefix from ADSL operator as 1
year before.
But with vehicles, one connects a vehicle here and gets a prefix,
then moves in that area and gets another prefix. At that point, if
the router obtaining a prefix wants to delegate further to another
vehicle needs to change the delegated prefix.
This dynamic change between the received prefix and the delegated
prefix is not a matter of DHCP. It can be implemented by like
scripting which are independent of DHCP implementation. One has to
touch the conf files be it of DHCP or of ND.
_and_ Relay (or Server). This may be feasible in practice but I
think it would be cleaner to have distinct protocols on a same
machine for receiving a prefix and for sending a prefix.
What is cleaner is to use existing standards where there already
is running code.
Right, there is cleanliness in reuse. Reuse as much as possible.
There is also the question of availability of DHCP software on
smaller platforms which have no SIM card. It may be easier to do
this with ND in smaller settings.
I'd imagine that there already are 2-3 existing FOSS available
implementations that do what you need for DHCPv6-PD client and
server. Instead you want to invent a new standard and create new
code.
In addition to FOSS (what is FOSS?) DHCP one also needs to
dynamically change the delegated prefix when the assigned prefix
changed.
I'm not saying this shouldn't be done, I'm just saying I don't
really see the rationale for it. I used to hate DHCPv6 role in
IPv6, but after a few years of being exposed to it, I've come to
accept that this is the way it is. There is code going back to a
standard Windows Vista that correctly implements DHCPv6-PD client,
and that is what, 5-6 years ago it was released? I've had PD in my
home on Cisco code for 3-5 years already, with no server
infrastructure at all, just single device doing "everything" for
the role needed.
If this was 2002, I'd agree with you that ND PD could be feasable,
but I believe the train has already left the station and we should
focus on keeping IPv6 stable when it comes to how it works, and get
implementations going, not new standards.
WEll yes, I agree that IPv6 should be kept stable and part of that
may be that we try to make sure that a new proposal does not break
existing implementation. This is a matter of further work.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org <mailto:ipv6@ietf.org> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org
<mailto:ipv6@ietf.org> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org
<mailto: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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
