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

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Oct 2012 09:59:57 +0200

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: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Oct 2012 10:08:39 +0200 (CEST)

> Comments about the idea in this draft?  About the problem?

What is the rationale for duplicating the functionality in DHCPv6-PD into 
ND? If code needs to be changed, why can't that code change be to 
implement existing standard instead of implementing a new standard?

Isn't ND handled by the kernel in a lot of OSes? Does prefix delegation 
really belong there?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philipp Kern <[email-masked]>
Date: Fri, 19 Oct 2012 10:22:13 +0200

Mikael,

am Fri, Oct 19, 2012 at 10:08:39AM +0200 hast du folgendes geschrieben:
> What is the rationale for duplicating the functionality in DHCPv6-PD
> into ND? If code needs to be changed, why can't that code change be
> to implement existing standard instead of implementing a new
> standard?
> 
> Isn't ND handled by the kernel in a lot of OSes? Does prefix
> delegation really belong there?

that reminds me of the RA/DHCPv6 for DNS recursor host configuration in
RFC4339, which provides advantages/disadvantages for shipping this
information by RDNSS vs. DHCPv6.

Kind regards
Philipp Kern

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Oct 2012 10:50:21 -0500

Hi Mikael,

On Fri, Oct 19, 2012 at 3:08 AM, Mikael Abrahamsson <[email-masked]> wrote:
> ND? If code needs to be changed, why can't that code change be to implement
> existing standard instead of implementing a new standard?
>

It is not just implementing that code in one node. DHCPv6-PD requires
Delegating Router on a DHCP server somewhere and then Requesting
Router on the edge router (there was a proposal to implement it on a
UE).

It is a system support issue, I think.

Regards,

Behcet
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Oct 2012 18:16:45 +0200 (CEST)

> Router on the edge router (there was a proposal to implement it on a

I know of implementations that do this in a single box (local DHCPv6-PD 
address pool), so that's not a deciding argument as far as I can tell.

> It is a system support issue, I think.

Well, that's what I'm after, the actual rationale. In the document, as far 
as I could find, the only motivation for implenting PD in ND was 
"DHCPv6-PD might not be available".

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Oct 2012 17:38:52 +0200

> to implement existing standard instead of implementing a new

Well, as you say below it depends on the software availability on
various platforms and contexts.  To such a generic question I could only
say that in some setting ND is preferred over DHCP but still prefix
delegation is needed.

> delegation really belong there?

Right, parts of ND are handled in kernel in most OSes.  But one key part
that would need to be modified is RA and that is userspace.  In linux
that means mainly radvd, and curiously enough that lacks RS which is
mostly kernel.

So, instead of preferring DHCP one may bring RS out of kernel into radvd
(a so called 'rsadvd').  At that point it's relatively easier to do
Prefix Delegation with ND than with DHCP, implementation-wise, not least
because code is smaller.

Where does PD belong - to DHCP or ND is a long discussion and I'll be
happy to take part if it happens.

ND to assign _full_ addresses (instead of just beaconing a prefix) is
something to which there was opposition but which also got RFC'ed.  If
that happened then why not prefixes as well.

If the discussion turns about which use case, then also I can provide
description about the use case - it's mostly in vehicular environments.

Listening.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Oct 2012 17:43:13 +0200

Le 19/10/2012 10:22, Philipp Kern a écrit :
>> What is the rationale for duplicating the functionality in
>> DHCPv6-PD into ND? If code needs to be changed, why can't that code
>> change be to implement existing standard instead of implementing a
>> new standard?
>>
> that reminds me of the RA/DHCPv6 for DNS recursor host configuration
>  in RFC4339, which provides advantages/disadvantages for shipping
> this information by RDNSS vs. DHCPv6.

I agree.  There is a certain similarity.  And there still exist
parameters exclusively configured by DHCP while others exclusive to ND
(MTU, printers, more).  As long as they exist trend will push to do at
one what the other does.

(let me add that I received a couple of private emails questioning the
necessity of ND PD even for vehicular environments, and citing ND PD
similar work some of which we still need to cite in our draft. I replied
privately but I am open to discussion on the mailing list as well.)

Listening.

Alex

>
> Kind regards Philipp Kern
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Oct 2012 17:46:48 +0200

Le 19/10/2012 17:50, Behcet Sarikaya a écrit :
> It is not just implementing that code in one node. DHCPv6-PD
> requires Delegating Router on a DHCP server somewhere and then
> Requesting Router on the edge router (there was a proposal to
> implement it on a UE).
>

I tend to agree.

I also work in a perspective where it is hard to say today which
particular feature will future ND and future DHCP support, especially in
vehicular environments.  In this sense, intelligent mechanisms may be
needed for an arbitrary vehicle to decide what kind of protocol to use
when facing another vehicle ready to provide it a default route and
maybe a prefix: try first ND, then DHCP... or similar logic.  However,
as much as I consider a system issue and appreciate the value of an
algorithm implementing it, it may be the case that no real protocol work
could be documented in an Internet Draft about such system issue.

Just some thoughts.

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Oct 2012 17:54:48 +0200

Le 19/10/2012 18:16, Mikael Abrahamsson a écrit :
> I know of implementations that do this in a single box (local
> DHCPv6-PD address pool), so that's not a deciding argument as far as
> I can tell.
>
> Well, that's what I'm after, the actual rationale. In the document,
> as far as I could find, the only motivation for implenting PD in ND
> was "DHCPv6-PD might not be available".

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.

In a setting with an IV (Internet Vehicle, with SIM card) and an LV
(Leaf Vehicle, no SIM card) the IV needs to run a DHCP Client to obtain
a prefix for its devices, because LTE only uses DHCP for PD.  Then, if
LV requests a prefix from IV then IV should be able to run DHCP Relay
(or DHCP Server) as well.  This makes IV to must support both Client
_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.

That's one aspect which led to this.

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.

Alex

---

From: [email-masked]
Date: Sat, 20 Oct 2012 18:36:28 +0200 (CEST)

> platforms which have no SIM card.  It may be easier to do this with ND

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

I am against adding lots of new ND functionality until we have DHCPv6
that is considerably more feature complete. Some of this is probably
coming (client MAC address), some of it is still being opposed for
mostly religious reasons (e.g. running DHCP without RA).

Steinar Haug, AS 2116

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Oct 2012 18:36:37 +0200 (CEST)

> that means mainly radvd, and curiously enough that lacks RS which is 

Sending of RA is userspace, reception of RA is kernel.

> Prefix Delegation with ND than with DHCP, implementation-wise, not least 

Why is it easier? Also, I'd imagine there are already implementations of 
DHCPv6-PD available under quite permissive licenses, instead of what 
you're proposing which requires everybody to develop new code.

> happy to take part if it happens.

For me, this is that discussion.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Oct 2012 18:42:28 +0200 (CEST)

> topology can be relatively complex with Client/Relay/Server, whereas ND 

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.

> receiving a prefix and for sending a prefix.

What is cleaner is to use existing standards where there already is 
running code.

> platforms which have no SIM card.  It may be easier to do this with ND 

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.

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Oct 2012 19:56:28 +0200

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

I guess yes, and vice-versa.

>  allocation, *and* it ties in with all sorts of support & backend

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, a Relay can hardly become a Server upon
network change, etc.

> mostly religious reasons (e.g. running DHCP without RA).

As a side note, running DHCP without RA has significant advantages in
machine-class devices.  The memory constraint may lead to select one
among the two to implement, not the two in the same small memory.

In the same class, one may also prefer _just_ ND; but it does not give
it enough functionality to establish IP.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Oct 2012 20:01:36 +0200

Le 20/10/2012 18:36, Mikael Abrahamsson a écrit :
>> Right, parts of ND are handled in kernel in most OSes.  But one
>> key part that would need to be modified is RA and that is
>> userspace. In linux that means mainly radvd, and curiously enough
>> that lacks RS which is mostly kernel.
>

Right, and that may make it an issue.  Our implementation of reception
RA is userspace.  I think it does not interfere with what the kernel
first does with that RA.  This should be ensured.

>> So, instead of preferring DHCP one may bring RS out of kernel into
>> radvd (a so called 'rsadvd').  At that point it's relatively easier
>> to do Prefix Delegation with ND than with DHCP,
>> implementation-wise, not least because code is smaller.
>
> Why is it easier? Also, I'd imagine there are already
> implementations of DHCPv6-PD available under quite permissive
> licenses, instead of what you're proposing which requires everybody
> to develop new code.

Well, not everybody should develop new code.  Just download some :-)

But there is indeed a point about compatibility with existing ND
implementations.  There may be a need to make sure that the proposed PD
extension implementation does not break other computers' ND stacks when
faced with it.  I think this would be enough, no?

Alex

>> Where does PD belong - to DHCP or ND is a long discussion and I'll
>> be happy to take part if it happens.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Oct 2012 20:10:59 +0200

Le 20/10/2012 18:42, Mikael Abrahamsson a écrit :
>> 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.
>

Right, there is cleanliness in reuse.  Reuse as much as possible.

> 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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Oct 2012 22:08:13 +0200 (CEST)

> are independent of DHCP implementation.  One has to touch the conf files

I'm sorry. I don't follow your reasoning.

Could you please write some text with a clear use case where DHCPv6-PD 
can't be used for what you want to do, thus justifying why your proposal 
is needed? Please keep it at a protocol level, not implementation level.

