idnits 2.17.1 draft-troan-6man-universal-ra-option-03.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 (6 October 2020) is 1296 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 261, but not defined == Missing Reference: 'RFC7050' is mentioned on line 267, 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 O. Troan 3 Internet-Draft cisco 4 Intended status: Standards Track 6 October 2020 5 Expires: 9 April 2021 7 The Universal IPv6 Configuration Option 8 draft-troan-6man-universal-ra-option-03 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 9 April 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 6 63 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 64 10. Informative References . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 This document proposes a new universal option for the Router 70 Advertisement IPv6 ND message [RFC4861] and DHCPv6 [RFC8415]. Its 71 purpose is to use the RA and DHCP messages as opaque carriers for 72 configuration information between an agent on a router or DHCP server 73 and host / host application. 75 DHCP is suited to give per-client configuration information, while 76 the RA mechanism advertises configuration information to all hosts on 77 the link. There is a long running history of "conflict" between the 78 two. The arguments go; there is less fate-sharing in DHCP, DHCP 79 doesn't deal with multiple sources of information, or make it more 80 difficult to change information independent of the lifetimes, RA 81 cannot be used to configure different information to different 82 clients and so on. And of course some options are only available in 83 RAs and some options are only available in DHCP. 85 While this proposal does not resolve the DHCP vs RA debate, it 86 proposes a solution to the problem of a very slow process of 87 standardizing new options, and the IETF spending an inordinate amount 88 of time arguing over new configuration options. 90 2. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 97 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 98 WON'T)*" in this document are to interpreted as described in RFC 6919 99 [RFC6919]. 101 3. Introduction 103 This document specifies a new "self-describing" universal 104 configuration option. Currently new configuration option requires 105 "standards action". The proposal is that no IETF document is 106 required. The configuration option is described directly in the 107 universal configuration IANA registry. 109 4. The Universal IPv6 Configuration option 111 The option data is described using the schema language CDDL 112 [RFC8610], encoded in CBOR [RFC7049]. 114 0 1 2 3 115 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 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Type | Length | Data ... 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Figure 1: IPv6 Configuration Option Format 122 Fields: 124 Type: 42 for Universal IPv6 Configuration Option 126 Length: The length of the option (including the type and length 127 fields) in units of 8 octets. 129 Data: CBOR encoded data. 131 The Option is zero-padded to nearest 8-octet boundary. 133 Example: 135 { 136 "ietf": { 137 "dns": { 138 "dnssl": [ 139 "example.com" 140 ], 141 "rdnss": [ 142 "2001:db8::1", 143 "2001:db8::2" 144 ] 145 }, 146 "nat64": { 147 "prefix": "64:ff9b::/96" 148 } 149 "rio": { 150 "routes": [ 151 "rio_routes": { 152 "prefix": "::/0", 153 "next-hop": "fe80::1" 154 } 155 ] 156 } 157 } 158 } 160 The universal IPv6 Configuration option MUST be small enough to fit 161 within a single IPv6 ND or DHCPv6 packet. It then follows that a 162 single element in the dictionary cannot be larger than what fits 163 within a single option. Different elements can be split across 164 multiple universal configuration options (in separate packets). All 165 IANA registered elements are under the "ietf" key in the dictionary. 166 Private configuration information can be included in the option using 167 different keys. 169 If information learnt via this option conflicts with other 170 configuration information learnt via Router Advertisement messages or 171 via DHCP, that is considered a configuration error. How those 172 conflicts should be resolved is left up to the implementation. 174 5. Implementation Guidance 176 The purpose of this option is to allow users to use the RA or DHCP as 177 an opaque carrier for configuration information without requiring 178 code changes in the option carrying infrastructure. 180 On the router or DHCP server side there should be an API allowing a 181 user to add an element, e.g. a JSON object [RFC8259] or a pre-encoded 182 CBOR string to RAs sent on a given interface or to DHCP messages sent 183 to a client. 185 On the host side, an API SHOULD be available allowing applications to 186 subscribe to received configuration elements. It SHOULD be possible 187 to subscribe to configuration object by dictionary key. 189 The contents of any elements that are not recognized, either in whole 190 or in part, by the receiving host MUST be ignored and the remainder 191 of option's contents processed as normal. 193 6. Implementation Status 195 The Universal IPv6 configuration option sending side is implemented 196 in VPP (https://wiki.fd.io/view/VPP (https://wiki.fd.io/view/VPP)). 198 The implementation is a prototype released under Apache license and 199 available at: https://github.com/vpp-dev/vpp/ 200 commit/156db316565e77de30890f6e9b2630bd97b0d61d (https://github.com/ 201 vpp-dev/vpp/commit/156db316565e77de30890f6e9b2630bd97b0d61d). 203 7. Security Considerations 205 Unless there is a security relationship between the host and the 206 router (e.g. SEND), and even then, the consumer of configuration 207 information can put no trust in the information received. 209 8. IANA Considerations 211 IANA is requested to add a new registry for the Universal IPv6 212 Configuration option. The registry should be named "IPv6 Universal 213 Configuration Information Option". Changes and additions to the 214 registry require expert review [RFC8126]. 216 The schema field follows the CDDL schema definition in [RFC8610]. 218 The IANA is requested to add the universal option to the "IPv6 219 Neighbor Discovery Option Formats" registry with the value of 42. 221 The IANA is requested to add the universal option to the "Dynamic 222 Host Configuration Protocol for IPv6 (DHCPv6) Option Codes" registry. 224 8.1. Initial objects in the registry 226 The PVD [RFC8801] elements (and PIO, RIO [RFC4191]) are included to 227 provide an alternative representation for the proposed new options in 228 that draft. 230 +-------------------------------------------------+-----------+ 231 | CDDL Description | Reference | 232 +---------------+---------------------------------+-----------+ 233 | ietf = { | | 234 | ? dns : dns | | 235 | ? nat64: nat64 | | 236 | ? ipv6-only: bool | | 237 | ? pvd : pvd | | 238 | ? mtu : uint .size 4 | | 239 | ? rio : rio | | 240 | } | | 241 | | | 242 | pio = { | [RFC4861] | 243 | prefix : tstr | | 244 | ? preferred-lifetime : uint | | 245 | ? valid-lifetime : uint | | 246 | ? a-flag : bool | | 247 | ? l-flag : bool | | 248 | } | | 249 | | | 250 | rio_route = { | [RFC4191] | 251 | prefix : tstr | | 252 | ? preference : (0..3) | | 253 | ? lifetime : uint | | 254 | ? mtu : uint .size 4 | [this] | 255 | ? nexthop: tstr | | 256 | } | | 257 | rio = { | | 258 | routes : [+ rio_route] | | 259 | } | | 260 | | | 261 | dns = { | [RFC8106] | 262 | dnssl : [* tstr] | | 263 | rdnss : ipv6-addresses : [* tstr] | | 264 | ? lifetime : uint | | 265 | } | | 266 | | | 267 | nat64 = { | [RFC7050] | 268 | prefix : tstr | | 269 | } | | 270 | ipv6-only : bool | [v6only] | 271 | | | 272 | pvd = { | [pvd] | 273 | fqdn : tstr | | 274 | uri : tstr | | 275 | ? dns : dns | | 276 | ? nat64: nat64 | | 277 | ? pio : pio | | 278 | ? rio : rio | | 279 | } | | 280 +---------------+---------------------------------+-----------+ 282 9. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 290 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 291 DOI 10.17487/RFC6919, April 2013, 292 . 294 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 295 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 296 October 2013, . 298 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 299 Definition Language (CDDL): A Notational Convention to 300 Express Concise Binary Object Representation (CBOR) and 301 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 302 June 2019, . 304 10. Informative References 306 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 307 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 308 November 2005, . 310 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 311 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 312 DOI 10.17487/RFC4861, September 2007, 313 . 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 [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. 332 Shao, "Discovering Provisioning Domain Names and Data", 333 RFC 8801, DOI 10.17487/RFC8801, July 2020, 334 . 336 Author's Address 338 O. Troan 339 cisco 341 Email: ot@cisco.com