idnits 2.17.1 draft-troan-6man-universal-ra-option-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (12 July 2021) is 1018 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) ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Winters 3 Internet-Draft QA Cafe 4 Intended status: Standards Track O. Troan 5 Expires: 13 January 2022 cisco 6 12 July 2021 8 The Universal IPv6 Configuration Option 9 draft-troan-6man-universal-ra-option-05 11 Abstract 13 One of the original intentions for the IPv6 host configuration, was 14 to configure the network-layer parameters only with IPv6 ND, and use 15 service discovery for other configuration information. Unfortunately 16 that hasn't panned out quite as planned, and we are in a situation 17 where all kinds of configuration options are added to RAs and DHCP. 18 This document proposes a new universal option for RA and DHCP in a 19 self-describing data format, with the list of elements maintained in 20 an IANA registry, with greatly relaxed rules for registration. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 13 January 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. The Universal IPv6 Configuration option . . . . . . . . . . . 3 59 5. CBOR encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 5 61 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 9.1. Universal configuration option . . . . . . . . . . . . . 6 65 9.2. Initial objects in the registry . . . . . . . . . . . . . 6 66 9.2.1. CDDL/JSON Mapping Parameters to CBOR . . . . . . . . 6 67 9.2.2. Key Registry . . . . . . . . . . . . . . . . . . . . 7 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 69 11. Informative References . . . . . . . . . . . . . . . . . . . 9 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 This document proposes a new universal option for the Router 76 Advertisement IPv6 ND message [RFC4861] and DHCPv6 [RFC8415]. Its 77 purpose is to use the RA and DHCP messages as opaque carriers for 78 configuration information between an agent on a router or DHCP server 79 and host / host application. 81 DHCP is suited to give per-client configuration information, while 82 the RA mechanism advertises configuration information to all hosts on 83 the link. There is a long running history of "conflict" between the 84 two. The arguments go; there is less fate-sharing in DHCP, DHCP 85 doesn't deal with multiple sources of information, or make it more 86 difficult to change information independent of the lifetimes, RA 87 cannot be used to configure different information to different 88 clients and so on. And of course some options are only available in 89 RAs and some options are only available in DHCP. 91 While this proposal does not resolve the DHCP vs RA debate, it 92 proposes a solution to the problem of a very slow process of 93 standardizing new options, and the IETF spending an inordinate amount 94 of time arguing over new configuration options. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 103 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 104 WON'T)*" in this document are to interpreted as described in RFC 6919 105 [RFC6919]. 107 3. Introduction 109 This document specifies a new "self-describing" universal 110 configuration option. Currently new configuration option requires 111 "standards action". The proposal is that no future IETF document 112 will be required. The configuration option is described directly in 113 the universal configuration IANA registry. 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: 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 The Option is zero-padded to nearest 8-octet boundary. 139 Example of an JSON instance of the option: 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 { 157 "prefix": "::/0", 158 "next-hop": "fe80::1" 159 }, 160 { 161 "prefix": "2001:db8::/32", 162 "next-hop": "fe80::2" 163 } 164 ] 165 } 166 } 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 packets). All 173 IANA registered elements are under the "ietf" key in the dictionary. 174 Private configuration information can be included in the option using 175 different keys. 177 If information learnt via this option conflicts with other 178 configuration information learnt via Router Advertisement messages or 179 via DHCPv6, that is considered a configuration error. How those 180 conflicts should be resolved is left up to the implementation. 182 5. CBOR encoding 184 It is recommended that the user can configure the option using JSON. 185 Likewise an application registering interest in an option SHOULD be 186 able to use string keys. The CBOR encoding to save space, uses 187 integers for map keys. The mapping table between integer and string 188 map keys are part of the IANA registry for the option. 190 Values -23-23 encodes to a single byte in CBOR, and these values are 191 reserved for IETF used map keys. 193 6. Implementation Guidance 195 The purpose of this option is to allow users to use the RA or DHCPv6 196 as an opaque carrier for configuration information without requiring 197 code changes in the option carrying infrastructure. 199 On the router or DHCPv6 server side there should be an API allowing a 200 user to add an element, e.g. a JSON object [RFC8259] or a pre-encoded 201 CBOR string to RAs sent on a given interface or to DHCPv6 messages 202 sent to a client. 204 On the host side, an API SHOULD be available allowing applications to 205 subscribe to received configuration elements. It SHOULD be possible 206 to subscribe to configuration object by dictionary key. 208 The contents of any elements that are not recognized, either in whole 209 or in part, by the receiving host MUST be ignored and the remainder 210 of option's contents MUST be processed as normal. 212 An implementation SHOULD provide a "JSON interface" for configuring 213 the option. 215 7. Implementation Status 217 The Universal IPv6 configuration option sending side is implemented 218 in VPP (https://wiki.fd.io/view/VPP (https://wiki.fd.io/view/VPP)). 220 The implementation is a prototype released under Apache license and 221 available at: https://github.com/vpp-dev/vpp/ 222 commit/156db316565e77de30890f6e9b2630bd97b0d61d (https://github.com/ 223 vpp-dev/vpp/commit/156db316565e77de30890f6e9b2630bd97b0d61d). 225 8. Security Considerations 227 Unless there is a security relationship between the host and the 228 router (e.g. SEND), and even then, the consumer of configuration 229 information can put no trust in the information received. 231 9. IANA Considerations 233 IANA is requested to add a new registry for the Universal IPv6 234 Configuration option. The registry should be named "IPv6 Universal 235 Configuration Information Option". 237 The schema field follows the CDDL schema definition in [RFC8610]. 239 Changes and additions to the registry follow the policies below 240 [RFC8126]: 242 +============================+========================+ 243 | Range | Registration Procedure | 244 +============================+========================+ 245 | -23-23 | Standards Action | 246 +----------------------------+------------------------+ 247 | 24-32767 | Specification Required | 248 +----------------------------+------------------------+ 249 | 32768-18446744073709551615 | Expert Review | 250 +----------------------------+------------------------+ 252 Table 1 254 A new registration requires a new CBOR key to parameter name 255 assignment and a CDDL definition. 257 9.1. Universal configuration option 259 The IANA is requested to add the universal option to the "IPv6 260 Neighbor Discovery Option Formats" registry with the value of 42. 262 The IANA is requested to add the universal option to the "Dynamic 263 Host Configuration Protocol for IPv6 (DHCPv6) Option Codes" registry. 265 9.2. Initial objects in the registry 267 9.2.1. CDDL/JSON Mapping Parameters to CBOR 269 +===========================+==========+ 270 | Parameter Name / JSON key | CBOR Key | 271 +===========================+==========+ 272 | ietf | -23 | 273 +---------------------------+----------+ 274 | pio | -22 | 275 +---------------------------+----------+ 276 | mtu | -21 | 277 +---------------------------+----------+ 278 | rio | -20 | 279 +---------------------------+----------+ 280 | dns | -19 | 281 +---------------------------+----------+ 282 | nat64 | -18 | 283 +---------------------------+----------+ 284 | ipv6-only | -17 | 285 +---------------------------+----------+ 286 | pvd | -16 | 287 +---------------------------+----------+ 288 | prefix | -15 | 289 +---------------------------+----------+ 290 | preferred-lifetime | -14 | 291 +---------------------------+----------+ 292 | valid-lifetime | -13 | 293 +---------------------------+----------+ 294 | lifetime | -12 | 295 +---------------------------+----------+ 296 | a-flag | -11 | 297 +---------------------------+----------+ 298 | l-flag | -10 | 299 +---------------------------+----------+ 300 | preference | -9 | 301 +---------------------------+----------+ 302 | nexthop | -8 | 303 +---------------------------+----------+ 304 | nssl | -7 | 305 +---------------------------+----------+ 306 | dnss | -6 | 307 +---------------------------+----------+ 308 | fqdn | -5 | 309 +---------------------------+----------+ 310 | uri | -4 | 311 +---------------------------+----------+ 313 Table 2 315 9.2.2. Key Registry 317 +------------------------------------------------+-----------+ 318 |CDDL | Reference | 319 +------------------------------------------------+-----------+ 320 |ietf = { | | 321 | ? pio : [+ pio] | | 322 | ? mtu : (0..65535) | | 323 | ? rio : [+ rio] | | 324 | ? dns : dns | | 325 | ? nat64: nat64 | | 326 | ? ipv6-only: bool | | 327 | ? pvd : pvd | | 328 |} | | 329 | | | 330 |pio = { | RFC4861 | 331 | prefix : ipv6-prefix | | 332 | ? preferred-lifetime : uint .size 4 | | 333 | ? valid-lifetime : uint .size 4 | | 334 | ? a-flag : bool | | 335 | ? l-flag : bool | | 336 |} | | 337 | | | 338 |rio = { | RFC4191 | 339 | prefix : ipv6-prefix | | 340 | ? preference : (0..3) | | 341 | ? lifetime : uint .size 4 | | 342 | ? mtu : (0..65535) | | 343 | ? nexthop: ipv6-address | | 344 |} | | 345 | | | 346 |dns = { | RFC8106 | 347 | nssl : [* tstr] | | 348 | dnss : [+ ipv6-address] | | 349 | lifetime : uint .size 4 | | 350 |} | | 351 | | | 352 |nat64 = { | RFC7050 | 353 | prefix : ipv6-prefix | | 354 |} | | 355 | | | 356 |pvd = { | | 357 | fqdn : tstr | | 358 | uri : tstr | | 359 | ? dns : dns | | 360 | ? nat64: nat64 | | 361 | ? pio : [+ pio] | | 362 | ? rio : [+ rio] | | 363 |} | | 364 |ipv6-prefix = #6.261(bstr) | | 365 |ipv6-address = #6.260(bstr) | | 366 +------------------------------------------------+-----------+ 368 10. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 376 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 377 DOI 10.17487/RFC4861, September 2007, 378 . 380 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 381 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 382 DOI 10.17487/RFC6919, April 2013, 383 . 385 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 386 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 387 October 2013, . 389 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 390 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 391 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 392 RFC 8415, DOI 10.17487/RFC8415, November 2018, 393 . 395 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 396 Definition Language (CDDL): A Notational Convention to 397 Express Concise Binary Object Representation (CBOR) and 398 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 399 June 2019, . 401 11. Informative References 403 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 404 Writing an IANA Considerations Section in RFCs", BCP 26, 405 RFC 8126, DOI 10.17487/RFC8126, June 2017, 406 . 408 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 409 Interchange Format", STD 90, RFC 8259, 410 DOI 10.17487/RFC8259, December 2017, 411 . 413 Appendix A. Acknowledgements 415 Many thanks to Dave Thaler for feedback and suggestions of a more 416 effective CBOR encoding. Thank you very much to Carsten Bormann for 417 CBOR and CDDL help. 419 Authors' Addresses 421 T. Winters 422 QA Cafe 424 Email: tim@qacafe.com 425 O. Troan 426 cisco 428 Email: ot@cisco.com