Subject: Centrally assigned "ULAs" for automotives and other environments

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 15:36:31 +0200

Hi,

it seems that there is currently not much interest in ULA-Cs (centrally
assigned ULAs). I came across several use cases, where manufacturers
(e.g, those of cars, airplanes, or smart metering environments)
would need internal/closed IPv6-based networks (maybe only for internal
control and management), that have no connection to the Internet.
For several reasons (esp. security) those networks
should operate isolated and independent from the Internet. In some cases
these products or installations may get merged, so prefix uniqueness
would be beneficial. Using locally assigned ULAs still bears the risk of
getting conflicts between manufacturers, esp. when considering the
number of manufacturers and products.

On the one hand it would be preferable for manufacturers to have an own
prefix for that purpose. Since every product with an on-board network
would need such a unique prefix, getting/requesting /48 ULAs per
product or installation doesn't seem to be appropriate.
On the other hand the currently defined ULA format is probably also not
very well-suited for that purpose, since it is intended to be used for
sites, but these products rarely require ~2^16 subnets, i.e., an 8 bit
subnet ID may be sufficient for most purposes. Thus, for this case the
currently defined ULA format is too restrictive requiring a 16-bit
subnet ID. Letting manufacturers ask for a large PI prefix from the
normal routing space does not make much sense either, since it is not
intended to be ever routed in the Internet.

Wouldn't it make more sense to define something similar to existing ULAs
along the lines of:
| 7 bits |  21 bits |      36 bits       |          64 bits           |
+--------+----------+--------------------+----------------------------+
| Prefix | OUID     | OLA Prefix         |        Interface ID        |
+--------+----------+--------------------+----------------------------+
Prefix: fixed, TBA, e.g., fa00::/7
OUID: Centrally assigned organizational unique ID
OLA Prefix: Organization locally assigned prefix, that consists
    of a Product specific prefix ID (PID) and an n-bit subnet ID, e.g.:

| 7 bits |  21 bits | 36-n bits | n bits |          64 bits           |
+--------+----------+-----------+--------+----------------------------+
| Prefix | OUID     | PID       |SubnetID|        Interface ID        |
+--------+----------+-----------+--------+----------------------------+
PID: Product specific prefix ID (should be unique across all products
     under the same OUID).

Usually n=8 or larger, depending on the number of manufactured products
(in this case 2^28=268,435,456) and their expected lifetimes. So the
idea is to centrally assign the OUIDs and let the organizations assign
the PID. If the OLA prefix space is too small for a manufacturer (some
sell currently more than 10^7 units per year), he may request another
OUID, just like it is done for company_ID/OUIs for IEEE-based
addresses. Different sizes for OUID and the OLA prefix may be discussed
(using 22 bits for OUID), but I just wanted to get input first whether
this would be useful at all or why it may be definitely a bad idea
(except that companies may misuse these addresses for other purposes).

Regards,
 Roland

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 27 Sep 2011 09:49:36 -0400

> number of manufacturers and products.

why can't these just use globally unique addresses?
are we certain they will never be connected to the Internet? (no
really, you are sure? really?)

-chris

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 15:51:02 +0200

> control and management), that have no connection to the Internet.

Why can't they request a prefix from their RIR?

RIRs are already "Central registries" in the broadest sense of the word.

[..]
> subnet ID may be sufficient for most purposes.
[..]
> Thus, for this case the
> subnet ID.

Then why not have the organisation needing and hardcoding those prefixes
calculate ULAs in /48s but splitting them up into subprefixes for
multiple products.

A better question maybe is if those components in such a prefix ever
have to talk outside of that closed network. If they don't, why bother
having a different unique prefix for every little private network?
Having to custom-provide different numbers on a large scale is likely
only an extra cost in software/ROM flashing.

(As the title notes 'automotive' I don't see them repurposing the same
hard/software and suddenly changing the whole mentality to start talking
against other networks; they might do that but only with the next
edition of the car.)

> Letting manufacturers ask for a large PI prefix from the

The RIR effectively only acts as a registration point thus guaranteeing
that address space allocated in their region, from them, is unique. They
do not and cannot guarantee anything regarding routing on the Internet.

Greets,
 Jeroen

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 16:19:17 +0200

Hi Christopher,

> why can't these just use globally unique addresses?

They can, but there are similar reasons for using ULAs:
- They are not intended to be routed in the Internet
- They use a well-known prefix to allow for easy filtering at site
  boundaries.

I'm not sure if the current policies allow to allocate
Global Unicast Addresses for these purposes. If it is a viable
solution, fine.

> really, you are sure? really?)

Not really in all cases, as learned from history.
So there may be cases where these networks get connected to the
Internet somehow, but usually only by using a security gateway/proxy,
because they should stay isolated, i.e., direct global access
to individual devices is usually not desired at all.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 16:46:30 +0200

Hi Jeroen,

> Why can't they request a prefix from their RIR?

This is an option, as it was when we deprecated site-local addresses,
but we have defined ULAs for several reasons that IMHO also apply
to the described use cases.

> RIRs are already "Central registries" in the broadest sense of the word.

I thought that these addresses are primarily intended to get routed in
the Internet. I'm not familiar with the RIR policies, so if it's
allowed: fine!

> calculate ULAs in /48s but splitting them up into subprefixes for

Would be an option, but collisions are still possible.

> having a different unique prefix for every little private network?

As I said, there may be cases when some of these networks get
coupled/merged somehow, still not requiring to get globally connected
though.

> do not and cannot guarantee anything regarding routing on the Internet.

Sure they can't, but I wasn't sure that they have some requirements
(policies) for requesting the address space.