> Right, there is cleanliness in reuse.  Reuse as much as possible.

Then why do you feel the need to create something new when there already 
is existing standards that will achieve the same thing?

> change the delegated prefix when the assigned prefix changed.

FOSS = Free and Open Source Software.

> implementation.  This is a matter of further work.

I'd say it's an absolute requirement that any proposal do not break 
existing implementations.

---

From: Doug Barton <[email-masked]>
Date: Sat, 20 Oct 2012 13:26:22 -0700

> mostly religious reasons (e.g. running DHCP without RA).

+1 on all counts.

Doug

-- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 21 Oct 2012 11:45:30 +1100

>allocation, *and* it ties in with all sorts of support & backend

=> Agreed. I'm not coming from a DHCP side of the argument but I see the
only reason for having
this feature is that some people think adding/implementing this in ND is
more convenient than adding a DHCP agent/relay.
I don't agree. But even if that's the truth, it seems to be six of one and
half dozen of the other. No compelling reason AFAICS.

Hesham

---

From: Thierry Ernst <[email-masked]>
Date: Sat, 20 Oct 2012 23:51:44 +0200

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 ?

Thierry

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2012 14:45:18 -0700 (PDT)

----- 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
> 
> 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. 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: Karl Auer <[email-masked]>
Date: Mon, 22 Oct 2012 10:52:34 +1100

On Sun, 2012-10-21 at 14:45 -0700, Mark Smith wrote:
> address.

I have yet to see this in the wild, and would be interested to hear if
anyone actually does this. 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.
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.

My understanding (poor) is that since site-local was deprecated, the
various ff05::/16 addresses were pretty much deprecated as well.
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.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2012 17:29:46 -0700 (PDT)

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Sunday, 21 October 2012 3:36 AM

Can people stop religiously using the "religious reasons" to complain about DHCPv6

not having a default gateway option?

The argument against a default gateway option in DHCPv6 is exactly the one

you're using against additional ND options - it's not only a solved problem,
the code to implement it has been widely deployed and widely works.

Some people believe that you need DHCPv6 to support a default
gateway option so that you can selectively give different hosts different
default gateways. That is not true, RAs can be also selectively sent to
different hosts, and the radvd daemon implements it - see the "clients"
interface option.

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2012 17:54:24 -0700 (PDT)

Hi Karl,

----- Original Message -----
> From: Karl Auer <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Monday, 22 October 2012 10:52 AM
> anyone actually does this.

I'd suggest that is because most people have only lived in a unicast IPv4

world, so there is very little understanding of and recognition of what
value multicast can provide to network operations.

That's not to say it should always be used for a relay, it is a trade

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.

> It seems to me that it is asking for trouble

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.

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

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

> "they are what they are".

Regards,
Mark.

---

From: Karl Auer <[email-masked]>
Date: Mon, 22 Oct 2012 12:30:01 +1100

On Sun, 2012-10-21 at 17:54 -0700, Mark Smith wrote:
> DHCP servers.

Unicast queries go only to the correct servers. Rogues don't get a look
in - except on the single link they are actually on, and filtering
doesn't help there (except on the hosts themselves, I suppose, which
doesn't scale well). You could automate the detection of rogue DHPv6
servers by snooping on MLD - they have to add themselves to the two
DHCPv6 multicast addresses. It'd be an interesting feature to add to
switches, and probably fairly trivial since an IPv6 aware switch already
does MLD snooping...

> Well, the same multicast address would be used on the relays' configurations,

The default for a relay is to send to a well-known site-local multicast
address. No config needed at all.  RFC3315:

   20. Relay Agent Behavior

      [...]If the relay agent has not been explicitly
   configured, it MUST use the All_DHCP_Servers multicast address as the
   default.

You could put a *different* multicast address on the relays, provided
the servers can be configured to support it. However, I reckon unicast
is a better idea, so I'd be interested in the experience of anyone who
has actually tried the multicast method.

> target DHCPv6 server becomes a single point of failure.

You configure the relays with a list of unicast addresses, just as you
do IPv4 "relays" now. No SPOF. RFC3315 again:

   20. Relay Agent Behavior

      The relay agent MAY be configured to use a list of destination
      addresses, which MAY include unicast addresses, the
All_DHCP_Servers
      multicast address, or other addresses selected by the network
      administrator.

> DHCPv6 server address in that scenario.

Actually I'm not sure anycast would work, I haven't thought about it
enough yet ;-) I think there would be issues if failover ever gets
reimplemented for IPv6.

Regards, K.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Oct 2012 18:50:25 +0200

