In this IPv6 series I’d like to tell you about my “journey” to implement the protocol. I already had some knowledge of it, but not extensively. As a first step I implemented it at home. The plan is to work my way back from home to my lab in the data-center.

In previous parts I described the basics and how to implement IPv6 in my home network using a tunneling technique called 6RD. A 6RD tunnel to my ISP (Tweak) is needed, since they currently do not offer native IPv6. Using the 6RD tunnel, my ISP assigned a /56 IPv6 prefix, which is awesome. A /56 supports 265 IPv6 prefixes of /64 each, so plenty of subnetting possibilities.

Let’s go to the lab now.

The series

My implementation steps will be split into several parts of which this one is the third. Other parts in this IPv6 series are:

Probable outline of next parts (subject to change)

  • Part 6: IPv6 with Cloud Director

Getting IPv6 prefixes

When using a business grade internet connection, you can ask your ISP to assign you a IPv6 prefix. Normally the ISP itself is assigned one of more /32 prefixes from their regional RIR (RIPE NCC in Europe) that they can subdivide to their customers. A customer is normally assigned a /48 prefix which allows for 65.536 prefixes of /64 each.

A second option to get an IPv6 prefix is using a public tunnelbroker like Hurricane Electric or using 6RD from your ISP (if available).

Unique Local addresses

The third option to get a IPv6 prefix, is to use Unique Local Addresses (ULA). The major downside of this type of prefix is that it cannot be routed over the public internet, but will do just fine in a lab environment. The intended use of ULA can be compared to RFC 1918 private IP’s, with the difference that ULA prefixes have a high probability of being unique. I say highly probably because these are not centrally registered. Using a unique ULA prefix in your network eases future merges with other network significantly.

Unique Local prefixes must always be /48 of size and are derived from fd00::/8. The 40 bit Global ID must be generated using a Pseudo-Random number generator per RFC 4193. To generate your ULA, you could use one of the websites in the links section at the bottom.

Routing prefixes

Often the ISP also assigns on or more routing prefixes for setting up the communication between the ISP and the customer router. In an IPv4 environment those consist of /30 or /31. For IPv6, I often see /112 of /126 prefixes being used.

Generic external routing setup

The picture below shows a logical IPv6 business setup. A set of provider (upstream) routers at the top and a set of customer routers below, using BGP as routing protocol.

IPv6 Upstream routing example 1
IPv6 upstream routing example using BGP and routing prefixes

Lab setup

In my lab, I have a more simplified routing configuration, which uses static routes for external connectivity and consists of a single appliance. pfSense is used as my primary router and runs as a VM on vSphere. pfSense is used for all the routing, firewalling and IPSec VPN in the lab. The setup can be seen in the image below:

IPv6 Lab Config

In the examples going forward, reserved IP prefixes are used that are intended for documentation or private use. In reality, public IPv4 and IPv6 prefixes are used on the WAN and DMZ interfaces. In the LAN interface, private IPv4 and public IPv6 prefix are used. DHCPv4 (not shown) and SLAAC are used for IP autoconfiguration.

Router Advertisement

Worth mentioning are the IPv6 Router Advertisement (RA) modes configured on the pfSense interfaces. Configuring RA appropriately determines how IPv6 routers can be found and how IP autoconfiguration is performed.

IPv6 Lab - Router Advertisement

Used RA Modes

  • Disabled: RA will not be enabled on the selected interface.
    • RA is disabled on the internet (WAN) interface, because static addressing is used and for other obvious reasons 😉
  • Router Only: Will advertise the router info on the selected interface.
    • Router Only mode is chosen on the DMZ interface, because only static addressing is used.
  • Unmanaged: Will advertise SLAAC (stateless autoconfig) and router info on the selected interface.
    • Unmanaged is chosen on the LAN interface, because only SLAAC is used.

Other RA modes (not used)

  • Managed: Will advertise the router with all configuration through a DHCPv6 server.
  • Assisted: Will advertise the router with configuration through a DHCPv6 server and/or stateless autoconfig.
  • Stateless DHCP: Will advertise the router with stateless autoconfig and other configuration information available via DHCPv6.

It is not required to activate DHCPv6 server on pfSense when the RA mode is set to “Managed”, “Assisted” or “Stateless DHCP”, it can be another host on the network.

Subnetting IPv6 to your needs

I gave the planning part of my IPv6 config plenty of attention. First and foremost for scalability and secondly to be able to segment parts of my network based on it’s usage. Being able to do so makes routing and firewalling much easier.

Subnetting for scalability

In this case I used the word “scalability” to be able to plan ahead. I chose not to start from the first available /64 and give every subsequent network the next available /64.

