Hi,
Le 24/10/2012 02:56, John Mann a écrit :
Hi,
On 23 October 2012 03:54, Alexandru Petrescu
<[email protected] <mailto:[email protected]>> 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.
Yes.
Why do you _want_ the LFN end devices to change IPv6 address as the
vehicles move around?
Well, it may indeed be desirable to avoid that change. But there is
still a need for initial assignment of IP addresses, no? Since this is
IPv6 no NAT, what IP addresses should be initially assigned to devices
in vehicles?
How about if you one-off assign prefixes to the in-car subnets, and then
one-off assign host addresses to the LFNs.
It is a possible way. When pre-assigning theses addresses one realizes
though they are topologically correct at only one place in the Internet.
I.e. if we assign a vehicle the prefix A which is valid in by lab X
when I move the vehicle in area Y the prefix A is no longer valid. I.e.
one must absolutely use a tunnelling form to connect prefix A in area Y,
right? Or, first we don't want to use MIP (we'll see later about MIP).
Then use tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to
the Internet.
Well yes. But we try it here without tunnels. This has certain
advantages: no need to use HA, no tunnelling, no triangular routing, etc.
(I wonder whether there's any other tunneling form than MIP, PMIP, VPN
and 6to4).
The LFNs having stable addresses would facilitate connections to and
from the Internet.
Yes, only if tunnelling is used.
There are additional ways to form stable addresses (we consider VIN,
more later) in a vehicle. These can be used to connect vehicles between
selves forming a local domain, but disconnected from the Internet. This
has still advantages over no connection at all.
It would be abnormal to forbid two vehicles in close vicinity to talk to
each other just because Internet is not available there, or because
their MIP can not connect to the HA.
For this we use VIN to generate ULA prefixes and
http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-02
to exchange prefixes.
Is there some soft of association between IVs and LVs?
- are they owned / managed by the same people?
no, not really.
- is there guaranteed to always be a IV in range of every LV?
no, not really. There may be question of several IVs present near one
LV and vice-versa.
- are the IV's happy that the LVs are using their bandwidth to the Internet?
Probably yes. Advertisement billboard vehicles are such kind.
- is there any need for the LFNs on IVs and LVs to communicate with each
other? locally?
YEs, like at an incident scene, where law enforcement fire department
vehicles deployed need to exchange files about a casualty.
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?
I guess yes - different as we move around.
Or does it take a roam plus a "reboot" to get a new address and prefix?
I guess yes, a roam and a reboot, some times.
Alex
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
[email protected] <mailto:[email protected]> Administrative Requests:
https://www.ietf.org/mailman/__listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
------------------------------__------------------------------__--------
------------------------------__------------------------------__--------
IETF IPv6 working group mailing list [email protected]
<mailto:[email protected]> Administrative
Requests: https://www.ietf.org/mailman/__listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
------------------------------__------------------------------__--------
------------------------------__------------------------------__--------
IETF IPv6 working group mailing list
[email protected] <mailto:[email protected]>
Administrative Requests:
https://www.ietf.org/mailman/__listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
------------------------------__------------------------------__--------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
