Subject: Re: [ipwave] Route Information Options in IPv6 Neighbor Discovery

From: [email-masked]
Date: Thu, 3 Jan 2019 08:44:13 -0800

Fred,

Happy New Year!

> I take it you approve, then.

Close enough. As you know, there are better ways if we could make some architectural changes for mobility for IPv6, but without those, the best that we can hope to do is to contain the routing ‘noise’ to an overlay, as you’ve done.  I think that there’s a scalability issue that you’ll need to address that’s going to be pretty critical. The same approach for wheeled vehicles would seem to be intractable, if only because it’s orders of magnitude larger. 

> Thank you also for giving us BGP; I don’t
> think most people realize how versatile a service it really is, and our
> draft is just one example.

It has been my honor to serve…

Tony

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 Jan 2019 15:19:42 +0000

Hi Tony,

Think of it as scalable de-aggregation. I have shown that a single lightweight
virtual machine can handle 1M BGP routes without any problem. I have not
tried with more routes, but I suspect the number could be pushed even
higher. But, if you want more routes (say by multiple orders of magnitude)
simply add more routers.

The document talks about scaling up to 1B routes, but the architecture
should be capable of even more given that everything can be deployed
on lightweight virtual machines. So, I do think the architecture is capable
of supporting massive numbers of wheeled vehicles, with mobility
services also employed.

Thanks - Fred

From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 03, 2019 8:44 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [ipwave] Route Information Options in IPv6 Neighbor Discovery

Fred,

Happy New Year!

Tony

---

From: [email-masked]
Date: Fri, 4 Jan 2019 08:36:33 -0800

Hi Fred,

Well, there are currently around 300M vehicles in the US and 1B already in the world.

In production, the Internet is just around 700K routes today. So that would be a three order of magnitude increase.

History suggests that some other mechanism will be necessary to grow that far.

Adding more routers doesn’t do it at all.  The entry point to the network needs to contain everything, so it needs to
carry the full 1B routes, not only in FIB and RIB, but in BGP.  And it needs to converge in sub-glacial time.

Or, vehicles can change addresses….

Tony

> On Jan 4, 2019, at 7:19 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Tony,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 4 Jan 2019 17:48:22 +0100

Le 04/01/2019 à 17:36, [email-masked] a écrit :
> In production, the Internet is just around 700K routes today.

YEs, it is in the Routing Table Report, and it's IPv4.  It grows 
continuously since year 2000, at an approximate rate of 50k per year. 
This growth is without mobility events, just Internet static growth.

> So that 
> would be a three order of magnitude increase.
> 
> Adding more routers doesn’t do it at all.  The entry point to the 
> network needs to contain everything, so it needs to

Propagation and convergence latency involved in route injection depends 
not only on the number of injections (number of vehicles and their 
supposed handover events) but also on (1) the way the nodes of the fixed 
network are connected and (2) the way the default routes are used.

A fewer number of routers in the fixed network, hyperconnected, and a 
wise use of default routes, both closely following the physical 
deployment of roads, and maximum allowed radio power levels, can lead to 
fewer routing messages exchanged (keep propagation local), and thus 
sub-glacial time.

I am not saying one should do it (route injection), but it is good to 
know it is possible and under what conditions.

> Or, vehicles can change addresses….

YEs, but should they change their addresses _and_ use tunneling _and_ 
maintain ongoing sessions.  Or can it be decoupled (de-tripled?).

Alex

> 
> Tony
> 
> 
>> On Jan 4, 2019, at 7:19 AM, Templin (US), Fred L 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Tony,
>> *From:*Tony Li [mailto:[email-masked]]*On Behalf 
>> [email-masked] <mailto:[email-masked]>
>> *Sent:*Thursday, January 03, 2019 8:44 AM
>> *To:*Templin (US), Fred L <[email-masked]>
>> *Cc:*Alexandre Petrescu <[email-masked]>; [email-masked]
>> *Subject:*Re: [ipwave] Route Information Options in IPv6 Neighbor 
>> Discovery
>> Fred,
>> Happy New Year!
>>
>>
>> Close enough. As you know, there are better ways if we could make some 
>> architectural changes for mobility for IPv6, but without those, the 
>> best that we can hope to do is to contain the routing ‘noise’ to an 
>> overlay, as you’ve done.  I think that there’s a scalability issue 
>> that you’ll need to address that’s going to be pretty critical. The 
>> same approach for wheeled vehicles would seem to be intractable, if 
>> only because it’s orders of magnitude larger.
>>
>>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 Jan 2019 17:50:40 +0000

