idnits 2.17.1 draft-troan-6man-universal-ra-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 April 2020) is 1478 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8106' is mentioned on line 264, but not defined == Missing Reference: 'RFC7050' is mentioned on line 270, but not defined ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Troan 3 Internet-Draft cisco 4 Intended status: Standards Track 2 April 2020 5 Expires: 4 October 2020 7 The Universal IPv6 Configuration Option (experiment) 8 draft-troan-6man-universal-ra-option-02 10 Abstract 12 One of the original intentions for the IPv6 host configuration, was 13 to configure the network-layer parameters only with IPv6 ND, and use 14 service discovery for other configuration information. Unfortunately 15 that hasn't panned out quite as planned, and we are in a situation 16 where all kinds of configuration options are added to RAs and DHCP. 17 This document proposes a new universal option for RA and DHCP in a 18 self-describing data format, with the list of elements maintained in 19 an IANA registry, with greatly relaxed rules for registration. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 4 October 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. The Experiment . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. The Universal IPv6 Configuration option . . . . . . . . . . . 3 58 5. Implementation Guidance . . . . . . . . . . . . . . . . . . . 4 59 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Initial objects in the registry . . . . . . . . . . . . . 5 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 This document proposes a new universal option for the Router 69 Advertisement IPv6 ND message [RFC4861] and DHCPv6 [RFC8415]. It's 70 purpose is to use the RA or DHCP message as an opaque carrier for 71 configuration information between an agent on a router or DHCP server 72 and host / host application. 74 DHCP is suited to give per-client configuration information, while 75 the RA mechanism advertises configuration information to all hosts on 76 the link. There is a long running history of "conflict" between the 77 two. The arguments go; there is less fate-sharing in DHCP, DHCP 78 doesn't deal with multiple sources of information, or make it more 79 difficult to change information independent of the lifetimes, RA 80 cannot be used to configure different information to different 81 clients and so on. And of course some options are only available in 82 RAs and some options are only available in DHCP. 84 While this proposal does not resolve the DHCP vs RA debate, it 85 proposes an experimental solution to the problem of a very slow 86 process of standardizing new options, and the IETF spending an 87 inordinate amount of time arguing over new configuration options. 89 2. Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 3. The Experiment 97 This document specifies a new "self-describing" universal 98 configuration option. Currently new configuration option requires 99 "standards action". The purpose of the experiment is two-fold. What 100 are the implications of an opaque configuration option that should 101 not require any code changes for new elements within the option? And 102 what happens when change control is relaxed? The proposal is that no 103 IETF document is required. The configuration option is described 104 directly in the universal configuration IANA registry. 106 Duration of experiment: 2 years. 108 How to evaluate success? How many new options have been defined. 109 Did expert review suffice to stop "harmful" options? Were any of the 110 options implemented and deployed? On a successful experiment, the 111 time limit of the registry will be removed and it's experimental 112 status will be removed. If the experiment is deemed a failure, then 113 the registry will be removed. 115 4. The Universal IPv6 Configuration option 117 The option data is described using the schema language CDDL 118 [RFC8610], encoded in CBOR [RFC7049]. 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Type | Length | Data ... 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Figure 1: Universal IPv6 Configuration Option Format 128 Fields: 130 Type 42 for Universal IPv6 Configuration Option 132 Length The length of the option (including the type and length 133 fields) in units of 8 octets. 135 Data CBOR encoded data. 137 Padding Option zero-padded to nearest 8-octet boundary 139 Example: 141 { 142 "ietf": { 143 "dns": { 144 "dnssl": [ 145 "example.com" 146 ], 147 "rdnss": [ 148 "2001:db8::1", 149 "2001:db8::2" 150 ] 151 }, 152 "nat64": { 153 "prefix": "64:ff9b::/96" 154 } 155 "rio": { 156 "routes": [ 157 "rio_routes": { 158 "prefix": "::/0", 159 "next-hop": "fe80::1" 160 } 161 ] 162 } 163 } 164 } 166 Figure 2 168 The universal IPv6 Configuration option MUST be small enough to fit 169 within a single IPv6 ND or DHCPv6 packet. It then follows that a 170 single element in the dictionary cannot be larger than what fits 171 within a single option. Different elements can be split across 172 multiple universal configuration options (in separate ND RA packets). 174 All IANA registered elements are under the "ietf" key in the 175 dictionary. Private configuration information can be included in the 176 option using different keys. 178 5. Implementation Guidance 180 The purpose of this option is to allow users to use the RA or DHCP as 181 an opaque carrier for configuration information without requiring 182 code changes in the option carrying infrastructure. 184 On the router or DHCP server side there should be an API allowing a 185 user to add an element, e.g. a JSON object [RFC8259] or a pre-encoded 186 CBOR string to RAs sent on a given interface or to DHCP messages sent 187 to a client. 189 On the host side, an API should be available allowing applications to 190 subscribe to received configuration elements. It should be possible 191 to subscribe to configuration object by dictionary key. 193 The contents of any elements that are not recognized, either in whole 194 or in part, by the receiving host MUST be ignored and the remainder 195 of option's contents processed as normal. 197 6. Implementation Status 199 The Universal IPv6 configuration option sending side is implemented 200 in VPP (https://wiki.fd.io/view/VPP). 202 The implementation is a prototype released under Apache license and 203 available at: https://github.com/vpp-dev/vpp/ 204 commit/156db316565e77de30890f6e9b2630bd97b0d61d. 206 7. Security Considerations 208 Unless there is a security relationship between the host and the 209 router (e.g. SEND), and even then, the consumer of configuration 210 information can put no trust in the information received. 212 8. IANA Considerations 214 IANA is requested to add a new registry for the Universal IPv6 215 Configuration option. The registry should be named "IPv6 ND RA 216 Universal option (experimental)". Changes and additions to the 217 registry require expert review [RFC8126]. 219 The schema field follows the CDDL schema definition in [RFC8610]. 221 The IANA is requested to add the universal option to the "IPv6 222 Neighbor Discovery Option Formats" registry with the value of 42. 224 The IANA is requested to add the universal option to the "Dynamic 225 Host Configuration Protocol for IPv6 (DHCPv6) Option Codes" registry. 227 8.1. Initial objects in the registry 229 The PVD [I-D.ietf-intarea-provisioning-domains] elements (and PIO, 230 RIO [RFC4191]) are included to provide an alternative representation 231 for the proposed new options in that draft. 233 +-------------------------------------------------+-----------+ 234 | CDDL Description | Reference | 235 +---------------+---------------------------------+-----------+ 236 | ietf = { | | 237 | ? dns : dns | | 238 | ? nat64: nat64 | | 239 | ? ipv6-only: bool | | 240 | ? pvd : pvd | | 241 | ? mtu : uint .size 4 | | 242 | ? rio : rio | | 243 | } | | 244 | | | 245 | pio = { | [RFC4861] | 246 | prefix : tstr | | 247 | ? preferred-lifetime : uint | | 248 | ? valid-lifetime : uint | | 249 | ? a-flag : bool | | 250 | ? l-flag : bool | | 251 | } | | 252 | | | 253 | rio_route = { | [RFC4191] | 254 | prefix : tstr | | 255 | ? preference : (0..3) | | 256 | ? lifetime : uint | | 257 | ? mtu : uint .size 4 | [this] | 258 | ? nexthop: tstr | | 259 | } | | 260 | rio = { | | 261 | routes : [+ rio_route] | | 262 | } | | 263 | | | 264 | dns = { | [RFC8106] | 265 | dnssl : [* tstr] | | 266 | rdnss : ipv6-addresses : [* tstr] | | 267 | ? lifetime : uint | | 268 | } | | 269 | | | 270 | nat64 = { | [RFC7050] | 271 | prefix : tstr | | 272 | } | | 273 | ipv6-only : bool | [v6only] | 274 | | | 275 | pvd = { | [pvd] | 276 | fqdn : tstr | | 277 | uri : tstr | | 278 | ? dns : dns | | 279 | ? nat64: nat64 | | 280 | ? pio : pio | | 281 | ? rio : rio | | 282 | } | | 283 +---------------+---------------------------------+-----------+ 285 Figure 3 287 9. References 289 [I-D.ietf-intarea-provisioning-domains] 290 Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 291 Shao, "Discovering Provisioning Domain Names and Data", 292 Work in Progress, Internet-Draft, draft-ietf-intarea- 293 provisioning-domains-11, 31 January 2020, 294 . 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 303 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 304 November 2005, . 306 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 307 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 308 DOI 10.17487/RFC4861, September 2007, 309 . 311 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 312 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 313 October 2013, . 315 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 316 Writing an IANA Considerations Section in RFCs", BCP 26, 317 RFC 8126, DOI 10.17487/RFC8126, June 2017, 318 . 320 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 321 Interchange Format", STD 90, RFC 8259, 322 DOI 10.17487/RFC8259, December 2017, 323 . 325 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 326 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 327 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 328 RFC 8415, DOI 10.17487/RFC8415, November 2018, 329 . 331 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 332 Definition Language (CDDL): A Notational Convention to 333 Express Concise Binary Object Representation (CBOR) and 334 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 335 June 2019, . 337 Author's Address 339 Ole Troan 340 cisco 341 Philip Pedersens vei 1 342 1366 Lysaker 343 Norway 345 Email: ot@cisco.com