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

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Nov 2012 20:53:09 +0100

[re-sending to [email-masked] as I am not sure about [email-masked]]

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
>> <[email-masked]
>> <mailto:[email-masked]>> 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
>>
>> [email-masked] <mailto:[email-masked]> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list [email-masked]
>> <mailto:[email-masked]> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list [email-masked]
>> <mailto:[email-masked]> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests:https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>>
>>
>>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Nov 2012 18:20:31 +0100

Hello Thierry,

Yours,

Alex

---

From: Michael Richardson <[email-masked]>
Date: Fri, 02 Nov 2012 15:59:24 -0400

Alexandru Petrescu <[email-masked]> 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.

    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?
Also, I can not find draft-jhlee-mext-mnpp. Is there a typo?

-- 
Michael Richardson
-on the road-

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Nov 2012 17:41:23 +0100

Le 25/10/2012 15:52, Michael Richardson a écrit :
>
> ralph> Why wouldn't RPL be used for such networks? It has built-in
> PD for ralph> dynamic networks, if I understand it correctly, with
> RA used at the ralph> subnet level.
>
> Alexandru Petrescu <[email-masked]> wrote: AP> RA used
> to exchange routes - if this is what you mean, and yes it may be AP>
> used by RPL (last time I read it).
>
> AP> If the question is about this, then I think it is pertinent.
> One may AP> imagine a way to use RPL on the MRs for that purpose.
>
> AP> However, I doubt RPL can Delegate Prefixes (in the pure sense of
> Prefix AP> Delegation).
>
> RPL doesn't do this in protocol, but then, neither does ND. I
> wouldn't extend RPL to do this, however, I'd send a DHCPv6 PD format
>  message.  It can be a single exchange, and nobody said a single
> program can't speak multiple protocols.

Yes, but consider that DHCPv6-PD is already used in a rather complicated
way on the MR of an IV (Internet Vehicle).  It is used according to
rfc6276, to obtain a prefix from home.  In that it is specified that MR
should be both a Requesting Router and a Relay for that tunnel interface.

On another hand, if the MR of LV requests a Prefix from the IV's MR then
this latter should also be a Relay, but on a real interface as well.

One ends up with two Relay software on the same machine.  I am afraid
this is next to impossible to configure with some existing software.

