idnits 2.17.1 draft-luo-6man-ipv6-ra-prefix-flag-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 : ---------------------------------------------------------------------------- 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 date (June 30, 2019) is 1755 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) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group(6man) Lin Luo 3 Internet-Draft H3C Corporation 4 Intended status: Standards Track Qianli Zhang 5 Expires: December 30, 2019 Tsinghua University 6 HaiHong Zhang 7 H3C Corporation 8 June 30, 2019 10 Enhanced IPv6 Stateless Address autoconfiguration 11 draft-luo-6man-ipv6-ra-prefix-flag-00 13 Abstract 15 This document specifies new flag in the format of a Prefix 16 Information Option, IPv6 routers advertise the address refresh 17 capability and address generation mechanism to IPv6 hosts. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 20, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Specification of Requirements . . . . . . . . . . . . . . . . 2 52 3. Algorithm Specification . . . . . . . . . . . . . . . . . . . 3 53 3.1. Prefix Information Option . . . . . . . . . . . . . . . . 3 54 3.2. Router processing . . . . . . . . . . . . . . . . . . . 4 55 3.3. Host processing . . . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 The IPv6 Neighbor Discovery (ND) Protocol [RFC4861] specifies router 64 advertisement message contains Prefix Information Option, [RFC4862] 65 specifies Stateless Address Autoconfiguration (SLAAC), On the other 66 hand, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415] 67 is used when a site requires tighter control over exact address 68 assignments. 70 IPv6 hosts generate addresses composed of prefix advertised by 71 router, an Interface Identifier(IID) in [RFC4291] typically embeds 72 the link-layer address. In [RFC4941], the concept of a temporary 73 address is proposed for privacy concerns, the host randomly generates 74 a temporary identification and the temporary address is regenerated 75 on a periodic basis. [RFC6724] recommends the host needs to prefer 76 the temporary address above the public address. Various new forms of 77 IIDs have been defined, including Cryptographically Generated 78 Addresses (CGAs) [RFC4982] of Secure Neighbor Discovery (SEND) 79 [RFC3971] and others. 81 The security and privacy implications of different IPv6 IIDs are 82 discussed, and [RFC8064] recommends semantically opaque address as 83 the default scheme for generating IPv6 stable addresses with SLAAC. 84 Otherwise, the mechanism of temporary address generation and address 85 selection are widely used by most operating systems. 87 This document specifies a new flag in the format of a Prefix 88 Information Option, IPv6 routers advertise the address refresh 89 capability and address generation mechanism to IPv6 hosts. Despite 90 hosts choose any IIDs generation forms, according to address refresh 91 capability, it is easy to perform extending lifetime of temporary 92 address and public address. [RFC7136] specifies IIDs MUST be viewed 93 as an opaque bit string by third parties, except in the local 94 context, the address generation flag provides a mechanism in 95 different kinds of application scenarios, such as authorized network 96 and location service network. 98 2. Specification of Requirements 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Algorithm Specification 106 In a local context, when hosts need authentication to access the 107 network, most routers offer the capability of flow monitoring and 108 quality of service based on host IPv6 address, stable address is 109 required here. Instead of letting host freely generate an address, it 110 is better to specify that the address time is forced to refresh. 111 Furthermore, routers can choose the address generation mechanism to 112 advertise, including CGA, stable and semantically opaque address, 113 address based on location. 115 3.1. Prefix Information Option 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Type | Length | Prefix Length |L|A|R|T|Mode|Res| 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Valid Lifetime | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Preferred Lifetime | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Reserved2 | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | | 128 + + 129 | | 130 + Prefix + 131 | | 132 + + 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 This format represents the following changes over that originally 137 specified for Neighbor Discovery [RFC4861] [RFC6275]: 139 T 1-bit address time refresh flag. When set, 140 indicates that the address generated by this prefix 141 must be refreshed. 143 Mode 3-bit unsigned integer indicating the address 144 generation mode, the follow mode values are 145 currently defined: 147 0 default addresses mode 148 1 [RFC7217] stable,opaque addresses mode 149 2 [RFC3972] CGA mode 151 Reserved1 Reduced from a 5-bit field to a 1-bit field to 152 account for the addition of the above bit. 154 3.2. Router Specification 156 A router sends Router Advertisement messages periodically or in response 157 to Router Solicitation. Prefix information Option specifies prefix and 158 corresponding flags which is used for stateless address 159 autoconfiguration. In each prefix information option: 161 a) If the router does not specify the address refresh flag and 162 generation mode , it must be set to 0. 164 b) If the Autonomous flag is set to 0, the address refresh flag and 165 generation mode should be set to 0. 167 c) According to the network configuration, the address refresh flag or 168 generation mode should be set to an appropriate value. 170 3.3. Host Specification 172 Upon receipt of a valid Router Advertisement message: 174 a) If the Autonomous flag is set to 0, the address refresh flag and 175 address generation mode should be silently ignored. 177 b) If the prefix is link-local prefix, the address refresh flag and 178 address generation mode should be silently ignored. 180 c) If the Prefix Information Option is valid to generate address: 182 1) The host must expand the time of address when the address 183 refresh flag is set to 1. 185 2) The generate mode should be ignored if the host does not 186 support. 188 3) The generation mode flag is set to 0, the address is generated 189 by default. 191 4) Host should generate address as the mode described. 193 4. Security Considerations 195 This document specifies a new flag in the format of a Prefix 196 Information Option, IPv6 routers to advertise the address refresh 197 capability and address generation mechanism to IPv6 hosts. The 198 inclusion of additional bit fields provides extend information of 199 network, it shares the security issues of NDP that are documented in 200 [RFC4861]. It recommends the existed scheme for generating IPv6 201 address with SLAAC, such that the security and privacy issues of IIDs 202 are mitigated. 204 5. IANA Considerations 206 This document does not include an IANA request. 208 6. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, March 1997. 212 . 214 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 215 Neighbor Discovery (SEND)", RFC 3971, March 2005. 216 . 218 [RFC3972] Aura, T., "Cryptographically Generated Addresses 219 (CGA)",RFC 3972, March 2005. 220 . 222 [RFC4291] R. Hinden, S. Deering, "IP Version 6 Addressing 223 Architecture",RFC4291, DOI 10.17487/RFC4291, February 224 2006. . 226 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 227 "Neighbor Discovery for IP version 6 (IPv6)", RFC 228 4861,September 2007. 229 . 231 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 232 Address Autoconfiguration", RFC 4862, DOI 233 10.17487/RFC4862, September 2007. 234 . 236 [RFC4941] T. Narten, R. Draves, S. Krishnan, "Privacy Extensions for 237 Stateless Address Autoconfiguration in IPv6",RFC4941, DOI 238 10.17487/RFC4941, September 2007.. 241 [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash 242 Algorithms in Cryptographically Generated Addresses 243 (CGAs)",RFC4982, DOI 10.17487/RFC4982, July 2007. 244 . 246 [RFC6275] C. Perkins, D. Johnson, and J. Arkko, "Mobility Support in 247 IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011. 248 . 250 [RFC6724] D. Thaler, R. Draves, and A. Matsumoto, "Default Address 251 Selection for Internet Protocol Version 6 (IPv6)", 252 RFC6724, DOI 10.17487/RFC6724, September 2012. 253 . 259 [RFC7217] F. Gont, "A Method for Generating Semantically Opaque 260 Interface Identifiers with IPv6 Stateless Address 261 Autoconfiguration (SLAAC)",RFC7217, DOI 10.17487/RFC7217, 262 April 2014. . 264 [RFC8064] F. Gont, A. Cooper, D. Thaler, W. Liu, "Recommendation on 265 Stable IPv6 Interface Identifiers",RFC8064, DOI 266 10.17487/RFC8064, February 2017. . 269 [RFC8415] T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. 270 Richardson, S. Jiang, T. Lemon, T. Winters, "Dynamic Host 271 Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, 272 November 2018. . 274 Authors' Addresses 276 Lin Luo 277 H3c Corporation 278 Hangzhou, 279 P.R.China 281 Email: extrall@h3c.com 283 Haihong Zhang 284 H3c Corporation 285 Beijing, 286 P.R.China 288 Email: zhanghaihong.04355@h3c.com 290 Qianli Zhang 291 Tsinghua University 292 Beijing, 100086 293 P.R.China 295 EMail: zhang@cernet.edu.cn