Le 20/10/2012 22:08, Mikael Abrahamsson a écrit :
>> 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.
>
> Could you please write some text with a clear use case where
> DHCPv6-PD can't be used for what you want to do, thus justifying why
> your proposal is needed? Please keep it at a protocol level, not
> implementation level.

Writing this text is feasible.

Let me first try an explanation here.  This topology is extracted from 
the draft.  Is this kind of explanation what would make sense?

                                                     +----------+
                                                     | INTERNET |
                                                     |  ACCESS  |
                                                     +-----+----+
                                                           |
                                                           |
                                                        E2 |
    +-------------------------+               +-------------------------+
    |                         |               |            |            |
    |                         |               |            |            |
    |      +-----------+      | E1         E1 |      +-----------+      |
    |      |   MR-LV   |------|---------------|------|   MR-IV   |      |
    |      +-----------+      |               |      +-----------+      |
    |         I1 |            |               |         I1 |            |
    |            |            |               |            |            |
    |    --------+--------    |               |    --------+--------    |
    |    |     |         |    |               |    |     |         |    |
    |  LFN-1 LFN-2 ... LFN-x  |               |  LFN-1 LFN-2 ... LFN-x  |
    |                         |               |                         |
    +-------------------------+               +-------------------------+

           Leaf Vehicle                            Internet Vehicle

We need MR-LV to be a DHCP Client and acquire a prefix that is 
topologically correct both at MR-IV and in the infrastructure, to avoid 
risks of ingress filtering.

Using DHCP-PD for LV in this figure can be done in two ways: (1) MR-IV 
is a Client+Server or (2) MR-IV is a Client+Relay.  In first case it has 
the drawback that it has to change the prefix it delegates as Server 
each time it acquires a new prefix as Client.  This functionality is not 
part of DHCP.  Besides, the management of different parts (Client and 
Server) of DHCP software on same machine may be cumbersome if I can say 
so.  Add that at times, there may be a need of a third part of DHCP, a 
Client which requests a prefix over a tunnel not over the real iface 
(DHCP-PD for NEMO).  This becomes complex DHCP on same machine.

For the second case - MR-IV is a Client and a Relay, we assume that the 
Server is in the infrastructure and not on MR-IV.  At that point, 
whenever the MR-IV Client changes its IP address, the Relay running on 
the MR-IV must inform the Server about its new IP address.  Otherwise 
the relationship between Relay and Server can't work.  This is not part 
of DHCP and doesnt exist as far as I can tell.

Finally, the connection between MR-LV and MR-IV is a link which does not 
use global addresses - only link local addresses.  MR-LV does not 
require an IP address from anywhere.  It only needs a prefix for its 
LFNs.  The DHCP it may use to acquire that prefix is only a DHCP for a 
prefix, not for addresses.  At that point we may end up with a 
requirement that _both_ DHCP _and_ ND to run on MR-LV.

But MR-LV may prefer to just run one protocol, not two.  Because small.

If MR-LV must choose between which to run - ND or DHCP?  It will choose 
ND because it's the only one to give a default route.  But ND doesn't 
give it Prefix Delegation.  Hence enhance ND with PD.

>>> What is cleaner is to use existing standards where there already
>>> is running code.
>>
> Then why do you feel the need to create something new when there
> already is existing standards that will achieve the same thing?

For several reasons as expressed above.  IT would be good to have only 
one protocol to achieve this V2V2I but as it stands today it requires 
two: ND and DHCP.  Second, DHCP has some issues described according to 
logic above.

>> In addition to FOSS (what is FOSS?) DHCP one also needs to
>> dynamically change the delegated prefix when the assigned prefix
>> changed.
>
>> 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.
>

Yes, noted and set aside to always consider it in further design.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Oct 2012 18:54:59 +0200

>  thus I assume configure all the nodes in the vehicle) every time it

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

>>>> 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.
>>
>>>> _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.
>>>
>>>> smaller platforms which have no SIM card.  It may be easier to
>>>> do this with ND in smaller settings.
>>>
>>> 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.
>>
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Oct 2012 18:56:39 +0200

Le 21/10/2012 02:45, Hesham Soliman a écrit :
>> needed because it gives you a single place to handle dynamic
>> address allocation, *and* it ties in with all sorts of support &
>> backend systems.
>
> => Agreed. I'm not coming from a DHCP side of the argument but I see
> the only reason for having this feature is that some people think
> adding/implementing this in ND is more convenient than adding a DHCP
> agent/relay. I don't agree. But even if that's the truth, it seems to
> be six of one and half dozen of the other. No compelling reason
> AFAICS.

There is already ND on MR-LV and MR-IV.  And it's not enough to do 
Prefix Delegation.  We add a new protocol DHCP-PD but that is not enough 
per se, it needs ND.

I wonder why do we always have to use two protocols when one should be 
sufficient.

Alex

>
> Hesham
>
>
>>
>> I am against adding lots of new ND functionality until we have
>> DHCPv6 that is considerably more feature complete. Some of this is
>> probably coming (client MAC address), some of it is still being
>> opposed for mostly religious reasons (e.g. running DHCP without
>> RA).
>>
>> Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Oct 2012 18:58:05 +0200

Le 21/10/2012 23:45, Mark Smith a écrit :
> 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?

Alex

  Geographically distributed DHCPv6 servers can then be

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Oct 2012 19:06:23 +0200

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?)

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
> 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*
>  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.
>
> 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: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2012 13:05:59 +0100

On 20/10/2012 19:10, Alexandru Petrescu wrote:
..
> needs to change the delegated prefix.

Why wouldn't RPL be used for such networks? It has built-in PD for
dynamic networks, if I understand it correctly, with RA used at the
subnet level.

    Brian

---

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Oct 2012 19:44:32 +0200

> dynamic networks, if I understand it correctly, with RA used at the

My understanding is that RPL assumes a multi-link subnet, with a single prefix used across the entire network and source routing or host-specific routing.

- Ralph

---

From: John Mann <[email-masked]>
Date: Wed, 24 Oct 2012 11:56:33 +1100

Hi,

> Is this answering in the direction you made the question?

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

>>> ------------------------------**------------------------------**--------
>>>
>>>
>>> https://www.ietf.org/mailman/**listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
>>> ------------------------------**------------------------------**--------
>>>
>>
>>
>>>
>>
>> ------------------------------**------------------------------**--------
>> Requests: https://www.ietf.org/mailman/**listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
>> ------------------------------**------------------------------**--------
>>
>>
>
> ------------------------------**------------------------------**--------
> Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
> ------------------------------**------------------------------**--------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Oct 2012 14:41:48 +0200

Le 23/10/2012 14:05, Brian E Carpenter a écrit :
> On 20/10/2012 19:10, Alexandru Petrescu wrote: ..
>> 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.
>

RA used to exchange routes - if this is what you mean, and yes it may be
used by RPL (last time I read it).

If the question is about this, then I think it is pertinent.  One may
imagine a way to use RPL on the MRs for that purpose.

However, I doubt RPL can Delegate Prefixes (in the pure sense of Prefix
Delegation).

What we need here is a means to Delegate Prefixes, not to exchange
routes.  A Prefix is Delegated by one Router to Another by setting up a
route at self towards the other _and_ informing the other about this
Delegated Prefix.  The route exchange operation is different: router
sets up a route entry about a route that the other router tells.

For the operation of exchanging routes we use a different protocol than
RPL, which is also based on RA, but not ND-PD (it is
http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-02)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Oct 2012 14:52:54 +0200

Hi,

Le 24/10/2012 02:56, John Mann a écrit :
> <[email-masked] <mailto:[email-masked]>> wrote:
>

Yes.

> Why do you _want_ the LFN end devices to change IPv6 address as the

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?

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

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

YEs, like at an incident scene, where law enforcement fire department 
vehicles deployed need to exchange files about a casualty.

> 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

>             ------------------------------__------------------------------__--------
>
>
>             [email-masked] <mailto:[email-masked]> Administrative Requests:
>             https://www.ietf.org/mailman/__listinfo/ipv6
>             <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
>         <https://www.ietf.org/mailman/listinfo/ipv6>
>         ------------------------------__------------------------------__--------
>
>
>
>     ------------------------------__------------------------------__--------
>     [email-masked] <mailto:[email-masked]>
>     Administrative Requests:
>     https://www.ietf.org/mailman/__listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     ------------------------------__------------------------------__--------
>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 24 Oct 2012 17:04:15 +0000

If an LV never ever wanted to get a PD from anything other than an IV, and an IV could only ever expect to delegate to a LV, then I see no problem. On the other hand, if these things do expect the same physical links to be used to connect with other ecosystems (like home networks or hotspots) that will be well-established in the IPv6 world by the time these vehicles come along, then I think this proposal has some undesirable ramifications. 

Questions:
Would an LV ever expect to use the same physical link to connect to a home network or hotspot, instead of an IV?
Would an IV ever expect to provide connectivity for devices that think they're inside a home network (e.g., maybe they're in a RV park, and the RV-owners networks are made up of traditional home networking components, so they can connect to non-cellular uplinks when such are available; maybe the IV is the truck pulling a trailer, and there's a regular home network set up in the trailer).

If the answer is no, then read no further.
If the answer is yes, then I'd like to dive a little deeper into understanding the ramifications of what is proposed.