> But, I question whether one always needs to get address space, vs
> announce it.  I don't know the answer: it really depends upon who
> your second vehicle needs to talk to, and why it thinks that vehicle
> one (and vehicle one's ISP) is willing to give it bandwidth.

I think both tools of announcing address space, and obtaining address
space, should be available to vehicles, and applied depending on whether
the communication is between two vehicle devices only, or not, whether
the infrastructure is available, or not.

It is viable that an LV self-configures ULAs based on VIN and announces
them only to vehicles nearby (not to infrastructure).

It is viable that an LV to get globally routable address space from an IV.

> If you don't want to speak RPL, then you need to pick the TBD
> homenet-routing-protocol. We don't need a third.

Needing a third or not - I don't know.  But picking homenet protocol, or
RPL for vehicles would probably involve a large change in requirements
of either.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Nov 2012 17:53:26 +0100

Le 02/11/2012 20:59, Michael Richardson a écrit :
>
> Alexandru Petrescu <[email-masked]> 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> uncovered areas.  There, one would still want vehicles to AP>
> inter-communicate.
>

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.

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.
>
> AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP>
> integrated in ISO 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

---

From: Romain KUNTZ <[email-masked]>
Date: Sat, 3 Nov 2012 18:54:45 +0100

Hello Alex,

> this is next to impossible to configure with some existing software.

Why two Relays? I believe one relay listening to multiple interface is enough. 

Romain

> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Romain KUNTZ <[email-masked]>
Date: Sat, 3 Nov 2012 19:05:16 +0100

Hello Alex,

> without fear of disturbing infrastructure routing, and happily without

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?

Thank you,
Romain

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Nov 2012 19:25:05 +0100

Le 03/11/2012 18:54, Romain KUNTZ a écrit :
>>> ralph> Why wouldn't RPL be used for such networks? It has
>>> built-in PD for ralph> dynamic networks, if I understand it
>>> correctly, with RA used at the ralph> subnet level.
>>>
>>> Alexandru Petrescu <[email-masked]> wrote: AP> RA
>>> used to exchange routes - if this is what you mean, and yes it
>>> may be AP> used by RPL (last time I read it).
>>>
>>> AP> However, I doubt RPL can Delegate Prefixes (in the pure
>>> sense of Prefix AP> Delegation).
>>>
>>> wouldn't extend RPL to do this, however, I'd send a DHCPv6 PD
>>> format message.  It can be a single exchange, and nobody said a
>>> single program can't speak multiple protocols.
>>
>> Yes, but consider that DHCPv6-PD is already used in a rather
>> complicated way on the MR of an IV (Internet Vehicle).  It is used
>> according to rfc6276, to obtain a prefix from home.  In that it is
>> specified that MR should be both a Requesting Router and a Relay
>> for that tunnel interface.
>>
>> On another hand, if the MR of LV requests a Prefix from the IV's
>> MR then this latter should also be a Relay, but on a real interface
>> as well.
>>
>> One ends up with two Relay software on the same machine.  I am
>> afraid this is next to impossible to configure with some existing
>> software.
>

Yes, a Relay I guess could listen on two interfaces (to be checked?).

But I mean the Relay's interface towards the other end, the one towards
the Server.  I think, if I'm not wrong, that's only one interface
possible.  MIP-NEMO-DHCP-PD would use it to talk to HA.

The MR-IV would need this additional Relay's interface towards the
immediate fixed infrastructure (not the remote tunnelled HA).  In the
case one would want direct IV-LV communications without HA.

I may be wrong though about Relays' capabilities.  It just that it looks
complex to me to set up, rather than using ND on the link between IV and
LV looks simpler.

Alex

>>> your second vehicle needs to talk to, and why it thinks that
>>> vehicle one (and vehicle one's ISP) is willing to give it
>>> bandwidth.
>>
>> I think both tools of announcing address space, and obtaining
>> address space, should be available to vehicles, and applied
>> depending on whether the communication is between two vehicle
>> devices only, or not, whether the infrastructure is available, or
>> not.
>>
>> It is viable that an LV self-configures ULAs based on VIN and
>> announces them only to vehicles nearby (not to infrastructure).
>>
>> Needing a third or not - I don't know.  But picking homenet
>> protocol, or RPL for vehicles would probably involve a large
>> change in requirements of either.
>>
>> Alex
>>
>>>
>>
>>
>> [email-masked] Administrative Requests:

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Nov 2012 19:29:49 +0100

Le 03/11/2012 19:05, Romain KUNTZ a écrit :
>>> 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.
>>
>>  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.

(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.)
>>
>>>
>>> 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.
>>>
>> Yes, I wonder about this as well.  I think Thierry or Jong-Hyouk
>> are in best position to briefly describe this.
>>
>> (it may look expired but there is intention on continuing it, I
>> believe) Is this pointer working for you?
>>
>> Alex
>>
>>>
>>>
>>>

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 3 Nov 2012 18:00:06 -0400

> specified or coded, I just suppose it as natural).

It is specified, unfortunately current implementations often fail to behave as specified.

There is a second bit of wording, in 6402 I believe, which says that one ought to also immediately de-advertise (as in, for a few RA intervals send RAs with the lifetime set to zero) a prefix that no longer has upstream connectivity, even if the delegation still has valid lifetime and even if the lifetime you were previously advertising has not expired, until the upstream comes back.

In other words, the RAs present on a link should at all times accurately reflect what prefixes are actually available and useful.

Andrew

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 5 Nov 2012 11:01:08 +0100

> Yes, a Relay I guess could listen on two interfaces (to be checked?).

From what I understand, RFC3315 does not forbid it.

> case one would want direct IV-LV communications without HA.

In the scenario from your draft, it seems that the DHCPv6 server that delegates prefix to the MR-IV and to the MR-LV is the same, so why would that interface be different? In both cases the DHCPv6 messages would go through the MR-IV - HA tunnel, or did I miss something? 

But even you use different interfaces, I believe nothing prevent a DHCPv6 relay to do so. There is no considerations on the number of interfaces to send/receive messages in RFC3315. Sending or relaying messages to a server is just a matter of knowing the server address and having a route for it. 

Before discussing solutions, I think there are probably a number of questions to answer about the ITS scenarios. For example, would the DHCPv6 server delegating prefixes for the MR-IV and the MR-LV be the same or not? Each would probably belong to the provider affiliated with the vehicle.

Thank you,
Romain

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 5 Nov 2012 11:12:00 +0100

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Nov 2012 14:56:22 +0100

Le 05/11/2012 11:01, Romain KUNTZ a écrit :
>>>>> Alexandru Petrescu <[email-masked]> wrote: AP>
>>>>>  RA used to exchange routes - if this is what you mean, and
>>>>> yes it may be AP> used by RPL (last time I read it).
>>>>>
>>>>> AP> If the question is about this, then I think it is
>>>>> pertinent. One may AP> imagine a way to use RPL on the MRs
>>>>> for that purpose.
>>>>>
>>>>> RPL doesn't do this in protocol, but then, neither does ND.
>>>>> I wouldn't extend RPL to do this, however, I'd send a DHCPv6
>>>>> PD format message.  It can be a single exchange, and nobody
>>>>> said a single program can't speak multiple protocols.
>>>>
>>>> complicated way on the MR of an IV (Internet Vehicle).  It is
>>>> used according to rfc6276, to obtain a prefix from home.  In
>>>> that it is specified that MR should be both a Requesting Router
>>>> and a Relay for that tunnel interface.
>>>>
>>>> On another hand, if the MR of LV requests a Prefix from the
>>>> IV's MR then this latter should also be a Relay, but on a real
>>>>  interface as well.
>>>>
>>>> afraid this is next to impossible to configure with some
>>>> existing software.
>>>

Yes, I think Relqy could listen on several interfaces on which Clients
connect.

>> But I mean the Relay's interface towards the other end, the one
>> towards the Server.  I think, if I'm not wrong, that's only one
>> interface possible.  MIP-NEMO-DHCP-PD would use it to talk to HA.
>>
>> immediate fixed infrastructure (not the remote tunnelled HA).  In
>> the case one would want direct IV-LV communications without HA.
>
> In the scenario from your draft, it seems that the DHCPv6 server that
> delegates prefix to the MR-IV and to the MR-LV is the same, so why
> would that interface be different? In both cases the DHCPv6 messages
> would go through the MR-IV - HA tunnel, or did I miss something?
>
> But even you use different interfaces, I believe nothing prevent a
> DHCPv6 relay to do so. There is no considerations on the number of
> interfaces to send/receive messages in RFC3315. Sending or relaying
> messages to a server is just a matter of knowing the server address
> and having a route for it.

Right, I meant that interface towards the Server.  Ok, it is a matter of
knowing the server's address and having a route for it.

There may be two problems: (1) the Server to which Relay should connect
may be different from place to place and (2) in case MIP-NEMO-DHCP-PD is
run on MR then there should be two different Relays - one that uses the
Server in the immediately available infrastructure and the second for
the HA.  (I ma not sure whether two different Relays can be run
independently on same machine, probably they could).

> Before discussing solutions, I think there are probably a number of
> questions to answer about the ITS scenarios.

I agree with you that before discussing solutions we may need to better
describe the scenarios.

> For example, would the DHCPv6 server delegating prefixes for the
> MR-IV and the MR-LV be the same or not? Each would probably belong
> to the provider affiliated with the vehicle.

This may be a perspective.

We  also consider only the IV (Internet Vehicle) has a SIM card and a
provider.  The LV (Leaf Vehicle) is not billed by that provider since it
has no SIM.  This may be a problem per se, in that its operator would
likely avoid allowing IV to sub-delegate further the prefixes it obtained.

Alex

>
> Thank you, Romain
>
>> I may be wrong though about Relays' capabilities.  It just that it
>>  looks complex to me to set up, rather than using ND on the link
>> between IV and LV looks simpler.
>>
>> Alex
>>
>>>
>>> Romain
>>>
>>>>> But, I question whether one always needs to get address
>>>>> space, vs announce it.  I don't know the answer: it really
>>>>> depends upon who your second vehicle needs to talk to, and
>>>>> why it thinks that vehicle one (and vehicle one's ISP) is
>>>>> willing to give it bandwidth.
>>>>
>>>> devices only, or not, whether the infrastructure is available,
>>>>  or not.
>>>>
>>>>> If you don't want to speak RPL, then you need to pick the
>>>>> TBD homenet-routing-protocol. We don't need a third.
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Nov 2012 15:02:34 +0100

Le 05/11/2012 11:12, Romain KUNTZ a écrit :
>>>>>  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.
>>>>
>>>> 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.
>>>>
>>>> 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?
>>
>> 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 [email-masked].

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> 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
>>>> Yes, I wonder about this as well.  I think Thierry or
>>>> Jong-Hyouk are in best position to briefly describe this.
>>>>
>>>> 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
>>>> Administrative Requests:

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Nov 2012 13:21:34 +0100

Le 22/10/2012 19:06, Alexandru Petrescu a écrit :
> Le 22/10/2012 02:54, Mark Smith a écrit : [...]
>> off. My point was that there is a method available for a relay to
>> discover DHCPv6 servers without the configuration issues related
>> to only being able to use a specific GUA or ULA unicast address.
>
> Well, the use of multicast to identify the servers may indeed seen as
> a good way towards discovering a server.
>
> But that would assume the IP multicast is working beyond just one
> link. Which is good if it is deployed, but is it.  Shoudl one require
> PIM-SM in the infrastructure in order to make sure that DHCP-PD works
> on a road between an LV and an IV?  I doubt.
>
> (as with homenet - should I require my operator to run PIM-SM in its
> network in order for me to be able to turn on an IPv6 WiFi range
> extender DHCP Client which connects to the ADSL box DHCP Relay?)

Let me add to my own message.

The use of multicast distribution of Request from Relay to Server not
only assumes that a multicast tree is maintained (PIM?) but also that
security IPsec is practically absent between the two.

(I just had a discussion with a colleague about this).

Alex

>
> Alex
>
>>> It seems to me that it is asking for trouble - anyone could set
>>> up a server and add themselves to that group, then receive - and
>>> answer! - DHCP queries. That is of course true anyway on the
>>> client link, but it's a different scale of problem on the wider
>>> network. Mitigation would need filters everywhere, just in case.
>>
>> True, however you also have the same sort of vulnerability issues
>> to rogue
>>
>> DHCP servers. That would be one of the considerations of whether
>> to do it or not.
>>
>>> Unicasting from relays requires configuration of all relays, but
>>> that is required anyway - and all the relays could have the
>>> *same* configuration, which is always good.
>>>
>>
>> Well, the same multicast address would be used on the relays'
>> configurations,
>>
>> so they'd all be the same. The drawback of unicast is that the
>> relay target DHCPv6 server becomes a single point of failure. I'm
>> not sure if you could use or whether it would be wise to use an
>> anycast address as a DHCPv6 server address in that scenario.
>>
>>
>>> My understanding (poor) is that since site-local was deprecated,
>>> the various ff05::/16 addresses were pretty much deprecated as
>>> well.
>>
>> I'm pretty sure site-local multicast scope wasn't deprecated with
>> site-local
>>
>> unicast addresses were. The issue with site-local unicast
>> addresses wasn't that the idea of a site was invalid, it was their
>> non-uniqueness and therefore it recreated in IPv6 all the sorts of
>> issues similar we suffer from with overlapping or duplicated
>> RFC1918 address spaces. If you ever want to explain to IPv4 people
>> the issues with duplicated RFC1918 address spaces, the IPv6 site
>> local deprecation RFC provides a good list.
>>
>>
>>> Actually that's not an understanding, it's an assumption :-) And
>>> I can see that an alternative path would be to let all the
>>> site-local well-known addresses stand alone; no longer site-local
>>> as such, just "they are what they are".
>>>
>>> Regards, K.
>>>
>>
>>
>> Regards, Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Nov 2012 13:24:21 +0100

Le 22/10/2012 18:58, Alexandru Petrescu a écrit :
> Le 21/10/2012 23:45, Mark Smith a écrit :
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Alexandru Petrescu <[email-masked]> To:
>>> [email-masked] Cc: [email-masked] Sent: Sunday, 21 October 2012
>>> 4:56 AM Subject: Re: Announcing Prefix Delegation extensions to
>>> ND draft-kaiser-nd-pd-00.txt
>>>
>>> Le 20/10/2012 18:36, [email-masked] a écrit :
>>>>> 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.
>>>>
>>>> The obvious conclusion to this argument is that a *lot* of
>>>> DHCP functionality will be duplicated in ND. Is this where we
>>>> want to go?
>>>
>>> I guess yes, and vice-versa.
>>>
>>>> I'm coming from the DHCP side of the argument. In my world DHCP
>>>> is needed because it gives you a single place to handle dynamic
>>>> address allocation, *and* it ties in with all sorts of support
>>>> & backend systems.
>>>
>>> Well yes, when that backend is a fixed infrastructure with
>>> things planned, highly human assisted.  But in a dynamic yet
>>> simple network (without assistance of various backend) it's hard
>>> to use DHCP: a Relay can't 'discover' a Server,
>>
>>
>> Actually it can, as the destination address for the server the
>> relay uses can be the all-dhcp-serviers site-local
>> (FF05:0:0:0:0:0:1:3) multicast address. DHCPv6 uses multicast
>> addresses where ever possible for these sorts of scenario.
>
> But isn't it that the DHCPv6 server must have a conf file which
> records in a fixed way the Relay's IP address?

I just learn from a collegue that the Server may not all implementations
need to hardcode the Relay's IP address at the Server - the Server would
simply Reply to the src address of the incoming Request.

Which could be fine in many cases.  But I doubt a Server in a cellular
operator would allow any Relay owning a SIM card to connect to it.

Alex

>
> Alex
>
> Geographically distributed DHCPv6 servers can then be
>> a member of a multicast that spans locations across the network.
>>
>>
>> RFC3315, 5.1. Multicast Addresses
>>
>> DHCP makes use of the following multicast addresses:
>>
>> All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
>> multicast address used by a client to communicate with neighboring
>> (i.e., on-link) relay agents and servers. All servers and relay
>> agents are members of this multicast group.
>>
>> All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used
>> by a relay agent to communicate with servers, either because the
>> relay agent wants to send messages to all servers or because it
>> does not know the unicast addresses of the servers.  Note that in
>> order for a relay agent to use this address, it must have an
>> address of sufficient scope to be reachable by the servers.  All
>> servers within the site are members of this multicast group.
>>
>>
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Nov 2012 13:30:41 +0100

When I presented this draft, Lorenzo explained that it's not good to
claim that ND is faster than DHCP (two messages instead of 4) because
DHCP has this Rapid Commit feature.  To which I agree.

But, consider that in V2V2I we may need not only Prefix Delegation but
also route exchange at the same time (IV delegates a global prefix to
LV,  and IV and LV exchange their self-formed ULA prefixes).  This
operation could be realized with a minimum 2 messages (IV sends RA with
delegated prefix and its own ULA prefix whereas LV sends RA with its own
ULA prefix).  This operation can not be achieved so with DHCP because
DHCP is request-response.

Moreover, DHCP as it stands today can not do route exchange at all.  The
only possibility is maybe be with the ongoing DHCP route-option draft.
But there seem to be the same opposition to make that progress.

Alex

Le 19/10/2012 09:59, Alexandru Petrescu a écrit :
> Dear participants to 6man group,
>
> We just submitted "Prefix Delegation extension to Neighbor Discovery
> protocol" draft-kaiser-nd-pd-00 available at:
> http://tools.ietf.org/html/draft-kaiser-nd-pd-00
>
> The context is vehicular environments, the goal to realize IP
> vehicle-to-vehicle-to-infrastructure communications.
>
> We had several problems to solve before materializing IP
> connectivity between vehicles and up to infrastructure: which IPv6
> addresses to use in a disconnected vehicle, how would one
> Internet-connected vehicle offer access to several IP devices in a
> nearby non-SIM-but-WiFi vehicle, etc.
>
> To solve the latter, we started by using existing ND, DHCP and Mobile
> IP protocols and realized that some mechanisms were missing.  Some of
> the needed mechanism was Prefix Delegation in ND (even though ND does
> offer default route, address auto-config, _is_ widely available,
> etc.)
>
> Hence we conceived this PD method for ND which is just one part of a
> bigger system.  We have prototyped and experimented it.
>
> We would like the 6man group to consider this draft.
>
> Comments about the idea in this draft?  About the problem?
>
> Thanks in advance,
>
> Alex
>
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title           : Prefix Delegation extension to Neighbor
>> Discovery protocol Author(s)       : Arnaud Kaiser Sylvain Decremps
>> Alexandru Petrescu Filename        : draft-kaiser-nd-pd-00.txt
>> Pages : 24 Date : 2012-10-15
>>
>> Abstract: This document describes an extension to the Neighbor
>> Discovery protocol (ND).  The proposed extension enhances ND by
>> providing it a new option: the Prefix Delegation option (ND_PD).
>> ND_PD offers the possibility for a router to ask for prefixes to
>> be delegated, even if no DHCPv6 Server (or Relay) are present on
>> link.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-kaiser-nd-pd
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-kaiser-nd-pd-00
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ I-D-Announce
>> mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Nov 2012 09:56:00 -0500

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> But, consider that in V2V2I we may need not only Prefix
    Alexandru> Delegation but also route exchange at the same time (IV
    Alexandru> delegates a global prefix to LV, and IV and LV exchange
    Alexandru> their self-formed ULA prefixes).  This operation could be
    Alexandru> realized with a minimum 2 messages (IV sends RA with
    Alexandru> delegated prefix and its own ULA prefix whereas LV sends
    Alexandru> RA with its own ULA prefix).  This operation can not be
    Alexandru> achieved so with DHCP because DHCP is request-response.

I don't think that the number of messages (2 vs 4) is particularly
relevant.  There are too many big picture questions which are not yet
answereed.

-- 
Michael Richardson
-on the road-

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 08 Nov 2012 00:02:42 +0100

> relevant.  There are too many big picture questions which are not yet

Well yes, let me try to understand what do you mean by these big picture 
questions?

Alex

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 13:12:03 -0500

{appologies if this is a resend}

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> Well yes, let me try to understand what do you mean by these big picture
    Alexandru> questions?

1) what use cases need topologically significant prefixes with default routes
2) what use cases need to exchange routes to locally configured
   Non-Connected Network prefixes (whether RIR NCN, or ULA)

