Applying the New IPv6 Documentation Space: A Practical Approach (3FFF::/20)

06/02/2025

Applying the New IPv6 Documentation Space: A Practical Approach (3FFF::/20)

By Alejandro Acosta, R&D Coordinator, and Julio Buiza, Registration Services Specialist, at LACNIC

Introduction

On 23 July 2024, the IANA reserved 3FFF::/20 as a new dedicated IPv6 address prefix for documentation purposes, thus adding a new block to the existing documentation block (2001:db8::/32). This request was included in IETF draft https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/05/ as follows:

“The document describes the reservation of an additional IPv6 address prefix for use in documentation. This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix. The addition of a /20 allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks.”

Following this expansion, in this article we will discuss an IPv6 address plan as an example, using address block3FFF::/20.

Importance of an IP Address Plan

What is an IP (v4/v6) address plan?

An IP address plan is defined as the form, actions, and systematic model used for assigning IP addresses on a network [1].

Why you should develop an IP address plan

An IP address plan:

  • Helps to keep the network documentation in order,
  • Simplifies the implementation of assignment policies,
  • Supports the orderly growth of the network (future assignments/scaling),
  • Improves network performance efficiency (smaller routing tables),
  • Facilitates troubleshooting, and
  • Simplifies network management.

What should an IP address plan look like? What aspects should it consider?

  • An IP address plan must be scalable (anticipate the potential growth of the network over the next 2, 5, 10, and 15 years).
  • It must be flexible. For example, in the future, new services may be added or coverage may be extended to other cities.
  • It must be simple and comprehensible, in other words, it must not introduce unnecessary complexity.
  • It must follow best practices.
  • It must separate the infrastructure from customers (important).

Recommendations to begin your IPv6 address plan

1)    The most important piece of advice, and one of the most fundamental, is to manipulate the blocks by nibbles, in other words, considering each character of the IPv6 address.

What would the new 3FFF::/20 prefix look like?

As shown in the image below, because the prefix is ​​a /20, the first five nibbles are fixed and every “X” character can be modified:

Where:

  • C1, C2, C3, C4, C5, C6, C7, C8 -> Represent groups of 16 bits

2)    Mapping the nibbles to a function

A common practice is to map a nibble or a group of nibbles to “something”, where this “something” might be a function, a country, a service, a type of customer, or something else.

This is illustrated in the following image:

  • For ISPs:

Where:

  • PPP -> Represents a country
  • CCC -> Represents a city
  • SS -> Represents a service
  • T -> Represents a type of customer
  • For End Users (EU):

Where:

  • UUU -> Represents a campus/location
  • EEE -> Represents a building withing the campus/location
  • SS -> Represents a service
  • F -> Represents a faculty

Important: Keep in mind that the final 64 bits (C5, C6, C7, and C8) are typically assigned by the autoconfiguration process and/or manually by the administrator.

Additional reading:
Expanding the IPv6 Documentation Space

Practical Example of an IPv6 Address Plan:

Below we have included a couple of examples of an address plan using the new 3FFF::/20 prefix.

Note: These examples are offered as recommendations and show one of many possible approaches to developing an IPv6 address plan within a network.

  1. IPv6 Address Plan for an ISP

In this scenario, an ISP operating in three countries, each with three cities, has been considered. Using the nomenclature in the previous example, specific values ​​have been assigned and characters have been replaced based on the category they each represent, as shown in the following table:

Characters to be modifiedCategoryValuesDescription
PPPCountry058Venezuela
057Colombia
051Peru
CCCCiudad212Caracas
261Maracaibo
241Valencia
601Bogota
604Medellin
605Cartagena
031Lima
032Arequipa
033Cusco
SSService10HFC Internet
20GPON Internet
30Satellite Internet
TType of customer1Company
2Government entity
3Residential
4NGO

This is an example of what an IPv6 address plan for an ISP would look like:

IPv6 prefixCountryPrefix assigned to the country [NET_ID]CitySubnet assigned to the city [Subnet]ServiceType of customerSubnet assigned to the service and type of customer [Division]
3FFF::/20Venezuela3FFF:0058::/32Caracas3FFF:0058:0212::/48HFC InternetCompany3FFF:0058:0212:0101::/64
Government entity3FFF:0058:0212:0102::/64
Residential3FFF:0058:0212:0103::/64
NGO3FFF:0058:0212:0104::/64
GPON InternetCompany3FFF:0058:0212:0201::/64
Residential3FFF:0058:0212:0203::/64
Maracaibo3FFF:0058:0261::/48GPON InternetCompany3FFF:0058:0261:0201::/64
Government entity3FFF:0058:0261:0202::/64
Residential3FFF:0058:0261:0203::/64
NGO3FFF:0058:0261:0204::/64
Valencia3FFF:0058:0241::/48GPON InternetCompany3FFF:0058:0241:0201::/64
Government entity3FFF:0058:0241:0202::/64
Satellite InternetResidential3FFF:0058:0241:0303::/64
NGO3FFF:0058:0241:0304::/64
Colombia3FFF:0057::/32Bogota3FFF:0057:0601::/48HFC InternetCompany3FFF:0057:0601:0101::/64
Government entity3FFF:0057:0601:0102::/64
Residential3FFF:0057:0601:0103::/64
NGO3FFF:0057:0601:0104::/64
Medellin3FFF:0057:0604::/48GPON InternetCompany3FFF:0057:0604:0201::/64
Government entity3FFF:0057:0604:0202::/64
Residential3FFF:0057:0604:0203::/64
NGO3FFF:0057:0604:0204::/64
Cartagena3FFF:0057:0605::/48GPON InternetCompany3FFF:0057:0605:0201::/64
Government entity3FFF:0057:0605:0202::/64
Satellite InternetResidential3FFF:0057:0605:0303::/64
NGO3FFF:0057:0605:0304::/64
Peru3FFF:0051::/32Lima3FFF:0051:0031::/48GPON InternetCompany3FFF:0051:0031:0201::/64
Residential3FFF:0051:0031:0203::/64
Satellite InternetResidential3FFF:0051:0031:0303::/64
Arequipa3FFF:0051:0032::/48HFC InternetCompany3FFF:0051:0032:0101::/64
Government entity3FFF:0051:0032:0102::/64
Residential3FFF:0051:0032:0103::/64
NGO3FFF:0051:0032:0104::/64
GPON InternetCompany3FFF:0051:0032:0201::/64
Government entity3FFF:0051:0032:0202::/64
Residential3FFF:0051:0032:0203::/64
NGO3FFF:0051:0032:0204::/64
Cusco3FFF:0051:0033::/48GPON InternetCompany3FFF:0051:0033:0201::/64
Residential3FFF:0051:0033:0203::/64
Satellite InternetNGO3FFF:0051:0033:0304::/64
Reserve blocks3FFF:0004::/32 – 3FFF::0FFF::/32Reserve IPv6 blocks/32–––
  • IPv6 Address Plan for an End User (EU)

For an End User (EU) scenario, an example will be provided considering a university with three campuses. Values have been assigned and characters have been replaced based on the category they each represent, as shown in the following table.

Characters to be modifiedCategoryValuesDescription
UUUCampus/Location001Main campus
002Secondary campus 1
003Secondary campus 2
EEEBuilding111Building 1
222Building 2
333Building 3
SSService10HFC Internet
20GPON Internet
FFaculty1Law
2Medicine
3Administration
4Engineering

This is an example of what an IPv6 address plan for an End User would look like:

IPv6 prefixCampus/LocationPrefix assigned to the campus [NET_ID]BuildingSubnet assigned to the building [Subnet]ServiceFacultySubnet assigned to the service and the faculty [Division]
3FFF::/20Main campus3FFF:0001::/32Building 13FFF:0001:0111::/48HFC InternetLaw3FFF:0001:0111:0101::/64
Medicine3FFF:0001:0111:0102::/64
Administration3FFF:0001:0111:0103::/64
Engineering3FFF:0001:0111:0104::/64
GPON InternetLaw3FFF:0001:0111:0201::/64
Administration3FFF:0001:0111:0203::/64
Building 23FFF:0001:0222::/48GPON InternetLaw3FFF:0001:0222:0201::/64
Medicine3FFF:0001:0222:0202::/64
Administration3FFF:0001:0222:0203::/64
Engineering3FFF:0001:0222:0204::/64
Building 33FFF:0001:0333::/48GPON InternetLaw3FFF:0001:0333:0201::/64
Medicine3FFF:0001:0333:0202::/64
Secondary campus 13FFF:0002::/32Building 13FFF:0002:0111::/48HFC InternetLaw3FFF:0002:0111:0101::/64
Medicine3FFF:0002:0111:0102::/64
Administration3FFF:0002:0111:0103::/64
Engineering3FFF:0002:0111:0104::/64
Building 23FFF:0002:0222::/48GPON InternetLaw3FFF:0002:0222:0201::/64
Medicine3FFF:0002:0222:0202::/64
Secondary campus 23FFF:0003::/32Building 13FFF:0003:0111::/48GPON InternetLaw3FFF:0003:0111:0201::/64
Administration3FFF:0003:0111:0203::/64
Building 23FFF:0003:0222::/48GPON InternetLaw3FFF:0003:0222:0201::/64
Administration3FFF:0003:0222:0203::/64
Reserve blocks3FFF:0004::/32 – 3FFF::0FFF::/32Reserve IPv6 blocks/32–––

Conclusions

An IPv6 address plan should be scalable, easy to understand, and facilitate network management. While there is no single way to create an IPv6 address plan, it is recommended to consider separating addresses by nibbles and assigning a function/task to each nibble character. This will help keep everything in order during the assignment process throughout the operation of the network.

References

[1] https://blog.acostasite.com/2018/06/concepto-que-es-un-plan-de.html?m=1

https://datatracker.ietf.org/doc/rfc9637

[2] LACNIC Podcast: Ampliación del espacio documentación IPv6

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.

Subscribe
Notify of

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments