Author: Craig Miller

Moving to IPv6 starts at home. Applications have to speak IPv6 as well as the network. The good news is that there is lots of software available which already supports IPv6. Unfortunately, there is much more that doesn’t.

An example, a Python-based webserver. Certainly not ready for a production network, but handy as a learning tool about how easy it can be to support IPv6 in your application.

Why Python? Python is a wonderful programming language, and getting only better with version 3. There are libraries for most needs, including one which serves up the web. And it runs just about anywhere that Python runs (Windows, Linux, BSD, Mac, Pi, ODROID, etc)

Python module SimpleHTTPServer

The python module SimpleHTTPServer supports IPv4 out of the box with the simple command:

python -m SimpleHTTPServer

However it does not support IPv6. There is no one-line equivalent to support IPv6, so a small script is required.

Looking at the code

The ipv6-httpd script is a short script supporting both IPv4 and IPv6. Looking at the following sections:

1. Initialization of the HTTPServer object (from SimpleHTTPServer library)
2. Class creation (of HTTPServerV6) to support IPv6

As with all Python scripts, the details roll backwards from the bottom. Initialization occurs in main

def main():
    global server
    server = HTTPServerV6(('::', listen_port), MyHandler)
    print('Listening on port:' + str(listen_port) + '\nPress ^C to quit')
    server.serve_forever()
    os._exit(0)

The IPv6 part

In order to support IPv6, we use a bit of object oriented inheritance trickery to modify the default of an existing class HTTPServer

class HTTPServerV6(HTTPServer):
    address_family = socket.AF_INET6

This creates a new class (which is used in our server ) with the address_family set to AF_INET6 (aka IPv6). This two-line change to the script transforms an IPv4-only script into an application that also supports IPv6.

Running the code

Now that we have a server which supports both IPv4 and IPv6, all we need to do is cd to the directory we wish to share, and start the server

$ cd public/
$ ~/bin/ipv6-httpd.py 
Listening on port:8080
Press ^C to quit
2001:db8:ebbd:0:4d18:71cd:b814:9508 - - [09/Jul/2017 11:49:41] "GET / HTTP/1.1" 200 -
^CCaught SIGINT, dying

The webserver log is sent to standard out (stdout), and can be redirected to a file if desired. In the above example, an IPv6 client ..:9508 requests an index, then the server is terminated with a ^C.

Want to server from a different directory? Stop the server, cd to another directory, and restart the server, it will now serve files from the new current working directory (cwd) location.

Security (or lack there of)

This is a personal webserver, designed to be started and stopped whenever you need it. It is NOT a production quality webserver that you should put on the internet.

It does not server encrypted pages (read: no SSL/TLS), and it is single threaded, which means if a second request comes in while serving the first request, the second request will have to wait.

Adding IPv6 Support to your App

As you can see, it doesn’t have to be difficult to add IPv6 to your apps, you just need to give it some thought when planning your App. By adding IPv6, you will future proof your App by being ready for the future of the Internet.

• the ipv6_httpd.py script can be downloaded from github
• Article previously posted to ipv6-net.blogspot.ca

In a small network of more than one router, one will quickly figure out that you can’t get there from here, even with DHCPv6-PD (Prefix Delegate) providing IPv6 addressing,. Sure you can get to the internet, but you can’t get to other parts of the network which are behind the other routers. You need a routing protocol to share information between the routers on your small network.

How to Get There?

So when we all have /56s or larger delegated to our house/SOHO, and we put in multiple IPv6 capable routers, how will the routers convey connectivity information? Well we could use HomeNet RFC 7788, but currently home routers don’t come out of the box configured for HomeNet (for example the Wifi is on the same subnet as the LAN). Not to diminish HomeNet’s work, but there is a forgotten protocol that can solve the problem.

The Forgotten Protocol: RIPng

RIPng (RFC 2080), the IPv6 cousin of RIPv2  RFC 2453 , has all the advantages of RIPv2, except it conveys IPv6 route information (rather than RIPv2’s IPv4-only info). But the same principles apply, easy to deploy, works pretty well, solves the problem (of distributing routes to multiple routers).

But finding support, and documentation on RIPng on the internet is threadbare. Even the venerable BIRD (BIRD Internet Routing Daemon) has a non-functional example configuration, not to mention they just call it RIP confusing whether it is for IPv4 or IPv6.

But why has it been forgotten? Because real men use OSPF (or IS-IS). And you can too, if you want to spend a week (or more) learning the complexities of the protocol. But what if you just wanted it to work, and move onto the next problem.

Getting from here to there

