When you write documentation for your application (you are writing documentation, aren’t you?), what IPv6 addresses are you using in your examples?

If you just use a random IPv6 address, it could turn out to be someone’s real IPv6 address. Even with the IPv6 address space being so huge, there still is the remote chance that your documentation choice could collide with a real address and potentially cause traffic or routing issues. If you use your own IPv6 addresses, well, are you sure you want the traffic of people typing in examples and hitting your systems? (And maybe I’m personally just too concerned about security, but I don’t want to have people probing around my systems!)

Thankfully, the good folks at the IETF solved this issue for us with RFC 3849, IPv6 Address Prefix Reserved for Documentation. The magic IPv6 address prefix to use for documentation is:

That prefix has been permanently allocated for documentation purposes and will never be assigned to an actual end party. It is, as they say, “nonroutable.”

If you look at the IPv6 addresses I have been using throughout this book, you’ll see that they all use the 2001:db8: prefix, although with various lengths:

When you are writing your documentation, if you need to show communication occurring between multiple IPv6 networks, you can simply subdivide the 2001:db8:: address space into appropriate subnets. For example, if you wanted to show two different networks, you could use address blocks such as these:

Or you could make the address ranges a bit more distinct visually:

The inclusion of letters makes for interesting documentation possibilities. You could simply have ranges like these:

or you could get a bit more creative:

On this last example, note that while the earlier examples showed a /48 address range, you can certainly use more specific subnets, such as a /64, or even smaller if you need to do so.

Regardless of whether you write about a single or multiple networks, as you write your documentation (or training materials), please use this 2001:db8: IPv6 prefix for any examples in your documentation. It’s definitely the safest way to proceed.

Beyond the user guide or similar documents related to your application, do you have training materials for your application?

Do you have actual training classes with associated courseware or slides? Online videos or screencasts?

Do any of these training materials need to be updated for IPv6? Do you need new screen captures for your documentation? Do you need to provide guidance on using your application with IPv6?

Odds are that if you have made any changes to address the issues raised in earlier chapters, you will have some work to do here to bring your training materials up to date, even if IPv6 usage or configuration is only a new appendix or additional section.

As you get a new release ready for your application, have you incorporated IPv6 testing into your test plans? If you have unit tests that are automatically run, have you created appropriate tests that stress the IPv6 interfaces? Do you test out all the IP address entry fields, storage, and the like, to verify that IPv6 addresses can be handled?

If you have a quality assurance (QA) team that tests your app, do their test plans include a segment on IPv6? Do they have an IPv6 test lab where they can actually test your application in a live environment?

Exactly what you need to test will obviously vary depending on your application, but do not forget to include IPv6 testing in your plans.