Hotspots and CE (home network) routers will use IA_PD for prefix delegation. Sub-delegating routers attaching to them will request prefixes by IA_PD.
Which means either the LV would have to support both ND_PD and IA_PD, or the hotspot/CE router would have to do so. And whoever does both would have to know which to use in which case, and make sure they don't get things confused between the two. Somebody's complexity-of-code has just been doubled (or more) by the addition of a 2nd way to do the same thing. If it's the hotspot/CE router, then it would have to run both delegation mechanisms simultaneously and keep track of prefixes delegated by IA_PD and ND_PD -- making sure there's no overlap in delegated prefixes and such.

On the IV side -- if the IV expects to be able to provide connectivity to regular CE routers as well as LVs, then either all of the CE routers would have to support both requesting mechanisms, or the IV would have to support both delegating mechanisms (simultaneously, in case some attaching devices are LV and some are regular CE routers).

It would be interesting to see who ended up having to do both mechanisms: vehicles or everyone else. My preference would be that vehicles should be the ones to incur the additional complexity, since they're the ones who caused the additional complexity. Of course, we don't get to choose -- the marketplace chooses. Generally, the choice is made according to (1) who sees greater benefit in being able to connect to the other, and (2) who was there first and already has a significant embedded base. My tea leaf reading is that there's going to be a huge embedded base of IPv6-connected hotspots and CE routers with IA_PD long before these vehicles come to fruition. Home networks and hotspots are already successful without connecting to vehicles. For "connected vehicles" to be desirable in the eyes of consumers, I believe they will have to be able to connect to the consumers' home networks. So I think vehicles will have to be the ones to go the extra mile to connect to existing ecosystems.

My Conclusion: If vehicles are really only ever expected to talk to other vehicles via this particular link, the proposal could be considered in the vacuum of its stand-alone ecosystem. But if the possibility is likely that vehicles will want to interact with other ecosystems over that same link, then somebody has to suffer and support both ways of doing the same thing. The savings of a couple of short messages at attachment time is, IMO, not worth the additional complexity on either side. And the advantage to vehicles of being able to operate in both ecosystems is much greater than the advantage of saving a couple of messages at attachment time.
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2012 07:14:53 -0400

>> dynamic networks, if I understand it correctly, with RA used at the

    RD> My understanding is that RPL assumes a multi-link subnet, with a
    RD> single prefix used across the entire network and source routing or
    RD> host-specific routing. 

RPL doesn't care.  
It's all /128 routes to anything not on the local (physical) link. 
Whether it's source routes or hop-by-hop LPM depends upon whether the
mode of operation is storing or not.

They don't have to come from the same subnet.  The RPL Target Option,
contained in the DAO that travels up the tree, has a prefix and
length. In typical layer-3 subnet mesh networks, it contains /128
prefixes.  

Like others on this thread, I'd like to know how real this vehicle use
case is.  Is CAE really working on such a thing?

My opinion is that vendor of vehicles should obtain a Non-Connected
Network prefix from a suitable registry, or from
not-yet-agreed-to-be-useful ULA-Central, and have the the MR-IV
and MR-LV (permanently) number the LFNs.   

When two cars connect for some non-Internet access reason (including to
talk into the homenet), they should speak RPL to each other across the
E1 link(s).  The DAG would not be grounded.
Like all the other home LLNs, the gateway into the homenet would need to run
RPL on one side, and homenet-routing-protocol on the other side (zOSPF,
whatever).  It would announce the prefixes of the vehicle into the
homenet (another kind of "walled garden"!!), just like the lighting
system does.

If Internet connectivity is available/desired, then one of two things
occur (not both):
1) the Internet connected vehicle obtains topologically significant
   (PA) address via homenet-routing-protocol, and then forms a new
   (grounded) DODAG which can be shared with adjacent vehicles that
   want connectivity.  This solution is probably more secure and
   probably will work in many non-homenet environments, since
   homenet-routing-protocol isn't the only way to get prefixes, and
   even if you get only a single /64, RPL will let you "share" it.

2) the Internet connected vehicle becomes a homenet router, and
   speaks homenet-routing-protocol on E1 link and enough address space
   for all vehicles is obtained.

The PA addresses live only for the duration that the vehicle(s) are
connected.

Again, maybe I missed the bigger picture: who is building these IPv6 enabled
vehicles? (And where can I get one?)

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2012 09:52:22 -0400

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.

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.

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

-- 
Michael Richardson
-on the road-

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Oct 2012 16:18:59 +0200

Le 24/10/2012 19:04, STARK, BARBARA H a écrit :
> If an LV never ever wanted to get a PD from anything other than an
> IV, and an IV could only ever expect to delegate to a LV, then I see
> no problem.

I understand in that case there would be no problem use ND instead of
DHCP to realize PD.

> On the other hand, if these things do expect the same physical links
>  to be used to connect with other ecosystems (like home networks or
> hotspots) that will be well-established in the IPv6 world by the time
> these vehicles come along, then I think this proposal has some
> undesirable ramifications.
>
> Questions: Would an LV ever expect to use the same physical link to
> connect to a home network or hotspot, instead of an IV?

YEs, LV would use that egress interface to connect to a fixed hotspot
sometimes, instead of an IV.

> Would an IV ever expect to provide connectivity for devices that
> think they're inside a home network (e.g., maybe they're in a RV
> park, and the RV-owners networks are made up of traditional home
> networking components, so they can connect to non-cellular uplinks
> when such are available; maybe the IV is the truck pulling a
> trailer, and there's a regular home network set up in the trailer).

Well, the trailer is still mobile, a vehicle, I think.

But, even though IV would mostly be like a billboard advertisement
vehicle on a highway whose clients would be other vehicles most of the
time, there may also exist clients other than mobile vehicles.  I can't
see which right away, but why not.

> If the answer is no, then read no further. If the answer is yes,
> then I'd like to dive a little deeper into understanding the
> ramifications of what is proposed.
>
> Hotspots and CE (home network) routers will use IA_PD for prefix
> delegation.

Yes.  It would be the case for devices like LTE-WiFi boxes and for CE
customer equipment.

Remark though that for CE, the nature of the uplink - a cable - would
make it hard to see a vehicle on it: it only sees the operator's end.  I
doubt there would be a conflict there.

> Sub-delegating routers attaching to them will request prefixes by
> IA_PD.

Which would be these sub-delegating routers?  WiFi range extenders?
Others?  I am not aware of which direction these devices take - whether
or not they'd use DHCP to obtain prefixes, or open to something else.

This something else may be open, even to protocols which transform an
IPv4 address into some IPv6 prefix, or 6rd, or so.

> Which means either the LV would have to support both ND_PD and
> IA_PD, or the hotspot/CE router would have to do so. And whoever does
> both would have to know which to use in which case, and make sure
> they don't get things confused between the two. Somebody's
> complexity-of-code has just been doubled (or more) by the addition of
> a 2nd way to do the same thing. If it's the hotspot/CE router, then
> it would have to run both delegation mechanisms simultaneously and
> keep track of prefixes delegated by IA_PD and ND_PD -- making sure
> there's no overlap in delegated prefixes and such.

Well yes, code complexity.  I agree that if there existed two means to
delegate prefixes then complexity is added up.  In that sense, one may
consider that one out of the two ways to realize PD is maybe of lesser
importance than the other, with less ambition in deployment.  Just don't
break existing DHCP-PD deployments present only where this ND-PD is
tinkered with.

> On the IV side -- if the IV expects to be able to provide
> connectivity to regular CE routers as well as LVs, then either all
> of the CE routers would have to support both requesting mechanisms,
> or the IV would have to support both delegating mechanisms
> (simultaneously, in case some attaching devices are LV and some are
> regular CE routers).
>
> It would be interesting to see who ended up having to do both
> mechanisms: vehicles or everyone else. My preference would be that
> vehicles should be the ones to incur the additional complexity,
> since they're the ones who caused the additional complexity. Of
> course, we don't get to choose -- the marketplace chooses. Generally,
> the choice is made according to (1) who sees greater benefit in being
> able to connect to the other, and (2) who was there first and already
> has a significant embedded base. My tea leaf reading is that there's
> going to be a huge embedded base of IPv6-connected hotspots and CE
> routers with IA_PD long before these vehicles come to fruition. Home
> networks and hotspots are already successful without connecting to
> vehicles.

I wonder whether any device in home networks has this sub-delegating
capability, I guess not.

> For "connected vehicles" to be desirable in the eyes of consumers, I
> believe they will have to be able to connect to the consumers' home
> networks. So I think vehicles will have to be the ones to go the
> extra mile to connect to existing ecosystems.

In a sense I agree.  It seems vehicles are the newcomers when compared
to fixed networks.

However, to make the DHCP-PD work in a vehicle-to-vehicle manner one
would need to modify DHCP (at least make the relationship between Relay
and Server be dynamic).  I wonder whether any work was pursued that way.

> My Conclusion: If vehicles are really only ever expected to talk to
> other vehicles via this particular link, the proposal could be
> considered in the vacuum of its stand-alone ecosystem. But if the
> possibility is likely that vehicles will want to interact with other
> ecosystems over that same link, then somebody has to suffer and
> support both ways of doing the same thing. The savings of a couple
> of short messages at attachment time is, IMO, not worth the
> additional complexity on either side. And the advantage to vehicles
> of being able to operate in both ecosystems is much greater than the
> advantage of saving a couple of messages at attachment time. Barbara