Regards,
 Roland

---

From: "George, Wes" <[email-masked]>
Date: Tue, 27 Sep 2011 10:53:36 -0400

From: [email-masked] On Behalf Of Roland Bless

but there are similar reasons for using ULAs:
- They are not intended to be routed in the Internet
- They use a well-known prefix to allow for easy filtering at site
  boundaries.

WEG] from the below it sounds like the first item isn't always true. The second item is easily solved using proper address planning within the application and network design - eg allocate the block for this use out of a certain range of the RIR or LIR delegated space, and filter only that at the site boundary. I.e. if you know that the lower /56 of each block is by convention used for this purpose, you can filter accordingly much easier than if you have to filter randomly-chosen blocks. All it takes is a bit of prior planning when defining the addressing plan for the network.

WEG] A firewall/gateway can do this regardless of the address space that you are using. What you're proposing is a use case similar to the IPv4 model of using RFC1918 addresses + NAT/NAPT at the edge of the private network, and you will not find good support for extending that model to IPv6 because it breaks end to end connectivity and there are none of the address constraints that are present in IPv4 - everything that wants a globally unique address can get one. Even if there is a legitimate reason for not wanting that end to end connectivity in your case, if we make an IPv6 version of RFC1918+NAT available, there's nothing preventing it from being used by everyone that equates that implementation with "better security" today in IPv4, no matter how much we say "don't do that..." You can still use a single gateway to control how devices access the internet (and more importantly, how the internet accesses those devices) without pushing them into ULA space by filtering traffic as necessary at the ingress/egress point without using the addresses themselves as an obfuscation mechanism. That way you remove none of the flexibility if you end up needing connectivity later, but retain the desired security.

You also note uniqueness as desirable to manage potential mergers and conflicts between manufacturers on networks that were previously not connected. I think that the solution here is to ensure that the gear in question supports a relatively straightforward renumbering procedure - divorce the network's prefix from the device ID in such a way that the network prefix can be altered on one or both networks should they be merged. Even if the device has a partially hard-coded address, it should be capable of accepting a different prefix should the situation dictate it. The 6renum working group is currently working on exactly this problem (making renumbering easier in IPv6 enterprise deployments), and would love to have input from you on specific considerations within the industries that are represented in this thread. (disclaimer, I am one of the 6renum WG chairs).

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 27 Sep 2011 10:56:11 -0400

> WEG] from the below it sounds like the first item isn't always true. The second item is easily solved using proper address planning within the application and network design - eg allocate the block…

I get the feeling we're not seeing the whole of the picture... Perhaps
roland could expound some on what the usecases/purposes of these
address blocks is? (or the concept he's after at least, perhaps this
is a square-peg/round-hole problem)

-chris
(the rest of your message I wholly agree with wes... ftr)

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 27 Sep 2011 08:12:31 -0700

> really, you are sure? really?)

To this, I ask the question are you sure private gua will not get leaked
when the security policy is that they not be router on the inernet? Really
sure?

This is not my first rodeo, and I have had no luck keeping public ips from
leaking in ipv4... especially on large networks with new engineers coming on
the team every few weeks to few months.

I believe ula is a good part of layered security and there are statistical
mechanisms to ensure uniqueness.

The prevailing ipv6 religion says no ula ever, but its not entirely logical
or consistent with the reality of how folks run networks and make policy.

If the security policy changes in a BIG way, you have renumber or proxy from
ula to gua, but factor that into your planning for if ula is really the
right fit.

I use ula for anything that does not need to speak to the internet... and in
my network, that is a lot of stuff.

Cb

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 27 Sep 2011 18:06:32 +0200

Roland,

At the risk of stating the obvious, ULA does not provide any real-world security... They do not have the E-bit set ;-)

More seriously, ULA can be routed, so, if a ULA route leaks, then your ULA can be reached. Obviously, if your ULA gets a default route, then it can send packets to the Internet (information leak/covert channel).

The 'only' advantage of ULA vs. GUA is ease of filtering on a very short and well-known prefix.

-éric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Roland Bless
> Sent: mardi 27 septembre 2011 15:37
> To: 6man
> Subject: Centrally assigned "ULAs" for automotives and other environments
> 
> Hi,
>

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 18:08:28 +0200

Hi Wes,

On 27.09.2011 16:53, George, Wes wrote:

> WEG] A firewall/gateway can do this regardless of the address space
> that you are using. What you're proposing is a use case similar to the
> IPv4 model of using RFC1918 addresses + NAT/NAPT at the edge of the
> private network, and you will not find good support for extending that
> model to IPv6 because it breaks end to end connectivity and there are
> none of the address constraints that are present in IPv4 - everything
> that wants a globally unique address can get one. Even if there is a

Oh no, I definitely hate NATs and don't want them in IPv6. I also like
the end-to-end principle and e2e transparency, but security is
unluckily an important reason to introduce a security gateway here.
The difference to NATs is that they try to be transparent for the
ECUs, whereas the security gateway is an explicitly modeled control point.
You definitely don't want that all ECUs (electronic control units)
in your car are reachable from the Internet thereby permitting attackers
to compromise your car, e.g., firing up the airbag while driving etc.
The car onboard network should operate independently from any "outside
connectivity" and addresses, but some services will likely require
intermittent connectivity with the Internet, e.g., map updates for the
navigation system, web radio streaming etc. So total isolation is
probably not possible.

> legitimate reason for not wanting that end to end connectivity in your
> case, if we make an IPv6 version of RFC1918+NAT available, there's
> nothing preventing it from being used by everyone that equates that
> implementation with "better security" today in IPv4, no matter how
> much we say "don't do that..." You can still use a single gateway to

