News Challenge to router manufacturers
April 2009 Internet protocols are changing. The existing internet protocol, IP version 4, is running out of space soon. So we have version 6 (IPv6) to replace it. IPv6 is no longer just experimental, it is happening. ISPs, like us, are ready for this by providing IPv6 services to customers as well as IPv4. Equipment manufacturers are getting ready by including IPv6 in their products. PCs operating systems support IPv6 including Windows, Mac, and linux. Businesses are starting to use IPv6. It is happening, and it is happening now. Recent LINX forum on IPv6.
Broadband routers
We provide IPv6 service to our customers now, but that means that those customers have to be reasonably technical. They have to set up their own equipment to handle the IPv6 routing and often they cannot do that properly because their broadband router lets them down.
Broadband routers at the connection point between your home or office and your ISP. If your ISP supports IPv6, as we do, then this is the point that really needs to support IPv6. Sadly, none of the existing cheap broadband routers support IPv6 yet, and the manufacturers don't seem to interested!
Challenge to manufacturers
The challenge is who will be first? ZyXEL? Billion? Speedtouch? Who will be the first cheap router manufacturer to support IPv6 in their broadband routers? This is a software change, so existing routers in the field can be upgraded even. Being first to embrace IPv6 will have marketing potential for that manufacturer. Even BT realised recently they have to embrace IPv6 - after saying they do not support IPv6 on their broadband platforms caused so much bad press they are now committed to support of IPv6 on their 21CN broadband platform and working with ISPs like ourselves to ensure it works properly. IPv6 is big news and getting bigger, so do not lose out.
We can help - we will help - for free
We will be happy to work with any manufacturer to help specify and test the changes you need to make, and get real customers using your code. We make the code our end of the broadband line, and so can provide a lot of technical feedback. Already around 8% of our customers have an IPv6 address allocation from us.
If you make it we will buy it
We will make the router our standard router offering that we include with the service if it supports IPv6, even if it costs us 50% more than the ones we supply now.
Challenge to other ISPs
Join us! We'd like to list other other ISPs on here that want IPv6 consumer broadband routers. Others ISPs can take this and use it as long as they maintain the same list of ISPs and include us in the list!
Technical
OK, we know that the developers for a router will be thinking this is a lot of work so we are outlining what you would need, as a bare minimum, you support this. Obviously full support for IPv6 in protocol stacks, etc, is a lot of work, but just getting basic support for being an IPv6 router for a single /64 LAN is not that hard.
So, lets assume a minimal support for IPv6 means simply that you can work with a single /64 IPv6 local network but do not actually talk IPv6 yourself. This would just meet our requirements, and is not so hard.
- Recognising IPv6 packets coming in on your LAN being for your MAC address (they have their own Ethernet type), and wrapping them either in PPP (just adding 0057) or adding a simple 20 byte protocol 41 IP header and wrapping that in PPP and sending on the line. This is literally a few lines of code. It really is simple. You would need to adjust hop count, but that does not even need a re-checksum, unlike IPv4, and there is a simple ICMPv6 error packet. You would have to recognise when its too big for MTU and generate a simple ICMPv6 error packet.
- You probably want to recognise packets addressed to your own IPv6 address and drop them if you do not talk IPv6, but again, that is a pretty simple check.
- Recognising IPv6 packets coming in on PPP (has its own PPP protocol type) or IPv6 wrapping in IPv4 protocol 41 to your WAN IPv4 address, unwrapping, and sending on the LAN. This does need neighbour discovery.
- Some basic neighbour discovery code which is very much like ARP code, and could easily be based on your ARP code. This allows you to find the MAC of the destination IPv6 on your LAN.
- Answering neighbour discovery for your IPv6 address.
- Answering IPv6 router solicitation requests, and sending periodic router announcements allowing simple auto config on the LAN.
- Allowing config of the LAN IPv6 subnet, even if you assume fixed /64 subnet size, even if you assumed your IPv6 address is ...::1/64. Would be nice if this could be set by some PPP message from the ISP, which we would be happy to work with.
- If IPv4 tunnelling rather than native IPv6, configuring the IPv4 endpoint - though you could assume 192.88.99.1 if you really wanted and avoids another config option.
- Maybe PPP negotiation of IPV6CP link local address, which basically indicates the ISP supports native IPv6 on the broadband side, and that you do too.
- The other issue is fire-walling, though this could be done in a relatively simple way checking UDP and TCP for example. The actual TCP and UDP headers are the same for IPv4 and IPv6 but in a different place. If you have IPv4 filtering on inbound SYN/no-ACK TCP and inbound UDP by port, without session tracking, that would meet most basic requirements applied to the inbound IPv6 packets.
This would only be a start. It would not be a complete implementation but would allow auto configured /64 IPv6 LAN to operate native or tunnelled IPv6 to an ISP.
If we can agree some PPP way to tell you the LAN prefix, you could even make this work with zero changes in the router config, just low level changes at Ethernet and PPP level.