HI Tony,

>> Adding more routers doesn’t do it at all.

Actually, it does. See Section 3.3 of ‘draft-templin-intarea-6706bis’.

>> The entry point to the network needs to contain everything,

The idea is to have multiple entry points into the network. For example, if the
service prefix for the global ITS service is 2001:db8::/32, a first set of c-ASBRs
could service the segment 2001:db8::/40, a second set of could service the
segment 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40,
etc. That way, each c-ASBR set only needs to see 1M routes.

>> so it needs to carry the full 1B routes, not only in FIB and RIB, but
>> in BGP.

No; each set of c-ASBRs only needs to manage O(1M) routes. So, we scale
by having many sets of c-ASBRs; each with their own sets of 1M routes.

>> And it needs to converge in sub-glacial time.

Right; that is exactly why “micro-mobility” events like a mobile node
changing from a first network access point to a second network access
point need to be kept out of the BGP routing system. The BGP routing
system only tracks “macro-mobility” events, like moving from the USA
to Europe.

It scales precisely because of the fact that we have many routers that
each are only asked to carry up to 1M routes that rarely change – we
would never ask a single router to carry 1B routes that are changing
dynamically.

Thanks - Fred

Sent: Friday, January 04, 2019 8:37 AM

Hi Fred,

Tony

On Jan 4, 2019, at 7:19 AM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tony,

Thanks - Fred

From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, January 03, 2019 8:44 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] Route Information Options in IPv6 Neighbor Discovery

Fred,

Happy New Year!

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 7 Jan 2019 12:40:25 +0100

Le 23/12/2018 à 21:02, [email-masked] a écrit :
> 
>>
>> I have a doubt why they are called 'delegated' prefixes, because the 
>> prefixes we put in RIOs are not delegated: they are hardcoded in cars. 
>> (they dont pre-arrive by DHCPv6PD).
> 
> 
> It will be interesting to see how this works with the Internet routing 
> and addressing architecture. Is this documented somewhere?

At this time, in trial, the cars are supposed to learn each others' 
prefixes.  We dont inject that into Internet.  I look for a cellular 
operator ready to accept such 'injections'.  On OCB I consider the RSUs 
that we control may accept injections.

As for the documented question: at this time we have not yet documented 
it.  We could document it for June 2019, in a private deliverable.  We 
dont know yet how and what to document.

I do have some pencil-and-paper explanation on power point about what is 
a mobiliy event (in terms of routing) and what is a route update 
('injection').  (attached).

But I learned recently there is an RFC 6227 titled "Design Goals for 
Scalable Internet Routing".  This RFC does have text about mobility.  In 
that text there is something about requiring injecting some routes by 
the mobiles, as an alternative.  I is an encouraging direction.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Jan 2019 17:45:31 +0000

Hi Alex,

> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Monday, January 07, 2019 3:40 AM
> To: [email-masked]
> Cc: [email-masked]
> prefixes.

That is good, but without some trust basis how can cars trust each
others' prefix assertions? I think what you are saying will be OK for
trials, but there will eventually need to be a trusted online service
that all cars trust so they can be convinced to trust each other.  

> We dont inject that into Internet.  I look for a cellular

The problem with asking a cellular operator to accept the injections is
that not all cars will subscribe to the same cellular operator. The cellular
service provider is simply one data link service among possibly many
that the car might have - for example, the car might also have a
satellite service. So, there needs to be some overlay service provider
network that rides over top of the available data links. The overlay
would be controlled by some transportation authority like the US
department of transportation. The roadside units would also be
under their control.

> dont know yet how and what to document.

Please have a look at our drafts - they came from the aviation community
but are also applicable to automotive.

> ('injection').  (attached).

Looks like a reasonable concise sketch. Not sure about the Mobile IP
conclusion, though; AERO is also a candidate.

> the mobiles, as an alternative.  I is an encouraging direction.

Yes, this came from the IRTF Routing Research Group, which is also
where AERO came from.

Thanks - Fred

---

From: [email-masked]
Date: Mon, 7 Jan 2019 10:32:09 -0800

> that all cars trust so they can be convinced to trust each other.  

One might suggest that RPKI might be useful, once again.  

> department of transportation. The roadside units would also be

That seems like an extreme solution, given that just about anyone could trivially set up an RSU. How do you mandate that type of hierarchical control?  How would you enforce it?

It seems to me that the basic use of DHCP with prefix delegation is far more likely to yield scalable results.  This has the huge advantage of having the addressing meet the topology.  One then applies the previous work on ad hoc or standard routing protocols (e.g,, AODV, OSPF, IS-IS) and you’re in pretty good shape.