I'm well aware that NATs aren't a security solution and all that
I'm proposing is to use a stable internal addressing for the onboard
network (no matter how the car is currently connected to the Internet)
and to use a security gateway/proxy when communication to the Internet
is somehow required.

> control how devices access the internet (and more importantly, how
> the internet accesses those devices) without pushing them into ULA
> space by filtering traffic as necessary at the ingress/egress point

You will definitely need an address separation. Whether you use
internally globally unrouted and filtered addresses from the
global unicast space or ULAs probably doesn't matter so much.

> without using the addresses themselves as an obfuscation mechanism.
> That way you remove none of the flexibility if you end up needing
> connectivity later, but retain the desired security.

IMHO all fine for ordinary networks, but probably not the automotive case.

> You also note uniqueness as desirable to manage potential mergers
> and
> conflicts between manufacturers on networks that were previously not
> connected. I think that the solution here is to ensure that the gear in
> question supports a relatively straightforward renumbering procedure -
> divorce the network's prefix from the device ID in such a way that the
> network prefix can be altered on one or both networks should they be
> merged. Even if the device has a partially hard-coded address, it should
> be capable of accepting a different prefix should the situation dictate
> it. The 6renum working group is currently working on exactly this
> problem (making renumbering easier in IPv6 enterprise deployments), and
> would love to have input from you on specific considerations within the
> industries that are represented in this thread. (disclaimer, I am one of
> the 6renum WG chairs).

Ok, interesting. The automotive scenario isn't probably a good use case
here, but there may be other environments. Maybe I can come back with
some examples.

Thanks for your comments,
 Roland

---

From: "George, Wes" <[email-masked]>
Date: Tue, 27 Sep 2011 13:43:36 -0400

From: Roland Bless [mailto:[email-masked]]

all that I'm proposing is to use a stable internal addressing for the onboard
network (no matter how the car is currently connected to the Internet)
and to use a security gateway/proxy when communication to the Internet
is somehow required.

WEG] ok this is a good bit clearer, apologies for not picking up more specifics of the application the first time. However, I think that this basically ends up being two separate networks, independent of any address separation that may be implemented. If anything on the local network needs to talk to the outside world, even for peer to peer (vehicle to vehicle) interactions, it talks to the Bluetooth/cellular/wifi/RFC6214 compliant module, which has both internal and external interfaces. Rather than forward the traffic directly, it then proxies the request out to the outside world as necessary. Even if you use that module as a security device instead of a proxy, where the end nodes can communicate through it to get outside, you could use the fact that IPv6 supports multiple IP addresses per interface to (temporarily?) add an address for only those modules expected to talk to the outside world out of whatever external GUA prefix is delegated to the comms module, and the rest keep only the ULA to talk on the car network.

What's unclear to me is why the in-car networks can't use the exact same prefix for every single copy of the network, regardless of manufacturer, model, etc? If there's an external mediation device to handle occasional external network communication, and the rest of the network is expected to be closed (save maybe access from the Ethernet port that replaces the OBD-II port used by the technician to talk to the computer), why are we worried about conflicting addresses between manufacturers, etc? Are you also looking to derive some information about manufacturer, serial number, etc from the address and don't have enough bits to represent it uniquely? Couldn't that be solved independently of the address?

Alternatively, there is nothing stopping you from writing a BCP or informational draft that identifies a recommended ULA numbering hierarchy for $industry (like for example the auto industry) to use in numbering in-vehicle private networks such that the appropriate information is maintained and there is reasonable assurance of uniqueness by dint of mutual adherence to the standard - all of them start with FC00:: but what you do with the rest of that /7 is mainly up to the implementer, and only locally significant. Rather than a registry, simply define a way to determine reasonable uniqueness algorithmically so that newcomers can derive their address. You can even use parts of the address to identify major and minor categories, sensors, actuators, etc. Maybe it's something as simple as numerically representing the ascii value of the brand name. And this is likely a value that would never need to change for the life of the car, regardless of what happens to the entity that originally produced it.

Hope that my comments are helpful...

Wes George

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 22:48:05 +0200

Hi,

On 27.09.2011 18:06, Eric Vyncke (evyncke) wrote:
> At the risk of stating the obvious, ULA does not provide any
> real-world security... They do not have the E-bit set ;-)

Even with the :-), I neither understood nor described
ULAs as a security solution - they only simplify some
filtering rules.

> More seriously, ULA can be routed, so, if a ULA route leaks, then
> your ULA can be reached. Obviously, if your ULA gets a default route,
> then it can send packets to the Internet (information leak/covert
> channel).

That should be avoided/excluded by proper engineering and putting
appropriate filters at the right places. A car will likely get a lot
of different and changing external addresses for Internet connectivity,
e.g., via the built-in UMTS/LTE module, via a connected smartphone, or
even WLAN hotspots... the internal network should never be affected
adversely by external routes or addresses.

> short and well-known prefix.

True, but not the only one. ULAs have the advantage of being usable
even in an autonomous and spontaneous setting, i.e., they can be
generated on demand without any further interaction, which is a
nice feature for autonomous and isolated networks. But you don't
need that in some cases. Using a global unicast address will also
work for most scenarios if appropriate filters are in place. The
question was, whether a ULA-like approach is preferable.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Sep 2011 23:18:29 +0200

Hi Wes,

see inline.