Those two situations need to be seperated.  
They are not the same thing, or the same problem.

In case #1, one needs to further split this into
1a) managed situations where all systems are under the control
    of a single administrator (aka "intra-AS")

1b) unmanaged situations where an individual lends another individual
    some bandwidth.

(1b) seems really easy in today's multiply NAT'ed IPv4, because the NAT 
     erases all evidence that first individual might have violated 
     an AUP. (I disagree with those AUPs)

-- 
Michael Richardson
-on the road-

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Nov 2012 11:16:32 +0100

Le 08/11/2012 19:12, Michael Richardson a écrit :
> Alexandru> Well yes, let me try to understand what do you mean by
> these big picture Alexandru> questions?
>

A vehicle assigned with globally-scoped IP subnet, and connecting to the
cellular network must be topologically correct at the point of
attachment, otherwise ingress filtering prevents its communications to CN.

If Mobile IP is used to alleviate this problem (i.e. tunnel to the HA
such that the prefix invalid at that attachment becomes valid thanks to
the topologically correct CoA), then one should consider that HA may not
be reachable sometimes, e.g. because network is down.

Whereas this problem of HA unreachability preventing one vehicle's MR to
communicate to Internet may not be that much apparent, considering that
the MR still has a CoA with wich to communicate.

The problem is more apparent for LFNs (devices) within the vehicle -
they wouldn't be able to communicate when the HA is unreachable.

