idnits 2.17.1 draft-carpenter-6man-why64-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 (January 6, 2014) is 3756 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5157 (Obsoleted by RFC 7707) == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-00 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-64share-09 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN B. Carpenter, Ed. 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational T. Chown 5 Expires: July 10, 2014 Univ. of Southampton 6 F. Gont 7 SI6 Networks / UTN-FRH 8 S. Jiang 9 Huawei Technologies Co., Ltd 10 A. Petrescu 11 CEA, LIST 12 A. Yourtchenko 13 cisco 14 January 6, 2014 16 Analysis of the 64-bit Boundary in IPv6 Addressing 17 draft-carpenter-6man-why64-00 19 Abstract 21 The IPv6 unicast addressing format includes a separation between the 22 prefix used to route packets to a subnet and the interface identifier 23 used to specify a given interface connected to that subnet. 24 Historically the interface identifier has been defined as 64 bits 25 long, leaving 64 bits for the prefix. This document discusses the 26 reasons for this fixed boundary and the issues involved in treating 27 it as a variable boundary. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 10, 2014. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Scenarios for prefixes longer than /64 . . . . . . . . . . . 3 65 2.1. Insufficient address space delegated . . . . . . . . . . 3 66 2.2. Concerns over ND cache exhaustion . . . . . . . . . . . . 3 67 3. Interaction with IPv6 specifications . . . . . . . . . . . . 4 68 4. Possible areas of breakage . . . . . . . . . . . . . . . . . 6 69 5. Experimental observations . . . . . . . . . . . . . . . . . . 7 70 6. Privacy issues . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. Implementation and deployment issues . . . . . . . . . . . . 8 72 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 13.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The IPv6 addressing architecture [RFC4291] specifies that a unicast 85 address is divided into n bits of subnet prefix followed by (128-n) 86 bits of interface identifier (IID). Since IPv6 routing is entirely 87 based on variable length subnet masks, there is no architectural 88 assumption that n has any particular fixed value. However, RFC 4291 89 also describes a method of forming interface identifiers from IEEE 90 EUI-64 hardware addresses [IEEE802] and this does specify that such 91 interface identifiers are 64 bits long. Various other methods of 92 forming interface identifiers also specify a length of 64 bits. This 93 has therefore become the de facto length of almost all IPv6 interface 94 identifiers. One exception is documented in [RFC6164], which 95 standardises 127-bit prefixes for inter-router links. 97 Recently it has been clarified that the bits in an IPv6 interface 98 identifier have no particular meaning and should be treated as opaque 99 values [I-D.ietf-6man-ug]. Therefore, there are no bit positions in 100 the currently used 64 bits that need to be preserved. 102 The question is often asked why the boundary is set rigidly at /64. 103 This limits the length of a routing prefix to 64 bits, whereas 104 architecturally, and from the point of view of routing protocols, it 105 could be anything (in theory) between /1 and /128 inclusive. Here, 106 we only discuss the question of a shorter IID, allowing a longer 107 routing prefix. 109 The purpose of this document is to analyse the issues around this 110 question. We make no proposal for change, but we do analyse the 111 possible effects of a change. 113 2. Scenarios for prefixes longer than /64 115 In this section we describe existing scenarios where prefixes longer 116 than /64 have been used or proposed. 118 2.1. Insufficient address space delegated 120 A site may not be delegated a sufficiently large prefix from which to 121 allocate a /64 prefix to all of its internal subnets. In this case 122 the site may either determine that it does not have enough address 123 space to number all its network elements and thus, at the very best, 124 be only partially operational, or it may choose to use internal 125 prefixes longer than /64 to allow multiple subnets and the hosts 126 within them to be configured with addresses. 128 In this case, the site might choose, for example, to use a /80 per 129 subnet, in combination with hosts using either manually configured 130 addressing or DHCPv6. 132 It should be noted that the homenet architecture text 133 [I-D.ietf-homenet-arch] states that a CPE should consider the lack of 134 sufficient address space to be an error condition, rather than using 135 prefixes longer than /64 internally. 137 2.2. Concerns over ND cache exhaustion 139 A site may be concerned that it is open to neighbour discovery (ND) 140 cache exhaustion attacks, whereby an attacker sends a large number of 141 messages in rapid succession to a series of (most likely inactive) 142 host addresses within a specific subnet, in an attempt to fill a 143 router's ND cache with ND requests pending completion, in so doing 144 denying correct operation to active devices on the network. 146 An example would be to use a /120 prefix, limiting the number of 147 addresses in the subnet to be similar to an IPv4 /24 prefix, which 148 should not cause any concerns for ND cache exhaustion. Note that the 149 prefix does need to be quite long for this scenario to be valid. The 150 number of theoretically possible ND cache slots on the segment needs 151 to be of the same order of magnitude as the actual number of hosts. 152 Thus small increases from the /64 prefix length do not have a 153 noticeable impact: even 2^32 potential entries, a factor of two 154 billion decrease compared to 2^64, is still more than enough to 155 exhaust the memory on current routers. 157 As in the previous scenario, hosts would likely be manually 158 configured with addresses, or use DHCPv6. 160 3. Interaction with IPv6 specifications 162 The precise 64-bit length of the Interface ID is widely mentioned in 163 numerous RFCs describing various aspects of IPv6. It is not 164 straightforward to distinguish cases where this has normative impact 165 or affects interoperability. 167 First and foremost, the RFCs describing the architectural aspects of 168 IPv6 addressing explicitly state, refer and repeat this apparently 169 immutable value: Addressing Architecture [RFC4291], Reserved 170 Interface Identifiers [RFC5453], ILNP [RFC6741]. Customer Edge 171 routers impose /64 for their interfaces [RFC7084]. Only the IPv6 172 Subnet Model [RFC5942] refers to the assumption of /64 prefix length 173 as a potential implementation error. 175 Numerous IPv6-over-foo documents make mandatory statements with 176 respect to the 64-bit length of the Interface ID to be used during 177 the Stateless Autoconfiguration. These documents are [RFC2464] 178 (Ethernet), [RFC2467] (FDDI), [RFC2470] (Token Ring), [RFC2492] 179 (ATM), [RFC2497] (ARCnet), [RFC2590] (Frame Relay), [RFC3146] (IEEE 180 1394), [RFC4338] (Fibre Channel), [RFC4944] (IEEE 802.15.4), 181 [RFC5072] (PPP), [RFC5121] [RFC5692] (IEEE 802.16), 182 [I-D.ietf-6lowpan-btle], [I-D.ietf-6man-6lobac], 183 [I-D.brandt-6man-lowpanz]. 185 To a lesser extent, the address configuration RFCs themselves may in 186 some way assume the 64-bit length of an Interface ID (SLAAC for the 187 link-local addresses, DHCPv6 for the potentially assigned 188 EUI-64-based IP addresses, Default Router Preferences [RFC4191] for 189 its impossibility of Prefix Length 4, Optimistic Duplicate Address 190 Detection [RFC4429] which computes 64-bit-based collision 191 probabilities). 193 The MLDv2 protocol [RFC3810] mandates all queries be sent with the 194 fe80::/64 link-local source address prefix and subsequently bases the 195 querier election algorithm on the link-local subnet prefix length of 196 length /64. 198 The IPv6 Flow Label Specification [RFC6437] gives an example of a 199 20-bit hash function generation which relies on splitting an IPv6 200 address in two equally-sized 64bit-length parts. 202 IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic 203 transition and Teredo rely on the use of IIDs of length 64. 205 The proposed method [I-D.ietf-v6ops-64share] of extending an assigned 206 /64 prefix from a smartphone's cellular interface to its WiFi link 207 relies on prefix length, and implicitely on the length of the 208 Interface ID, to be valued at 64. 210 The HBA, CGA and SeND RFCs rely on the 64bit identifier length, as do 211 the Privacy extensions and some examples in IKEv2bis. 213 464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. 214 However, it also discusses the possibility of using the interface 215 address on the device as the endpoint for the traffic, thus 216 potentially removing this dependency. 218 [RFC2526] reserves a number of subnet anycast addresses by reserving 219 some anycast IIDs. An anycast IID so reserved cannot be less than 7 220 bits long. This means that a subnet prefix length longer than /121 221 is not possible, and a subnet of exactly /121 would be useless since 222 all its identifiers are reserved. It also means that half of a /120 223 is reserved for anycast. This could of course be fixed in the way 224 described for /127 in [RFC6164], i.e., avoiding the use of anycast 225 within a /120 subnet. 227 Other RFCs refer to mandatory alignment on 64-bit boundaries, 64-bit 228 data structures, 64-bit counters in MIB, 64-bit sequence numbers and 229 cookies in security. Finally, the 64 number may be considered 230 'magic' in some RFCs, (e.g., 64k limits in DNS and Base64 encodings 231 in MIME) but this of course has no influence on the length of the 232 IID. All the same, a programmer might be lulled into assuming a 233 comfortable rule of thumb that an IID is always length 64. 235 4. Possible areas of breakage 237 This section discusses several specific aspects of IPv6 where we can 238 expect operational breakage with subnet prefixes other than /64. 240 o Multicast: [RFC3306] defines a method for generating IPv6 241 multicast group addresses based on unicast prefixes. This method 242 assumes a longest network prefix of 64 bits. If a longer subnet 243 is used, there is no way to generate a specific multicast group 244 address using this method. In such cases the administrator would 245 need to use a shorter prefix from within their allocation (a /64 246 or shorter) from which to generate the group address. 248 Similarly [RFC3956], which specifies Embedded-RP, allowing IPv6 249 multicast rendezvous point addresses to be embedded in the 250 multicast group address, would also fail, as the scheme assumes a 251 maximum prefix length of 64 bits. 253 o CGA: The Cryptographically Generated Address format (CGA, 254 [RFC3972]) is heavily based on a /64 interface identifier. 255 [RFC3972] has defined a detailed algorithm how to generate 64-bit 256 interface identifier from a public key and a 64-bit subnet prefix. 257 Breaking the /64 boundary would certainly break the current CGA 258 definition. However, CGA might benefit in a redefined version if 259 more bits are used for interface identifier (which means shorter 260 prefix length). For now, 59 bits are used for cryptographic 261 purposes. The more bits are available, the stronger CGA could be. 262 Conversely, longer prefixes would weaken CGA. 264 o NAT64: Both stateless [RFC6052] NAT64 and stateful NAT64 [RFC6146] 265 are flexible for the prefix length. [RFC6052] has defined 266 multiple address formats for NAT64. In Section 2 "IPv4-Embedded 267 IPv6 Prefix and Format" of [RFC6052], the network-specific prefix 268 could be one of /32, /40, /48, /56, /64 and /96. The remaining 269 part of the IPv6 address is constructed by a 32-bit IPv4 address, 270 a 8-bit u byte and a variable length suffix (there is no u byte 271 and suffix in the case of 96-bit Well-Known Prefix). NAT64 is 272 therefore OK with a boundary out to /96, but not longer. 274 o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also 275 bound to /64 boundary. NPTv6 maps a /64 prefix with other /64 276 prefix. When the NPTv6 Translator is configured with a /48 or 277 shorter prefix, the 64-bit interface identifier is kept unmodified 278 during translation. However, the /64 boundary might be broken as 279 long as the "inside" and "outside" prefix has the same length. 281 o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is 282 designed around the /64 boundary, since it relies on locally 283 unique 64-bit interface identifiers. While a re-design to use 284 longer prefixes is not inconceivable, this would need major 285 changes to the existing specification for the IPv6 version of 286 ILNP. 288 o shim6: The Multihoming Shim Protocol for IPv6 (shim6) [RFC5533] in 289 its insecure form treats IPv6 address as opaque 128-bit objects. 290 However, to secure the protocol against spoofing, it is essential 291 to either use CGAs (see above) or Hash-Based Addresses (HBA) 292 [RFC5535]. Like CGAs, HBAs are generated using a procedure that 293 assumes a 64-bit identifier. Therefore, in effect, secure shim6 294 is affected by the /64 boundary exactly like CGAs. 296 o others? 298 It goes without saying that if prefixes longer than /64 are to be 299 used, all hosts must be capable of generating IIDs shorter than 64 300 bits, in order to follow the auto-configuration procedure correctly 301 [RFC4862]. There is however the rather special case of the link- 302 local prefix. While RFC 4862 is careful not to define any specific 303 length of link-local prefix within fe80::/10, operationally there 304 would be a problem unless all hosts on a link use IIDs of the same 305 length to configure a link-local address during reboot. Typically 306 today the choice of /64 for the link-local prefix length is hard- 307 coded per interface. There might be no way to change this except 308 conceivably by manual configuration, which will be impossible if the 309 host concerned has no local user interface. 311 5. Experimental observations 313 Still to be written - some experiments are underway, and more input 314 is welcomed. Some points made earlier on the v6ops list can be 315 incorporated here. 317 6. Privacy issues 319 The length of the interface identifier has implications for privacy 320 [I-D.ietf-6man-ipv6-address-generation-privacy]. In any case in 321 which the value of the identifier is intended to be hard to guess, 322 whether or not it is cryptographically generated, it is apparent that 323 more bits are better. For example, if there are only 20 bits to be 324 guessed, at most just over a million guesses are needed, today well 325 within the capacity of a low cost attack mechanism. It is hard to 326 state in general how many bits are enough to protect privacy, since 327 this depends on the resources available to the attacker, but it seems 328 clear that a privacy solution needs to resist an attack requiring 329 billions rather than millions of guesses. Trillions would be better, 330 suggesting that at least 40 bits should be available. Thus we can 331 argue that subnet prefixes longer than say /80 might raise privacy 332 concerns by making the IID guessable. 334 A prefix long enough to limit the number of addresses comparably to 335 an IPv4 subnet, such as /120, would create exactly the same situation 336 for privacy as IPv4. 338 7. Implementation and deployment issues 340 Still to be written - suggestions welcome. Some points made earlier 341 on the v6ops list can be incorporated here. 343 8. Conclusion 345 Summary of pros and cons; risks (write this bit last!) 347 9. Security Considerations 349 In addition to the privacy issues mentioned in Section 6, and the 350 issues mentioned with CGAs and HBAs in Section 4, the length of the 351 subnet prefix affects the matter of defence against scanning attacks 352 [RFC5157]. Assuming the attacker has discovered or guessed the 353 prefix length, a longer prefix reduces the space that the attacker 354 needs to scan, e.g., to only 256 addresses if the prefix is /120. On 355 the other hand, if the attacker has not discovered the prefix length 356 and assumes it to be /64, routers can trivially discard attack 357 packets that do not fall within an actual subnet. 359 However, assume that an attacker finds one valid address A and then 360 starts a scanning attack by scanning "outwards" from A, by trying 361 A+1, A-1, A+2, A-2, etc. This attacker will easily find all hosts in 362 any subnet with a long prefix, because they will have addresses close 363 to A. We therefore conclude that any prefix containing densely packed 364 valid addresses is vulnerable to a scanning attack, without the 365 attacker needing to guess the prefix length. Therefore, to preserve 366 IPv6's advantage over IPv4 in resisting scanning attacks, it is 367 important that subnet prefixes are short enough to allow sparse 368 allocation of identifiers within each subnet. The considerations are 369 similar to those for privacy, and we can again argue that prefixes 370 longer than say /80 might significantly increase vulnerability. 371 Ironically, this argument is exactly converse to the argument for 372 longer prefixes to resist an ND cache attack, as described in 373 Section 2.2. 375 10. IANA Considerations 377 This document requests no action by IANA. 379 11. Acknowledgements 381 Valuable comments were received from Stig Venaas, ... and other 382 participants in the IETF. 384 This document was produced using the xml2rfc tool [RFC2629]. 386 12. Change log [RFC Editor: Please remove] 388 draft-carpenter-6man-why64-00: original version, 2014-01-06. 390 13. References 392 13.1. Normative References 394 [I-D.ietf-6man-ug] 395 Carpenter, B. and S. Jiang, "Significance of IPv6 396 Interface Identifiers", draft-ietf-6man-ug-06 (work in 397 progress), December 2013. 399 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 400 Networks", RFC 2464, December 1998. 402 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 403 Networks", RFC 2467, December 1998. 405 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 406 IPv6 Packets over Token Ring Networks", RFC 2470, December 407 1998. 409 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 410 Networks", RFC 2492, January 1999. 412 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 413 Networks", RFC 2497, January 1999. 415 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 416 Addresses", RFC 2526, March 1999. 418 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 419 IPv6 Packets over Frame Relay Networks Specification", RFC 420 2590, May 1999. 422 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 423 over IEEE 1394 Networks", RFC 3146, October 2001. 425 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 426 Multicast Addresses", RFC 3306, August 2002. 428 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 429 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 431 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 432 Point (RP) Address in an IPv6 Multicast Address", RFC 433 3956, November 2004. 435 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 436 RFC 3972, March 2005. 438 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 439 More-Specific Routes", RFC 4191, November 2005. 441 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 442 Architecture", RFC 4291, February 2006. 444 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 445 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 446 over Fibre Channel", RFC 4338, January 2006. 448 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 449 for IPv6", RFC 4429, April 2006. 451 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 452 Address Autoconfiguration", RFC 4862, September 2007. 454 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 455 "Transmission of IPv6 Packets over IEEE 802.15.4 456 Networks", RFC 4944, September 2007. 458 [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 459 PPP", RFC 5072, September 2007. 461 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 462 Madanapalli, "Transmission of IPv6 via the IPv6 463 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 464 February 2008. 466 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 467 5157, March 2008. 469 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 470 5453, February 2009. 472 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 473 Shim Protocol for IPv6", RFC 5533, June 2009. 475 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 476 2009. 478 [RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP 479 over Ethernet over IEEE 802.16 Networks", RFC 5692, 480 October 2009. 482 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 483 Model: The Relationship between Links and Subnet 484 Prefixes", RFC 5942, July 2010. 486 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 487 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 488 October 2010. 490 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 491 NAT64: Network Address and Protocol Translation from IPv6 492 Clients to IPv4 Servers", RFC 6146, April 2011. 494 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 495 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 496 Router Links", RFC 6164, April 2011. 498 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 499 Translation", RFC 6296, June 2011. 501 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 502 "IPv6 Flow Label Specification", RFC 6437, November 2011. 504 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 505 (ILNP) Engineering Considerations", RFC 6741, November 506 2012. 508 [RFC7084] Singh, H., Beebee, W., Donley, C., Stark, B., 509 "Basic Requirements for IPv6 Customer Edge 510 Routers", RFC 7084, November 2013. 512 13.2. Informative References 514 [I-D.brandt-6man-lowpanz] 515 Brandt, A. and J. Buron, "Transmission of IPv6 packets 516 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 517 (work in progress), June 2013. 519 [I-D.ietf-6lowpan-btle] 520 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 521 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 522 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 523 (work in progress), February 2013. 525 [I-D.ietf-6man-6lobac] 526 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 527 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 528 6man-6lobac-01 (work in progress), March 2012. 530 [I-D.ietf-6man-ipv6-address-generation-privacy] 531 Cooper, A., Gont, F., and D. Thaler, "Privacy 532 Considerations for IPv6 Address Generation Mechanisms", 533 draft-ietf-6man-ipv6-address-generation-privacy-00 (work 534 in progress), October 2013. 536 [I-D.ietf-homenet-arch] 537 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 538 "IPv6 Home Networking Architecture Principles", draft- 539 ietf-homenet-arch-11 (work in progress), October 2013. 541 [I-D.ietf-v6ops-64share] 542 Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64 543 Prefix from a 3GPP Mobile Interface to a LAN link", draft- 544 ietf-v6ops-64share-09 (work in progress), October 2013. 546 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 547 Networks: Overview and Architecture", IEEE Std 802-2001 548 (R2007), 2007. 550 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 551 June 1999. 553 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 554 (ILNP) Engineering Considerations", RFC 6741, November 555 2012. 557 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 558 Combination of Stateful and Stateless Translation", RFC 559 6877, April 2013. 561 Authors' Addresses 563 Brian Carpenter (editor) 564 Department of Computer Science 565 University of Auckland 566 PB 92019 567 Auckland 1142 568 New Zealand 570 Email: brian.e.carpenter@gmail.com 572 Tim Chown 573 University of Southampton 574 Southampton, Hampshire SO17 1BJ 575 United Kingdom 577 Email: tjc@ecs.soton.ac.uk 579 Fernando Gont 580 SI6 Networks / UTN-FRH 581 Evaristo Carriego 2644 582 Haedo, Provincia de Buenos Aires 1706 583 Argentina 585 Email: fgont@si6networks.com 587 Sheng Jiang 588 Huawei Technologies Co., Ltd 589 Q14, Huawei Campus 590 No.156 Beiqing Road 591 Hai-Dian District, Beijing 100095 592 P.R. China 594 Email: jiangsheng@huawei.com 596 Alexandru Petrescu 597 CEA, LIST 598 CEA Saclay 599 Gif-sur-Yvette, Ile-de-France 91190 600 France 602 Email: Alexandru.Petrescu@cea.fr 603 Andrew Yourtchenko 604 cisco 605 7a de Kleetlaan 606 Diegem 1830 607 Belgium 609 Email: ayourtch@cisco.com