Although some ISPs will give a fairly stable prefix (via DHCPv6-PD), others do not, leading to a very dynamic prefix environment at home or the SOHO (see Request: Less Dynamic Prefix, Mr./Ms. ISP. Cascaded routers can further divide the /56 via DHCPv6-PD allocating smaller chunks downstream. If one only needs to get to the internet (everything is in the cloud, right?), this works quite well. After all each cascaded router has a default route pointing upstream (towards the ISP).

But what if you have your NAS on Network B, and you client on Network C, it isn’t going to work.

Router 3 doesn’t know about Router 2, or even the subnet B behind Router 2

Of course, you could put in static route in each of Routers 2 & 3. But not only does that take a bit more knowledge of routing (hint: the next hop is a link-local address), but it doesn’t work in a dynamic prefix (where the ISP is changing the prefix) environment.

RIPng to the rescue

So, enter an easy to configure, easy to use routing protocol, RIPng. Running RIPng, Routers 2 & 3 can share information about themselves, and more importantly, the subnets they are serving. If the ISP changes the prefix, DHCPv6-PD will propagate the new prefix down to the cascaded routers, and RIPng will refresh the routing information between the routers, all automagically.

Making RIPng work

First, use router software that supports RIPng. Of course Cisco supports RIPng, but not everyone has multiples of these at home. OpenWrt/LEDEis a good option, since if your router is not over 5 years old, it is probably supported. And it has BIRD as an easy to install package.

First, install bird6 & birdc6 (the CLI for bird6). The bird6 package is a direct port from the bird maintainers, and therefore uses its own configuration file (rather than UCI). But RIPng is easy, so onto the next step.

Uncomment the following lines in the package-provided configuration file /etc/bird6.conf

router id 192.168.0.1;

protocol kernel {
    learn;          # Learn all alien routes from the kernel
    scan time 20;       # Scan kernel routing table every 20 seconds
    export all;     # Default is export none
}

protocol rip {
    import all;
    export all;
    infinity 16;
    interface "*" { mode multicast; };
}

Even though RIPng does not require a “router id” bird6 won’t run without it. Restart the bird6 daemon with /etc/init.d/bird6 restart, and you are done*

Of course you could optimize it a bit by telling the config which interfaces to use, such as interface "eth1" {mode multicast }; but this article is about making it easy, and it doesn’t break anything sending route updates out the other interfaces.

How to tell RIPng is working

ssh to the router. The birdc6 CLI is the easiest in showing the routing table, which includes sources of the routes, like this:

# bindc6
bird> show route
fdcd:5cb4:d0e1::/64 dev br-lan [kernel1 2017-11-30] * (10)
fdcd:5cb4:d0e1::/48 unreachable [kernel1 2017-11-30] * (10)
2001:db8:ebbd:8::/64 dev br-lan [kernel1 2017-11-30] * (10)
2001:db8:ebbd:8::/62 unreachable [kernel1 2017-11-30] * (10)
2001:db8:ebbd:c::/64 via fe80::224:a5ff:fed7:3089 on eth1 [rip1 23:30:58] * (120/2)
2001:db8:ebbd:c::/62 via fe80::224:a5ff:fed7:3089 on eth1 [rip1 23:30:58] * (120/2)
2001:db8:ebbd::/60 via fe80::221:29ff:fec3:6cb0 on eth1 [rip1 00:00:44] * (120/2)
2001:db8:ebbd:4::/64 via fe80::221:29ff:fec3:6cb0 on eth1 [rip1 00:00:44] * (120/2)
2001:db8:ebbd:4::/62 via fe80::221:29ff:fec3:6cb0 on eth1 [rip1 00:00:44] * (120/2)
2001:270:ebbd::/60 via fe80::221:29ff:fec3:6cb0 on eth1 [kernel1 2017-11-30] * (10)
fd37:5218::/64     via fe80::221:29ff:fec3:6cb0 on eth1 [rip1 00:00:44] * (120/2)
fd37:5218::/48     via fe80::221:29ff:fec3:6cb0 on eth1 [rip1 00:00:44] * (120/2)
64:ff9b::/96       via fe80::221:29ff:fec3:6cb0 on eth1 [rip1 00:00:44] * (120/2)
fd11::/64          via fe80::224:a5ff:fed7:3089 on eth1 [rip1 23:30:58] * (120/2)
fd11::/48          via fe80::224:a5ff:fed7:3089 on eth1 [rip1 23:30:58] * (120/2)
bird> 

All those “rip1” lines are routes learned from RIPng. Since no filters were used, not only are the globally unique addresses shared, but so are the Unique Local addresses (ULA) configured in each router. Here’s the fun part, even though there is not ULA on subnet A, RIPng provides connectivity between the ULA islands. Of course, it would be better to have a single ULA /48 for the entire network, but this is a test network, and OpenWrt/LEDE creates a ULA by default for each router. I wanted to see how RIPng would handle this non-optimal situation. And, it handles is pretty well.

While it is possible to figure out who the other RIPng routers are, it is easier to use the bindc6 command:

bird> show rip neigh
rip1:
IP address                Interface  Metric Routes   Seen
fe80::224:a5ff:fed7:3089  eth1            1      4     27
fe80::221:29ff:fec3:6cb0  eth1            1      9      6
bird> 

What’s missing in this simple configuration: authentication

RIPv2 included authentication, to ensure that the routing updates that are being received, are from the correct sources.

RIPng RFC 2080 does not use authentication natively, but rather relies on IPv6’s Authentication Header (AH), one of the extension header types, for authentication (see Stretching IPv6 with extension headers). The configuration above, does not utilize the AH header, however, the risk should be low in a small network. More to come later on RIPng with AH.

Don’t forget DNS

Of course, if you creating a network with IPv6 and more than one subnet, don’t forget the DNS. Have each router forward DNS requests to your local DNS server (you do have a local DNS server, right?).

Add your local DNS server address the following to dnsmasq section of /etc/config/dhcp

config dnsmasq
    list server '2001:db8:ebbd:0::dbc8'

Now all your IPv6 addresses will have names, and it will be a breeze getting around your network.

Wrapping up RIPng

RIPng may have been forgotten, and overlooked for the past 20 years, but that doesn’t mean it can’t still solve problems for small networks (say less that 25 routers) quickly and easily. Sure, you can put in a more complex routing protocol like OSPFv3, but on the other hand, you might want to spend your time just going to the NAS, fire up a good movie, and enjoy the popcorn.

*traffic photo – Creative Commons

**if you are running a firewall, the default on OpenWrt/LEDE, you will need to put in a rule to accept IPv6 UDP port 521

 

See www.makikiweb.com for full article with tcpdump output.

In a recent, rather unscientific poll on Reddit, IPv6 advocates were asked how much IPv6 address space did their respective ISPs give them. It looks like ISPs are getting it, and on average giving out a /56 to home users, which should be plenty for most.

The results

• U.S.
  • Comcast /60
  • TWC/Spcturm /64 (with “hint” /56)
  • AT&T Uverse /60
  • Cox /56 (with “hint”)
  • Charter /64
  • Frontier (no IPv6 support)
• Canada
  • Rogers /56
  • TekSavvy /56 (DSL-0nly)
  • Telus /56
• UK
  • Sky /56
  • BT /56
  • IDNet /56
• Germany
  • Deutsche Telecom /56
  • 1&1 /56
  • Unitymedia /56
• France
  • Free (5 /64s)
• Norway Telenor NO xDSL /48
• Denmark Kviknet /48
• Europe  Orange /56
• Austrailia
  • Internode /56 (static, tied to account, nice!)
  • Australian WISP /56
• New Zealand  2degrees /56 static (or /48 dynamic)

The good and bad

Of course, this is the good news. The less good news is that there are still ISPs out there which provide no IPv6 support for their customers. But it is a good start, and those who are supporting IPv6 have realized that one /64 at the home isn’t enough networks for the future (think: /64 for IoT, /64 for appliances, /64 for HVAC (such as Nest), /64 for your kids, etc, all with different traffic rules). Keep up the good work.

 

 

 

It has felt funny telling people that IPv6 is the new internet protocol, since it is almost 20 years old. But now with RFC 8200, I can honestly say, IPv6 is the new internet protocol which will replace the old creeky-nat-ridden IPv4 protocol.

RFC 8200, if you haven’t seen it, obsoletes RFC 2460 penned in 1998. The title says it all, “Internet Protocol, Version 6 (IPv6) Specification”. It is not a rewrite of the protocol, but rather an encapsulation of the many errata and clarification RFCs. The authors have conveniently put the differences/changes from RFC 2460 in Appendix B, to help people already familiar with IPv6 get up to speed with the new specification.

So go out and honestly tell everyone, there’s a new protocol on the block, and it is IPv6.

There are still people who are uncomfortable with the decision to not include variable subnet masking in IPv6, and making every end-user subnet a /64.

The latest is a drift before the IETF entitled “IPv6 is Classless” which if adopted would allow differing prefix lengths out to /128. But I would ask why? If you want to see what breaks when deviating from the /64, I recommend reading RFC 7421.

How NOT to have people use IPv6 on your Corporate Guest Network

But I have seen corporate guest networks that were /119? I had to think about that one. The line of thinking is that a /119 is like a /23 in IPv4-land, allowing 512 host addresses. But why? When I asked about SLAAC support, the IT guy replied that they don’t support SLAAC (sure, because you need a /64 to support SLAAC). So therefore every Android phone which joins the corporate guest network will not be able to use IPv6. That is an 80% market-share of phones or 4 out of 5, that won’t be using IPv6 on the guest network.

Simplify the network

The /64 network has a certain simplicity to it that hearkens back to when I worked for UH (University of Hawaii) in the early 90’s when the entire campus was (IPv4) /24s, even the point to point links. There was a certain simplicity to it that made the network easy to understand.

Move beyond the address-scarcity mentality

There are those who would argue that it is a crime against the internet to waste all that address space for a point to point link by using a /64. But I would argue that is IPv4-thinking. An analogy I give is that address space is like breaths of air. When you are scuba diving, every breath counts, that tank on your back only holds so much air and when it is out, it is out. Where as, when we get up in the morning, we don’t think “how many breaths have I taken since I brushed my teeth?” After all, even with air pollution, the Earth’s atmosphere is vast! The scuba tank is IPv4, and the Earth’s atmosphere is IPv6.

Go ahead, take a deep breath, it will be OK to use /64s everywhere.

 

• this is a re-occurring theme, discussed earlier

 

 

One of the messages that was clear at this year’s North American IPv6 Summit is that Dual-Stack is only halfway there. We don’t really want to maintain two networks (IPv4 and IPv6) forever. We want to get to IPv6-Only networks.

Moving to IPv6-Only

The good news is that major corporations, such as Cisco, Microsoft, and Comcast, are moving in this direction. With them in the lead, we don’t have to reinvent the wheel when transitioning our own networks for IPv6-Only.

However, another key message at the conference was that there will be a Long-Tail of IPv4 use. We don’t have the luxury of abandoning IPv4 just because it is simpler to manage a single protocol IPv6 network.

Transition: MAP-T

Therefore we need to create transition mechanisms which allow older IPv4-only devices to gain access to the legacy IPv4 Internet. One of the transitions mechanisms which has potential is MAP-T (Mapping of Address and Port using Translation). Think of MAP-T as IPv6 quasi-tunneling in reverse. Rather than how we have been stitching the IPv6 network together with tunnels over IPv4, it is the reverse, carrying IPv4 over an IPv6-Only network.

RFC 7599 explains in detail how MAP-T operates, but here are the highlights

• The CE uses stateless NAT64 creating an algorithmic IPv4-IPv6 address mapping codified as MAP Rules
• A MAP IPv6 address identifier MAP-T includes the IPv4 destination address and a 16 bit PSID (Port Set ID) in the last 64 bits (IID) of the IPv6 address.
• CE IPv4-IPv6 forwarding behavior where IPv6 packets arrive from the BR, and are subject to NAT44 and translated to the private address Dual-Stack network.

MAP is bit more complex in that a CE and BR are required than standard stateful NAT64. However, it utilized stateless NAT64, which is expected to scale better.

Trying it out in a Virtual Lab

OpenWrt/LEDE both have MAP-T CE packages, and you can start exploring this transition mechanism now. In fact, Cisco has a very nice KVM Lab page, running everything (CE, DHCPv6 server, BR) in VMs, where no hardware is required.

I still see stateful NAT64 being useful for smaller networks, but MAP-T takes great strides at solving the scale problems of NAT64. So start thinking about IPv6-Only network, it is closer than you think.

 

 

The North American IPv6 Summit was held in Sunnyvale last month. It is always a pleasure to be in a large room with people who get it. There is no convincing that we need to give up our comfortable Linus-blanket of IPv4 for something new and different. No, everyone in the room is a convert, and many are outspoken advocates.

The conference was organized by the regional IPv6 Task Forces on the mainland: California IPv6 Task Force, Rocky Mountain IPv6 Task Force, Texas IPv6 Task Force, and Mexico IPv6 Task Force.

Speakers, shakers and movers

Some of the speakers were:

• Tony Scott, the former CIO of the Unitied States of America
• John Curran, the President and CEO of ARIN (American Registry for Internet Numbers)
• Kevin Jones, Chair for IPv6 transition at NASA
• John Brzozowski, Chief Architect, IPv6 and Fellow,  at Comcast

Major Points

Missed it? Here’s the presentations

Thanks to all the volunteers of the regional task forces, and Linked-in for hosting the conference. The presentations are posted online, in case you didn’t make it down to Sunnyvale last week. Hope to see you there next time.

This post previously appeared on ipv6-net.blogspot.ca

Microsoft released the Creator Update last month (11 April 2017) with lots of interesting stuff. But the most interesting for IPv6 is support for the RDNSS field in the RA (Router Advertisement). The RDNSS field is the one that carries DNS server information in the RA.

In order to run an IPv6-only SLAAC-based network the host must need 2 things: an address, and the address of a DNS server. Without DNS, IPv4 or IPv6 is pretty useless.

The fact that MS is now supporting SLAAC-only networks is a huge shift from their previous DHCPv6 only stance. Why is this important? Because there are use-cases for SLAAC-only networks, and now not only can you use your Android devices (which don’t do DHCPv6) but also your Windows 10 machines as well.

Windows continues to dominate the PC market with about 85%. Now with Windows 10 Creator Update, there is no excuse to not deploy IPv6 in your network now.