idnits 2.17.1 draft-mishra-6man-variable-slaac-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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 76 has weird spacing: '... prefix usage...' -- The document date (October 29, 2020) is 1274 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: 'IANA-RF' is mentioned on line 1085, but not defined == Unused Reference: 'RFC8273' is defined on line 1475, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-bourbaki-6man-classless-ipv6-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.bourbaki-6man-classless-ipv6' ** Downref: Normative reference to an Informational RFC: RFC 2450 ** Obsolete normative reference: RFC 3177 (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3587 ** Obsolete normative reference: RFC 3627 (Obsoleted by RFC 6547) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4389 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Downref: Normative reference to an Informational RFC: RFC 5214 ** Downref: Normative reference to an Informational RFC: RFC 5375 ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Downref: Normative reference to an Experimental RFC: RFC 6296 ** Downref: Normative reference to an Informational RFC: RFC 7084 Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN Working Group G. Mishra 3 Internet-Draft Verizon Inc. 4 Updates: RFC2464, RFC4291, RFC4861, A. Petrescu 5 RFC4862, RFC7136, RFC8273 (if CEA, LIST 6 approved) N. Kottapalli 7 Intended status: Standards Track Benu Networks 8 Expires: May 2, 2021 N. Kottapalli 9 Ciena 10 D. Shytyi 11 SFR 12 October 29, 2020 14 SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) 15 draft-mishra-6man-variable-slaac-00 17 Abstract 19 This draft proposes the use of arbitrary length prefixes in PIO for 20 SLAAC. A prefix of length 65 in PIO, for example, would be permitted 21 to form an addresses whose interface identifier length is length 63, 22 which allows several benefits. 24 In the past, various IPv6 addressing models have been proposed based 25 on a subnet hierarchy embedding a 64-bit prefix. The last remnant of 26 IPv6 classful addressing is a inflexible interface identifier 27 boundary at /64. This document proposes flexibility to the fixed 28 position of that boundary for interface addressing. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 2, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. The History behind the 64 bit fixed boundary . . . . . . . . 4 67 4. Identifier and Subnet Length Statements . . . . . . . . . . . 7 68 5. Recommendations for implementation of variable SLAAC . . . . 8 69 6. Recommended use cases where 64 bit prefix should be utilized 8 70 7. Reasons for longer than 64 bit prefix length . . . . . . . . 12 71 7.1. Insufficient Address Space Delegated . . . . . . . . . . 12 72 7.2. Hierarchical Addressing . . . . . . . . . . . . . . . . . 13 73 7.3. Audit Requirement . . . . . . . . . . . . . . . . . . . . 13 74 7.4. Concerns over ND Cache Exhaustion . . . . . . . . . . . . 14 75 7.5. Longer prefixes lengths used for embedding information . 14 76 8. Greater than 64 bit prefix usage by ISPs is strictly 77 prohibited . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9. Comparison of Static, SLAAC, DHCPv6 and Variable SLAAC . . . 15 79 10. Variable SLAAC Use Cases . . . . . . . . . . . . . . . . . . 18 80 10.1. Permission-less Extension of the Network . . . . . . . . 18 81 10.2. Private Networks . . . . . . . . . . . . . . . . . . . . 18 82 10.3. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 19 83 10.4. Home and SOHO . . . . . . . . . . . . . . . . . . . . . 19 84 10.5. 3GPP V2I and V2V networking . . . . . . . . . . . . . . 19 85 10.6. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 10.7. Large ISP's backbone POP . . . . . . . . . . . . . . . . 20 87 11. Variable SLAAC implementation using RA Flag . . . . . . . . . 20 88 12. Applicability Statements . . . . . . . . . . . . . . . . . . 22 89 13. Router and Operational Considerations . . . . . . . . . . . . 22 90 14. Host Behavior Considerations . . . . . . . . . . . . . . . . 22 91 15. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 94 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 19.1. Normative References . . . . . . . . . . . . . . . . . . 24 97 19.2. Informative References . . . . . . . . . . . . . . . . . 30 98 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 32 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 101 1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. Introduction 111 From the beginning, the IPv6 addressing plan was based on a 128 bit 112 address format made up of 8 hextets which were broken down into a 64 113 bit four hextet prefix and 64 bit four hextet interface identifier. 114 For example, the address 2001:db8:3:4::1 has the first 4 hextets 115 forming the /64 prefix 2001:db8:3:4::/64, whereas the last four 116 hextets form an interface identifier abbreviated as ::1 (a 'hextet' 117 is a group of max 4 hex digits between two columns, e.g. "2001" and 118 "db8" are each a hextet). A comprehensive analysis of the 64-bit 119 boundary is provided in [RFC7421]. The history of IPv6 Classful 120 models proposed, and the last remnant of IPv6 Classful addressing 121 rigid network interface identifier boundary at /64 is discussed in 122 detail as well as the removal of the fixed position of the boundary 123 for interface addressing in draft [I-D.bourbaki-6man-classless-ipv6]. 125 This document discusses the reasons why the interface identifier has 126 been fixed at 64 bits, and the problems that can be addressed by 127 changing the GUA interface identifier from fixed 64 bit size to a 128 variable interface identifier. This change would be consistent with 129 static and DHCPv6 stateful IPv6 address assignment, as well as the 130 proposed solution would ensure maintaining backwards compatibility 131 for existing implementations. This document tries to achieve 132 clearing the confusion related to prefix length, and provide 133 consistency of variable length prefix across the three IPv6 134 addressing strategies deployed, static, DHCPv6 and Stateless Address 135 Autoconfiguration(SLAAC), and finally update all RFCs with the new 136 variable SLAAC standard. 138 Over the years one of the merits of increasing the prefix length, and 139 reducing the size of the interface identifier has been incorrectly 140 stated as the possibility of IPv6 address space exhaustion could be 141 circumvented, or that a 64 bit interface identifier is a wasteful use 142 of address space. 144 3. The History behind the 64 bit fixed boundary 146 The fixed length of an Interface Identifier has roots in other early 147 non-IP networks such as IPX of Novell and another from Apple. 149 Over the course of the history of the IPv6 protocol, several 150 addressing models have been proposed to break up the prefix into a 151 hierarchical format. One of the first attempts was [RFC2450] which 152 was based on a 13 bit Level Aggregation (TLA), 24 bit Next-Level 153 Aggregation (NLA), 16 bit Site Level aggregator Identifiers. The 154 current IPv6 addressing architecture for global unicast addressing 155 uses [RFC3587] for global unicast address currently being delegated 156 by IANA 2000::/3 prefix. With the recommendation in [RFC3177] which 157 called for a default end site assignment of a /48 which was adopted 158 by the Regional Internet Registry was revised with [RFC6177] to a 159 smaller block size of /56 prefix to end sites to avoid risk of 160 premature address depletion. The current IPv6 addressing 161 architecture [RFC3587] for global unicast addressing was now based on 162 an IPv6 hierarchical format which now consists of a 45 bit global 163 routing prefix, 16 bit subnet ID followed by 64 bit interface 164 identifier. In the earlier deployments of IPv6 due to the stringent 165 guidelines of [RFC4291] which stated that for all unicast addresses, 166 except those that start with the binary value 000, Interface IDs are 167 required to be 64 bits long and to be constructed in Modified EUI-64 168 format. Referencing IPv6 Addressing architecture [RFC3513] section 169 2.5.5 depicts examples of global unicast addresses that start with 170 binary 000 are IPv6 addresses with embedded IPv4 addresses and IPv6 171 address containing encoded NSAP addresses [RFC4548] described in 172 [RFC6052]. An example use case would be for NAT64 [RFC6146] as well 173 as many other use cases that exist with transition technology 174 tunneling using IPv4 IPv6 translators. 176 The general format for IPv6 global unicast addresses is as follows: 178 | n bits | m bits | 128-n-m bits | 179 +------------------------+-----------+----------------------------+ 180 | global routing prefix | subnet ID | interface ID | 181 +------------------------+-----------+----------------------------+ 183 Figure 1: Format of the IPv6 global unicast addresses 185 Even though [RFC4291] states that all global unicast addresses except 186 those that start with binary value 000, which use ipv4 ipv6 187 translators [RFC6052], that static and DHCPv6 violates [RFC4291] as 188 variable length masking to 128 is supported, where SLAAC variable 189 length masking remains forbidden. IPv6 packets over LAN based 190 technologies such as ethernet must use 64 bit interface identifier 191 per [RFC2464]. Nothing is mentioned regarding wireless based 192 technologies such as MIP6, V2V or 6loWPAN, with regards to interface 193 identifier length stringent requirement for 64 bit prefix length. 194 Stateful Address Autoconfiguration [RFC4862] states that the sum 195 total of the prefix length and interface identifier should equal 128 196 bits, but does not state that the interface identifier should be 64 197 bits. Note that [RFC4861] states that the PIO (Prefix information 198 Options), that the A-bit Autonomous address-configuration flag when 199 set indicates that the prefix can be used for (SLAAC) stateless 200 address autoconfiguration, and [RFC4862] states to silently ignore 201 the PIO options if the A flag is not set in the Router Advertisement. 202 If the A flag is not set then /64 is only a recommendation which 203 applies to DHCPv6 and static. 205 During the early deployments of IPv6, /64 was a 'de facto' standard 206 prefix length for deployment to all router interfaces including 207 point-to-point and loopbacks. In early deployments of IPv6, due to 208 the complexity and overall learning curve, and change going from IPv4 209 to IPv6, the keep it simple approach of /64 everywhere was the 210 general rule of thumb for deployment. After decades of deployment, 211 operators started to dig further into how IPv4 started out as 212 classful with classful routing protocols such as RIP or IGRP. Later 213 as Classless inter-domain routing with BGP became mainstream with 214 larger enterprises and service providers, operators started looking 215 at IPv6 and variable length masking. Operators now started 216 experimenting trying to subnet at nibble boundaries to start and 217 became brave enough to tackle subnetting on a bit boundary. As 218 variable length subnet masking became more mainstream with IPv6, 219 operators started to use /126 mask on point-to-point links. Around 220 that time [RFC3627] came out which talked about the harmful effects 221 of /127 and that it was forbidden due to operational impacts. 222 Harmful impacts of /127 were due to subnet-router anycast being in 223 conflict with [RFC2526] /121. Later was found the benefits of /127 224 avoided the ping-pong effect and the subnet-router anycast conflict 225 could be avoided by disabling Duplicate address detection thus the 226 status of use of /127 on point-to-point links was updated by 227 [RFC6164]. As the evolution of IPv6 continued, questions would come 228 as to why the interface identifier is so large at 64 bits, as 64 bits 229 equates to 18,446,744,073,709,551,616 IPv6 addresses, which is more 230 than anyone could ever imagine on a single flat subnet far into the 231 distant future. The main reason for the larger 64 bit interface 232 identifier is for privacy when connected directly to the internet, or 233 on an unsecure public hotspot or location so your device is not 234 traceable. 236 From the beginning of IPv6 deployments most enterprises went with 237 SLAAC, but as DHCPv6 matured, enterprises migrated to DHCPv6, and 238 network infrastructure remained configured manually using static 239 configurations. Since so many RFC's mention the SLAAC 64 bit 240 boundary requirement and confusion related to this topic, in fact 241 prevented operators proliferation of even attempting to use longer 242 prefixes on host subnets with static or DHCPv6 stateful. Most IPv6 243 implementations even to this day do not use longer than 64 bit 244 prefixes, and still maintain the 64 bit boundary for host subnet, for 245 both DHCPv6 and static, even though technically feasible, due to fear 246 of interoperability issues that may arise. With this new evolution 247 of IPv6 addressing architecture with variable SLAAC, we can bring 248 back SLAAC to the mainstream for all IPv6 deployments. This will 249 also allow operators to now comfortably deploy both DHCPv6 and static 250 with greater than 64 bit prefix length to host subnets, without fear 251 of interoperability problems. 253 Today we have three methods of IPv6 address deployment, SLAAC, DHCPv6 254 and static. DHCPv6 does not provide an adequate IPv6 addressing 255 solution as described in detail in the DHCPv6, Static, and SLAAC 256 comparison section. As user subnets flatten out further, as the IPv4 257 under pinning is eliminated, removing the shackles on IPv6, the 258 subnets will get much flatter. As the subnets flatten out in large 259 Enterprise networks where you have 100's of Dual Stack subnets 260 migrate to a single "IPV6-ONLY" subnet, the overhead DHCPv6 Normal 261 mode messaging becomes exacerbated. The problem with DHCPv6 is that 262 once the "M" managed bit is set to "1", all hosts on the subnet cache 263 the M bit and change to DHCPv6 stateful mode. Higher probability of 264 rouge devices such as printers or other appliances misbehaving with 265 IPv6 enabled by default, now in DHCPv6 mode, spewing of millions of 266 DHCPv6 messages that can now impact the router control plane 267 processing of packets. This can be alleviated with special custom 268 Control Plane policer policy, however now adds complexity and 269 administrative overhead to DHCPv6 deployments. Enterprises and 270 Service Providers require a viable IPv6 deployment solution that can 271 accommodate the shortfalls of both static and DHCPv6 addressing. 272 Static addressing due to administrative overhead of manual assignment 273 does not provide a viable solution for even moderately sized 274 networks. 276 An arbitrary length prefix solves problems described in detail in 277 section 7 and are being highlighted here as well as a key part of the 278 problem statement to be addressed. A site may not be able to 279 delegate sufficient address space from a /64 prefix to all of its 280 internal subnets. In this case a site may be partially operational 281 as it is unable to number all of its subnets. An alternative would 282 be to be able to use prefixes longer then /64 to allow multiple 283 subnets for example /80 for numbering subnets with a mixture of hosts 284 that are static or DHCPv6 without worry of interoperability issues. 285 Some operators would like the ability to have a hierarchical 286 addressing structure and may require more than 16 bits given with a 287 /48 allocation. In such instances longer prefix lengths would allow 288 for additional levels of aggregation as required. It is common for 289 some operators to have security audit requirements where they wish to 290 know all active hosts on a /64 subnet. As /64 subnets can contain an 291 enormous number of hosts and thus cannot be scanned as can IPv4 292 subnets. Operators have argued that one method to be able to scan 293 for active hosts would be by reducing the size of the subnet. 294 Neighbor discovery cache exhaustion when an attacker sends a large 295 number of messages in rapid succession to hosts filling the routers 296 ND cache is another problem with fixed length /64 size SLAAC subnets. 297 Neighbor Discovery cache exhaustion issues are relatively common on 298 IXP (Internet Exchange Points) where a very large number of Internet 299 Service Providers are full mesh peering to exchange routing updates. 300 As the number of hosts on a SLAAC subnet can be 2^64, a much smaller 301 subnet size can drastically reduce the Neighbor Discovery cache 302 exhaustion issues. 304 The goal of this document is to fix the problems related to stateless 305 address autoconfiguration (SLAAC), current obscurities of the 64 bit 306 prefix boundary, issues that exist today with current IPv6 addressing 307 using manual and DHCPv6, and how variable SLAAC can now be used to 308 fill the gaps with static and DHCPv6, and also update all standards 309 specifications to reflect the new variable SLAAC standard making the 310 prefix lengths variable. 312 4. Identifier and Subnet Length Statements 314 IPv6 router interfaces and hosts configured to use Stateful Address 315 Autoconfiguration (SLAAC) will now support variable mask up to 128 316 bits consistent with static and DHCPv6. This change will allow 317 variable SLAAC to be used on any infrastructure link from point-to- 318 point /127 to infrastructure shared subnets from /65 to /127. All 319 routers support routing of variable length IPv6 prefix lengths called 320 variable length subnet masks(VLSM) up to 128 bits in length, so this 321 variable stateless address autoconfiguration change will be in line 322 with all interior gateway routing protocols and exterior gateway 323 routing protocols. This change is for both Global Unicast address 324 [RFC3587] and Unique Local Address [RFC4193]. There will be no 325 change to the IPv6 link local address interface identifier which will 326 remain 64 bits for link local fe80::/10 router or host interface 327 fe80::/64 [RFC4291]. 329 The term "Variable SLAAC" as defined in this document states that the 330 length of the prefix can now be greater than 64 bits up to 127 bits 331 with a corresponding shorter interface identifier. The interface 332 identifier will range from 64 bits to 1 bit in length. The length of 333 the prefix can now be less than 64 bits to 3 bits in length with a 334 corresponding longer interface identifier and can now be greater than 335 64 bits to 125 bits in length. 337 The "race to the bottom problem" - is the problem where allowing 338 prefixes longer than 64 to be used in SLAAC will lead to 65, 66 and 339 so on, up to 127 and 128 allocations. At that point the bottom would 340 be reached and thus impossible to extend the network further. 342 One version of the "address waste" problem is: SLAAC is used in a 343 subnet where 2^64 addresses are possible. But there are no link 344 layers that allow as many addresses to connect on a single link. 345 E.g. wired Ethernet allows for a few hundreds or a few thousands 346 nodes in a switched network. Because of that, the difference up to 347 2^64 addresses will not be used, as such they will be wasted. 349 5. Recommendations for implementation of variable SLAAC 351 This document proposes a plan to provide flexibility for implementers 352 to now have the option to use SLAAC (Stateful Address 353 Autoconfiguration) where previously they used DHCPv6 or static. This 354 will also open the door to interoperability and mixed device types 355 supporting either SLAAC, static or DHCPv6 to now be able to exist on 356 the same subnet or VLAN without risk of interoperability issues. 358 It is recommended to use variable length SLAAC on network 359 infrastructure point-to-point links as well as for host subnets where 360 historically /64 was used that now variable length SLAAC prefix can 361 be used up to 127 bit prefix length. It is recommended that the use 362 of variable length prefix be based on each individual IPv6 deployment 363 requirement. If more address space is required, necessity to break 364 up a /64 for address space management, creating an internal 365 hierarchical addressing plan based on prefixes delegated or 366 allocated, then variable length prefix is now an available option in 367 the designers toolbox that now can be utilized. Changes to DHCPv6 368 prefix-delegation is outside of the scope of this document. 370 It is recommended that ISP allocations and Customer allocations per 371 [RFC6177] and [RFC5375] not change due to this variable SLAAC 372 proposed standard. 374 6. Recommended use cases where 64 bit prefix should be utilized 376 Listed below are use cases where the 64 bit prefix length MUST be 377 adhered to and in these cases variable SLAAC feature should not be 378 utilized. 380 The precise 64-bit length of the interface identifier is widely 381 mentioned in numerous RFCs describing various aspects of IPv6. It is 382 not straightforward to distinguish cases where this has normative 383 impact or affects interoperability. This section aims to identify 384 specifications that contain an explicit reference to the 64-bit 385 length. Regardless of implementation issues, the RFCs themselves 386 would all need to be updated if the 64-bit rule was changed, even if 387 the updates were small, which would involve considerable time and 388 effort. 390 First and foremost, the RFCs describing the architectural aspects of 391 IPv6 addressing explicitly state, refer, and repeat this apparently 392 immutable value: Addressing Architecture [RFC4291], IPv6 Address 393 Assignment to End Sites [RFC6177], Reserved interface identifiers 394 [RFC5453], and ILNP Node Identifiers [RFC6741]. Customer edge 395 routers impose /64 for their interfaces [RFC7084]. The IPv6 Subnet 396 Model [RFC5942] points out that the assumption of a /64 prefix length 397 is a potential implementation error. 399 Numerous IPv6-over-foo documents make mandatory statements with 400 respect to the 64-bit length of the interface identifier to be used 401 during the Stateless Autoconfiguration. These documents include 402 [RFC2464] (Ethernet), [RFC2467] (Fiber Distributed Data Interface 403 (FDDI)), [RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet), 404 [RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre 405 Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121] 406 [RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site 407 Automatic Tunnel Addressing Protocol (ISATAP)), 408 [I-D.templin-aerolink] (Asymmetric Extended Route Optimization 409 (AERO)), [I-D.ietf-6lowpan-btle] (BLUETOOTH Low Energy), 410 [I-D.ietf-6lo-6lobac] (IPv6 over MS/TP), and [I-D.ietf-6lo-lowpanz] 411 (IPv6 packets over ITU-T G.9959). 413 To a lesser extent, the address configuration RFCs themselves may in 414 some ways assume the 64-bit length of an interface identifier (e.g, 415 [RFC4862] for the link-local addresses, DHCPv6 for the potentially 416 assigned EUI- 64-based IP addresses, and Optimistic Duplicate Address 417 Detection [RFC4429] that computes 64-bit-based collision 418 probabilities). 420 The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and 421 MLDv2 [RFC3810] protocols mandate that all queries be sent with a 422 link-local source address, with the exception of MLD messages sent 423 using the unspecified address when the link-local address is 424 tentative [RFC3590]. At the time of publication of [RFC2710], the 425 IPv6 addressing architecture specified link-local addresses with 426 64-bit interface identifiers. MLDv2 explicitly specifies the use of 427 the fe80::/64 link-local prefix and bases the querier election 428 algorithm on the link-local subnet prefix of length /64. 430 The "IPv6 Flow Label Specification" [RFC6437] gives an example of a 431 20-bit hash function generation, which relies on splitting an IPv6 432 address in two equally sized, 64-bit-length parts. 434 The basic transition mechanisms [RFC4213] refer to interface 435 identifiers of length 64 for link-local addresses; other transition 436 mechanisms such as Teredo [RFC4380] assume the use of interface 437 identifiers of length 64. Similar assumptions are found in 6to4 438 [RFC3056] and 6rd [RFC5969]. Translation-based transition mechanisms 439 such as NAT64 and NPTv6 have some dependency on prefix length, 440 discussed below. 442 The proposed method [RFC7278] of extending an assigned /64 prefix 443 from a smartphone's cellular interface to its WiFi link relies on 444 prefix length, and implicitly on the length of the interface 445 identifier, to be valued at 64. 447 The Cryptographically Generated Addresses (CGA) and Hash-Based 448 Addresses (HBA) specifications rely on the 64-bit identifier length 449 (see below), as do the Privacy extensions [RFC4941] and some examples 450 in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296]. 452 464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. 453 However, it also discusses the possibility of using the interface 454 address on the device as the end point for the traffic, thus 455 potentially removing this dependency. 457 [RFC2526] reserves a number of subnet anycast addresses by reserving 458 some anycast interface identifiers. An anycast interface identifier 459 so reserved cannot be less than 7 bits long. This means that a 460 subnet prefix length longer than /121 is not possible, and a subnet 461 of exactly /121 would be useless since all its identifiers are 462 reserved. It also means that half of a /120 is reserved for anycast. 463 This could of course be fixed in the way described for /127 in 464 [RFC6164], i.e., avoiding the use of anycast within a /120 subnet. 465 Note that support for "on-link anycast" is a standard IPv6 neighbor 466 discovery capability [RFC4861] [RFC7094]; therefore, applications and 467 their developers would expect it to be available. 469 The Mobile IP home network models [RFC4887] rely heavily on the /64 470 subnet length and assume a 64-bit interface identifier. 472 o Multicast: [RFC3306] defines a method for generating IPv6 473 multicast group addresses based on unicast prefixes. This method 474 assumes a longest prefix of 64 bits. If a longer prefix is used, 475 there is no way to generate a specific multicast group address 476 using this method. In such cases, the administrator would need to 477 use an "artificial" prefix from within their allocation (a /64 or 478 shorter) from which to generate the group address. This prefix 479 would not correspond to a real subnet. 481 o Similarly, [RFC3956], which specifies the Embedded Rendezvous 482 Point (RP)) allowing IPv6 multicast rendezvous point addresses to 483 be embedded in the multicast group address, would also fail, as 484 the scheme assumes a maximum prefix length of 64 bits. 486 o CGA: The Cryptographically Generated Address format [RFC3972] is 487 heavily based on a /64 interface identifier. [RFC3972] has 488 defined a detailed algorithm showing how to generate a 64-bit 489 interface identifier from a public key and a 64-bit subnet prefix. 490 Changing the /64 boundary would certainly invalidate the current 491 CGA definition. However, the CGA might benefit in a redefined 492 version if more bits are used for interface identifiers (which 493 means shorter prefix length). For now, 59 bits are used for 494 cryptographic purposes. The more bits are available, the stronger 495 CGA could be. Conversely, longer prefixes would weaken CGA. 497 o NAT64: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] 498 are flexible for the prefix length. [RFC6052] has defined 499 multiple address formats for NAT64. In Section 2 of 500 "IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the 501 network-specific prefix could be one of /32, /40, /48, /56, /64, 502 and /96. The remaining part of the IPv6 address is constructed by 503 a 32-bit IPv4 address, an 8-bit u byte and a variable length 504 suffix (there is no u byte and suffix in the case of the 96-bit 505 Well-Known Prefix). NAT64 is therefore OK with a subnet boundary 506 out to /96 but not longer. 508 o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also 509 bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 510 prefix. When the NPTv6 Translator is configured with a /48 or 511 shorter prefix, the 64-bit interface identifier is kept unmodified 512 during translation. However, the /64 boundary might be changed as 513 long as the "inside" and "outside" prefixes have the same length. 515 o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is 516 designed around the /64 boundary, since it relies on locally 517 unique 64-bit node identifiers (in the interface identifier 518 field). While a redesign to use longer prefixes is not 519 inconceivable, this would need major changes to the existing 520 specification for the IPv6 version of ILNP. 522 o Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in 523 its insecure form treats IPv6 addresses as opaque 128-bit objects. 524 However, to secure the protocol against spoofing, it is essential 525 to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs 526 are generated using a procedure that assumes a 64-bit identifier. 527 Therefore, in effect, secure shim6 is affected by the /64 boundary 528 exactly like CGAs. 530 o Duplicate address risk: If SLAAC was modified to work with shorter 531 interface identifiers, the statistical risk of hosts choosing the 532 same pseudo- random identifier [RFC7217] would increase 533 correspondingly. The practical impact of this would range from 534 slight to dramatic, depending on how much the interface identifier 535 length was reduced. In particular, a /120 prefix would imply an 536 8-bit interface identifier and address collisions would be highly 537 probable. 539 o The link-local prefix: While [RFC4862] is careful not to define 540 any specific length of link-local prefix within fe80::/10, the 541 addressing architecture [RFC4291] does define the link-local 542 interface identifier length to be 64 bits. If different hosts on 543 a link used interface identifiers of different lengths to form a 544 link-local address, there is potential for confusion and 545 unpredictable results. Typically today the choice of 64 bits for 546 the link-local interface identifier length is hard-coded per 547 interface, in accordance with the relevant IPv6-over-foo 548 specification, and systems behave as if the link-local prefix was 549 actually fe80::/64. There might be no way to change this except 550 conceivably by manual configuration, which will be impossible if 551 the host concerned has no local user interface. 553 7. Reasons for longer than 64 bit prefix length 555 In this section we are providing the justification for longer 556 prefixes and shorter interface identifiers essentially variable 557 SLAAC. 559 7.1. Insufficient Address Space Delegated 561 A site may not be delegated a sufficiently generous prefix from which 562 to allocate a /64 prefix to all of its internal subnets. In this 563 case, the site may either determine that it does not have enough 564 address space to number all its network elements and thus, at the 565 very best, be only partially operational, or it may choose to use 566 internal prefixes longer than /64 to allow multiple subnets and the 567 hosts within them to be configured with addresses. 569 In this case, the site might choose, for example, to use a /80 per 570 subnet in combination with hosts using either manually configured 571 addressing or DHCPv6 [RFC3315]. 573 Scenarios that have been suggested where an insufficient prefix might 574 be delegated include home or small office networks, vehicles, 575 building services, and transportation services (e.g., road signs). 576 It should be noted that the homenet architecture text [RFC7368] 577 states that Customer Premises Equipment (CPE) should consider the 578 lack of sufficient address space to be an error condition, rather 579 than using prefixes longer than /64 internally. 581 Another scenario occasionally suggested is one where the Internet 582 address registries actually begin to run out of IPv6 prefix space, 583 such that operators can no longer assign reasonable prefixes to users 584 in accordance with [RFC6177]. It is sometimes suggested that 585 assigning a prefix such as /48 or /56 to every user site (including 586 the smallest) as recommended by [RFC6177] is wasteful. In fact, the 587 currently released unicast address space, 2000::/3, contains 35 588 trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a 589 small fraction have been allocated. Allowing for a conservative 590 estimate of allocation efficiency, i.e., an HD-ratio of 0.94 591 [RFC4692], approximately 5 trillion /48 prefixes can be allocated. 592 Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 593 prefixes can be allocated. Furthermore, with only 2000::/3 currently 594 committed for unicast addressing, we still have approximately 85% of 595 the address space in reserve. Thus, there is no objective risk of 596 prefix depletion by assigning /48 or /56 prefixes even to the 597 smallest sites. 599 7.2. Hierarchical Addressing 601 Some operators have argued that more prefix bits are needed to allow 602 an aggregated hierarchical addressing scheme within a campus or 603 corporate network. However, if a campus or enterprise gets a /48 604 prefix (or shorter), then that already provides 16 bits for 605 hierarchical allocation. In any case, flat IGP routing is widely and 606 successfully used within rather large networks, with hundreds of 607 routers and thousands of end systems. Therefore, there is no 608 objective need for additional prefix bits to support hierarchy and 609 aggregation within enterprises. 611 7.3. Audit Requirement 613 Some network operators wish to know and audit nodes that are active 614 on a network, especially those that are allowed to communicate off- 615 link or off-site. They may also wish to limit the total number of 616 active addresses and sessions that can be sourced from a particular 617 host, LAN, or site, in order to prevent potential resource-depletion 618 attacks or other problems spreading beyond a certain scope of 619 control. It has been argued that this type of control would be 620 easier if only long network prefixes with relatively small numbers of 621 possible hosts per network were used, reducing the discovery problem. 622 However, such sites most typically operate using DHCPv6, which means 623 that all legitimate hosts are automatically known to the DHCPv6 624 servers, which is sufficient for audit purposes. Such hosts could, 625 if desired, be limited to a small range of interface identifier 626 values without changing the /64 subnet length. Any hosts 627 inadvertently obtaining addresses via SLAAC can be audited through 628 Neighbor Discovery (ND) logs. 630 7.4. Concerns over ND Cache Exhaustion 632 A site may be concerned that it is open to ND cache exhaustion 633 attacks [RFC3756], whereby an attacker sends a large number of 634 messages in rapid succession to a series of (most likely inactive) 635 host addresses within a specific subnet. Such an attack attempts to 636 fill a router's ND cache with ND requests pending completion, which 637 results in denying correct operation to active devices on the 638 network. 640 One potential way to mitigate this attack would be to consider using 641 a /120 prefix, thus limiting the number of addresses in the subnet to 642 be similar to an IPv4 /24 prefix, which should not cause any concerns 643 for ND cache exhaustion. Note that the prefix does need to be quite 644 long for this scenario to be valid. The number of theoretically 645 possible ND cache slots on the segment needs to be of the same order 646 of magnitude as the actual number of hosts. Thus, small increases 647 from the /64 prefix length do not have a noticeable impact; even 2^32 648 potential entries, a factor of two billion decrease compared to 2^64, 649 is still more than enough to exhaust the memory on current routers. 650 Given that most link-layer mappings cause SLAAC to assume a 64-bit 651 network boundary, in such an approach hosts would likely need to use 652 DHCPv6 or be manually configured with addresses. 654 It should be noted that several other mitigations of the ND cache 655 attack are described in [RFC6583], and that limiting the size of the 656 cache and the number of incomplete entries allowed would also defeat 657 the attack. For the specific case of a point-to-point link between 658 routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. 660 7.5. Longer prefixes lengths used for embedding information 662 Ability to utilize the longer than 64 bit prefixes to be able to 663 embed geographic or other information into the prefix that could be 664 valuable to the IPv6 addressing architecture providing more 665 flexibility to the operator. 667 8. Greater than 64 bit prefix usage by ISPs is strictly prohibited 669 The RA flag S bit setting proposed by this draft for greater or less 670 then /64 bit prefix feature is strictly for enterprises and broadband 671 subscriber customer use only. In the broadband space this feature is 672 to be used only by home broadband users or Small Office Home Office 673 broadband users. ISPs can use DHCPv6-PD to send greater than /64 674 prefix advertisement message to the CE router. However, ISPs MUST 675 NOT set the RA flag S bit, and send greater than /64 prefix down to 676 the host. With this draft, no changes will be made to any of the 677 current IPv6 prefix allocation guidelines for customers prefixes 678 sizes sent by ISPs. In the enterprise space any router is allowed to 679 set the RA flag S bit for greater then /64 prefix allocation. This 680 provides tremendous flexibility for enterprises as well as broadband 681 subscriber customers to segment and further extend a single /64 682 allocation. Enterprise use case allows for added further 683 segmentation granularity and functionality for endpoints devices. 684 Broadband subscriber use cases with the proliferation of IoT and 6lo 685 devices in the home or small office use case, allows for added 686 further segmentation granularity and functionality for endpoints 687 devices. This change of stateful address auto configuration to now 688 allow for greater then 64 bit prefix length is not being done because 689 there is wasted space with a /64 prefix length or that there is any 690 even remote possibility of running out of address space. The reason 691 for restriction of use of this feature by ISP's is also because it 692 puts the customer at the shorter end of the stick with smaller 693 allocation, which you could be interpreted as biased or unfair to 694 smaller customers that cannot afford the larger space as large 695 companies. This would be another form of inequality between 696 customers and service provider similar to net neutrality discussions 697 and fairness in quality of service. ISPs have essentially nothing to 698 gain by advertising smaller prefixes with greater than /64 prefixes 699 allocations as address space is in abundance. On the other hand for 700 ISPs' OPEX costs could be increased and so much less cost effective 701 to administer greater then /64 variable length prefixes versed fixed 702 /64 size prefix would be much more challenging and cost prohibitive 703 to manage. 705 9. Comparison of Static, SLAAC, DHCPv6 and Variable SLAAC 707 o Static - IPv6 address and Default Gateway: 709 Pros: 711 + Deactivation of RA processing 713 + Good resistance against RA attack 715 Cons: 717 + Operational impact in configuring interface manually 719 + Network dynamics might require renumbering which needs work 721 o Static - IPv6 address and Default Route via RA 723 Pros: 725 + Does not require disabling RA processing 727 + Works better with FHRP router redundancy 729 Cons: 731 + RA related security issues combat with RA Guard 733 o DHCPv6 [RFC3315] 735 Pros: 737 + Centralized provisioning of IPv6 addressing 739 + IPv6, DNS, NTP can all be distributed 741 Cons: 743 + Administrative overhead of managing DHCPv6 server 745 + Caveats with redundancy and split scopes required for 746 failover. Split scope and failover is resolved with DHCPv6 747 Failover protocol [RFC8156] 749 + RA related security issues combat with RA Guard 751 o SLAAC [RFC7217] Stable Random station-id with privacy and 752 [RFC8064] Recommendations for Stable interfae identifier 754 Pros: 756 + Automatic provisioning IPv6 address to hosts 758 + [RFC7217] Stable Random station-id with privacy extensions 760 Cons: 762 + RA related security issues combat with RA Guard 764 o Variable SLAAC with [RFC7217] Stable Random station-id with 765 privacy and [RFC8064] Recommendations for Stable interfae 766 identifier 768 Pros: 770 + Automatic provisioning IPv6 address to hosts 772 + [RFC7217] Stable Random station-id with privacy extensions 774 Cons: 776 + RA related security issues combat with RA Guard 778 + Security is reduced with longer prefixes and shorter stable 779 random station-id 781 IPv6 address deployment summary statement. 783 DHCPv6 [RFC3315] state machine introduces a large number of messaging 784 packets with Normal mode, four messages called solicit, advertise, 785 request and reply. DHCPv6 Rapid Commit mode reduces the messages 786 from four to two messages only solicit and reply. DHCPv6 Normal mode 787 is the Default. It is recommended to use DHCPv6 Rapid mode [RFC4039] 788 in "high mobility" networks where clients come and go often. The 789 overhead of four messages might not be required so two messages might 790 enough to accommodate. However, if you have multiple DHCPv6 servers 791 for redundancy then you need to use DHCPv6 Normal mode. If you have 792 subnets where there are a large flat user subnets with a very large 793 number of hosts and redundancy is required and DHCPv6 Normal mode is 794 utilized, DHCPv6 messaging is exacerbated exponentially as the 795 subnets flatten out further and further. As the paradigm shifts and 796 IPv4 is eliminated as hosts subnets change to "IPv6-ONLY" subnets, 797 the coupling of IPv4 with IPv6 Dual stack dependency is eliminated, 798 thus removing the shackles pinning IPv6 to smaller many IPv4 subnets. 799 This change allows IPv6 subnets to become very large and flat with 800 the only limiting factor being the L2 switch infrastructure. In many 801 cases Dual stacked implementations with 100's of subnets may change 802 to a single "IPV6 ONLY" subnet. As "IPV6-ONLY" subnets will soon 803 become the future direction of all user access infrastructure, we 804 need a viable solution that will accommodate these very large flat 805 subnets. The problem with DHCPv6 is that once the "M" managed bit is 806 set to "1", all hosts on the subnet cache the Managed IP "M bit" and 807 changes host to DHCPv6 stateful mode. Higher probability of rouge 808 devices such as printers or other appliances misbehaving with IPv6 809 enabled by default, now in DHCPv6 mode, spewing of millions of DHCPv6 810 messages that can now impact the router control plane processing of 811 packets. This can be alleviated with special custom Control plane 812 policer policy, however now adds complexity and administrative 813 overhead to DHCPv6 deployments. Enterprises and Service Providers 814 require a viable IPv6 deployment solution that can accommodate the 815 shortfalls of both static and DHCPv6 addressing. Static addressing 816 due to administrative overhead of manual assignment does not provide 817 a viable solution for even moderately sized networks. Variable SLAAC 818 now has the ability to fill the gaps outlined with DHCPv6 and static 819 that can now be used as a viable ubiquitous all encompassing solution 820 for IPv6 address deployments. 822 10. Variable SLAAC Use Cases 824 This section describes real world use cases of variable slaac that 825 cannot be done today and with fixed 64 bit prefix lengths. 827 10.1. Permission-less Extension of the Network 829 Permission-less extensions of the network with new links (and by 830 implication with new routers) are not supported. 832 The lack of possibility to realize a permission-less extension of the 833 network is an important problem. The problem appears at the edge of 834 the network. The permission is 'granted' for end users situated at 835 the edge of the network. This permission is 'granted' by advertising 836 a prefix of length 64, typically. This prefix is set in the PIO 837 option in an RA. The end user receives this prefix, forms an 838 address, and is able to connect to the Internet. However, the end 839 user has no permission to further extend the network. Although s/he 840 is able to form subsequent prefixes of a length of, say 65, and 841 further advertise it down in the extension of the network, no other 842 Host in that extension of the network is able to use that 843 advertisement; a Host can not form an address with a prefix length 65 844 by using SLAAC. The linux error text reported in the kernel log upon 845 reception of a plen 65 is "illegal" (or similar). 847 10.2. Private Networks 849 Private networks such as Service Provider core not accessable by 850 customers and enterprises where all hosts are trusted are the primary 851 use case for variable SLAAC as the shorter interface identifier does 852 not create any security issues with not having a longer 64 bit 853 interface identifier for privacy extensions stable interface 854 identifier [RFC8084] due to all hosts being inherently trusted. 855 Private internal networks such as corporate intranets traditionally 856 have always used static IPv6 addressing for infrastructure. This 857 manual IPv6 address assignment process for network infrastructure 858 links can take long lead times to complete deployment. By changing 859 the behavior of SLAAC to support variable length prefix and interface 860 identifier allows SLAAC to be used programmatically to deploy to 861 large scale IPv6 networks with thousands of point-to-point links. 862 Note that network infrastructure technically does not require IPv6 863 addressing due to IPv6 next hop being a link local address for IGP 864 routing protocols such as OSPF and ISIS as well as the link local 865 address can be the peer IPv6 address for exterior gateway routing 866 protocols such as BGP. However for hop by hop ping and traceroute 867 capability to have IPv6 reachability at each hop for troubleshooting 868 jitter, latency and drops it is an IPv6 recommended best practice to 869 configure IPv6 address on all infrastructure interfaces. 871 10.3. Mobile IPv6 873 Old MIP6 (Mobile IPv6) Working Group and old Nemo Working Group's 874 routing solution scenarios related to Mobile IPv6 ([RFC3775]) (note: 875 nowadays most MIP-related activity is in DMM WG) where the mobile 876 endpoint can now obtain from the home agent variable SLAAC address 877 and not 64 bit prefix /64 address. This maybe useful in cases where 878 a /64 can now be managed from an addressing perspective and 879 subdivided into blocks for manageability of MIP6 endpoints instead of 880 allocating a single /64 per endpoint. 882 10.4. Home and SOHO 884 Home and SOHO (Small Office and Home Office) environments where 885 internet access uses a broadband service provider single or dual 886 homed scenario. In those such Home networking Homenet environments 887 where HNCP (Home Network Control Protocol [RFC7788] SADR (Source 888 Address Dependent Routing) are deployed for automatic configuration 889 for LAN WIFI endpoint subnets can also now take advantage of variable 890 length SLAAC in deployment scenarios. In cases where multiple 891 routers are deployed in a home environment where routing prefix 892 reachability needs to be advertised where Bable [RFC6126] routing 893 protocol is utilized in those cases variable SLAAC can also be 894 utilized to break up a /64 into multiple smaller subnets. 896 10.5. 3GPP V2I and V2V networking 898 In V2I networking (with 3GPP or with IEEE 802.11bd) the vehicle 899 receives a /64 prefix from the cellular network (or from a Road-Side 900 Unit). This /64 prefix can be used to form one address for the 901 egress interface of the Mobile Router (IP On-Board Unit), but can not 902 be used to form IP addresses for other hosts in the vehicle. 904 3GPP V2V networking use cases where a /56 is allocated to the 4G 905 modem and a /64 is delegated to downstream devices within the 906 automobile now the /64 prefixes can be sub divided into smaller 907 prefix lengths of /65-/128. This provides additional granularity to 908 use cases. 910 10.6. 6lo 912 6lo Working IPv6 over Network Constrained nodes working group use 913 cases. Use cases for IoT devices where have limited network access 914 requirements could now take advantage of variable SLAAC longer 915 prefixes lengths /65-/128. 917 10.7. Large ISP's backbone POP 919 Large ISP backbone POPs such as IXPs where many carriers share the 920 same backbone and ND cache exhaustion may occur due to /64 subnet 921 size. One mitigation technique employed is the use of an ARP Sponge 922 for IPv4 or Layer 2 multicast rate limiters for IPv6. In those 923 particular cases a longer prefix static or variable SLAAC subnet 924 could be utilized to reduce the maximum number of hosts on the 925 subnet. 927 11. Variable SLAAC implementation using RA Flag 929 [RFC5175] currently defines the flags in the NDP Router Advertisement 930 message and these flags are registered in the IANA IPv6 ND Router 931 Advertisement flags Registry [IANA-RF]. This currently contains the 932 following one-bit flags defined in published RFCs: 934 0 1 2 3 4 5 6 7 935 +-+-+-+-+-+-+-+-+ 936 |M|O|H|Prf|P|R|R| 937 +-+-+-+-+-+-+-+-+ 939 Figure 2: Format of flags in Router Advertisement message 941 o M: Managed Address Configuration Flag [RFC4861] 943 o O: Other Configuration Flag [RFC4861] 945 o H: Mobile IPv6 Home Agent Flag [RFC3775] 947 o Prf: Router Selection Preferences [RFC4191] 949 o P: Neighbor Discovery Proxy Flag [RFC4389] 951 o R: Reserved 952 This document defines bit 6 to be the Variable SLAAC Flag: 954 o S: SLAAC Variable length interface identifier Flag 956 This flag has two values. These are: 958 o 0: Variable length interface identifier is disabled 960 o 1: Variable length interface identifier is enabled (ignored by 961 hosts not supporting) 963 [RFC5175] requires that unused flag bits be set to zero. Therefore, 964 a router that does not support the new flag will not appear to assert 965 that the PIO list prefix list advertised does not support variable 966 length interface identifier. 968 Hosts receiving the Router Advertisement SHOULD only process this 969 flag if the advertising router is a Default Router. Specifically, if 970 the Lifetime field in the Router Advertisement is not zero, otherwise 971 it SHOULD be ignored. 973 Note that although this mechanism uses one of only two reserved flag 974 bits in the RA, an extension mechanism is defined in Section 4 of 975 [RFC5175] in case additional flags are ever required for future 976 extensions. It should be noted that since [RFC5175] was published in 977 2008, no new RA flags have been assigned in the IANA registry. 979 This draft precludes the use of EUI64 based, 64 bit fixed length 980 interface identifier generation algorithms, and allows the use of any 981 standard variable interface identifier generation algorithm for the 982 auto generating variable length interface identifier less than 64 983 bits for example [RFC4941] Privacy Extensions for Stateless Address 984 Autoconfiguration in IPv6 or [RFC7217] Semantically opaque interface 985 identifier with SLAAC privacy extension algorithm for stable variable 986 length interface identifier per [RFC8064]. In this particular case 987 the prefix will be greater than 64 bits and the stable interface 988 identifier will be less than 64 bits. 990 This draft precludes the use of EUI64 based, 64 bit fixed length 991 interface identifier generation algorithms, and allows the use of any 992 standard variable interface identifier generation algorithm for the 993 auto generating variable length interface identifier greater than 64 994 bits for example [RFC4941] Privacy Extensions for Stateless Address 995 Autoconfiguration in IPv6 or [RFC7217] Semantically opaque interface 996 identifier with SLAAC privacy extension algorithm for stable variable 997 length interface identifier per [RFC8064]. In this particular case 998 the prefix will be less than 64 bits and the stable interface 999 identifier will be less than 64 bits. 1001 Draft rfc4941bis Privacy Extension for SLAAC using [RFC4086] Pseudo- 1002 Random Number Generator(PRNG) can also be used as a possible method 1003 of generating greater then 64 bit or less then 64 bit interface 1004 identifier automatically since stated in the draft that the interface 1005 identifier can be generated for any arbitrary length. 1006 https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/ 1008 12. Applicability Statements 1010 The RA flag option for variable length interface identifier is 1011 designed to allow administrators send variable length prefixes in the 1012 PIO list advertisement to the host and hosts supporting this variable 1013 interface identifier option would be able to process the flag and use 1014 the prefix with variable interface identifier in the PIO list . 1016 Administrators MUST only use this variable length interface 1017 identifier flag configured on the router to signal processing of the 1018 longer prefix if they have longer then 64 bit prefix configured on 1019 the router. 1021 13. Router and Operational Considerations 1023 Default IPv6 routers that have the variable interface identifier with 1024 longer than 64 bit prefixes SHOULD be configured by the administrator 1025 to set the variable SLAAC flag to 1. In all other cases the flag 1026 SHOULD NOT be set to 1. 1028 The intent is that the administrator of the router configures the 1029 router to set the variable SLAAC flag if and only if she/he wants to 1030 tell the hosts on the link that the prefixes being sent are greater 1031 then 64 bits and shorter then the standard 64 bit interface 1032 identifier. This is a configuration flag, it is not something that 1033 the router decides on its own. Routers MAY log a configuration error 1034 if the flag is set and the prefix is not longer the 64 bits and the 1035 interface identifier is not shorter then 64 bits. 1037 Routers implementing this document SHOULD log to system or network 1038 management inconsistent setting of the variable SLAAC flag. This 1039 extends the behavior specified in Section 6.2.7 of [RFC4861]. 1041 14. Host Behavior Considerations 1043 Host operating system support will be backwards compatible so host 1044 that do not support the flag will ignore the variable SLAAC flag 1045 being set to 1. In that scenario the router supports the variable 1046 length prefix option and would be configured with the flag set and 1047 would send the variable length prefix to the host, however the host 1048 not supporting the flag will not accept the prefix as it is not 64 1049 bit length and as it is unable to process the flag. Hosts that 1050 support the variable SLAAC RA flag MUST have a configuration option 1051 to ignore or process the flag. The motivation for this configuration 1052 option is for hosts that are capable of processing the variable SLAAC 1053 flag to only act on the flag if they are configured to do so. 1055 If there are multiple IPv6 default routers on a link, they might send 1056 different values of the flag. If at least one IPv6 default router 1057 sends the flag with value 1, the host supporting the flag will 1058 receive will receive and process the flag and accept the PIO list 1059 with variable prefixes. If all IPv6 default routers send the flag 1060 with value 1 the host will receive and process the prefix and flag 1061 from all routers sending the RA. 1063 15. Security Considerations 1065 The administrator should be aware to maintain 64 bit interface 1066 identifier for privacy when connected directly to the internet so 1067 that entropy for optimal heuristics are maintained for security. 1069 Variable length interface identifier shorter then 64 bits should be 1070 only used within corporate intranets and private networks where all 1071 hosts are trusted. 1073 In all cases where the host is on a public network for privacy 1074 concerns to avoid traceability variable interface identifier MUST 1075 never be utilized. 1077 16. IANA Considerations 1079 IANA is requested to assign the new Router Advertisement flag defined 1080 in Section 5 of this document. Bit 6 is the next available bit in 1081 this registry, IANA is requested to use this bit unless there is a 1082 reason to use another bit in this registry. 1084 IANA is also requested to register this new flag bit in the IANA IPv6 1085 ND Router Advertisement flags Registry [IANA-RF]. 1087 17. Contributors 1089 Contributors. 1091 18. Acknowledgements 1093 Ole Troean. 1095 19. References 1097 19.1. Normative References 1099 [I-D.bourbaki-6man-classless-ipv6] 1100 Bourbaki, N., "IPv6 is Classless", draft-bourbaki-6man- 1101 classless-ipv6-05 (work in progress), April 2019. 1103 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1104 Requirement Levels", BCP 14, RFC 2119, 1105 DOI 10.17487/RFC2119, March 1997, 1106 . 1108 [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", 1109 RFC 2450, DOI 10.17487/RFC2450, December 1998, 1110 . 1112 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1113 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1114 . 1116 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 1117 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 1118 . 1120 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 1121 IPv6 Packets over Token Ring Networks", RFC 2470, 1122 DOI 10.17487/RFC2470, December 1998, 1123 . 1125 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 1126 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 1127 . 1129 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 1130 Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, 1131 . 1133 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1134 Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, 1135 . 1137 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1138 Domains without Explicit Tunnels", RFC 2529, 1139 DOI 10.17487/RFC2529, March 1999, 1140 . 1142 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 1143 IPv6 Packets over Frame Relay Networks Specification", 1144 RFC 2590, DOI 10.17487/RFC2590, May 1999, 1145 . 1147 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1148 Listener Discovery (MLD) for IPv6", RFC 2710, 1149 DOI 10.17487/RFC2710, October 1999, 1150 . 1152 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1153 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1154 2001, . 1156 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 1157 over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, 1158 October 2001, . 1160 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 1161 Allocations to Sites", RFC 3177, DOI 10.17487/RFC3177, 1162 September 2001, . 1164 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1165 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1166 August 2002, . 1168 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1169 C., and M. Carney, "Dynamic Host Configuration Protocol 1170 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1171 2003, . 1173 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1174 (IPv6) Addressing Architecture", RFC 3513, 1175 DOI 10.17487/RFC3513, April 2003, 1176 . 1178 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1179 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 1180 August 2003, . 1182 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1183 Listener Discovery (MLD) Protocol", RFC 3590, 1184 DOI 10.17487/RFC3590, September 2003, 1185 . 1187 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1188 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1189 September 2003, . 1191 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1192 in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004, 1193 . 1195 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1196 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1197 DOI 10.17487/RFC3810, June 2004, 1198 . 1200 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1201 Point (RP) Address in an IPv6 Multicast Address", 1202 RFC 3956, DOI 10.17487/RFC3956, November 2004, 1203 . 1205 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1206 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1207 . 1209 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1210 "Randomness Requirements for Security", BCP 106, RFC 4086, 1211 DOI 10.17487/RFC4086, June 2005, 1212 . 1214 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1215 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1216 November 2005, . 1218 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1219 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1220 . 1222 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1223 for IPv6 Hosts and Routers", RFC 4213, 1224 DOI 10.17487/RFC4213, October 2005, 1225 . 1227 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1228 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1229 2006, . 1231 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 1232 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 1233 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 1234 January 2006, . 1236 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1237 Network Address Translations (NATs)", RFC 4380, 1238 DOI 10.17487/RFC4380, February 2006, 1239 . 1241 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1242 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 1243 2006, . 1245 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1246 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 1247 . 1249 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1250 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1251 DOI 10.17487/RFC4548, May 2006, 1252 . 1254 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1255 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1256 DOI 10.17487/RFC4861, September 2007, 1257 . 1259 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1260 Address Autoconfiguration", RFC 4862, 1261 DOI 10.17487/RFC4862, September 2007, 1262 . 1264 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1265 Extensions for Stateless Address Autoconfiguration in 1266 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1267 . 1269 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1270 "Transmission of IPv6 Packets over IEEE 802.15.4 1271 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1272 . 1274 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 1275 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 1276 . 1278 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 1279 Madanapalli, "Transmission of IPv6 via the IPv6 1280 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 1281 DOI 10.17487/RFC5121, February 2008, 1282 . 1284 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 1285 Advertisement Flags Option", RFC 5175, 1286 DOI 10.17487/RFC5175, March 2008, 1287 . 1289 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1290 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1291 DOI 10.17487/RFC5214, March 2008, 1292 . 1294 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1295 and C. Hahn, "IPv6 Unicast Address Assignment 1296 Considerations", RFC 5375, DOI 10.17487/RFC5375, December 1297 2008, . 1299 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 1300 RFC 5453, DOI 10.17487/RFC5453, February 2009, 1301 . 1303 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1304 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1305 June 2009, . 1307 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 1308 DOI 10.17487/RFC5535, June 2009, 1309 . 1311 [RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP 1312 over Ethernet over IEEE 802.16 Networks", RFC 5692, 1313 DOI 10.17487/RFC5692, October 2009, 1314 . 1316 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1317 Model: The Relationship between Links and Subnet 1318 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1319 . 1321 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1322 Infrastructures (6rd) -- Protocol Specification", 1323 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1324 . 1326 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1327 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1328 DOI 10.17487/RFC6052, October 2010, 1329 . 1331 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 1332 DOI 10.17487/RFC6126, April 2011, 1333 . 1335 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1336 NAT64: Network Address and Protocol Translation from IPv6 1337 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1338 April 2011, . 1340 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1341 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1342 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1343 . 1345 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1346 Assignment to End Sites", BCP 157, RFC 6177, 1347 DOI 10.17487/RFC6177, March 2011, 1348 . 1350 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1351 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1352 . 1354 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1355 "IPv6 Flow Label Specification", RFC 6437, 1356 DOI 10.17487/RFC6437, November 2011, 1357 . 1359 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1360 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1361 DOI 10.17487/RFC7084, November 2013, 1362 . 1364 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1365 Kivinen, "Internet Key Exchange Protocol Version 2 1366 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1367 2014, . 1369 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1370 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1371 2016, . 1373 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1374 "Recommendation on Stable IPv6 Interface Identifiers", 1375 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1376 . 1378 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 1379 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 1380 . 1382 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1383 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1384 May 2017, . 1386 19.2. Informative References 1388 [I-D.ietf-6lo-6lobac] 1389 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 1390 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 1391 6lo-6lobac-08 (work in progress), March 2017. 1393 [I-D.ietf-6lo-lowpanz] 1394 Brandt, A. and J. Buron, "Transmission of IPv6 packets 1395 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08 1396 (work in progress), October 2014. 1398 [I-D.ietf-6lowpan-btle] 1399 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1400 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 1401 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 1402 (work in progress), February 2013. 1404 [I-D.templin-aerolink] 1405 Templin, F., "Asymmetric Extended Route Optimization 1406 (AERO)", draft-templin-aerolink-82 (work in progress), May 1407 2018. 1409 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1410 Neighbor Discovery (ND) Trust Models and Threats", 1411 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1412 . 1414 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 1415 the Dynamic Host Configuration Protocol version 4 1416 (DHCPv4)", RFC 4039, DOI 10.17487/RFC4039, March 2005, 1417 . 1419 [RFC4692] Huston, G., "Considerations on the IPv6 Host Density 1420 Metric", RFC 4692, DOI 10.17487/RFC4692, October 2006, 1421 . 1423 [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 1424 Mobility Home Network Models", RFC 4887, 1425 DOI 10.17487/RFC4887, July 2007, 1426 . 1428 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1429 Neighbor Discovery Problems", RFC 6583, 1430 DOI 10.17487/RFC6583, March 2012, 1431 . 1433 [RFC6741] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1434 Protocol (ILNP) Engineering Considerations", RFC 6741, 1435 DOI 10.17487/RFC6741, November 2012, 1436 . 1438 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1439 Combination of Stateful and Stateless Translation", 1440 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1441 . 1443 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1444 "Architectural Considerations of IP Anycast", RFC 7094, 1445 DOI 10.17487/RFC7094, January 2014, 1446 . 1448 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1449 Interface Identifiers with IPv6 Stateless Address 1450 Autoconfiguration (SLAAC)", RFC 7217, 1451 DOI 10.17487/RFC7217, April 2014, 1452 . 1454 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 1455 /64 Prefix from a Third Generation Partnership Project 1456 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 1457 DOI 10.17487/RFC7278, June 2014, 1458 . 1460 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 1461 Weil, "IPv6 Home Networking Architecture Principles", 1462 RFC 7368, DOI 10.17487/RFC7368, October 2014, 1463 . 1465 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 1466 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 1467 Boundary in IPv6 Addressing", RFC 7421, 1468 DOI 10.17487/RFC7421, January 2015, 1469 . 1471 [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", 1472 RFC 8156, DOI 10.17487/RFC8156, June 2017, 1473 . 1475 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1476 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1477 . 1479 Appendix A. ChangeLog 1481 The changes are listed in reverse chronological order, most recent 1482 changes appearing at the top of the list. 1484 -00: initial version. 1486 Authors' Addresses 1488 Gyan Mishra 1489 Verizon Inc. 1491 Email: gyan.s.mishra@verizon.com 1493 Alexandre Petrescu 1494 CEA, LIST 1495 CEA Saclay 1496 Gif-sur-Yvette, Ile-de-France 91190 1497 France 1499 Phone: +33169089223 1500 Email: Alexandre.Petrescu@cea.fr 1502 Naveen Kottapalli 1503 Benu Networks 1504 300 Concord Road 1505 Billerica MA 01821 1506 United States of America 1508 Phone: +1 978 223 4700 1509 Email: nkottapalli@benu.net 1510 Dusan Mudric 1511 Ciena 1512 Canada 1514 Phone: +1-613-670-2425 1515 Email: dmudric@ciena.com 1517 Dmytro Shytyi 1518 SFR 1519 Paris 1520 France 1522 Email: dmytro.shytyi@sfr.com