The problem is further exacerbated when considering LVs (Leaf Vehicles -
capable of doing only short range link layers, no SIM card).  These LVs
are not capable to communicate to Internet (neither their LVs nor their
LFNs) when the IV's HA is unreachable.

> Non-Connected Network prefixes (whether RIR NCN, or ULA)

There are a number of specific vehicular communications use cases which
need one vehicle to communicate to another even though the
infrastructure is not available.

I mention one just for example but there are many others.

'Platooning' involves a chain of one 'head' larger vehicle which
dictates speed to vehicles behind it in a chaining like fashion.  This
is typically achieved with onboard radars (and maybe lasers?) but there
exist certain needs (ask) to move this to IP communications.  One
possible way is for the 'head' to sample its GPS location at very high
frequency and transmit it to the next vehicle which in turn decides fine
up/down speed steps.  This communication pattern does not need global
addressing - ULA is sufficient.  The ends of the communications are
within this ephemeral platoon only.

Other more entertainment 'V2V' communications involve video conferencing
between passengers of vehicles, and more.

> Those two situations need to be seperated. They are not the same
> thing, or the same problem.

Ok, I agree to separate the situations.

> In case #1, one needs to further split this into 1a) managed
> situations where all systems are under the control of a single
> administrator (aka "intra-AS")
>
> 1b) unmanaged situations where an individual lends another
> individual some bandwidth.

Yes, I agree.

> (1b) seems really easy in today's multiply NAT'ed IPv4, because the
> NAT erases all evidence that first individual might have violated an
> AUP. (I disagree with those AUPs)

Well ok and it seems impossible with non-NAT IPv6.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Nov 2012 14:01:48 +0100

> 1) what use cases need topologically significant prefixes with

I am not sure why default routes are mentioned in this question of
topologically significant prefixes (i.e. using Internet global addresses)?

I think a default route (an entry in the routing table) needs to be
known at any host or router which gets a global address or prefix
(except maybe DFZ).  This is so because it is impossible to store in a
node a route for each destination its application may run (there are
many applications).

One may question why a default route is needed in a smaller local domain
of ULA addressing were Internet is not available.  I think that even in
that case a default route is useful for its relationship to hierarchical
addressing - because it offers smaller routing table sizes.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Nov 2012 13:30:05 +0100

Hello Michael,

Thank you for the reply.  I have some comments, see below.

Le 28/11/2012 15:28, Michael Richardson a écrit :
> Alexandru> A vehicle assigned with globally-scoped IP subnet, and
> connecting to the Alexandru> cellular network must be topologically
> correct at the point of Alexandru> attachment, otherwise ingress
> filtering prevents its communications to CN.
>
> You explained the question in detail.   All of what you wrote is
> true, but it's also true that the Mars Curiosity Rover could share
> it's bandwidth with Marvin Martian, but we are not yet planning for
> that problem.  This is the internet *ENGINEERING* task force, and we
> have to make tradeoffs to solve problems people actually have, not
> theorectical problems that might show up.
>
> You didn't give me a use case.
>
> A use case would be something like: SNCF wifi services needs this
> when parked in an underground station where 3G will be unavailable
>
> This use case implicitly tells me that the leaf vehicles are under
> the same administrative authority, and share some kind of trust
> relationship, and the uplink provider understands that multiple
> prefixes will be required.