I read and thank you for the message.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Oct 2012 16:55:33 +0200

Le 25/10/2012 13:14, Michael Richardson a écrit :
>>>> 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.
>>>
>>> Why wouldn't RPL be used for such networks? It has built-in PD
>>> for dynamic networks, if I understand it correctly, with RA used
>>>  at the subnet level.
>
> RD> single prefix used across the entire network and source routing
> or RD> host-specific routing.
>
> RPL doesn't care. It's all /128 routes to anything not on the local
> (physical) link.

That is with route exxchange, right?  Something like Router1 informs
Router2 about a prefix and a next-hop, and Router2 informs Router1 about
the other prefix and next-hop.

But with ND-PD and PD in general one contemplates the assignment of
prefix (maybe accompanied by modifying routing tables), instead of route
exchange.

> Whether it's source routes or hop-by-hop LPM depends upon whether
> the mode of operation is storing or not.

Ok, that is the way of forwarding application data packets.  But it's
not a way to attribute prefixes.

RPL does not seem to assign neither addresses nor prefixes, which is
good, if I am not mistaken.

> They don't have to come from the same subnet.  The RPL Target
> Option, contained in the DAO that travels up the tree, has a prefix
> and length. In typical layer-3 subnet mesh networks, it contains
> /128 prefixes.

Is that for communicating the prefix in the sense of 'route exchange' or
in the sense of 'prefix delegation'?

> Like others on this thread, I'd like to know how real this vehicle
> use case is.  Is CAE really working on such a thing?

CAE... Computer-Assisted Engineering?  I know not.

> Network prefix from a suitable registry,

In the vehicle industry there may exist such registry already which
distributes VINs (Vehicle Identifier Numbers).  But not IP addresses.

Is there another such vehicular specific registry?

> or from not-yet-agreed-to-be-useful ULA-Central, and have the the
> MR-IV and MR-LV (permanently) number the LFNs.

Or, have a method to convert from VIN to a ULA address or prefix.  Like
when converting MAC addresses to Interface Identifiers.

> When two cars connect for some non-Internet access reason (including
>  to talk into the homenet), they should speak RPL to each other
> across the E1 link(s).

Well, we can discuss this.  As much as RPL can be seen as a routing
protocol for many things, hence maybe useful for vehicles too, and for
homenets, it may also be seen as dedicated to Low-Power and Lossy
Networks, which LTE and intra-vehicular WiFi and CAN networks are less.

> The DAG would not be grounded. Like all the other home LLNs, the
> gateway into the homenet would need to run RPL on one side, and
> homenet-routing-protocol on the other side (zOSPF, whatever).  It
> would announce the prefixes of the vehicle into the homenet (another
> kind of "walled garden"!!), just like the lighting system does.

I read.

> If Internet connectivity is available/desired, then one of two
> things occur (not both): 1) the Internet connected vehicle obtains
> topologically significant (PA) address via homenet-routing-protocol,
>  and then forms a new (grounded) DODAG which can be shared with
> adjacent vehicles that want connectivity.  This solution is probably
>  more secure and probably will work in many non-homenet environments,
>  since homenet-routing-protocol isn't the only way to get prefixes,
> and even if you get only a single /64, RPL will let you "share" it.
>

I agree that IV should obtain topologically significant prefixes.
Supposedly giving some of them to others interested.

I doubt though RPL could do this?

> Again, maybe I missed the bigger picture: who is building these IPv6
>  enabled vehicles? (And where can I get one?)

It's hard to answer straight without doubt.  It's not my specialty, I am
coming more from networks research than from vehicle field.

But I couldn't imagine a connected vehicle manufacturer not considering
IPv6, especially when IPv4 space has run out and NAT would make
impossible the new applications querying data from vehicle, etc.

And I am listening too about this.

A vehicle which is IPv6 does not exist probably on the market, as we speak.

What one can buy right now is equipment that is dedicated to vehicles
and add it, (like in "tuning a vehicle").  This includes ruggedized
linux computers, dedicated linux boards, antennas.  For connection
inside, one widely used CAN access is OBD-II cheap.  In addition the
classic short-range WiFi/Bluetooth/ZigBee could be deployed
intra-vehicle, provided their chipsets can be powered on 12-24V or so.
For outside vehicle one may consider 3G, GPS, DVB, LTE cheap devices and
maybe cheap 802.11p although not as widely available.

Having all that one faces the problem of how to assign addresses and
establish routes.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Sat, 27 Oct 2012 11:30:43 +0200

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:
> 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.
> - is there any need for the LFNs on IVs and LVs to communicate with 
> each other? locally?
> Internet give out different IPv6 address or delegate different 
> prefixes as you move around?
>             prefix,