Internet-Draft The Universal IPv6 Configuration Option October 2021
Winters & Troan Expires 25 April 2022 [Page]
Network Working Group
Intended Status:
Standards Track
T. Winters
QA Cafe
O. Troan

The Universal IPv6 Configuration Option


One of the original intentions for the IPv6 host configuration, was to configure the network-layer parameters only with IPv6 ND, and use service discovery for other configuration information. Unfortunately that hasn't panned out quite as planned, and we are in a situation where all kinds of configuration options are added to RAs. This document proposes a new universal option for RA in a self-describing data format, with the list of elements maintained in an IANA registry, with greatly relaxed rules for registration.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 25 April 2022.

1. Introduction

This document proposes a new universal option for the Router Advertisement IPv6 ND message [RFC4861]. Its purpose is to use the RA messages as opaque carriers for configuration information between an agent on a router and a host.

DHCP is suited to give per-client configuration information, while the RA mechanism advertises configuration information to all hosts on the link. There is a long running history of "conflict" between the two. The arguments go; there is less fate-sharing in DHCP, DHCP doesn't deal with multiple sources of information, or make it more difficult to change information independent of the lifetimes, RA cannot be used to configure different information to different clients and so on. And of course some options are only available in RAs and some options are only available in DHCP.

While this proposal does not resolve the DHCP vs RA debate, it proposes a solution to the problem of a very slow process of standardizing new Router Advertisement options, and the IETF spending an inordinate amount of time arguing over new configuration options in Router Advertisements. It is possible in the future to use the new universal option in DHCP, since this would lead to additional conflict resolution an additional document will need to be considered for that.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Additionally, the key words "MIGHT", "COULD", "MAY WISH TO", "WOULD PROBABLY", "SHOULD CONSIDER", and "MUST (BUT WE KNOW YOU WON'T)" in this document are to interpreted as described in RFC 6919 [RFC6919].

3. Introduction

This document specifies a new "self-describing" universal configuration option. Currently new configuration option requires "standards action". The proposal is that no future IETF document will be required. The configuration option is described directly in the universal configuration IANA registry.

4. The Universal IPv6 Configuration option

The option data is described using the schema language CDDL [RFC8610], encoded in CBOR [RFC7049].

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |     Type      |    Length     |   Data ...
Figure 1: IPv6 Configuration Option Format



42 for Universal IPv6 Configuration Option


The length of the option (including the type and length fields) in units of 8 octets.


CBOR encoded data.

The Option is zero-padded to nearest 8-octet boundary.

Example of an JSON instance of the option:

    "ietf": {
        "dns": {
            "dnssl": [
            "rdnss": [
        "nat64": {
            "prefix": "64:ff9b::/96"
        "rio": [
                "prefix": "::/0",
                "next-hop": "fe80::1"
                "prefix": "2001:db8::/32",
                "next-hop": "fe80::2"

The universal IPv6 Configuration option MUST be small enough to fit within a single IPv6 ND packet. It then follows that a single element in the dictionary cannot be larger than what fits within a single option. Different elements can be split across multiple universal configuration options (in separate packets). All IANA registered elements are under the "ietf" key in the dictionary. Private configuration information can be included in the option using different keys.

If information learnt via this option conflicts with other configuration information learnt via Router Advertisement messages, that is considered a configuration error. How those conflicts should be resolved is left up to the implementation.

5. CBOR encoding

It is recommended that the user can configure the option using JSON. Likewise an application registering interest in an option SHOULD be able to use string keys. The CBOR encoding to save space, uses integers for map keys. The mapping table between integer and string map keys are part of the IANA registry for the option.

Values -23-23 encodes to a single byte in CBOR, and these values are reserved for IETF used map keys.

6. Implementation Guidance

The purpose of this option is to allow users to use the RA as an opaque carrier for configuration information without requiring code changes in the option carrying infrastructure.

On the router there should be an API allowing a user to add an element, e.g. a JSON object [RFC8259] or a pre-encoded CBOR string to RAs sent on a given interface.

On the host side, an API SHOULD be available allowing applications to subscribe to received configuration elements. It SHOULD be possible to subscribe to configuration object by dictionary key.

The contents of any elements that are not recognized, either in whole or in part, by the receiving host MUST be ignored and the remainder of option's contents MUST be processed as normal.

An implementation SHOULD provide a "JSON interface" for configuring the option.

7. Implementation Status

The Universal IPv6 configuration option sending side is implemented in VPP (

The implementation is a prototype released under Apache license and available at:

8. Security Considerations

Unless there is a security relationship between the host and the router (e.g. SEND), and even then, the consumer of configuration information can put no trust in the information received.

9. IANA Considerations

IANA is requested to add a new registry for the Universal IPv6 Configuration option. The registry should be named "IPv6 Universal Configuration Information Option".

The schema field follows the CDDL schema definition in [RFC8610].

Changes and additions to the registry follow the policies below [RFC8126]:

Table 1
Range Registration Procedure
-23-23 Standards Action
24-32767 Specification Required
32768-18446744073709551615 Expert Review

A new registration requires a new CBOR key to parameter name assignment and a CDDL definition.

9.1. Universal configuration option

The IANA is requested to add the universal option to the "IPv6 Neighbor Discovery Option Formats" registry with the value of 42.

9.2. Initial objects in the registry

The PVD [RFC8801] elements and DNS [RFC8106]) are included to provide an alternative representation for the proposed new options in that draft.

9.3. Initial objects in the registry

9.3.1. CDDL/JSON Mapping Parameters to CBOR

Table 2
Parameter Name / JSON key CBOR Key
ietf -23
pio -22
mtu -21
rio -20
dns -19
nat64 -18
ipv6-only -17
pvd -16
prefix -15
preferred-lifetime -14
valid-lifetime -13
lifetime -12
a-flag -11
l-flag -10
preference -9
nexthop -8
nssl -7
dnss -6
fqdn -5
uri -4

9.3.2. Key Registry

|CDDL                                            | Reference |
|ietf = {                                        |           |
|  ? pio : [+ pio]                               |           |
|  ? rio : [+ rio]                               |           |
|  ? dns : dns                                   |           |
|  ? nat64: nat64                                |           |
|  ? ipv6-only: bool                             |           |
|  ? pvd : pvd                                   |           |
|}                                               |           |
|                                                |           |
|                                                |           |
|dns = {                                         | RFC8106   |
|  nssl : [* tstr]                               |           |
|  dnss : [+ ipv6-address]                       |           |
|  lifetime : uint .size 4                       |           |
|}                                               |           |
|                                                |           |
|nat64 = {                                       | RFC7050   |
|  prefix : ipv6-prefix                          |           |
|}                                               |           |
|ipv6-only : bool                                | [v6only]  |
|                                                |           |
|pvd = {                                         |           |
|  fqdn : tstr                                   |           |
|  uri : tstr                                    |           |
|  ? dns : dns                                   |           |
|  ? nat64: nat64                                |           |
|  ? pio : [+ pio]                               |           |
|  ? rio : [+ rio]                               |           |
|}                                               |           |

10. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <>.
Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, , <>.
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, , <>.
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <>.

11. Informative References

Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, , <>.
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <>.
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <>.
Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", RFC 8801, DOI 10.17487/RFC8801, , <>.

Appendix A. Acknowledgements

Many thanks to Dave Thaler for feedback and suggestions of a more effective CBOR encoding. Thank you very much to Carsten Bormann for CBOR and CDDL help.

Authors' Addresses

T. Winters
QA Cafe
O. Troan