We engineer embedded systems (electronics & software), running our own OS with LWIP (a network stack). The device is configured to be IPv6 only (means: no IPv4 is available). These embedded systems run a webserver. A browser must be able to open web pages served by them. Unfortunately, Chrome, Firefox and others do NOT support link local IPv6 addresses as URLs (see e.g. Mozilla and W3C).

Our embedded systems will be connected to the existing network infrastructure (Ethernet). Today, most of our customers networks do not have proper IPv6 setup. Namely, no IPv6 router is available and therefore, our embedded systems and the customers computers (Windows, Linux, etc.) will only have a "link local address" (LLA). As stated above, using LLA is not possible with most browsers.

To workaround this, the best solution we can think of is to 'advertise' a prefix to let all computers and our embedded systems generate "unique local addresses" (ULA). The problem is that for some (most?) customers, it won't be easy to convince their IT to reconfigure their network for IPv6 and setup their router to advertise such a prefix in the near future. Therefore, we came up with the following idea: Let our embedded system send out router advertisements (RAs) propagating a prefix like FDxx:xxxx:xxxx::xxxx/64. With that solution, all hosts in the same network will automatically create ULAs and thus every computers browser will be able to connect to our embedded systems. (Note: The idea is that all our embedded systems propagate exactly the same prefix)

Waht do you think about that idea? Specifically:

  • It's a common use case that several of our embedded systems will be added to the same network. Therefore, multiple systems will send out RAs with the same prefix. So far, Googling and reading RFCs, I coulnd't find any statement whether it's allowed to have more than one "router" sending out RAs with the same prefix. Is it allowed? Is it considered to be "ok" doing that?
  • Our embedded systems are not really "router devices". In fact, these are "automation devices" which control motors, actors and sensors. Is it "ok" that non-router devices send out RAs?
  • Also: We's send out RAs ONLY to cause all hosts in the network to generate a ULA. We effectively do NOT want any host to use our embedded systems as router/gateway. Is that ok?

A non-router shouldn't send RAs, but they can. If you say the lifetime to zero devices won't use it as a default gateway. The problem is advertising a single prefix by all your devices on all networks. Don't assume that users will only have one subnet and that users won't want to connect to your devices across different subnets.

The best solution is to use multicast name resolution like mDNS and LLMNR. Take a look at https://serverfault.com/questions/352632/name-resolution-in-an-ipv6-network-without-a-dns-server.

Another option is to provide a simple IPv6 "dummy router" to your customers that advertises a prefix, where each router advertises a different ULA prefix that is printed on the outside. It can advertise a default gateway lifetime of 0 so it doesn't become a default gateway. Customers that have IPv6 already can use their own prefix, and customers without IPv6 can use/buy/etc your dummy router and use its unique ULA prefix.

  • The only problem I see with that is the stated non-cooperation of the customers' network staff. That can certainly lead to problems between the customers and the vendor. – Ron Maupin Aug 28 '15 at 21:34
  • It depends on the environment where this is being deployed. Home networks usually don't have RA guard, and enterprise networks need cooperation from the network admin to allow another "router" on the network. Both situations can work. – Sander Steffann Aug 28 '15 at 21:36
  • @SanderSteffann: Thanks for pointing out the thing with the different subnets at customer site. I didn't thought about that. The mDNS thing is something I already considered to use. But to my understanding, it wouldn't solve any issue with IPv6 adressing itself, it would "only" allow using "nice names" instead of "addresses", wouldn't it? If names resolve to LLA, browser will still not be able to access the targets, are they? (Or do you refer to ZeroConf? Assuming you are: But then, doesn't it simply end up with LLA again, which aren't useful in my web browser use case?) – Zulli Sep 1 '15 at 4:49
  • LLA should work fine with mDNS etc. It's usually just the parsing of link local address literals in the URL bar that fails. – Sander Steffann Sep 1 '15 at 6:44

I think that this is a very bad idea. Only routers are supposed to send out RAs. Announcing Prefixes without routing them will break things.

  • 1
    Hence, we have things like Cisco's RA Guard. – Ron Maupin Aug 28 '15 at 13:36
  • Good point. These features will render those embedded devices useless. – Jens Link Aug 28 '15 at 13:48
  • @JensLink Thanks for the answer! From a logical point of view, it makes sense that non-routers should not send RAs. But is your statement, that a device sending out RAs must "route" something really true? According to RFC4861 (tools.ietf.org/html/rfc4861#page-19) related to "Router Lifetime": "A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list.". As I understand this, I simply need to set this value to 0. (Sure I'm most probably wrong, but I don't understand it yet. Where is it specified?) – Zulli Aug 28 '15 at 14:15
  • I just read about Cisco's RA Guard. I now understand what @RonMaupin mentioned "switches should be set to block RAs from other sources": A switch can/should be configured to only forward RA-packages from ports on which a "router" is connected to. This definitely makes my approach useless. – Zulli Aug 28 '15 at 14:20
  • @Zulli, can't you just get by with the link-local addresses that the end-device will negotiate among themselves? – Ron Maupin Aug 28 '15 at 14:24

This is absolutely not the way to accomplish your goals. Only real routers should send out RAs and the switches should be set to block RAs from other sources.

The end-devices should get their global addressing information through a real router or be statically configured, although they will generate their own link-local addresses using ND, and, if they aren't allowed to use a router, that could be all they need since it will allow IPv6 network on the local link.

Non-routers should not generate RAs because other devices will try to use them as routers. Non-routers sending RAs is considered a form of DoS.

  • @RonMauping As stated in answer from JensLink: I believe you're right, except I don't see any evidence for the last point ("other devices will try to use them as routers"). Do I miss something or are you wrong? – Zulli Aug 28 '15 at 14:23
  • 1
    End-devices that receive RAs from a device will try to use that device as a router. That is the whole point of RAs. That is the reason for RA Guard and why doing that is considered DoS. – Ron Maupin Aug 28 '15 at 14:27
  • If that's true, how do you understand RFC4861s description of the "Router Lifetime". What is it refering to when mentioning "A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list."? – Zulli Aug 28 '15 at 14:38
  • 1
    What I'm saying is that trying to bypass the network guys and use a protocol for something other (even slightly) than what it was intended for is rarely a good idea. If you, or your customers, want to use IPv6, the people running the network need to be on board. Many companies are locking down IPv6 for security until they can get a handle on deploying it correctly. Providing IPv6 capability is exactly the right thing to do, but not in the way you are proposing. If the customers' IT doesn't want IPv6, vendors and end-users can't force it on them, and your company may end up looking bad. – Ron Maupin Aug 28 '15 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.