Home / Blogs

IP Addresses in Cars, Car Manufacturers as Internet Registries? - Another Need for IPv6 Now!

I recently came across an interesting piece about the use of IP addresses in the Tesla model S. The part that caught my attention and led to this post is that the car uses the private IPv4 address subnet to address different nodes e.g. the centre console is and the dashboard/navigation screen is

Put your geek hat on for a moment as you ponder that! – anything in the car that you want to be able to communicate with individually can now have its own IP address. Here are some scenarios that are not too far-fetched.

  • In-car wireless LANs to which devices can connect. Think of having an iPad or Galaxy Note III in the car, on the network making available its library of music, videos or books available to other devices in the car, or even the cards entertainment system. Apart from limiting the transmit power of the wireless radio for the LAN so as not to cause interference with nearby cars, all technologies required to achieve this already exist and are mature.
  • Don’t stop at an IP address for the front console, the seat-back entertainment system are also good targets for their own IP addresses (that’s one way they’ll interact with the mobile device you connect for example).
  • In the spirit of containing failure domains, there should be one IP subnet for different sub systems of the car—entertainment, system monitoring, sensors and climate control etc. (You really don’t want packets from say the proximity sensors contending with packets of the videos or audios being streamed from the media server in the hood to mobile devices in the car or seat-back screens.)

An interesting question for the industry is whether this address space be private or public? If it remains private as is apparently currently the case, it will mean that every Tesla dashboard has the exact same IP address (I don’t know the internals of how Tesla architect this but I suspect that if they do run remote diagnostics on the car like they do, they are probably using a different private subnet for each car) . Public address space will mean that every dashboard in every car that is IP-enabled will have its own unique way of globally addressing. The globally unique public options is both exciting and terrifying. Exciting because the increase in the number of addressable devices in the global network (and thus the value of that network) will increase. Terrifying because that global addressability could be abused with consequences ranging from privacy violations (will an employee of the car company be able to access the feeds from the in-car video camera?), through potential for remote car-jacking to pervasive surveillance. Don’t forget that the same capability that will let the car manufacturer run diagnostics and fix your car remotely or get it to report its location when stolen is the same one that big brothers every where love.

Of course the public addressing option is only feasible in an IPv6 world. I also think it is a perfect opportunity, IP on such a scale in cars is pretty greenfield and users don’t yet have too many expectations, so starting with IPv6 will be perfect ... as it will define THE IP-in-cars experience and set the baseline. Ultimately though, I expect to see private addressing maintained some components (those that will only ever need to communicate with other subsystem in the car) and public addressing for other components.

Going for a moment with the premises that each car needs to have some publicly addressable space, the interesting question comes up—how will each car get this globally unique address space? Here are the possibilities for this addressing:

  1. The car manufacturer (Tesla, Toyota, Honda, BMW etc) becomes an Local Internet Registry (LIR). That is it will get blocks of address space from the RIRs which it will then assign bits of that space to each car it makes and sells. This raises an interesting side-question. As the cars will be sold globally, which RIR would the car company get address space from? The simplest answer is they’ll get it from the RIR that serves the region where they currently have their manufacturing operations. If this is the case, I foresee problems ensuring that this space is globally routable as cars are sold in different countries. I don’t think this is an effective option.
  2. The car manufacturer assigns private IPv6 ULAs to systems it needs to remotely access and then installs an in-car router which could get a public IPv6 prefix via 3G or 4G from the local ISP, and then provisions various /64s for different subsystems. In this scenario, the car manufacturer doesn’t become an LIR but can still uniquely address (via ULA) all cars it makes with very low probability of address space collision. Hey maybe they could even get IANA to reserve a block of IPv6 space for this purpose.

So how much address space should one car get? The answer, whatever it is , is most certainly not a /64. Because some some systems will need to have auto-provisioning (SLAAC or DHCPv6 .... the article indicates the dashboard runs off of Ubuntu), each car needs to have at least one /64 available. And just like the small home user, I see at least a /60 per car (yes I love my nibble boundaries).

Statistics from the International Organisation of Motor Vehicle Manufacturers of annual car production numbers from 1999 till date indicate that on average, the world produces about 48 million cars annually (This doesn’t include heavy trucks and light 2 wheeled vehicles). So if we plan to have a /60 for each of those cars, then that’s one /34 for all cars in the world. Which is quite small if you consider that RIRs give at least a /32 to an LIR.

And as the IP network of the car of the future becomes more complex, we might need to deploy more of the same IP technologies we plan to deploy for the home network of the future. Because unlike smartphones and tables where one would expect the users to be more technologically sophisticated, users of such cars will likely not want to configure stuff or even be able to hence the need for complete auto-configuration. In any case, exciting times ahead and this will be an interesting development to watch.

By Mukom Akong Tamon, Chief Excellence Officer™ | Certified in IPv6, 4DX Strategy Execution, Lean Si

Mukom works for a Regional Internet Registry (RIR). Everything he writes are his opinion and do not necessarily reflect the views of his employers, past, present or future.

Visit Page

Filed Under


wow, what a bad idea John Levine  –  May 21, 2014 11:40 PM

Do we really have to explain why it’s a terrible idea to allow random devices to connect to a car’s internal network?  See, for example

Hi John,I don't advocate random devices connecting. Mukom Akong Tamon  –  May 23, 2014 8:57 AM

Hi John, I don't advocate random devices connecting. Such in-car WiFi will be subject to the same kind of security controls on any other WiFi (at least WPA keys). Secondly, I advocate for multiple subnets - the network to which things like passenger's devices connect will be blocked from accessing the network that controls critical systems.

Seems reasonable John Levine  –  May 23, 2014 4:05 PM

So if the car has its own private network, firewalled from the rest of the world, what difference does it make what its internal numbering is?

Fun fact: GM’s Onstar service that puts a cell phone in each car uses lots of phone numbers in the 5XX area codes to make each car addressable.

Let me re-state what I meant JohnSubnetA: Mukom Akong Tamon  –  May 23, 2014 4:13 PM

Let me re-state what I meant John SubnetA: Critical Systems SubnetB: In-car wifi So you'd block all traffic from SubnetB to SubnetA However you still want subnetA to have a public space so that the manufacturer for example could run remote diagnostics (I think Tesla does this --- not sure). If there's no need for remote access to SubnetA, then you still need it separate from SubnetB but then accessible via some specialised wired port.

not really John Levine  –  May 23, 2014 4:20 PM

On the equipment I use, e.g. my home router, there’s a single public address of a bastion host that provides limited access to the inside. Why would you want more than that? We really don’t want random outside access to systems where bugs and malware can kill people.

Also, if you assume that every car in the world has its own /64, how would you route the traffic?

If we agree that the car company Mukom Akong Tamon  –  May 27, 2014 3:08 AM

If we agree that the car company has a requirement to access nodes on some critical subnet e.g for remote diagnostics, then it is quite possible the use some kind of similar bastion host. But since there are likely going to be more than one node on that critical subnet, each one of them needs to have its own address, hence the need for more than one IP address.

Of course another alternative would be to not make those elements IP-enabled but they use some kind of communications protocol to talk to the bastion host which then talks to the car manufacturer.

Don’t forget that we are talking about cars - I’m sure 95% of those who buy these cars have no clue what a bastion host is, hence the need for automation. Which is why I think the technologies being developed in the Homenet IETF working group may be adaptable to this situation.

As for the routing issue (I think a /64 is too small for a car), an auto-config type protocol that detects what the control subnet prefix is and routes it using the 3G or 4G router that is in the car already exists.  Apparently today, Tesla already can remotely access each of its cars and today it gives each of then a /24 subne.

Aw, come on John Levine  –  May 27, 2014 3:57 AM

The components in the car need separate addresses on the internal RFC1918 network, and you set up single the bastion host to provide a controlled gateway to whichever of the internal hosts need access.  This is an entirely normal way to set up a network, easy to do with any $29.95 home router.  Surely you’re familiar with it. It sounds like that’s what Tesla is doing.
Also, do you understand why it’s not practical to route a separate static /64 to every car in the world? The routing tables would explode.

I'm not advocating for the routing of Mukom Akong Tamon  –  May 27, 2014 5:17 AM

I’m not advocating for the routing of a single /64 - at least not if that single /64 comes from some central space controlled by the car manufacturer. However, if the /64 comes from the local connectivity provider’s space - then no problem. It’s what they already do for their mobile (non-tethering) clients anyway.

Also, if the manufacturer uses ULA, they’d use the same methods they use today to access those hosts - the bastion host with a public IP gotten from the local provider of connectivity is one valid way. Nothing changes. That is the scenario in option (b) of the article.

Where I think we diverge is that - you being a geek see a simple problem to be solved with a $29 home router. I think of the non-geeks and think the solution must be fully automated and transparent to the user of the car. If the car manufacturer (probably working in conjunction with a connectivity provider in different countries) can figure how to do that, then it is a fitting solution.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Brand Protection

Sponsored byCSC


Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix