idnits 2.17.1 draft-troan-6man-universal-ra-option-04.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 (2 November 2020) is 1264 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 262, but not defined == Missing Reference: 'RFC7050' is mentioned on line 268, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 5 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: 6 May 2021 cisco 6 2 November 2020 8 The Universal IPv6 Configuration Option 9 draft-troan-6man-universal-ra-option-04 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 6 May 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. The Universal IPv6 Configuration option . . . . . . . . . . . 3 59 5. Implementation Guidance . . . . . . . . . . . . . . . . . . . 4 60 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 8.1. Initial objects in the registry . . . . . . . . . . . . . 6 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 10. Informative References . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 This document proposes a new universal option for the Router 71 Advertisement IPv6 ND message [RFC4861] and DHCPv6 [RFC8415]. Its 72 purpose is to use the RA and DHCP messages as opaque carriers for 73 configuration information between an agent on a router or DHCP server 74 and host / host application. 76 DHCP is suited to give per-client configuration information, while 77 the RA mechanism advertises configuration information to all hosts on 78 the link. There is a long running history of "conflict" between the 79 two. The arguments go; there is less fate-sharing in DHCP, DHCP 80 doesn't deal with multiple sources of information, or make it more 81 difficult to change information independent of the lifetimes, RA 82 cannot be used to configure different information to different 83 clients and so on. And of course some options are only available in 84 RAs and some options are only available in DHCP. 86 While this proposal does not resolve the DHCP vs RA debate, it 87 proposes a solution to the problem of a very slow process of 88 standardizing new options, and the IETF spending an inordinate amount 89 of time arguing over new configuration options. 91 2. Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 98 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 99 WON'T)*" in this document are to interpreted as described in RFC 6919 100 [RFC6919]. 102 3. Introduction 104 This document specifies a new "self-describing" universal 105 configuration option. Currently new configuration option requires 106 "standards action". The proposal is that no future IETF document 107 will be required. The configuration option is described directly in 108 the universal configuration IANA registry. 110 4. The Universal IPv6 Configuration option 112 The option data is described using the schema language CDDL 113 [RFC8610], encoded in CBOR [RFC7049]. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Type | Length | Data ... 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Figure 1: IPv6 Configuration Option Format 123 Fields: 125 Type: 42 for Universal IPv6 Configuration Option 127 Length: The length of the option (including the type and length 128 fields) in units of 8 octets. 130 Data: CBOR encoded data. 132 The Option is zero-padded to nearest 8-octet boundary. 134 Example: 136 { 137 "ietf": { 138 "dns": { 139 "dnssl": [ 140 "example.com" 141 ], 142 "rdnss": [ 143 "2001:db8::1", 144 "2001:db8::2" 145 ] 146 }, 147 "nat64": { 148 "prefix": "64:ff9b::/96" 149 } 150 "rio": { 151 "routes": [ 152 "rio_routes": { 153 "prefix": "::/0", 154 "next-hop": "fe80::1" 155 } 156 ] 157 } 158 } 159 } 161 The universal IPv6 Configuration option MUST be small enough to fit 162 within a single IPv6 ND or DHCPv6 packet. It then follows that a 163 single element in the dictionary cannot be larger than what fits 164 within a single option. Different elements can be split across 165 multiple universal configuration options (in separate packets). All 166 IANA registered elements are under the "ietf" key in the dictionary. 167 Private configuration information can be included in the option using 168 different keys. 170 If information learnt via this option conflicts with other 171 configuration information learnt via Router Advertisement messages or 172 via DHCPv6, that is considered a configuration error. How those 173 conflicts should be resolved is left up to the implementation. 175 5. Implementation Guidance 177 The purpose of this option is to allow users to use the RA or DHCPv6 178 as an opaque carrier for configuration information without requiring 179 code changes in the option carrying infrastructure. 181 On the router or DHCPv6 server side there should be an API allowing a 182 user to add an element, e.g. a JSON object [RFC8259] or a pre-encoded 183 CBOR string to RAs sent on a given interface or to DHCPv6 messages 184 sent to a client. 186 On the host side, an API SHOULD be available allowing applications to 187 subscribe to received configuration elements. It SHOULD be possible 188 to subscribe to configuration object by dictionary key. 190 The contents of any elements that are not recognized, either in whole 191 or in part, by the receiving host MUST be ignored and the remainder 192 of option's contents MUST be processed as normal. 194 6. Implementation Status 196 The Universal IPv6 configuration option sending side is implemented 197 in VPP (https://wiki.fd.io/view/VPP (https://wiki.fd.io/view/VPP)). 199 The implementation is a prototype released under Apache license and 200 available at: https://github.com/vpp-dev/vpp/ 201 commit/156db316565e77de30890f6e9b2630bd97b0d61d (https://github.com/ 202 vpp-dev/vpp/commit/156db316565e77de30890f6e9b2630bd97b0d61d). 204 7. Security Considerations 206 Unless there is a security relationship between the host and the 207 router (e.g. SEND), and even then, the consumer of configuration 208 information can put no trust in the information received. 210 8. IANA Considerations 212 IANA is requested to add a new registry for the Universal IPv6 213 Configuration option. The registry should be named "IPv6 Universal 214 Configuration Information Option". Changes and additions to the 215 registry require expert review [RFC8126]. 217 The schema field follows the CDDL schema definition in [RFC8610]. 219 The IANA is requested to add the universal option to the "IPv6 220 Neighbor Discovery Option Formats" registry with the value of 42. 222 The IANA is requested to add the universal option to the "Dynamic 223 Host Configuration Protocol for IPv6 (DHCPv6) Option Codes" registry. 225 8.1. Initial objects in the registry 227 The PVD [RFC8801] elements (and PIO, RIO [RFC4191]) are included to 228 provide an alternative representation for the proposed new options in 229 that draft. 231 +-------------------------------------------------+-----------+ 232 | CDDL Description | Reference | 233 +---------------+---------------------------------+-----------+ 234 | ietf = { | | 235 | ? dns : dns | | 236 | ? nat64: nat64 | | 237 | ? ipv6-only: bool | | 238 | ? pvd : pvd | | 239 | ? mtu : uint .size 4 | | 240 | ? rio : rio | | 241 | } | | 242 | | | 243 | pio = { | [RFC4861] | 244 | prefix : tstr | | 245 | ? preferred-lifetime : uint | | 246 | ? valid-lifetime : uint | | 247 | ? a-flag : bool | | 248 | ? l-flag : bool | | 249 | } | | 250 | | | 251 | rio_route = { | [RFC4191] | 252 | prefix : tstr | | 253 | ? preference : (0..3) | | 254 | ? lifetime : uint | | 255 | ? mtu : uint .size 4 | [this] | 256 | ? nexthop: tstr | | 257 | } | | 258 | rio = { | | 259 | routes : [+ rio_route] | | 260 | } | | 261 | | | 262 | dns = { | [RFC8106] | 263 | dnssl : [* tstr] | | 264 | rdnss : ipv6-addresses : [* tstr] | | 265 | ? lifetime : uint | | 266 | } | | 267 | | | 268 | nat64 = { | [RFC7050] | 269 | prefix : tstr | | 270 | } | | 271 | ipv6-only : bool | [v6only] | 272 | | | 273 | pvd = { | [pvd] | 274 | fqdn : tstr | | 275 | uri : tstr | | 276 | ? dns : dns | | 277 | ? nat64: nat64 | | 278 | ? pio : pio | | 279 | ? rio : rio | | 280 | } | | 281 +---------------+---------------------------------+-----------+ 283 9. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 291 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 292 DOI 10.17487/RFC4861, September 2007, 293 . 295 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 296 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 297 DOI 10.17487/RFC6919, April 2013, 298 . 300 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 301 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 302 October 2013, . 304 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 305 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 306 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 307 RFC 8415, DOI 10.17487/RFC8415, November 2018, 308 . 310 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 311 Definition Language (CDDL): A Notational Convention to 312 Express Concise Binary Object Representation (CBOR) and 313 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 314 June 2019, . 316 10. Informative References 318 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 319 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 320 November 2005, . 322 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 323 Writing an IANA Considerations Section in RFCs", BCP 26, 324 RFC 8126, DOI 10.17487/RFC8126, June 2017, 325 . 327 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 328 Interchange Format", STD 90, RFC 8259, 329 DOI 10.17487/RFC8259, December 2017, 330 . 332 [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. 333 Shao, "Discovering Provisioning Domain Names and Data", 334 RFC 8801, DOI 10.17487/RFC8801, July 2020, 335 . 337 Authors' Addresses 339 T. Winters 340 QA Cafe 342 Email: tim@qacafe.com 344 O. Troan 345 cisco 347 Email: ot@cisco.com