The Universal IPv6 Router Advertisement Option (experiment)
draft-troan-6man-universal-ra-option-01

Abstract

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 and DHCP. This document proposes a new universal RA option 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 https://datatracker.ietf.org/drafts/current/.

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 July 1, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

This document proposes a new universal option for the Router Advertisement IPv6 ND message [RFC4861]. It's purpose is to use the RA as an opaque carrier for configuration information between an agent on a router and host / host application.

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 son 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 an experimental solution to the problem of a very slow process of standardizing new options, and the IETF spending an inordinate amount of time arguing over new configuration options.

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].

3. The Experiment

This document specifies a new "self-describing" universal RA option. Currently new configuration option requires "standards action". The purpose of the experiment is two-fold. What is the implications of an opaque RA option that should not require any code changes for new elements within the option? And what happens when change control is relaxed? The proposal is that no IETF document is required. The configuration option is described directly in the universal RA IANA registry. The other part of the experiment is to

Duration of experiment: 2 years.

How to evaluate success? How many new options have been defined. Did expert review suffice to stop "harmful" options? Was any of the options implemented and deployed? On a successful experiment, the time limit of the registry will be removed and it's experimental status will be removed. If the experiment is deamed a failure, then the registry will be removed.

4. The Universal RA option

The option data is described using the schema language CDDL [I-D.ietf-cbor-cddl], with the limitation described in appendix E "Use with JSON" and encoded in CBOR [RFC7049]. The restriction is there to ensure an easy representation in JSON [RFC8259].

     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: Universal RA Option Format

Fields:

Type

42 for Universal RA Option

Length

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

Data

CBOR encoded JSON padded to the nearest 8 octet boundary.

Example:

{
    "ietf": {
        "dns": {
            "dnssl": [
                "example.com"
            ],
            "rdnss": [
                "2001:db8::1",
                "2001:db8::2"
            ]
        },
        "nat64": {
            "prefix": "64:ff9b::/96"
        }
    }
}

Figure 2

The universal RA option MUST be small enough to fit within a single RA packet. It then follows that a single JSON object can not be larger than what fits within a single option. Different JSON objects can be split across multiple universal RA options (in separate RA packets).

All IANA registered elements are under the "ietf" JSON object. Private configuration information can be included in the option using different keys.

5. 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.

On the router side there should be an API allowing a user to add a JSON object 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 RA elements, based on a JSON dictionary key. Note, the host side must be able to decode the CBOR into a JSON representation.

6. Security Considerations

Unless there is a secutity 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.

7. IANA Considerations

IANA is requested to add a new registry for the Universal RA option. The registry should be named "IPv6 ND RA Universal option (experimental)". Changes and additions to the registry require expert review [RFC8126].

The schema field follows the CDDL schema definition in [I-D.ietf-cbor-cddl].

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

7.1. Initial objects in the registry

The PVD [I-D.ietf-intarea-provisioning-domains] elements (and PIO, RIO [RFC4191]) are included to provide an alternative representation for the proposed new options in that draft.

   +-------------------------------------------------+-----------+
   | CDDL Description                                | Reference |
   +---------------+---------------------------------+-----------+
   | ietf = {                                        |           |
   |   ? dns : dns				     |		 |
   |   ? nat64: nat64				     |		 |
   |   ? ipv6-only: bool			     |		 |
   |   ? pvd : pvd				     |		 |
   |   ? mtu : uint				     |		 |
   |   ? rio : rio				     |		 |
   | }						     |		 |
   |                                                 |           |
   | pio = {                                         | [RFC4861] |
   |   prefix : tstr                                 |           |
   |   ? preferred-lifetime : uint                   |           |
   |   ? valid-lifetime : uint                       |		 |
   |   ? a-flag : bool				     |		 |
   |   ? l-flag : bool				     |		 |
   | }						     |		 |
   |                                                 |           |
   | rio_route = {				     | [RFC4191] |
   |   prefix : tstr				     |		 |
   |   ? preference : (0..3)			     |		 |
   |   ? lifetime : uint			     |		 |
   | }						     |		 |
   | rio = {					     |		 |
   |   routes : [+ rio_route]			     |		 |
   | }						     |		 |
   |                                                 |           |
   | dns = {                                         | [RFC8106] |
   |  dnssl : [* tstr]                               |           |
   |  rdnss : ipv6-addresses : [* tstr]              |           |
   |  ? lifetime : uint                              |           |
   | }                                               |           |
   |                                                 |           |
   | nat64 = {	                   		     | [RFC7050] |
   |   prefix : tstr                                 |		 |
   | }     			                     |		 |
   | ipv6-only : bool                                | [v6only]  |
   |						     |           |
   | pvd = {                                         | [pvd]     |
   |   fqdn : tstr				     |           |
   |   uri : tstr				     |		 |
   |   ? dns : dns				     |		 |
   |   ? nat64: nat64				     |		 |
   |   ? pio : pio				     |		 |
   |   ? rio : rio				     |		 |
   | }						     |		 |
   +---------------+---------------------------------+-----------+

   

Figure 3

8. References

Author's Address

Table of Contents

• 1. Introduction
• 2. Conventions
• 3. The Experiment
• 4. The Universal RA option
• 5. Implementation Guidance
• 6. Security Considerations
• 7. IANA Considerations
• 7.1. Initial objects in the registry
• 8. References
• Author's Address