On 27.09.2011 19:43, George, Wes wrote:
> all that I'm proposing is to use a stable internal addressing for the
> onboard network (no matter how the car is currently connected to the
> Internet) and to use a security gateway/proxy when communication to
> the Internet is somehow required.
> 
> WEG] ok this is a good bit clearer, apologies for not picking up more
> specifics of the application the first time. However, I think that
> this basically ends up being two separate networks, independent of
> any address separation that may be implemented. If anything on the
> local network needs to talk to the outside world, even for peer to
> peer (vehicle to vehicle) interactions, it talks to the
> Bluetooth/cellular/wifi/RFC6214 compliant module, which has both
> internal and external interfaces. Rather than forward the traffic
> directly, it then proxies the request out to the outside world as
> necessary. Even if you use that module as a security device instead

Yep, exactly.

> of a proxy, where the end nodes can communicate through it to get
> outside, you could use the fact that IPv6 supports multiple IP
> addresses per interface to (temporarily?) add an address for only
> those modules expected to talk to the outside world out of whatever
> external GUA prefix is delegated to the comms module, and the rest
> keep only the ULA to talk on the car network.

This is a potential model, but probably at a higher security risk.

> What's unclear to me is why the in-car networks can't use the exact
> same prefix for every single copy of the network, regardless of
> manufacturer, model, etc? If there's an external mediation device to

Sure, you can, but uniqueness makes things easier in some cases.
Maybe not in the car scenario so much, but in others.

> handle occasional external network communication, and the rest of the
> network is expected to be closed (save maybe access from the Ethernet
> port that replaces the OBD-II port used by the technician to talk to
> the computer), why are we worried about conflicting addresses between
> manufacturers, etc? Are you also looking to derive some information

That's correct. Usually, there is no need to ever connect the devices of
those two isolated car networks. Only if they access the same L2
medium without any further demultiplexing possibility there may be
conflicts. One potential scenario could be wireless access via a single
WLAN to several cars simultaneously in a garage for diagnostic purposes.
For wired scenarios you may use the VLAN or switch port for selecting
the right network etc.
But there may be other application scenarios (not cars)
where formerly independent networks may get used together after
some kind of merger. Maybe I can provide a more elaborated example
later.

> about manufacturer, serial number, etc from the address and don't
> have enough bits to represent it uniquely? Couldn't that be solved
> independently of the address?

Yep, could be.

> Alternatively, there is nothing stopping you from writing a BCP or
> informational draft that identifies a recommended ULA numbering
> hierarchy for $industry (like for example the auto industry) to use
> in numbering in-vehicle private networks such that the appropriate
> information is maintained and there is reasonable assurance of
> uniqueness by dint of mutual adherence to the standard - all of them
> start with FC00:: but what you do with the rest of that /7 is mainly
> up to the implementer, and only locally significant. Rather than a
> registry, simply define a way to determine reasonable uniqueness
> algorithmically so that newcomers can derive their address. You can

Yes, all fine we already came up with such a scheme. While
you can ensure a conflict free mapping within a single manufacturer,
you can't ensure it across manufacturers.
However, some manufacturers still feel uncomfortable with the risk
of getting conflicts (however, the implementation should deal with
that case...).

> even use parts of the address to identify major and minor categories,
> sensors, actuators, etc. Maybe it's something as simple as
> numerically representing the ascii value of the brand name. And this
> is likely a value that would never need to change for the life of the
> car, regardless of what happens to the entity that originally
> produced it.
> 

Yes. Thanks, they basically confirm our thoughts so far...
 Roland

---

From: David Farmer <[email-masked]>
Date: Tue, 27 Sep 2011 16:28:47 -0500

On 9/27/11 08:36 CDT, Roland Bless wrote:
> assigned ULAs).

That interest varies significantly I would suggest you are correct int 
he IETF and service provider worlds.  However, in the enterprise and 
manufacturing worlds I this there is more interest in the ULA model.

> I came across several use cases, where manufacturers

When saw this this morning my initially reaction was negative, however 
I'm warming to the idea.  However if we do something like this for the 
manufacturing world we better move forward normal ULA-C for the 
enterprise guys that want ULA otherwise you will quickly burn through 
your 21 - bit OUI. It won't just be manufactures that use this form of 
ULA (how about ULA-M, for ULA-Manufacturing) if it is created without a 
more standard ULA-C available for the enterprise guys.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: David Farmer <[email-masked]>
Date: Tue, 27 Sep 2011 17:06:13 -0500

On 9/27/11 08:49 CDT, Christopher Morrow wrote:
> On Tue, Sep 27, 2011 at 9:36 AM, Roland Bless<[email-masked]>  wrote:
>> Hi,
>>

I'm sympathetic to your questions here, but there are people that really 
want this kind of thing and know what they are doing.  Yes, there are a 
lot that don't, but that doesn't mean we should ignore the ones that do 
know what they are doing, just to protect the ones that don't from 
themselves.

Also, the RIR policies focus on Internet connected uses of addresses. 
Sometimes the policies outright prohibit non-connected use.  Or if they 
don't, there are written in ways that to the uninitiated think the 
policies prohibit such use.  ARIN-2010-8 (Rework of IPv6 assignment 
criteria) allows unconnected assignments now, but I'm not sure the other 
RIRs policies are as clear.

ARIN-2010-4 (Rework of IPv6 allocation criteria) modified by ARIN-2011-3 
(Better IPv6 Allocations for ISPs) doesn't dis-allow non-connected 
allocations, but it is really focused on ISPs connected to the Internet. 
2010-4 originally explicitly discussed non-connected network but that 
had to be removed to gain consensus.  So while it is not diss-allowed, 
it is not clear to the uninitiated in plain language that it is allowed. 
  RIR policy is driven by service providers and their view of the world. 
  So if you want to push people to GUA you need to ensure RIR policies 
enable that, in clear and understandable language, and they don't really 
do a good enough job of that currently.

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 12:08:35 +0200

Hi David,

> manufacturing world we better move forward normal ULA-C for the

The current ULA-C has the problem of allocating /48s. A manufacturer
would have to request many of them and the fixed 16-bit subnet ID
structure given in the spec isn't suitable for many of these applications.

> your 21 - bit OUI. It won't just be manufactures that use this form of

For OUI exhaustion I don't agree. The currently public OUI assigned
numbers of IEEE are around 16.000. Maybe this isn't directly comparable,
but provides at least a rough estimate.

> more standard ULA-C available for the enterprise guys.

Yep, regards
 Roland

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 12:20:57 +0200

Hi David,

> RIRs policies are as clear.

This is important information that I was looking for, thanks!

> allocations, but it is really focused on ISPs connected to the Internet.

That was my rough guess.

> do a good enough job of that currently.

I would also point out that manufacturers would - depending on their
number of installations or products - need rather large address blocks
(>/28), and not only /48s

Regards,
 Roland

---

From: "t.petch" <[email-masked]>
Date: Wed, 28 Sep 2011 14:44:07 +0200

----- Original Message ----- 
From: "Roland Bless" <[email-masked]>
To: "David Farmer" <[email-masked]>
Cc: "6man" <[email-masked]>
Sent: Wednesday, September 28, 2011 12:08 PM

> but provides at least a rough estimate.

FYI

There was a recent post on OPSAWG from the IEEE RAC about their need
to ensure that they do not run out of OUI; it was Cloud Computing that 
triggered their concern, but this might as well.

Tom Petch

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 16:10:22 +0200

Hi Tom,

> triggered their concern, but this might as well.

Thanks for the hint. I see the point. The problem is caused by the many
virtual entities that are used nowadays in these data center / cloud
computing scenarios. So effectively the number of devices per OUI runs
out quickly requiring to allocate another OUI, leading to the problem.
However, virtual entities would be covered in the IID part of the ULA,
and my intended use case for OUIs is different.

Regards,
 Roland

---

From: David Farmer <[email-masked]>
Date: Wed, 28 Sep 2011 13:24:30 -0500

> but provides at least a rough estimate.

Yes, OUI exhaustion isn't and shouldn't be a problem unless we make it one.

My point was if you implement your proposal without doing a more classic ULA-C also, you will create demand for OUIs from the enterprise world just so they can get registered ULAs.  There are not enough OUIs to satisfy that demand, and it would be a waste, too.

So if you do an ULA-M you need to also do ULA-C to prevent those that would be happy with ULA-C from consuming vast numbers of OUIs only for the purpose of obtaining ULA.

Networking&  Telecommunication Services

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 21:57:55 +0200

Hi David,

On 28.09.2011 20:24, David Farmer wrote:
> My point was if you implement your proposal without doing a more
> classic ULA-C also, you will create demand for OUIs from the
> enterprise world just so they can get registered ULAs.  There are not
> enough OUIs to satisfy that demand, and it would be a waste, too.
> 
> So if you do an ULA-M you need to also do ULA-C to prevent those that
> would be happy with ULA-C from consuming vast numbers of OUIs only
> for the purpose of obtaining ULA.

I see your point now and agree. My intent was not to replace ULA-Cs,
but to propose something that fits more the intended use cases.

Regards,
 Roland

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 28 Sep 2011 16:10:27 -0400

There seem to be a number of assumptions, some of which I suspect I am 
misunderstanding, in the case being described.

I tend to make two assumptions:
1) Even low end intra-automotive devices can cope with multiple addresses
2) Even low end automotive-internal devices will need to communicate 
externally.

 From what you have described, it seems that all such extenral 
communication (whether to another vehicle, to a trusted monitoring 
entity, or to the Internet, will have to go through what you describe as 
a "proxy" which will deal with changing the IPv6.
Put differently, the only application communication will be via an ALG.

Based on our experience, that seems to be a very bad design target.
And it seems unnecessary for the goal of having stable itnernal 
addresses for internal communication.

Yours,
Joel M. Halpern

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Sep 2011 15:25:21 -0500

I dunno about automotive, but I'm with Roland on the requirement to keep the internal controls strictly isolated from the Internet in other platforms. Yes, there is remote condition monitoring going on, but NEVER directly from the Internet to the internal devices, other than through proxies.

Perhaps the culture will change in time, or perhaps this culture will get even more strict in this regard. My sense is, the latter is a much more likely trend. I used to use public IP addresses religiously, for the internal hosts, but have stopped doing so recently. It seems that a number of people were relieved by this change. (Who knew?)

So from my perspective, easily recognizable "private" IP addresses are a really good feature.

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 28, 2011 4:10 PM
To: Roland Bless
Cc: 6man
Subject: Re: Centrally assigned "ULAs" for automotives and other environments

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 28 Sep 2011 16:39:10 -0400

Then use a good firewall to control what is and is not allowed to pass.
What I am objecting to is requiring an ALG, and using addressing to try 
to create security.

Yours,
Joel

---

From: David Farmer <[email-masked]>
Date: Wed, 28 Sep 2011 15:42:23 -0500

> Perhaps the culture will change in time, or perhaps this culture will get even more strict in this regard. My sense is, the latter is a much more likely trend. I used to use public IP addresses rel…

Personally, I wouldn't use a proxy.  I would use a VPN over the 
Internet, because it would maintain the end-to-end model.  But from a 
security point of view I believe a proxy and VPN would be more or less 
equilivant.

> So from my perspective, easily recognizable "private" IP addresses are a really good feature.

+1, ULA of several types serve a number of different purposes, and can 
be use without damaging the global publicly reachable Internet.

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 22:49:18 +0200

Hi Joel,

> misunderstanding, in the case being described.

Yes, I guess so.

> 2) Even low end automotive-internal devices will need to communicate

