Network Working Group O. Troan
Internet-Draft Cisco Systems
Intended status: Experimental December 28, 2018
Expires: July 1, 2019
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
Troan Expires July 1, 2019 [Page 1]
Internet-Draft December 2018
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
Troan Expires July 1, 2019 [Page 2]
Internet-Draft December 2018
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:
Troan Expires July 1, 2019 [Page 3]
Internet-Draft December 2018
{
"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.
Troan Expires July 1, 2019 [Page 4]
Internet-Draft December 2018
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 | |
Troan Expires July 1, 2019 [Page 5]
Internet-Draft December 2018
| ? 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
[I-D.ietf-6man-ipv6only-flag]
Hinden, R. and B. Carpenter, "IPv6 Router Advertisement
IPv6-Only Flag", draft-ietf-6man-ipv6only-flag-04 (work in
progress), November 2018.
[I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor-
cddl-06 (work in progress), November 2018.
Troan Expires July 1, 2019 [Page 6]
Internet-Draft December 2018
[I-D.ietf-intarea-provisioning-domains]
Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
draft-ietf-intarea-provisioning-domains-03 (work in
progress), October 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
Author's Address
Ole Troan
Cisco Systems
Philip Pedersens vei 1
Lysaker 1366
Norway
Email: ot@cisco.com
Troan Expires July 1, 2019 [Page 7]