Let me explain.

I agree to usefulness of such usecase description - it expresses
incentive to immediate deployment and thus precise problems to be solved.

There may exist restraints to mention company names like 'SNCF' in
public emails.  I am not employed by 'SNCF' and even if I sometimes work
_with_ e.g. 'SNCF' they wouldn't appreciate to see their most immediate
deployment plans revealed in public email lists.   Hence this apparent
schism between my scenario description and real deployments.

That said, we do co-author a published I-D 'Scenarios Reqs' together
with an industry partner in this space and we are interested to
improving it, by getting comments of the kind you provided above - thank
you.
(draft-petrescu-its-scenarios-reqs-01)

>>> Non-Connected Network prefixes (whether RIR NCN, or ULA)

What is NCN non-connected networks - is there a reference, I am not
feeling lucky, thank you.

> Alexandru> There are a number of specific vehicular communications
> use cases which Alexandru> need one vehicle to communicate to
> another even though the Alexandru> infrastructure is not available.
>
> Alexandru> I mention one just for example but there are many others.
>
> Alexandru> 'Platooning' involves a chain of one 'head' larger
> {details deleted}
>
> ...
>
> Alexandru> Other more entertainment 'V2V' communications involve
> video conferencing Alexandru> between passengers of vehicles, and
> more.
>
> those seem like very useful things.   Do you agree that they need
> routing, not prefix allocation?

Yes and no.

There are two different cases: either each vehicle has hardcoded
prefixes or it has no hardcoded prefixes.

In the first case, if a vehicle has hardcoded prefixes - then routing is
needed, in your terms - the vehicle needs to inform the other vehicles
about its own prefix.

In the second case, if a vehicle has no hardcoded prefixes, then a
vehicle must obtain a prefix from somewhere, for its own use.  If
infrastructure is not available, then it should obtain such a prefix
from a vehicle nearby.

> Alexandru> Yes, I agree.
>
>>> (1b) seems really easy in today's multiply NAT'ed IPv4, because
>>> the NAT erases all evidence that first individual might have
>>> violated an AUP. (I disagree with those AUPs)
>
> Alexandru> Well ok and it seems impossible with non-NAT IPv6.
>
> What I predict is that individuals that wish to share their uplink
> connectivity, and are on providers which will not give them enough
> prefixes so that they can share, will make use of either mobile IP or
> other IP6-in-IP6 (including Teredo and ayyaya/aiccu) technologies to
> get the addressing they need.  I don't see a reason to need any
> protocol other than DHCPv6 PD for this.

Ok, administratively, in the case _individuals_ need to share their
uplink connectivity.  In addition to individuals, we also consider
groups of individuals (like train coach/wagon, or larger vehicles).  For
these, the billing notion of 'individual' is blurred - it's more
'enterprise' or so.

An operator may wish initially to control this form of sharing either by
higher subscription rates($) for enterprise-class or by owning the
device (the Mobile Router).  But as time advances, only the first is
kept in place - i.e. allow the SIM to be put in a non operator-owned
Mobile Router, but still charge more if traffic levels indicate some
form of sharing.

Technically, about Mobile IP, IPv6-in-IPv6 and DHCPv6-PD.

Mobile IP may indeed be used on one vehicle which has cellular
connectivity, SIM card.  This has certain advantages.  It may keep a
pre-allocated/hardcoded prefix in the vehicle and use tunnels to respect
topological correctness at the Internet in the fixed infrastructure.

But Mobile IP also has inconvenients.  A vehicle without long range
connectivity (w/o SIM) but with short range like 802.11p/b, connecting
to another vehicle and using Mobile IP will involve artificially long
paths - not only classical triangular routing but rectangular routing (a
known problem in Mobile IP NEMO - 2 MRs, 2 HAs, 4 angles).  This 4-leg
routing is so artificial when knowing that the two vehicles are just
there, one near the other.  It's because Mobile IP.

Second, Mobile IP has one option of dynamically configuring the prefix
within the moving network - it's DHCPv6-PD for NEMO.  This requires the
use of Relay and Client simultaneously on the MR.  If that same vehicle
which does Mobile IP/NEMO also would be DHCP Server then one ends up
with a Relay, a Client and a Server on the same machine.  Moreover, if
one needs that MR to sometimes obtain a prefix from the immediate
infrastructure (not from HA) then one ends with 2 Clients, Relay,
Server, all on same machine.

Other forms of dynamic IPv6-in-IPv6 tunnelling may indeed be considered
instead of Mobile IP.  But conceptually they all suffer from same
problem - they need the presence of an infrastructure tunnel endpoint;
this is artificial when knowing the two vehicles are just there nearby.

> I think that much of the challenge you have seen has been as a
> result of trying to hack software that isn't architected to do v6-PD
> client and server.

Well, I don't think DHCP-PD is architected to run 2 Clients, a Relay and
a Server on the same machine in order to achieve LV-to-IV
communications.  There must be a simpler architecture to realize that.

And yes, we do consider ND to realize PD thinking it should be simpler.

> dnsmasq has grown v6-PD recently.

Ok, I didn't know dnsmasq could do Prefix Delegation too.

In separate searches we identified other protocols that may-if-extended
do Prefix Delegation: EAP(PANA?), OSPF, LDAP.

We could discuss separately about each one of those.

Alex