Over the last year there has been a slow hum, quietly building around the notion of building what has been called an “IPv6-mostly” network. What does this term mean? How do we do it? Why bother? Well, let me attempt to answer those questions.
First, what is IPv6-mostly? Thankfully, it is pretty much what it sounds like – a network segment (i.e. a LAN segment) that is mostly IPv6, and only legacy IPv4 where it has to be. This is better described to in the RFC that defines the “how”, RFC8925:
It would be beneficial for IPv6 deployment if operators could implement IPv6-mostly (or IPv4-on-demand) segments where IPv6-only hosts coexist with legacy dual-stack devices.
In practice, this works with IPv4-only devices just as well as dual-stack devices. I like to think of it as a network allowing a system to “operate at its highest level of network stack evolution”. Because I had a bit of a time finding examples of how this is implemented in practice (the KEA docs are fantastic, but also very, very deep and comprehensive – a bit much to weed through when looking for a working example.
{
"Dhcp4":
{
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
}
],
"interfaces-config": {
"interfaces": [ "eth0/10.9.9.5" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 86400,
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases"
},
"subnet4": [
{
"id": 4,
"subnet": "10.209.4.0/25",
"pools": [
{ "pool": "10.9.4.100 - 10.9.4.120" }
],
"interface": "eth0",
"option-data": [
{
"name": "domain-name-servers",
"code": 6,
"space": "dhcp4",
"csv-format": true,
"data": "10.9.9.126, 10.9.9.53, 10.9.9.2, 10.9.6.2"
},
{
"name": "routers",
"code": 3,
"space": "dhcp4",
"csv-format": true,
"data": "10.9.4.1"
}
]
}
{
"id": 6,
"subnet": "10.9.6.0/25",
"pools": [
{ "pool": "10.9.6.30 - 10.9.6.120" }
],
"interface": "eth0",
"option-data": [
{
"name": "domain-name-servers",
"code": 6,
"space": "dhcp4",
"csv-format": true,
"data": "10.9.6.2, 10.9.9.126, 10.9.9.53, 10.9.9.2"
},
{
"name": "routers",
"code": 3,
"space": "dhcp4",
"csv-format": true,
"data": "10.9.6.1"
}
]
},
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea/dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 0
}
]
}
}
This KEA configuration assumed that that dhcp is centralized and being relayed via a router relay / ip helper. As mentioned in this APNIC blog, option 108 is still a work in progress. It’s still got some issues with certain clients, and is completely absent in all versions os Microsoft windows.
We have recently recorded an episode of MODEM on my recent experience building and running an IPv6-mostly network, and there is a great IPv6 Buzz Podcast on the same topic that is very good. You can take a listen here, or in your favorite podcatcher, or streamed below.
