idnits 2.17.1 draft-troan-6man-universal-ra-option-06.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (22 October 2021) is 917 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 (~~), 3 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: 25 April 2022 cisco 6 22 October 2021 8 The Universal IPv6 Configuration Option 9 draft-troan-6man-universal-ra-option-06 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. This 18 document proposes a new universal option for RA in a self-describing 19 data format, with the list of elements maintained in an IANA 20 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 25 April 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 5 61 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Universal configuration option . . . . . . . . . . . . . 6 65 9.2. Initial objects in the registry . . . . . . . . . . . . . 6 66 9.3. Initial objects in the registry . . . . . . . . . . . . . 6 67 9.3.1. CDDL/JSON Mapping Parameters to CBOR . . . . . . . . 6 68 9.3.2. Key Registry . . . . . . . . . . . . . . . . . . . . 7 69 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 70 11. Informative References . . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 This document proposes a new universal option for the Router 77 Advertisement IPv6 ND message [RFC4861]. Its purpose is to use the 78 RA messages as opaque carriers for configuration information between 79 an agent on a router and a host. 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 Router Advertisement options, and the IETF spending 94 an inordinate amount of time arguing over new configuration options 95 in Router Advertisements. It is possible in the future to use the 96 new universal option in DHCP, since this would lead to additional 97 conflict resolution an additional document will need to be considered 98 for that. 100 2. Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 107 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 108 WON'T)*" in this document are to interpreted as described in RFC 6919 109 [RFC6919]. 111 3. Introduction 113 This document specifies a new "self-describing" universal 114 configuration option. Currently new configuration option requires 115 "standards action". The proposal is that no future IETF document 116 will be required. The configuration option is described directly in 117 the universal configuration IANA registry. 119 4. The Universal IPv6 Configuration option 121 The option data is described using the schema language CDDL 122 [RFC8610], encoded in CBOR [RFC7049]. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type | Length | Data ... 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 1: IPv6 Configuration Option Format 132 Fields: 134 Type: 42 for Universal IPv6 Configuration Option 136 Length: The length of the option (including the type and length 137 fields) in units of 8 octets. 139 Data: CBOR encoded data. 141 The Option is zero-padded to nearest 8-octet boundary. 143 Example of an JSON instance of the option: 145 { 146 "ietf": { 147 "dns": { 148 "dnssl": [ 149 "example.com" 150 ], 151 "rdnss": [ 152 "2001:db8::1", 153 "2001:db8::2" 154 ] 155 }, 156 "nat64": { 157 "prefix": "64:ff9b::/96" 158 }, 159 "rio": [ 160 { 161 "prefix": "::/0", 162 "next-hop": "fe80::1" 163 }, 164 { 165 "prefix": "2001:db8::/32", 166 "next-hop": "fe80::2" 167 } 168 ] 169 } 170 } 172 The universal IPv6 Configuration option MUST be small enough to fit 173 within a single IPv6 ND packet. It then follows that a single 174 element in the dictionary cannot be larger than what fits within a 175 single option. Different elements can be split across multiple 176 universal configuration options (in separate packets). All IANA 177 registered elements are under the "ietf" key in the dictionary. 178 Private configuration information can be included in the option using 179 different keys. 181 If information learnt via this option conflicts with other 182 configuration information learnt via Router Advertisement messages, 183 that is considered a configuration error. How those conflicts should 184 be resolved is left up to the implementation. 186 5. CBOR encoding 188 It is recommended that the user can configure the option using JSON. 189 Likewise an application registering interest in an option SHOULD be 190 able to use string keys. The CBOR encoding to save space, uses 191 integers for map keys. The mapping table between integer and string 192 map keys are part of the IANA registry for the option. 194 Values -23-23 encodes to a single byte in CBOR, and these values are 195 reserved for IETF used map keys. 197 6. Implementation Guidance 199 The purpose of this option is to allow users to use the RA as an 200 opaque carrier for configuration information without requiring code 201 changes in the option carrying infrastructure. 203 On the router there should be an API allowing a user to add an 204 element, e.g. a JSON object [RFC8259] or a pre-encoded CBOR string to 205 RAs sent on a given interface. 207 On the host side, an API SHOULD be available allowing applications to 208 subscribe to received configuration elements. It SHOULD be possible 209 to subscribe to configuration object by dictionary key. 211 The contents of any elements that are not recognized, either in whole 212 or in part, by the receiving host MUST be ignored and the remainder 213 of option's contents MUST be processed as normal. 215 An implementation SHOULD provide a "JSON interface" for configuring 216 the option. 218 7. Implementation Status 220 The Universal IPv6 configuration option sending side is implemented 221 in VPP (https://wiki.fd.io/view/VPP (https://wiki.fd.io/view/VPP)). 223 The implementation is a prototype released under Apache license and 224 available at: https://github.com/vpp-dev/vpp/ 225 commit/156db316565e77de30890f6e9b2630bd97b0d61d (https://github.com/ 226 vpp-dev/vpp/commit/156db316565e77de30890f6e9b2630bd97b0d61d). 228 8. Security Considerations 230 Unless there is a security relationship between the host and the 231 router (e.g. SEND), and even then, the consumer of configuration 232 information can put no trust in the information received. 234 9. IANA Considerations 236 IANA is requested to add a new registry for the Universal IPv6 237 Configuration option. The registry should be named "IPv6 Universal 238 Configuration Information Option". 240 The schema field follows the CDDL schema definition in [RFC8610]. 242 Changes and additions to the registry follow the policies below 243 [RFC8126]: 245 +============================+========================+ 246 | Range | Registration Procedure | 247 +============================+========================+ 248 | -23-23 | Standards Action | 249 +----------------------------+------------------------+ 250 | 24-32767 | Specification Required | 251 +----------------------------+------------------------+ 252 | 32768-18446744073709551615 | Expert Review | 253 +----------------------------+------------------------+ 255 Table 1 257 A new registration requires a new CBOR key to parameter name 258 assignment and a CDDL definition. 260 9.1. Universal configuration option 262 The IANA is requested to add the universal option to the "IPv6 263 Neighbor Discovery Option Formats" registry with the value of 42. 265 9.2. Initial objects in the registry 267 The PVD [RFC8801] elements and DNS [RFC8106]) are included to provide 268 an alternative representation for the proposed new options in that 269 draft. 271 9.3. Initial objects in the registry 273 9.3.1. CDDL/JSON Mapping Parameters to CBOR 275 +===========================+==========+ 276 | Parameter Name / JSON key | CBOR Key | 277 +===========================+==========+ 278 | ietf | -23 | 279 +---------------------------+----------+ 280 | pio | -22 | 281 +---------------------------+----------+ 282 | mtu | -21 | 283 +---------------------------+----------+ 284 | rio | -20 | 285 +---------------------------+----------+ 286 | dns | -19 | 287 +---------------------------+----------+ 288 | nat64 | -18 | 289 +---------------------------+----------+ 290 | ipv6-only | -17 | 291 +---------------------------+----------+ 292 | pvd | -16 | 293 +---------------------------+----------+ 294 | prefix | -15 | 295 +---------------------------+----------+ 296 | preferred-lifetime | -14 | 297 +---------------------------+----------+ 298 | valid-lifetime | -13 | 299 +---------------------------+----------+ 300 | lifetime | -12 | 301 +---------------------------+----------+ 302 | a-flag | -11 | 303 +---------------------------+----------+ 304 | l-flag | -10 | 305 +---------------------------+----------+ 306 | preference | -9 | 307 +---------------------------+----------+ 308 | nexthop | -8 | 309 +---------------------------+----------+ 310 | nssl | -7 | 311 +---------------------------+----------+ 312 | dnss | -6 | 313 +---------------------------+----------+ 314 | fqdn | -5 | 315 +---------------------------+----------+ 316 | uri | -4 | 317 +---------------------------+----------+ 319 Table 2 321 9.3.2. Key Registry 322 +------------------------------------------------+-----------+ 323 |CDDL | Reference | 324 +------------------------------------------------+-----------+ 325 |ietf = { | | 326 | ? pio : [+ pio] | | 327 | ? rio : [+ rio] | | 328 | ? dns : dns | | 329 | ? nat64: nat64 | | 330 | ? ipv6-only: bool | | 331 | ? pvd : pvd | | 332 |} | | 333 | | | 334 | | | 335 |dns = { | RFC8106 | 336 | nssl : [* tstr] | | 337 | dnss : [+ ipv6-address] | | 338 | lifetime : uint .size 4 | | 339 |} | | 340 | | | 341 |nat64 = { | RFC7050 | 342 | prefix : ipv6-prefix | | 343 |} | | 344 |ipv6-only : bool | [v6only] | 345 | | | 346 |pvd = { | | 347 | fqdn : tstr | | 348 | uri : tstr | | 349 | ? dns : dns | | 350 | ? nat64: nat64 | | 351 | ? pio : [+ pio] | | 352 | ? rio : [+ rio] | | 353 |} | | 354 +------------------------------------------------+-----------+ 356 10. Normative References 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 364 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 365 DOI 10.17487/RFC4861, September 2007, 366 . 368 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 369 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 370 DOI 10.17487/RFC6919, April 2013, 371 . 373 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 374 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 375 October 2013, . 377 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 378 Definition Language (CDDL): A Notational Convention to 379 Express Concise Binary Object Representation (CBOR) and 380 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 381 June 2019, . 383 11. Informative References 385 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 386 "IPv6 Router Advertisement Options for DNS Configuration", 387 RFC 8106, DOI 10.17487/RFC8106, March 2017, 388 . 390 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 391 Writing an IANA Considerations Section in RFCs", BCP 26, 392 RFC 8126, DOI 10.17487/RFC8126, June 2017, 393 . 395 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 396 Interchange Format", STD 90, RFC 8259, 397 DOI 10.17487/RFC8259, December 2017, 398 . 400 [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. 401 Shao, "Discovering Provisioning Domain Names and Data", 402 RFC 8801, DOI 10.17487/RFC8801, July 2020, 403 . 405 Appendix A. Acknowledgements 407 Many thanks to Dave Thaler for feedback and suggestions of a more 408 effective CBOR encoding. Thank you very much to Carsten Bormann for 409 CBOR and CDDL help. 411 Authors' Addresses 413 T. Winters 414 QA Cafe 415 Email: tim@qacafe.com 417 O. Troan 418 cisco 420 Email: ot@cisco.com