idnits 2.17.1 draft-troan-6man-universal-ra-option-00.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 a Security Considerations section. ** 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 (December 17, 2018) is 1950 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC8106' is mentioned on line 159, but not defined == Missing Reference: 'RFC7050' is mentioned on line 176, but not defined == Unused Reference: 'RFC2119' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 200, but no explicit reference was found in the text == Unused Reference: 'RFC7049' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 209, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-handrews-json-schema-01 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 3 errors (**), 0 flaws (~~), 8 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 Systems 4 Intended status: Experimental December 17, 2018 5 Expires: June 20, 2019 7 The Universal IPv6 Router Advertisement Option (experiment) 8 draft-troan-6man-universal-ra-option-00 10 Abstract 12 The intentions for the IPv6 host configuration design, was to 13 configure the core network layer parameters with IPv6 ND, and use 14 service discovery for other configuration parameters. Unfortunately 15 that hasn't panned out as planned, and we are in a situation where 16 all kinds of configuration options are requested in RAs and in DHCP. 17 This document proposes an a new universal option, formatted in JSON. 18 The list of elements are maintained in an IANA registry, with greatly 19 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 June 20, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 The intentions for the IPv6 host configuration design, was to 56 configure the core network layer parameters with IPv6 ND, and use 57 service discovery for other configuration parameters. Unfortunately 58 that hasn't panned out as planned, and we are in a situation where 59 all kinds of configuration options are requested in RAs and in DHCP. 60 This document proposes an a new universal option, formatted in JSON. 61 The list of elements are maintained in an IANA registry, with greatly 62 relaxed rules for registration. 64 DHCP is suited to give per-client configuration information, while 65 the RA mechanism advertises configuration information to all hosts on 66 the link. There is a long running history of "conflict" between the 67 two. The arguments go; there is less fate-sharing in DHCP, DHCP 68 doesn't deal with multiple sources of information, or make it more 69 difficult to change information independent of the lifetimes, RA 70 cannot be used to configure different information to different 71 clients and son on. And of course some options are only available in 72 RAs and some options are only available in DHCP. 74 While this proposal does not resolve the DHCP vs RA debate, it 75 proposes an experimental solution to the problem of a very slow 76 process of standardizing new options, and the IETF spending an 77 inordinate amount of time arguing over new configuration options. 79 2. The Experiment 81 This document specifies a new "self-describing" universal RA option. 82 Currently any new configuration option requires "standards action". 83 The experiment is to find out what happens when change control is 84 relaxed. The proposal is that no document is required. The 85 configuration option is described directly in the universal RA IANA 86 registry. 88 Duration of experiment: 2 years. 90 How to evaluate success? How many new options have been defined. 91 Did expert review suffice to stop "harmful" options? Was any of the 92 options implemented and deployed? On a successful experiment, the 93 time limit of the registry will be removed and it's experimental 94 status will be removed. If the experiment is deamed a failure, then 95 the registry will be removed. 97 3. The Universal RA option 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Type | Length | JSON object 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 1: Universal RA Option Format 107 Fields: 109 Type 42 for Universal RA Option 111 Length The length of the option (including the type and length 112 fields) in units of 8 octets. 114 JSON object JSON [RFC8259] in ASCII space padded to nearest 8 octet 115 boundary. A JSON object with each option as JSON objects under 116 the main key "ietf". 118 Example: 120 { 121 "ietf": { 122 "dns": { 123 "dnssl": [ 124 "example.com" 125 ], 126 "lifetime": 86400, 127 "rdnss": [ 128 "2001:db8::1", 129 "2001:db8::2" 130 ] 131 }, 132 "nat64": { 133 "lifetime": 86400, 134 "prefix": "64:ff9b::/96" 135 } 136 } 137 } 139 Figure 2 141 4. IANA Considerations 143 IANA is requested to add a new registry for the Universal RA option. 144 The registry should be named "IPv6 ND RA Universal option 145 (experimental)". Changes and additions to the registry require 146 expert review. 148 The schema field follows the JSON schema definition in 149 [I-D.handrews-json-schema]. 151 The IANA is requested to add the universal option to the "IPv6 152 Neighbor Discovery Option Formats" registry with the value of 42. 154 4.1. Initial objects in the registry 156 +---------------+---------------------------------+-----------+ 157 | JSON key | Description | Reference | 158 +---------------+---------------------------------+-----------+ 159 | dns |"dns": { | [RFC8106] | 160 | | "dnssl": { | | 161 | | "items": { | | 162 | | "type": "domain-name"| | 163 | | }, | | 164 | | "type": "array" | | 165 | | }, | | 166 | | "lifetime": { | | 167 | | "type": "integer" | | 168 | | }, | | 169 | | "rdnss": { | | 170 | | "items": { | | 171 | | "type": "ipv6-address"| | 172 | | }, | | 173 | | "type": "array" | | 174 | | } | | 175 | |}, | | 176 | nat64 |"nat64": { | [RFC7050] | 177 | | "lifetime": { | | 178 | | "type": "integer" | | 179 | | }, | | 180 | | "prefix": { | | 181 | | "type": "ipv6-prefix" | | 182 | | } | | 183 | |} | | 184 +---------------+---------------------------------+-----------+ 186 Figure 3 188 5. References 190 [I-D.handrews-json-schema] 191 Wright, A. and H. Andrews, "JSON Schema: A Media Type for 192 Describing JSON Documents", draft-handrews-json-schema-01 193 (work in progress), March 2018. 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, 197 DOI 10.17487/RFC2119, March 1997, 198 . 200 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 201 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 202 DOI 10.17487/RFC4861, September 2007, 203 . 205 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 206 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 207 October 2013, . 209 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 210 Writing an IANA Considerations Section in RFCs", BCP 26, 211 RFC 8126, DOI 10.17487/RFC8126, June 2017, 212 . 214 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 215 Interchange Format", STD 90, RFC 8259, 216 DOI 10.17487/RFC8259, December 2017, 217 . 219 Author's Address 221 Ole Troan 222 Cisco Systems 223 Philip Pedersens vei 1 224 Lysaker 1366 225 Norway 227 Email: ot@cisco.com