First, I subdivided the /48 prefix into 256 prefixes of /56 each. This way I have a rather large prefix for every purpose I would ever need. So how does this look like in practice.

  • 2001:db8:1::/48
    • 2001:db8:1::/56 (LAN, DMZ and routing networks)
    • 2001:db8:1:100:/56 (NSX-T / VCD Lab)
    • 2001:db8:1:200:/56 (future use)
    • 2001:db8:1:300:/56 (future use)
    • and so forth

Secondly, I subdivided the first /56 prefix into 16 prefixes of /60 each. Every /60 is destined for a specific router interface. If I did not use VLAN’s of the interface the first available /64 within the /60 would be used. If additional VLAN are needed, I could grab the next available /64 from the /60 prefix. This way I’m able to assign 16 prefixes of /64 each to a router interface . So how does this look like in practice.

  • 2001:db8:1::/56 (LAN and DMZ networks)
    • 2001:db8:1::/60 (routing networks)
    • 2001:db8:1:10:/60 (LAN – pfSense Interface 1)
      • 2001:db8:1:10:/64 (IF 1 – VLAN 0)
      • 2001:db8:1:11:/64 (IF 1 – VLAN 1)
      • 2001:db8:1:12:/64 (IF 1 – VLAN 2)
    • 2001:db8:1:20:/60 (DMZ – pfSense Interface 2)
      • 2001:db8:1:20:/64 (IF 2 – VLAN 0)
      • 2001:db8:1:21:/64 (IF 2 – VLAN 1)
      • 2001:db8:1:22:/64 (IF 2 – VLAN 2)
    • 2001:db8:1:30:/60 (future use – pfSense Interface 3)

As you have seen, all of my prefixes end at least on full nibbles (4 bits). This makes subnetting much easier, because it represents a full hexadecimal number.

Subnetting for segmentation

Being able to recognize parts of your network based on it’s segment makes sense. Looking at the examples above:

  • 2001:db8:1:11 is the first interface and the second VLAN
  • 2001:db8:1:100 is the second /56 designated for the NSX-T Lab

Using this addressing schema simplifies my lab setup. Routing (for example, multiple BGP ASNs or OSPF areas) and firewalling will be less complex.

Based on scalability of the prefixes in the previous section, it’s now easy to build an new lab environment that uses IPv6. This way I could use a new interface, VLAN or even a router and use a whole /56 of /60 of global unicast space for this purpose. Awesome, you gotta love the increased address space op IPv6. You can finally think big.

Many books have been written about IPv6 network planning, check them out for additional ideas on the matter.

Dual-stacked

Many services on the internet are not reachable via IPv6 only. This way we’re probably be stuck with using both IP versions for a significant amount of time.

Most hosts in a IPv6 enabled network will probably be dual stacked, which means they will have IPv4 and IPv6 addresses. Especially routers and basic services like DNS, NTP and AAA need to be reachable on both.

IPv6 Lab interface configuration
Dual stacked pfSense WAN interface

DNS servers

Especially DNS servers in IPv6 enabled networks needs to be configured correctly. When recursive or authoritative name servers (including it’s zones) are only reachable over IPv6, name space fragmentation could occur for IPv4 hosts. In other words parts of the internet or network cannot be resolved.

The IP recommendations for DNS servers are:

  • Every recursive DNS servers should be IPv4 or dual stacked.
    • IPv6 only recursive DNS servers should not be used.
  • Every DNS zone should be served by at least one IPv4 reachable authoritative DNS server.
    • IPv6 only authoritative DNS servers should not be used.

Source: IPv6 Essentials (3rd Edition) / RFC 3901

IPv6 Lab DNS config
Dual stacked DNS server

Interesting to know is that dual stacked hosts query recursive DNS servers for both A and AAAA records for any given host. When both types of records are received, (by default) hosts prefer IPv6 connections.

IPv6 Lab DNS resolve example
Dual stacked hosts queries both the A and AAAA records

DHCPv6 versus SLAAC

Hosts in IPv6 networks can be autoconfigured based on DHCPv6, SLAAC or a combination of both.

In enterprise networks, DHCPv6 will probably be used instead of SLAAC because it’s more auditable and controllable by the IT staff. With DHCPv6 the server assigns the addresses, instead of the host itself. Still Duplicate Address Detection (DAD) is used to check for duplicate addresses. Additional features of using DHCP (over SLAAC) are IP reservations and the ability to configure DHCP options.

With SLAAC on the other hand, the hosts will choose an IPv6 address themselves, checks if it is used using DAD and uses it, if nobody responds. Only basic parameters like DNS servers and domain can be assigned by the router using SLAAC.

The middle way is also possible and could be a combination of both. SLAAC for IP autoconfig and DHCP for additional properties like domain, search suffix, NTP, DNS and so on.

Fun With IPv6 addresses

You can have a bit of fun with IPv6 addresses, since it uses hexadecimal characters. I admit that it’s a bit geeky, but hey, aren’t we all a bit in IT.

Being based in hex characters, IPv6 gives us the characters A to F for creating words, just like in the old days with Netware IPX/SPX networks. Additionally some of the numbers can be used as characters also.

NumberLetter
1I or L
2Z
5S
7T
9G

Now we’re able to use all sorts of words in IPv6 addresses. Check out SophieDoggs blog for an extensive list. Fun fact is that facebook also did this, just ping facebook.com.

Some ideas 🙂

  • c001:babe:cafe
  • a1f:ea75:ca75
  • 1ce:1ce:babe
  • 1:5ee:bad:c0de

To conclude

After writing about the IPv6 basics in part 1 and how to implement it at home in part 2, this part outlines how you could implement IPv6 in your lab. Obtaining a prefix is the first to start with, depending on your needs, followed thinking through a suitable IP plan.

The sections that follow describe the choices to be made about IP (auto)configuration. Are you going to use DHCPv6, SLAAC, both or maybe static?

Finally give dual stack configuration of your routers and essential services like DNS, DHCP, NTP and AAA a good thought.

Have fun in the lab and let me know your thoughts and feedback on this series.

Cheers, Daniël

Useful links

Documentation

pfSense docs: IPv6 Router Advertisements

Wikipedia: Reserved IP addresses

Wikipedia: Unique Local Address

Book

IPv6 Essentials 3rd Edition

RFC’s

RFC 3901: DNS IPv6 Operational Guidelines

RFC 4193: Unique Local IPv6 Unicast Addresses

ULA Generators

DNSChecker: Unique Local Address generator

Ultratools: Unique Local Address generator

Fun Words

Fun With IPv6 Words!

Funny IPv6 Words


4 Comments

Murphy · May 6, 2021 at 15:34

Hi and thank you for that great article.

Do you have any insights on using multiple ULA-Ranges by subsequent routers?
I have two different use cases for this:
– having a segmented network (eg. multiple branches/building with pontential failurable links)
– using virtual networks / segements with Docker

I could not figure out those until now.

Greetings,

Murphy

    Daniël Zuthof · May 10, 2021 at 21:25

    Hi Murphy,

    Thanks for your positive feedback.

    Based on you comment, I would say (in general) it is possible to route traffic between the sites you’re using ULA in, when using private (non-internet) links or using a routed VPN over the internet. If possible use global unicast for your hosts. If ULA is used nevertheless for hosts and servers, IPv6 is design for multi-homing. A global unicast for internet and ULA for internal communication could be a viable solution. On the routers, this can be separately routed.

    Often implementing NAT66 causes lot of headaches in the future.

    Cheers, Daniël.

      Murphy · May 14, 2021 at 15:56

      Thanks for your reply.

      I do not have seperate sites that are connected via VPN which of course would imply that we need to setup rooting through that tunnel. However I am currently trying to wrap my head around the following scenario:
      – one router
      — connects the network to the internet
      — provides ULA to the network (always) ==> ULA-Set-1
      — provides IPv6 addresses to each node on the network
      — provides IPv6 subnet if requested (prefix delegation)
      – Server A
      — gets IPv6 from ULA-Set-1 for physical interface (ethernet)
      — runs docker with an own IPv6 prefix for ULA ==> ULA-Set-2
      – Server B
      — gets IPv6 from ULA-Set-1 for physical interface (ethernet)
      — runs docker with an own IPv6 prefix for ULA ==> ULA3
      – Client C
      — gets IPv6 from ULA-Set-1 for physical interface (ethernet)

      I am currently trying to get the Client C to reach any of the docker services running on either Server A or Server B as well als Server A and B may host some services that need to communicate with each other (in my case: CI/CD-System needs access to repositories).
      I just don’t see were to set the routing information correctly, as I do not want to add the routing manually to all nodes.

      I wish I could attach a graphic to illustrate this issue better than just text.

      And I am totally with you: You should avoid using NAT66 if possible, this would be really a last resort solution for me.

      Cheers,
      Murphy

        Daniël Zuthof · May 15, 2021 at 17:01

        Hi Murphy,

        Obvious I cannot tell exactly what to do. I general routing 3 IPv6 ULA prefixes is not very different from routing 3 RFC 1918 subnets internally. When you implement routing on professional router gear (arista / juniper / cisco) together with static (or dynamic routing protocols like OSPF and BGP that part should be just fine. This way routing can take place centrally between your ULA prefixes including IPv4 (if any).

        If (some) of your ULA assigned hosts also need IPv6 internet access this is something ULA is not designed for. The obvious best solution would be to obtain IPv6 PI space and start renumbering. This way you are provider independent. Maybe assigning both ULA and GUA addresses to host is possible in your situation, since ULA to ULA communication is preferred over others with IPv6. The least desired option would be to investigate NPTv6 / NAT66.

        https://blog.ipspace.net/2014/01/source-ipv6-address-selection-saves-day.html

        Cheers, Daniël

Leave a Reply

Your email address will not be published. Required fields are marked *