Yep, but 2) isn't true for all automotive devices. Only a part of them
needs communication to the public Internet.

> a "proxy" which will deal with changing the IPv6.

It's not about changing the IPv6 address (like a NAT) in the first
place, but about having a security gateway as a first line of defense
against attackers.

> Put differently, the only application communication will be via an ALG.

No, that's not totally correct.
Internal application communication doesn't have to go through an ALG,
only external communication.
Furthermore, devices in an untrusted, external zone may communicate
freely to the Internet, but not freely to the internal devices.

> Based on our experience, that seems to be a very bad design target.

I fully agree with this for ordinary networks and I'm well aware
of all the problems with NATs/ALGs and the like concerning e2e
transparency, complexity etc. The intended architecture is similar
to common firewall architectures with DMZs.

> addresses for internal communication.

Sure, with your assumption 1), devices may use several addresses
simultaneously which is a very common scenario with IPv6. If the
device, however, gets an external publicly reachable address, it
may be attacked directly. Security is the only reason for following such
a gateway architecture, which is similar to firewall
architectures that are widely in use. If you have something avoiding
this and providing the same level of security, I'm all ears. :-)

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Sep 2011 23:03:30 +0200

Hi Joel,

> What I am objecting to is requiring an ALG, and using addressing to try

Sure, ALGs are ugly, but usually you don't want
any kind of unwanted traffic on safety critical internal
devices (think of flooding, sending exploit packets etc.).
Furthermore, I'm very pessimistic about end-system security.
IMHO we will never see exploit-free implementations given the ever
growing complexity of our systems. Allowing a direct end-to-end
communication to internal devices IMHO increases attack possibilities.
An ALG has the advantage that you have more possibilities for policing
and that any not explicitly modeled communication cannot pass the ALG.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Sep 2011 10:07:31 +1300

On 2011-09-28 23:08, Roland Bless wrote:
...
> The current ULA-C...

What do you mean? There is no current definition of ULA-C.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Sep 2011 14:28:20 -0700

> Sent: Wednesday, September 28, 2011 2:04 PM
> To: Joel M. Halpern
> Cc: 6man

ALGs are harmful and the NAT industry has over a decade experience 
that shows ALGs are harmful.  ALGs have prevented proper operation
of SIP, FTP, and a variety of other protocols.  The more complex
a protocol, the more likely an ALG interferes with the complex
protocol -- rather than helping it.  This is because the ALG makes
naive assumptions of message flows and interfere with advanced
functions the protocol would like to do.

An ALG also requires unencrypted communications (so the application 
can be examined) and, if the application payload is supposed to be 
modified, also requires using no integrity checking.  That means 
the entire system has a greater attack surface just to allow the
ALG to examine and to modify the packets in transit.

An ALG also complicates upgrading protocols.  Protocol changes have
to be done so they remain compatible with the remote system (always
a requirement) as well as with the ALG (which is a requirement because
of the ALG).  This increases the complexity to the protocol, especially
as the ALGs, themselves, evolve and have their own bugs fixed, but
are not proper, signaled elements in the architecture.

-d

---

From: David Farmer <[email-masked]>
Date: Wed, 28 Sep 2011 16:29:33 -0500

> but to propose something that fits more the intended use cases.

I don't think you actually need to reinvent that wheel, 
draft-hain-ipv6-ulac-02 seems reasonable to me.   When we are inventing 
ULA-M, or what ever it it call, based on OUIs, we just need to realize 
that we need to push the other wheel out the door too.

Maybe we can start with new names;

ULA-S (Self-assigned) - Statistically unique prefix with local 
algorithmic assignment at no cost, you assign a prefix yourself.
ULA-R (Registered) - Unique Prefix registered to an Organizations 
through the RIRs, a prefix is assigned to you.
ULA-M (Manufactured) - Unique Prefix manufactured into a device, a 
prefix comes with your device.

ULA-S is the current RFC 4193, ULA-R could be based on 
draft-hain-ipv6-ulac-02, ULA-M is based on OUIs and OLAs as you describe.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Sep 2011 16:49:59 -0500

Dan Wing wrote:

> of SIP, FTP, and a variety of other protocols.

