idnits 2.17.1 draft-templin-6man-lla-type-02.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 (November 23, 2020) is 1250 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) == Outdated reference: A later version (-99) exists of draft-templin-6man-omni-interface-50 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft The Boeing Company 4 Intended status: Standards Track November 23, 2020 5 Expires: May 27, 2021 7 The IPv6 Link-Local Address Type Field 8 draft-templin-6man-lla-type-02 10 Abstract 12 IPv6 link-local addresses are formed from the prefix fe80::/10 which 13 is followed by 54 "zero" bits, then followed by a 64-bit Interface 14 Identifier. There are multiple methods for generating link-local 15 addresses, and multiple may be in use by nodes on the same link (and 16 sometimes even the same interface) at the same time. This document 17 defines an IPv6 link-local address "Type" field that identifies the 18 type of link-local address being used. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 27, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The IPv6 Link-Local Address Type Field . . . . . . . . . . . 3 57 4. LLA-Based Prefix Delegation (PD) . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 8.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 The IPv6 link-local address (LLA) prefix is defined in [RFC4291] as 69 the prefix fe80::/10 followed by 54 "zero" bits, then followed by a 70 64-bit interface identifier. There are multiple methods for 71 generating LLAs, and multiple may be in use on the same link (and 72 sometimes even the same interface) at the same time. 74 For example, [I-D.ietf-6man-rfc4941bis], [RFC7217], [RFC4291], 75 [RFC3972], [I-D.templin-6man-omni-interface] and possibly others 76 define diverse methods for generating interface identifiers for 77 constructing LLAs on a given interface. Administrative configuration 78 (e.g., manually setting the interface ID) is also an option available 79 to all interfaces. 81 IPv6 multi-addressing allows each interface to assign multiple IPv6 82 addresses, and even multiple IPv6 LLAs. On some interfaces, it may 83 even be the case that multiple LLAs of different types would be 84 configured at the same time. But, since the diverse methods for 85 generating interface identifiers are not coordinated with one 86 another, some interfaces may need a way to differentiate the types of 87 LLAs as well as to avoid collisions and duplication. 89 This document defines a Type field in the LLA prefix for 90 differentiating LLA construction types. The Type field also has a 91 companion Function field which can be used to perform Type-specific 92 functions such as Prefix Delegation (PD). 94 This document updates [RFC4291]. 96 2. Terminology 98 The terminology in the normative references applies. 100 3. The IPv6 Link-Local Address Type Field 102 [RFC4291] defines the IPv6 LLA format as the prefix fe80::/10, 103 followed by 54 zero bits, then followed by a 64-bit Interface 104 Identifier as shown in Figure 1: 106 | 10 | 107 | bits | 54 bits | 64 bits | 108 +----------+-------------------------+----------------------------+ 109 |1111111010| 0 | interface ID | 110 +----------+-------------------------+----------------------------+ 112 Figure 1: IPv6 Link-Local Address Format 114 In this format, there is currently no use for the 54 bits of 0s, and 115 existing IPv6-over-(foo) documents such as [RFC2464] expect them 116 always to be zero regardless of the method used in generating the 117 Interface ID. 119 However, new IPv6-over-(foo) documents could benefit from having a 120 coded indication of the LLA construction type. This would not only 121 allow the interface to differentiate between the LLA 122 autoconfiguration methods used by the sender in packets received with 123 LLAs, but it would also provide a means for avoiding address 124 duplication between diverse address autoconfiguration methods used on 125 the same link. 127 This document defines a new Type field in the IPv6 LLA prefix. The 128 Type field and a companion Function field occupy the least 129 significant 16 bits of the prefix fe80::/64 as shown in Figure 2: 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 |1|1|1|1|1|1|1|0|1|0| zeros (22 bits) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | zeros (16 bits) | Function | Type | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Figure 2: IPv6 LLA Prefix with Type and Function Fields 141 In this format, Type is an 8-bit field that identifies the LLA type 142 on IPv6-over-(foo) interfaces that recognize the field, and Function 143 is an 8-bit Type-specific field. The values for Type that are 144 currently defined are: 146 Link-Local Format Type 147 ***************** **** 148 Unspecified (default) 0 149 Administratively Configured 1 150 RFC4941bis 2 151 RFC7217 3 152 RFC4291 4 153 RFC3972 5 154 OMNI 6 156 Figure 3 158 For example, on IPv6-over-(foo) interface types that recognize the 159 Type field, an IPv6 link-local address formed according to [RFC7217] 160 would be written as: fe80:0:0:3::[Interface ID], while one formed 161 according to [RFC3972] would be written as: fe80:0:0:5::[Interface 162 ID]. For some link types, it is possible that multiple types would 163 be assigned on the same link and possibly even on the same interface. 165 Note that for existing IPv6-over-(foo) link types, the Type and 166 Function fields are always set to the value 0 (unspecified) and the 167 link local address format fe80::/64 still applies as it always has. 169 4. LLA-Based Prefix Delegation (PD) 171 Prefix Delegation (PD) concerns a Requesting Router (RR) requesting 172 an IPv6 PD from a Delegating Router (DR) on the same link. The Type 173 and Function extensions of the LLA are used to drive the PD process 174 as discussed below. 176 RRs autoconfigure a Type '2' "Temporary" LLA according to 177 [I-D.ietf-6man-rfc4941bis] and set the Function field to a prefix 178 length value between 1 and 64 to indicate the length of PD that is 179 being requested (if a PD is not requested, the RR instead sets the 180 Function field to the value 0). The RR then uses the LLA as the IPv6 181 source address of a Router Solicitation (RS) message used to request 182 a PD. 184 When the DR receives the RS message, it coordinates with the PD 185 service to receive an IPv6 prefix delegation. The DR then 186 autoconfigures a 'Type 6' "OMNI" LLA according to 187 [I-D.templin-6man-omni-interface], where the delegated prefix is 188 encoded in the interface identifier of the LLA. For example, if the 189 delegated prefix is 2001:db8:1:2::/NN, the DR writes the LLA as 190 fe80::2001:db8:1:2, then sets the Type field to the value '6' and the 191 Function field to the value 'NN' as fe80:0:0:NN06:2001:db8:1:2. The 192 DR then sets the LLA as the destination address of a Router 193 Advertisement (RA) message, and sends the RA message back to the RR. 195 When the RR receives the RA message, it both derives the delegated 196 prefix from the LLA destination address and assigns the LLA to the 197 receiving interface. The RR can then distribute the delegated prefix 198 to its downstream-attached networks. 200 Note that if the RR knows in advance its own OMNI LLA (for example, 201 if the OMNI LLA were administratively configured a priori) it can 202 send an RS message with the OMNI LLA as the source address in its 203 first exchange with the DR. If the DR is able to confirm that the RR 204 is authorized to use its claimed OMNI LLA, it sends an RA message 205 back to the RR with the same OMNI LLA as the IPv6 destination 206 address. 208 5. IANA Considerations 210 This document defines a Type field for IPv6 link-local addresses, for 211 which IANA is instructed to create and maintain a new registry 212 entitled "IPv6 Link-Local Address Type values". Initial values are 213 given below; future assignments are to be made through Expert Review 214 [RFC8126]: 216 Link-Local Format Type 217 ***************** **** 218 Unspecified (default) 0 219 Administratively Configured 1 220 RFC4941bis 2 221 RFC7217 3 222 RFC4291 4 223 RFC3972 5 224 OMNI 6 226 Figure 4: IANA IPv6 Link-Local Address Type Registry 228 6. Security Considerations 230 Security considerations for IPv6 [RFC8200] apply. 232 7. Acknowledgements 234 This document is aligned with the IETF 6man (IPv6) working group. 236 . 238 8. References 240 8.1. Normative References 242 [I-D.ietf-6man-rfc4941bis] 243 Gont, F., Krishnan, S., Narten, T., and R. Draves, 244 "Temporary Address Extensions for Stateless Address 245 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12 246 (work in progress), November 2020. 248 [I-D.templin-6man-omni-interface] 249 Templin, F. and T. Whyman, "Transmission of IP Packets 250 over Overlay Multilink Network (OMNI) Interfaces", draft- 251 templin-6man-omni-interface-50 (work in progress), October 252 2020. 254 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 255 RFC 3972, DOI 10.17487/RFC3972, March 2005, 256 . 258 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 259 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 260 2006, . 262 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 263 Interface Identifiers with IPv6 Stateless Address 264 Autoconfiguration (SLAAC)", RFC 7217, 265 DOI 10.17487/RFC7217, April 2014, 266 . 268 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 269 Writing an IANA Considerations Section in RFCs", BCP 26, 270 RFC 8126, DOI 10.17487/RFC8126, June 2017, 271 . 273 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 274 (IPv6) Specification", STD 86, RFC 8200, 275 DOI 10.17487/RFC8200, July 2017, 276 . 278 8.2. Informative References 280 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 281 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 282 . 284 Author's Address 286 Fred L. Templin (editor) 287 The Boeing Company 288 P.O. Box 3707 289 Seattle, WA 98124 290 USA 292 Email: fltemplin@acm.org