Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt

[Thierry Ernst <[e-mail]>]

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. 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.

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.

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.

Regards,
Thierry.





On 24/10/12 02:56, John Mann wrote:
> Hi,
>
>
> On 23 October 2012 03:54, Alexandru Petrescu 
> <[e-mail] <mailto:[e-mail]>> 
> 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
>
>             [e-mail] <mailto:[e-mail]> Administrative Requests:
>             https://www.ietf.org/mailman/listinfo/ipv6
>             --------------------------------------------------------------------
>
>
>
>
>
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list [e-mail]
>         <mailto:[e-mail]> Administrative
>         Requests: https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------
>
>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[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
> --------------------------------------------------------------------