Harmful in your sense of the word is good, in some circles. Remember, we are only talking about ALGs to the outside Internet, not ALGs in paths internal to the controls network. (I guess I didn't make that clear when responding to Joel, but Roland did.) And too, other networks that are non-critical would not be limited this way.

In some circles, the fact that SIP, FTP, or what have you, are either hampered or rendered useless, from the Internet direct to an internal device, is deemed to be a feature. Nothing must be allowed to go direct.

I think there are very few arguments now, if any, that would change this culture. In fact, all the talk is about locking everything down more, not less. People get beat up for creating vulnerabilities, never for making outside access more difficult. And yet, IP is what everyone is specifying. Go figure.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Sep 2011 11:13:45 +1300

On 2011-09-29 10:28, Dan Wing wrote:
> that shows ALGs are harmful.  

+1. I think the problem here is trying to provide some kind of
transparency where it is in fact impossible and even
undesirable. I'm surprised that the target is either an ALG or a
simple proxy. I would think that you would actually want an
application server at the boundary, acting for example as a data
collector on the ULA side and as a data provider on the "uplink"
side. There might also need to be a firewall router at the
boundary for regular Internet access from users inside the
vehicle, but that would be a standard CPE in most respects and
would not be handling vehicle data.

(Much the same applies to building automation, except that that
doesn't require mobility support.)

    Brian

ALGs have prevented proper operation

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Sep 2011 17:51:13 -0700

> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Wednesday, September 28, 2011 2:50 PM
> To: Dan Wing; 'Roland Bless'; 'Joel M. Halpern'
> Cc: '6man'
> Subject: RE: Centrally assigned "ULAs" for automotives and other
> environments
> 
> Dan Wing wrote:
> 
> Harmful in your sense of the word is good, in some circles. Remember,
> we are only talking about ALGs to the outside Internet, not ALGs in
> paths internal to the controls network. (I guess I didn't make that
> clear when responding to Joel, but Roland did.) And too, other networks
> that are non-critical would not be limited this way.
> 
> In some circles, the fact that SIP, FTP, or what have you, are either
> hampered or rendered useless, from the Internet direct to an internal
> device, is deemed to be a feature. Nothing must be allowed to go
> direct.

You're not getting my point.

It doesn't matter which protocol has an ALG.  Pick some fancy
car-only protocol that hasn't yet been invented.  Its future
development will be *hampered* by the existence and reliance
on an ALG.

And as we have all experienced, today's "only goes to the 
Internet" protocols are tomorrows "used within my network" protocols
(e.g., HTTP used within a home for video streaming) and visa versa 
(e.g., NFS used across the Internet).

> I think there are very few arguments now, if any, that would change
> this culture. In fact, all the talk is about locking everything down
> more, not less.  People get beat up for creating vulnerabilities, never
> for making outside access more difficult. And yet, IP is what everyone
> is specifying. Go figure.

It's too bad computer science is not a science, or we would actually
look at the past, and this mistakes that were made, to build tomorrow's
systems.  ALGs were a mistake.

-d

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 28 Sep 2011 22:09:30 -0400

> systems.  ALGs were a mistake.

I like algs for some things but agree with dan here... and the larger
point is really: "Plan for your thingy to live on the open internetz,
else you will fail/pay later."

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 28 Sep 2011 23:26:27 -0700

> else you will fail/pay later."

the traditional assumption that one can build scada systems with soft
gooey centers and everything would be a-ok due to algs proxies and
airwalls was always a bit shaky, it's only mater of time before that
bites us in a visceral fashion.

this little gem has been making the rounds, and while I find it a bit
silly it's worth a second glance.

https://www.infosecisland.com/blogview/16696-FACT-CHECK-SCADA-Systems-Are-Online-Now.html

---

From: Roland Bless <[email-masked]>
Date: Thu, 29 Sep 2011 09:20:29 +0200

Hi Brian,

> What do you mean? There is no current definition of ULA-C.

That's right :-)
I was referring to the definition in RFC 4193 with L=0, i.e.,
centrally assigned ULAs. I know that the registry and assignment
procedure for ULA-C are not defined yet, but the basic format will be
the same as in RFC 4193. The few I-D proposals for ULA-Cs seemed
to suggest allocating /48s and not larger address blocks and I could
very well imagine, that this will be the case if we ever define ULA-Cs.
That was what I meant.

Regards,
 Roland

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 29 Sep 2011 09:30:28 +0200

> very well imagine, that this will be the case if we ever define ULA-Cs.

You do realize that the RIRs are providing exactly what you describe? :)

 - globally guaranteed unique (due to registry) large address prefixes

Which is why from my information ULA-C has also been abandoned, as it
already is something that has already been resolved.

What makes me wonder though, is why you would want to have different
prefixes in different locations that never ever ever will talk to each
other directly using those prefixes.

At least I hope to never have a car that gets chatted up by the car next
to it to suddenly pull on the handbreak.

Any car-2-car communication IMHO would happen with a different global
prefix, likely dynamically assigned to a 'gateway' function that has
proper security properties (call it a 'car rest interface or so). That
security gateway will then relay commands to it's internal network.
That internal network can thus have the same prefix as the other car.
This thus allows one to simply take a random /48 (likely ULA) and
pre-program them in all the systems.

Though it would be a cool idea, dynamically assigning addresses to
random components in a car where one actually needs to also then
maintain a registry of which components are where, will effectively mean
that there will be a DNS server too of sorts to map 'engine' to
2001:db8:.....x and the left-mirror to 2001:db8:... Will be a lot of fun
to build I guess, but debugging that will be horrible and overly
complex. Then again, some times that is the fun in things right ;)

Greets,
 Jeroen

---

From: Roland Bless <[email-masked]>
Date: Thu, 29 Sep 2011 10:15:24 +0200

Hi Dan,

> functions the protocol would like to do.

I know that very well, because I've attended your excellent tutorial
at some IETF meeting in the past. :-)

> are not proper, signaled elements in the architecture.

Agreed, but I think that the case of NAT-ALGs is a little bit different
as they try to be transparent to the end-hosts. We think more of a
security gateway/proxy architecture, where the existence of the proxy
is explicitly modeled, e.g., use an HTTP proxy for web access.
Sure, not all protocols allow the use of proxies.
Please note, that a car's onboard network is a very different
use case than hosts operating in the open public Internet.
We need a very secure solution in order to guarantee the safety
of the car and the passengers. Which internal devices communicate
externally is usually well-known in advance.
Though a good point is that the protocols on the remote side may
change and that you have to adapt to the changes.
In some cases when using the proxy architecture, maybe only the proxy
has to be upgraded,  not the internal devices, in other cases maybe
the proxy in addition to the internal devices, which increases the
complexity.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Thu, 29 Sep 2011 10:59:35 +0200