> but are also applicable to automotive.

There are some OCB use cases that I think bear further thought in this context.  While aircraft-to-aircraft is probably a minor use case, in the OCB world, it would seem like it would be very common.  How does that work in the AERO context? 

In OCB, there may be no working uplinks, only peer-to-peer links.  No RSU’s in reach, only other vehicles? How would AERO support this?

> Yes, this came from the IRTF Routing Research Group, which is also

You’ll also note that the RRG’s proposed solution for this has not yet been picked up by the IETF or industry.  Nor has any other clear solution come to light.

Tony

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Jan 2019 20:04:21 +0000

Hi Tony,

> Sent: Monday, January 07, 2019 10:32 AM

Yes, there certainly needs to be security key management, key revocation
lists, trust anchors, etc. 

> That seems like an extreme solution, given that just about anyone could trivially set up an RSU. How do you mandate that type of
> hierarchical control?  How would you enforce it?

It might not be right to equate the ITS RSU construct to the AERO Server
construct, so I'll let Alex answer this. But, with AERO, the Server is the same
as any VPN server. So, to secure the network it is necessary to secure the
Servers. This would need to be done by the same administrative entity
that secures the overlay.

> It seems to me that the basic use of DHCP with prefix delegation is far more likely to yield scalable results.  This has the huge
> advantage of having the addressing meet the topology.  One then applies the previous work on ad hoc or standard routing protocols
> (e.g,, AODV, OSPF, IS-IS) and you’re in pretty good shape.

We are indeed using DHCPv6 PD with great results.

> There are some OCB use cases that I think bear further thought in this context.  While aircraft-to-aircraft is probably a minor use case,
> in the OCB world, it would seem like it would be very common.  How does that work in the AERO context?
> 

I have an answer for this, but I would like to hold off for now and hopefully post
something later this week. But, the architecture I have in mind fully supports and
encourages  OCB operations.

> You’ll also note that the RRG’s proposed solution for this has not yet been picked up by the IETF or industry.  Nor has any other clear

There are multiple solution alternatives proposed in the IETF right now, and
I don't see any of them moving forward over the others as of yet. But, BGP
with scalable de-aggregation seems like a fit for ITS and other use cases.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 8 Jan 2019 16:26:51 +0100

Le 07/01/2019 à 18:45, Templin (US), Fred L a écrit :
[...]
> others' prefix assertions?

We are in an urgent need to secure these prefix assertions.  Until then 
the prefixes and other sensitive data travel in clear, potentially in 
public areas, at 5.9GHz.

It must be something easy to do for beginner programmer.  As simple as 
all the other non secure things are.

Since this is urgent, we explore several directions.

SeND (Secure Neighbor Discovery) does have some advantages but it seems 
no implementaiton is simple and straightforwad.

VPN implementations between cars is straightforward, yet OpenVPN has 
some complains about proprietary secrecy; 'algo' from MIT, 'simplevpn' 
and SoftEther are other candidates.

> I think what you are saying will be OK for

YEs I agree, the need can be there, but it is so much difficult to satisfy.

In France the situation is relatively fuzzy about this.  There are some 
directions of building such trust, but they are mainly just statements. 
There is very little actual help.

There is this company 'idnomic' that many French people refer to, but I 
cant seem to get something quickly out of their website.  It's far from 
being as easy and trustful as, say, VeriSign.

There is ETSI certificates too, but not sure who is the CA for that.

This situation is far from being as easy as the deployed PKI with CAs in 
widely deployed web browsers.

One is basically left to one self: generate certificates oneself.

Maybe 'Let's Encrypt' for cars - another direction.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 8 Jan 2019 16:15:59 +0000

Hi Alex,

I like the idea of using SEND, but the issue is how to ensure that CGAs are
unique. DAD would only confirm uniqueness among a mobile node's current
set of neighbors, but that set could be changing dynamically over time.

The solution we chose for AERO was to forget about DAD for CGAs and
instead include a link-local address based on the node's mobile network
prefix (MNP) in a form that is known as the AERO address. So, for example,
if the MNP is 2001:db8:1:2::/64 then the AERO address is fe80::2001:db8:1:2.

The CGA and AERO address then work together to provide the link-local
identity for the mobile node, and SEND functions normally even if there
may be a CGA collision on the link. This is discussed in more detail in
Section 7 of 'draft-templin-intarea-6706bis'.

Let me know what you think,

Fred

> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2019 7:27 AM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]
> Cc: [email-masked]