Hi Jeroen,

> already is something that has already been resolved.

Ok, fine. We could use that _if_ the RIR policies allow unconnected use,
but David Farmer pointed out that some policies may forbid that. I just
figured out that RIPE's "IPv6 Address Allocation and Assignment Policy"
says in 2.6:
"To 'assign' means to delegate address space to an ISP or End User for
specific use within the Internet infrastructure they operate."
I'm not sure that one could denote the internal on-board network
of a car as Internet infrastructure operated by ...?!
Manufacturers also do not meet the LIR definition in 2.4, which
is a precondition to get an initial allocation though (cf. 5.1.1 a)).
Furthermore, where would a German manufacturer allocate the prefixes
for its cars that are exported to Asia (at RIPE or APNIC)?
So if we talk about ULA-Cs for traditional fixed networks you're right,
but my use case was different.

> other directly using those prefixes.

As already said, maybe not in the car scenario but in others.
However, history told us that address uniqueness is preferable in most
cases.

> to it to suddenly pull on the handbreak.

Right, that's why we care about security in such an architecture.

> proper security properties (call it a 'car rest interface or so). That

Yep, correct.

> pre-program them in all the systems.

Sure, you could do that.

> complex. Then again, some times that is the fun in things right ;)

The car on-board network requires usually real-time control guarantees,
so having too much dynamics and several indirections/mappings is
probably not so suitable.

Regards,
 Roland

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Sep 2011 09:44:23 -0400

> of a car as Internet infrastructure operated by ...?!

it runs the 'internet protocol' right?

in all seriousness, why would/should we (rir/internet community) care
if you use the resource on a link between you and your mom or between
you and comcast/telia/etc? my stance is that we ought not care, we
should assign the resources to folks who can put them to use. we may
have to help in the educational process a bit, but hiding behind
'private addressing' and 'we never want to ... oops, we connected to
the internet!' just isn't working today.

> However, history told us that address uniqueness is preferable in most

addresses from the RIR == unique. There is no registry for ULA-C...

> probably not so suitable.

just don't pull the "Connexion by Boeing" model of every vehicle is
numbered in the exact same way :) from the exact same netblock... (see
preso from ietf plenary ~8yrs ago? or maybe 6 in Minneapolis?)

-chris

---

From: Roland Bless <[email-masked]>
Date: Thu, 29 Sep 2011 16:09:52 +0200

Hi,

> the internet!' just isn't working today.

As a general statement fine, but in our use case you
a) need stable addresses which can be used independently
   of any other existing connectivity (whether ULAs
   or global PI addresses doesn't matter so much)
b) explicitly consider cases where you get connected
   to the Internet (w/o putting safety at risk)

Regards,
 Roland

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 29 Sep 2011 07:32:00 -0700

> bites us in a visceral fashion.

100% agree. I don't think that is fundamentally inconsistent with using
'private' address space to easily identify internal-only hosts or
interfaces.

One place I find ULA especially useful is my pref64 in the nat64 / dns64
deployment.  I only want internal host with my ula reachability to have this
gateway feature.  Yes, other measure are in place, but this is one that is
easy on the eyes for both network and host troubleshooting, small in the
config, and likely cosistent with my peers filtering rules.

Cb

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Sep 2011 10:53:59 -0400

>   or global PI addresses doesn't matter so much)

Sure,  a structure to build that upon 'reboot' seems like a simple
task to accomplish... lots of things do this already, it's not new or
scary, it does take some planning and thought early in the process
though.

>   to the Internet (w/o putting safety at risk)

right, each part (addressable item in the total system) needs to
understand it's place in the security world, protect itself and it's
neighbors. It's fine to have (and probably a great thing) some
security measures at the 'borders' (gateways between "internal" and
"external") but those can not be the sole guardians. Quality code,
quality security architecture, quality interfaces between components
(hardware and software) are all key to making the vehicular
environment safe.

my larger point wasn't really about your case though...

-chris

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Sep 2011 08:21:06 -0700

> Sent: Thursday, September 29, 2011 1:15 AM
> To: Dan Wing
> Cc: 'Joel M. Halpern'; '6man'

Did I come across as disliking ALGs a bit?  ;-)

> as they try to be transparent to the end-hosts.

Yes, that's the definition of an ALG.

There are ALGs for firewalls, as well.  The first ALG written, to my 
knowledge, was for a firewall (not a NAT) and was for "active mode" 
FTP.  Active mode FTP is where the server makes a TCP connection back
to the client.  If the client is behind a firewall (e.g., corporate
firewall), FTP broke.  Adding an ALG to the firewall, so it sniffed
FTP signaling and created a mapping in the firewall, allowed active
mode FTP to work.

> We think more of a

But that's a proxy.  A proxy is not an ALG.

-d

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 29 Sep 2011 08:34:38 -0700

> the internet!' just isn't working today.

Ask Bechtel where the addresses space used for aiports bridges and
tunnels comes from and how they assign address space to structures with
a design life measured in decades.

prefix assignment to customers even for disconted networks is a really
convenient way to insure non-overlap far into the future.

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Sep 2011 01:30:35 +0900

> draft-hain-ipv6-ulac-02, ULA-M is based on OUIs and OLAs as you describe.

maybe you can start with ULA-NO, and use global addresses.  i am told
that, in ipv6, there are enough of them.

our experience with rfc 1918 has clearly shown that it is not a good
idea to try to use special addressing to create special routing.

we have been around the whack-a-mole of ULA too many times.  don't we
have real work to do?

randy