idnits 2.17.1 draft-ietf-v6ops-security-overview-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1623. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 2005) is 6778 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) == Unused Reference: 'I-D.ietf-v6ops-natpt-to-exprmntl' is defined on line 1245, but no explicit reference was found in the text == Unused Reference: 'I-D.dupont-ipv6-rfc3041harmful' is defined on line 1318, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-ndproxy' is defined on line 1333, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-ipv6-privacy-addrs-v2-04 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-natpt-to-exprmntl-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-natpt-to-exprmntl (ref. 'I-D.ietf-v6ops-natpt-to-exprmntl') == Outdated reference: A later version (-08) exists of draft-ietf-vrrp-ipv6-spec-07 ** Downref: Normative reference to an Informational RFC: RFC 2375 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3964 == Outdated reference: A later version (-02) exists of draft-chown-v6ops-port-scanning-implications-01 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-ipv6-dns-issues-11 == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-ndproxy-03 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-nap-01 == Outdated reference: A later version (-05) exists of draft-krishnan-ipv6-hopbyhop-00 == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-02 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations E. Davies 3 Internet-Draft Consultant 4 Expires: April 9, 2006 S. Krishnan 5 Ericsson 6 P. Savola 7 CSC/Funet 8 October 6, 2005 10 IPv6 Transition/Co-existence Security Considerations 11 draft-ietf-v6ops-security-overview-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 9, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The transition from a pure IPv4 network to a network where IPv4 and 45 IPv6 co-exist brings a number of extra security considerations that 46 need to be taken into account when deploying IPv6 and operating the 47 dual-protocol network and the associated transition mechanisms. This 48 document attempts to give an overview of the various issues grouped 49 into three categories: 50 o issues due to the IPv6 protocol itself, 51 o issues due to transition mechanisms, and 52 o issues due to IPv6 deployment. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4 58 2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 4 59 2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 4 60 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 5 61 2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 5 62 2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 6 63 2.1.5. Anycast Traffic Identification and Security . . . . . 7 64 2.1.6. Address Privacy Extensions Interact with DDoS 65 Defenses . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1.7. Dynamic DNS: Stateless Address Auto-Configuration, 67 Privacy Extensions and SEND . . . . . . . . . . . . . 8 68 2.1.8. Extension Headers . . . . . . . . . . . . . . . . . . 8 69 2.1.9. Fragmentation: Reassembly and Deep Packet 70 Inspection . . . . . . . . . . . . . . . . . . . . . . 11 71 2.1.10. Fragmentation Related DoS Attacks . . . . . . . . . . 11 72 2.1.11. Link-Local Addresses and Securing Neighbor 73 Discovery . . . . . . . . . . . . . . . . . . . . . . 12 74 2.1.12. Securing Router Advertisements . . . . . . . . . . . . 13 75 2.1.13. Host to Router Load Sharing . . . . . . . . . . . . . 13 76 2.1.14. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 14 77 2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 14 78 2.3. Increased End-to-End Transparency . . . . . . . . . . . . 15 79 2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 15 80 2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 16 81 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 17 82 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 17 83 3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 18 84 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 85 Network Security Assumptions . . . . . . . . . . . . . . . 19 86 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 20 87 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 20 88 4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 22 89 4.3. Addressing Schemes and Securing Routers . . . . . . . . . 22 90 4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 22 91 4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 23 92 4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 24 93 4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 24 94 4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 25 95 4.8. Operational Factors when Enabling IPv6 in the Network . . 25 96 4.9. Ingress Filtering Issues Due to Privacy Addresses . . . . 26 97 4.10. Security Issues Due to ND Proxies . . . . . . . . . . . . 26 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 103 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 104 Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 32 105 Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 33 106 B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 33 107 B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 33 108 B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 34 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 110 Intellectual Property and Copyright Statements . . . . . . . . . . 36 112 1. Introduction 114 The transition from a pure IPv4 network to a network where IPv4 and 115 IPv6 co-exist brings a number of extra security considerations that 116 need to be taken into account when deploying IPv6 and operating the 117 dual-protocol network with its associated transition mechanisms. 118 This document attempts to give an overview of the various issues 119 grouped into three categories: 120 o issues due to the IPv6 protocol itself, 121 o issues due to transition mechanisms, and 122 o issues due to IPv6 deployment. 124 It is important to understand that we have to be concerned not about 125 replacing IPv4 with IPv6 (in the short term), but with adding IPv6 to 126 be operated in parallel with IPv4 [I-D.savola-v6ops-transarch]. 128 This document also describes two matters which have been wrongly 129 identified as potential security concerns for IPv6 in the past and 130 explains why they are unlikely to cause problems: considerations 131 about probing/mapping IPv6 addresses (Appendix A), and considerations 132 with respect to privacy in IPv6 (Appendix B). 134 2. Issues Due to IPv6 Protocol 136 2.1. IPv6 Protocol-specific Issues 138 There are significant differences between the features of IPv6 and 139 IPv4: some of these specification changes may result in potential 140 security issues. Several of these issues have been discussed in 141 separate drafts but are summarized here to avoid normative references 142 which may not become RFCs. The following specification-related 143 problems have been identified, but this is not necessarily a complete 144 list: 146 2.1.1. Routing Headers and Hosts 148 All IPv6 nodes must be able to process Routing Headers [RFC2460]. 149 This RFC can be interpreted, although it is not clearly stated, to 150 mean that all nodes (including hosts) must have this processing 151 enabled. This can result in hosts forwarding received traffic if 152 there are segments left in the Routing Header when it arrives at the 153 host. 155 A number of potential security issues associated with this behavior 156 were documented in [I-D.savola-ipv6-rh-hosts]. Some of these issues 157 have been resolved (a separate routing header type is now used for 158 Mobile IPv6 [RFC3775] and ICMP Traceback has not been standardized), 159 but two issues remain: 160 o Routing headers can be used to evade access controls based on 161 destination addresses. This could be achieved by sending a packet 162 ostensibly to a publicly accessible host address but with a 163 routing header containing a 'forbidden' address. If the publicly 164 accessible host is processing routing headers it will forward the 165 packet to the destination address in the routing header which 166 would have been forbidden by the packet filters if the address had 167 been in the destination field when the packet was checked. 168 o If the packet source address in the previous case can be spoofed, 169 any host could be used to mediate an anonymous reflection denial- 170 of-service attack by having any publicly accessible host redirect 171 the attack packets. 173 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes 175 In addition to the basic Routing Header (Type 0), which is intended 176 to influence the trajectory of a packet through a network by 177 specifying a sequence of router 'waypoints', Routing Header (Type 2) 178 has been defined as part of the Mobile IPv6 specifications in 179 [RFC3775]. The Type 2 Routing Header is intended for use by hosts to 180 handle 'interface local' forwarding needed when packets are sent to 181 the care-of address of a mobile node which is away from its home 182 address. 184 It is important that nodes treat the different types of routing 185 header appropriately. It should be possible to apply separate 186 filtering rules to the different types of Routing Header. By design, 187 hosts must process Type 2 Routing Headers to support Mobile IPv6 but 188 routers should not: to avoid the issues in Section 2.1.1 it may be 189 desirable to forbid or limit the processing of Type 0 Routing Headers 190 in hosts and some routers. 192 Routing Headers are an extremely powerful and general capability. 193 Alternative future uses of Routing Headers need to be carefully 194 assessed to ensure that they do not open new avenues of attack that 195 can be exploited. 197 2.1.3. Site-scope Multicast Addresses 199 IPv6 supports multicast addresses with site scope which can 200 potentially allow an attacker to identify certain important resources 201 on the site if misused. 203 Particular examples are the 'all routers' (FF05::2) and 'all Dynamic 204 Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses 205 defined in [RFC2375]: an attacker that is able to infiltrate a 206 message destined for these addresses on to the site will potentially 207 receive in return information identifying key resources on the site. 208 This information can then be the target of directed attacks ranging 209 from simple flooding to more specific mechanisms designed to subvert 210 the device. 212 Some of these addresses have current legitimate uses within a site. 213 The risk can be minimized by ensuring that all firewalls and site 214 boundary routers are configured to drop packets with site scope 215 destination addresses. Also nodes should not join multicast groups 216 for which there is no legitimate use on the site and site routers 217 should be configured to drop packets directed to these unused 218 addresses. 220 2.1.4. ICMPv6 and Multicast 222 It is possible to launch a denial-of-service (DoS) attack using IPv6 223 which could be amplified by the multicast infrastructure. 225 Unlike ICMP for IPv4, ICMPv6 [RFC2463] allows error notification 226 responses to be sent when certain unprocessable packets are sent to 227 multicast addresses. 229 The cases in which responses are sent are: 230 o The received packet is longer than the next link MTU: 'Packet Too 231 Big' responses are needed to support Path MTU Discovery for 232 multicast traffic. 233 o The received packet contains an unrecognized option in a hop-by- 234 hop or destination options extension header with the first two 235 bits of the option type set to binary '10': 'Parameter Problem' 236 responses are intended to inform the source that some or all of 237 the recipients cannot handle the option in question. 239 If an attacker can craft a suitable packet sent to a multicast 240 destination, it may be possible to elicit multiple responses directed 241 at the victim (the spoofed source of the multicast packet). On the 242 other hand, the use of 'reverse path forwarding' checks to eliminate 243 loops in multicast forwarding automatically limits the range of 244 addresses which can be spoofed. 246 In practice an attack using oversize packets is unlikely to cause 247 much amplification unless the attacker is able to carefully tune the 248 packet size to exploit a network with smaller MTU in the edge than 249 the core. Similarly a packet with an unrecognized hop-by-hop option 250 would be dropped by the first router. However a packet with an 251 unrecognized destination option could generate multiple responses. 253 In addition to amplification, this kind of attack would potentially 254 consume large amounts of forwarding state resources in routers on 255 multicast-enabled networks. These attacks are discussed in more 256 detail in [I-D.savola-v6ops-firewalling]. 258 2.1.5. Anycast Traffic Identification and Security 260 IPv6 introduces the notion of anycast addresses and services. 261 Originally the IPv6 standards disallowed using an anycast address as 262 the source address of a packet. Responses from an anycast server 263 would therefore supply a unicast address for the responding server. 264 To avoid exposing knowledge about the internal structure of the 265 network, it is recommended that anycast servers now take advantage of 266 the ability to return responses with the anycast address as the 267 source address if possible. 269 If the server needs to use a unicast address for any reason, it may 270 be desirable to consider using specialized addresses for anycast 271 servers which are not used for any other part of the network to 272 restrict the information exposed. Alternatively operators may wish 273 to restrict the use of anycast services from outside the domain, thus 274 requiring firewalls to filter anycast requests. For this purpose, 275 firewalls need to know which addresses are being used for anycast 276 services: these addresses are arbitrary and not distinguishable from 277 any other IPv6 unicast address by structure or pattern. 279 One particular class of anycast addresses that should be given 280 special attention is the set of Subnet-Router anycast addresses 281 defined in The IPv6 Addressing Architecture [RFC3513]. All routers 282 are required to support these addresses for all subnets for which 283 they have interfaces. For most subnets using global unicast 284 addresses, filtering anycast requests to these addresses can be 285 achieved by dropping packets with the lower 64 bits (the Interface 286 Identifier) set to all zeroes. 288 2.1.6. Address Privacy Extensions Interact with DDoS Defenses 290 The purpose of the privacy extensions for stateless address auto- 291 configuration [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] is to change 292 the interface identifier (and hence the global scope addresses 293 generated from it) from time to time. By varying the addresses used, 294 eavesdroppers and other information collectors find it more difficult 295 to identify which transactions actually relate to a specific node. 297 A security issue may result from this if the frequency of node 298 address change is sufficiently great to achieve the intended aim of 299 the privacy extensions: with a relatively high rate of change, the 300 observed behavior of the node could look very like that of a 301 compromised node which was the source of a distributed denial of 302 service (DDoS). It would thus be difficult for any future defenses 303 against DDoS attacks to distinguish between a high rate of change of 304 addresses resulting from genuine use of the privacy extensions and a 305 compromised node being used as the source of a DDoS with 'in-prefix' 306 spoofed source addresses as described in [I-D.dupont-ipv6- 307 rfc3041harmful]. 309 Even if a node is well behaved, the change in the address could make 310 it harder for a security administrator to define a policy rule (e.g. 311 access control list) that takes into account a specific node. 313 2.1.7. Dynamic DNS: Stateless Address Auto-Configuration, Privacy 314 Extensions and SEND 316 The introduction of Stateless Address Auto-Configuration (SLAAC) 317 [RFC2462] with IPv6 provides an additional challenge to the security 318 of Dynamic DNS (DDNS). With manual addressing or the use of DHCP, 319 the number of security associations that need to be maintained to 320 secure access to the DNS server is limited, assuming any necessary 321 updates are carried out by the DHCP server. This is true equally for 322 IPv4 and IPv6. 324 Since SLAAC does not make use of a single and potentially trusted 325 DHCP server, but depends on the node obtaining the address, securing 326 the insertion of updates into DDNS may need a security association 327 between each node and the DDNS server. This is discussed further in 328 [I-D.ietf-dnsop-ipv6-dns-issues]. 330 Using the Privacy Extensions to SLAAC [RFC3041][I-D.ietf-ipv6- 331 privacy-addrs-v2] may significantly increase the rate of updates of 332 DDNS. Even if a node using the Privacy Extensions does not publish 333 its address for 'forward' lookup (as that would effectively 334 compromise the privacy which it is seeking), it may still need to 335 update the reverse DNS records so that reverse routability checks can 336 be carried out. If the rate of change needed to achieve real privacy 337 has to be increased as is mentioned in Section 2.1.6 the update rate 338 for DDNS may be excessive. 340 Similarly, the cryptographically generated addresses used by SEND 341 [RFC3971] are expected to be periodically regenerated in line with 342 recommendations for maximum key lifetimes. This regeneration could 343 also impose a significant extra load on DDNS. 345 2.1.8. Extension Headers 347 A number of issues relating to the specification of IPv6 Extension 348 headers have been identified. Several of these are discussed in 349 [I-D.savola-v6ops-firewalling]. 351 2.1.8.1. Processing Extension Headers in Middleboxes 353 In IPv4 deep packet inspection techniques are used to implement 354 policing and filtering both as part of routers and in middleboxes 355 such as firewalls. Fully extending these techniques to IPv6 would 356 require inspection of all the extension headers in a packet. This is 357 essential to ensure that policy constraints on the use of certain 358 headers and options are enforced and to remove, at the earliest 359 opportunity, packets containing potentially damaging unknown options. 361 This requirement appears to conflict with Section 4 of the IPv6 362 specification in [RFC2460] which requires that destination options 363 are not processed at all until the packet reaches the appropriate 364 destination (either the final destination or a routing header 365 waypoint). 367 Also [RFC2460] forbids processing the headers other than in the order 368 in which they appear in the packet. 370 A further ambiguity relates to whether an intermediate node should 371 discard a packet which contains a header or destination option which 372 it does not recognize. If the rules above are followed slavishly, it 373 is not (or may not be) legitimate for the intermediate node to 374 discard the packet because it should not be processing those headers 375 or options. 377 [RFC2460] therefore does not appear to take account of the behavior 378 of middleboxes and other non-final destinations which may be 379 inspecting the packet, and thereby potentially limits the security 380 protection of these boxes. 382 2.1.8.2. Processing Extension Header Chains 384 There is a further problem for middleboxes that want to examine the 385 transport headers which are located at the end of the IPv6 header 386 chain. In order to locate the transport header or other protocol 387 data unit, the node has to parse the header chain. 389 The IPv6 specification [RFC2460] does not mandate the use of the 390 Type-Length-Value format with a fixed layout for the start of each 391 header although it is used for the majority of headers currently 392 defined. (Only the Type field is guaranteed in size and offset). 394 A middlebox cannot therefore guarantee to be able to process header 395 chains which may contain headers defined after the box was 396 manufactured. As noted in Section 2.1.8.1, middleboxes ought not to 397 have to know about all header types in use but still need to be able 398 to skip over such headers to find the transport PDU start. This 399 either limits the security which can be applied in firewalls or makes 400 it difficult to deploy new extension header types. 402 At the time of writing, only the Fragment Header does not fully 403 conform to the TLV format used for other extension headers. In 404 practice, many firewalls reconstruct fragmented packets before 405 performing deep packet inspection, so this divergence is less 406 problematic than it might have been, and is at least partially 407 justified because the full header chain is not present in all 408 fragments. 410 Destination Options may also contain unknown options. However, the 411 options are encoded in TLV format so that intermediate nodes can skip 412 over them during processing, unlike the enclosing extension headers. 414 2.1.8.3. Unknown Headers/Destination Options and Security Policy 416 A strict security policy might dictate that packets containing either 417 unknown headers or destination options are discarded by firewalls or 418 other filters. This requires the firewall to process the whole 419 extension header chain which may be currently in conflict with the 420 IPv6 specification as discussed in Section 2.1.8.1. 422 Even if the firewall does inspect the whole header chain, it may not 423 be sensible to discard packets with items unrecognized by the 424 firewall: the intermediate node has no knowledge of which options and 425 headers are implemented in the destination node. Hence it is highly 426 desirable to make the discard policy configurable. This will avoid 427 firewalls dropping packets with legitimate items that they do not 428 recognize because their hardware or software is not aware of a new 429 definition. 431 2.1.8.4. Excessive Hop-by-Hop Options 433 IPv6 does not limit the number of hop by hop options which can be 434 present in a hop-by-hop option header. The lack of a limit can be 435 used to mount denial of service attacks affecting all nodes on a path 436 as described in [I-D.krishnan-ipv6-hopbyhop]. 438 2.1.8.5. Overuse of Router Alert Option 440 The IPv6 router alert option specifies a hop-by-hop option that, if 441 present, signals the router to take a closer look at the packet. 442 This can be used for denial of service attacks. By sending a large 443 number of packets containing a router alert option an attacker can 444 deplete the processor cycles on the routers available to legitimate 445 traffic. 447 2.1.9. Fragmentation: Reassembly and Deep Packet Inspection 449 The current specifications of IPv6 in [RFC2460] do not mandate any 450 minimum packet size for the fragments of a packet before the last 451 one, except for the need to carry the unfragmentable part in all 452 fragments. 454 The unfragmentable part does not include the transport port numbers 455 so that it is possible that the first fragment does not contain 456 sufficient information to carry out deep packet inspection involving 457 the port numbers. 459 Also the reassembly rules for fragmented packets in [RFC2460] do not 460 mandate behavior which would minimize the effects of overlapping 461 fragments. 463 Depending on the implementation of packet reassembly and the 464 treatment of packet fragments in firewalls and other nodes which use 465 deep packet inspection for traffic filtering, this potentially leaves 466 IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128] 467 for IPv4. 469 There is no reason to allow overlapping packet fragments and overlaps 470 could be prohibited in a future revision of the protocol 471 specification. Some implementations already drop all packets with 472 overlapped fragments. 474 Specifying a minimum size for packet fragments does not help in the 475 same way as it does for IPv4 because IPv6 extension headers can be 476 made to appear very long: an attacker could insert one or more 477 undefined destination options with long lengths and the 'ignore if 478 unknown' bit set. Given the guaranteed minimum MTU of IPv6 it seems 479 reasonable that hosts should be able to ensure that the transport 480 port numbers are in the first fragment in almost all cases and that 481 deep packet inspection should be very suspicious of first fragments 482 that do not contain them. 484 2.1.10. Fragmentation Related DoS Attacks 486 Packet reassembly in IPv6 hosts also opens up the possibility of 487 various fragment-related security attacks. Some of these are 488 analogous to attacks identified for IPv4. Of particular concern is a 489 DoS attack based on sending large numbers of small fragments without 490 a terminating last fragment which would potentially overload the 491 reconstruction buffers and consume large amounts of CPU resources. 493 Mandating the size of packet fragments could reduce the impact of 494 this kind of attack by limiting the rate at which fragments could 495 arrive and limiting the number of fragments which need to be 496 processed. 498 2.1.11. Link-Local Addresses and Securing Neighbor Discovery 500 All IPv6 nodes are required to configure a link-local address on each 501 interface. This address is used to communicate with other nodes 502 directly connected to the link accessed via the interface, especially 503 during the neighbor discovery and auto-configuration processes. 504 Link-local addresses are fundamental to the operation of the Neighbor 505 Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462]. NDP also 506 provides the functionality of associating link layer and IP addresses 507 provided by the Address Resolution Protocol (ARP) in IPv4 networks. 509 The standard version of NDP is subject to a number of security 510 threats related to ARP spoofing attacks on IPv4. These threats have 511 been documented in [RFC3756] and mechanisms to combat them specified 512 in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional 513 mechanism which is particularly applicable to wireless and other 514 environments where it is difficult to physically secure the link. 516 Because the link-local address can, by default, be acquired without 517 external intervention or control, it allows an attacker to commence 518 communication on the link without needing to acquire information 519 about the address prefixes in use or communicate with any authorities 520 on the link. This feature gives a malicious node the opportunity to 521 mount an attack on any other node which is attached to this link; 522 this vulnerability exists in addition to possible direct attacks on 523 NDP. Link-local addresses may also facilitate the unauthorized use 524 of the link bandwidth ('bandwidth theft') to communicate with another 525 unauthorized node on the same link. 527 Link-local addresses allocated from the prefix 169.254.0.0/16 are 528 available in IPv4 as well and procedures for using them are described 529 in [I-D.ietf-zeroconf-ipv4-linklocal] but the security issues were 530 not as pronounced as for IPv6 for the following reasons: 531 o link-local addresses are not mandatory in IPv4 and are primarily 532 intended for isolated or ad hoc networks that cannot acquire a 533 routable IPv4 address by other means, 534 o IPv4 link-local addresses are not universally supported across 535 operating systems, and 536 o the IPv4 link-local address should be removed when a non-link- 537 local address is configured on the interface and will generally 538 not be allocated unless other means of acquiring an address are 539 not available. 541 These vulnerabilities can be mitigated in several ways. A general 542 solution will require 543 o authenticating the link layer connectivity, for example by using 544 IEEE 802.1x functionality, port-based MAC address security 545 (locking), or physical security, and 546 o using SEcure Neighbor Discovery (SEND) to create a 547 cryptographically generated link-local address as described in 548 [RFC3971] which is tied to the authenticated link layer address. 549 This solution would be particularly appropriate in wireless LAN 550 deployments where it is difficult to physically secure the 551 infrastructure 553 In wired environments, where the physical infrastructure is 554 reasonably secure, it may be sufficient to ignore communication 555 requests originating from a link-local address for other than local 556 network management purposes. This requires that nodes should only 557 accept packets with link-local addresses for a limited set of 558 protocols including NDP, MLD and other functions of ICMPv6. 560 2.1.12. Securing Router Advertisements 562 As part of the Neighbor Discovery process, routers on a link 563 advertise their capabilities in Router Advertisement messages. The 564 version of NDP defined in [RFC2461] does not protect the integrity of 565 these messages or validate the assertions made in the messages with 566 the result that any node which connects to the link can maliciously 567 claim to offer routing services which it will not fulfill, and 568 advertise inappropriate prefixes and parameters. These threats have 569 been documented in [RFC3756]. 571 A malicious node may also be able to carry out a DoS attack by 572 deprecating an established valid prefix (by advertising it with a 573 zero lifetime). Similar DoS attacks are possible if the optional 574 Router Selection mechanism is implemented as described in the 575 security considerations of [I-D.ietf-ipv6-router-selection]. 577 SEND [RFC3971] can be used to provide verification that routers are 578 authorized to provide the services they advertise through a 579 certificate-based mechanism. This capability of SEND is also 580 particularly appropriate for wireless environments where clients are 581 reliant on the assertions of the routers rather than a physically 582 secured connection. 584 2.1.13. Host to Router Load Sharing 586 If a host deploys the optional Host to Router Load Sharing mechanism 587 [I-D.ietf-ipv6-host-load-sharing] a malicious application could try 588 to subvert the load sharing algorithm to direct a large volume of 589 traffic to a subset of the routers. 591 However, as described in [I-D.ietf-ipv6-host-load-sharing], this is 592 not considered a significant threat as 593 1. load-sharing routers should be provisioned to handle the load in 594 any case (e.g., if one of them goes down), 595 2. a privileged user can launch such an attack using raw sockets in 596 any case, and 597 3. a user or application could just attack the routers directly or 598 in other, simpler ways. 600 2.1.14. Mobile IPv6 602 Mobile IPv6 offers significantly enhanced security compared with 603 Mobile IPv4 especially when using optimized routing and care-of 604 addresses. Return routability checks are used to provide relatively 605 robust assurance that the different addresses which a mobile node 606 uses as it moves through the network do indeed all refer to the same 607 node. The threats and solutions are described in [RFC3775] and a 608 more extensive discussion of the security aspects of the design can 609 be found in [I-D.ietf-mip6-ro-sec]. 611 2.1.14.1. Obsolete Home Address Option in Mobile IPv6 613 The Home Address option specified in early drafts of Mobile IPv6 614 would have allowed a trivial source spoofing attack: hosts were 615 required to substitute the source address of incoming packets with 616 the address in the option, thereby potentially evading checks on the 617 packet source address. This is discussed at greater length in 618 [I-D.savola-ipv6-rh-ha-security]. The version of Mobile IPv6 as 619 standardized in [RFC3775] has removed this issue by ensuring that the 620 Home Address destination option is only processed if there is a 621 corresponding binding cache entry and securing Binding Update 622 messages. 624 A number of pre-standard implementations of Mobile IPv6 were 625 available which implemented this obsolete and insecure option: care 626 should be taken to avoid running such obsolete systems. 628 2.2. IPv4-mapped IPv6 Addresses 630 Overloaded functionality is always a double-edged sword: it may yield 631 some deployment benefits, but often also incurs the price which comes 632 with ambiguity. 634 One example of such is IPv4-mapped IPv6 addresses: a representation 635 of an IPv4 address as an IPv6 address inside an operating system. 636 Since the original specification, the use of IPv4-mapped addresses 637 has been extended to a transition mechanism, Stateless IP/ICMP 638 Translation algorithm (SIIT) [RFC2765], where they are potentially 639 used in the addresses of packets on the wire. 641 Therefore, it becomes difficult to unambiguously discern whether an 642 IPv4 mapped address is really an IPv4 address represented in the IPv6 643 address format *or* an IPv6 address received from the wire (which may 644 be subject to address forgery, etc.). 646 In addition, special cases like these, while giving deployment 647 benefits in some areas, require a considerable amount of code 648 complexity (e.g. in the implementations of bind() system calls and 649 reverse DNS lookups) which is probably undesirable. Some of these 650 issues are discussed in [I-D.cmetz-v6ops-v4mapped-api-harmful] and 651 [I-D.itojun-v6ops-v4mapped-harmful]. 653 In practice, although the packet translation mechanisms of SIIT are 654 specified for use in the Network Address Translator - Protocol 655 Translator (NAT-PT) [RFC2765], NAT-PT uses a mechanism different from 656 IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses 657 in IPv6 addresses. Also SIIT is not recommended for use as a 658 standalone transition mechanism. Given the issues that have been 659 identified, it seems appropriate that mapped addresses should not be 660 used on the wire. However, changing application behavior by 661 deprecating the use of mapped addresses in the operating system 662 interface would have significant impact on application porting 663 methods [RFC4038] and needs further study. 665 2.3. Increased End-to-End Transparency 667 One of the major design aims of IPv6 has been to maintain the 668 original IP architectural concept of end-to-end transparency. 669 Transparency can help foster technological innovation in areas such 670 as peer-to-peer communication but maintaining the security of the 671 network at the same time requires some modifications in the network 672 architecture. Ultimately, it is also likely to need changes in the 673 security model as compared with the norms for IPv4 networks. 675 2.3.1. IPv6 Networks without NATs 677 The necessity of introducing Network Address Translators (NATs) into 678 IPv4 networks, resulting from a shortage of IPv4 addresses, has 679 removed the end-to-end transparency of most IPv4 connections: the use 680 of IPv6 would restore this transparency. However, the use of NATs, 681 and the associated private addressing schemes, has become 682 inappropriately linked to the provision of security in enterprise 683 networks. The restored end-to-end transparency of IPv6 networks can 684 therefore be seen as a threat by poorly informed enterprise network 685 managers. Some seem to want to limit the end-to-end capabilities of 686 IPv6, for example by deploying private, local addressing and 687 translators, even when it is not necessary because of the abundance 688 of IPv6 addresses. 690 Recommendations for designing an IPv6 network to meet the perceived 691 security and connectivity requirements implicit in the current usage 692 of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end 693 transparency are described in IPv6 Network Architecture Protection 694 [I-D.ietf-v6ops-nap]. 696 2.3.2. Enterprise Network Security Model for IPv6 698 The favored model for enterprise network security in IPv4 stresses 699 the use of a security perimeter policed by autonomous firewalls and 700 incorporating the NATs. Both perimeter firewalls and NATs introduce 701 asymmetry and reduce the transparency of communications through these 702 perimeters. The symmetric bidirectionality and transparency which 703 are extolled as virtues of IPv6 may seem to be at odds with this 704 model. Consequently network managers may even see them as 705 undesirable attributes, in conflict with their need to control 706 threats to and attacks on the networks they administer. 708 It is worth noting that IPv6 does not *require* end-to-end 709 connectivity. It merely provides end-to-end addressability; the 710 connectivity can still be controlled using firewalls (or other 711 mechanisms), and it is indeed wise to do so. 713 A number of matters indicate that IPv6 networks should migrate 714 towards an improved security model, which will increase the overall 715 security of the network but facilitate end-to-end communication: 716 o Increased usage of end-to-end security especially at the network 717 layer. IPv6 mandates the provision of IPsec capability in all 718 nodes and increasing usage of end-to-end security is a challenge 719 to current autonomous firewalls that are unable to perform deep 720 packet inspection on encrypted packets. It is also incompatible 721 with NATs because they modify the packets, even when packets are 722 only authenticated rather than encrypted. 723 o Acknowledgement that over-reliance on the perimeter model is 724 potentially dangerous. An attacker who can penetrate today's 725 perimeters will have free rein within the perimeter, in many 726 cases. Also a successful attack will generally allow the attacker 727 to capture information or resources and make use of them. 728 o Development of mechanisms such as 'Trusted Computing' which will 729 increase the level of trust which network managers are able to 730 place on hosts. 731 o Development of centralized security policy repositories and secure 732 distribution mechanisms which, in conjunction with trusted hosts, 733 will allow network managers to place more reliance on security 734 mechanisms at the end points. The mechanisms are likely to 735 include end-node firewalling and intrusion detection systems as 736 well as secure protocols that allow end points to influence the 737 behavior of perimeter security devices. 738 o Review of the role of perimeter devices with increased emphasis on 739 intrusion detection, network resource protection and coordination 740 to thwart distributed denial of service attacks. 742 Several of the technologies required to support an enhanced security 743 model are still under development, including secure protocols to 744 allow end points to control firewalls: the complete security model 745 utilizing these technologies is now emerging but still requires some 746 development. 748 In the meantime, initial deployments will need to make use of similar 749 firewalling and intrusion detection techniques to IPv4 which may 750 limit end-to-end transparency temporarily, but should be prepared to 751 use the new security model as it develops and avoid the use of NATs 752 by the use of the architectural techniques described in [I-D.ietf- 753 v6ops-nap]. In particular, using NAT-PT [RFC2766] as a general 754 purpose transition mechanism should be avoided as it is likely to 755 limit the exploitation of end-to-end security and other IPv6 756 capabilities in future as explained in [I-D.ietf-v6ops-natpt-to- 757 exprmntl]. 759 3. Issues Due to Transition Mechanisms 761 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues 763 The more complicated the IPv6 transition/co-existence becomes, the 764 greater the danger that security issues will be introduced either 765 o in the mechanisms themselves, 766 o in the interaction between mechanisms, or 767 o by introducing unsecured paths through multiple mechanisms. 768 These issues may or may not be readily apparent. Hence it would be 769 desirable to keep the mechanisms simple, as few in number as possible 770 and built from as small pieces as possible to simplify analysis. 772 One case where such security issues have been analyzed in detail is 773 the 6to4 tunneling mechanism [RFC3964]. 775 As tunneling has been proposed as a model for several more cases than 776 are currently being used, its security properties should be analyzed 777 in more detail. There are some generic dangers to tunneling: 779 o it may be easier to avoid ingress filtering checks 780 o it is possible to attack the tunnel interface: several IPv6 781 security mechanisms depend on checking that Hop Limit equals 255 782 on receipt and that link-local addresses are used. Sending such 783 packets to the tunnel interface is much easier than gaining access 784 to a physical segment and sending them there. 785 o automatic tunneling mechanisms are typically particularly 786 dangerous as there is no pre-configured association between end 787 points. Accordingly, at the receiving end of the tunnel packets 788 have to be accepted and decapsulated from any source. 789 Consequently, special care should be taken when specifying 790 automatic tunneling techniques. 792 3.2. Automatic Tunneling and Relays 794 Two mechanisms have been (or are being) specified which use automatic 795 tunneling and are intended for use outside a single domain. These 796 mechanisms encapsulate the IPv6 packet directly in an IPv4 packet in 797 the case of 6to4 [RFC3056] or in an IPv4 UDP packet in the case of 798 Teredo [I-D.huitema-v6ops-teredo]. In each case packets can be sent 799 and received by any similarly equipped nodes in the IPv4 Internet. 801 As mentioned in Section 3.1, a major vulnerability in such approaches 802 is that receiving nodes must allow decapsulation of traffic sourced 803 from anywhere in the Internet. This kind of decapsulation function 804 must be extremely well secured because of the wide range of potential 805 sources. 807 An even more difficult problem is how these mechanisms are able to 808 establish communication with native IPv6 nodes or between the 809 automatic tunneling mechanisms: such connectivity requires the use of 810 some kind of "relay". These relays could be deployed in various 811 locations such as: 812 o all native IPv6 nodes, 813 o native IPv6 sites, 814 o in IPv6-enabled ISPs, or 815 o just somewhere in the Internet. 817 Given that a relay needs to trust all the sources (e.g., in the 6to4 818 case, all 6to4 routers) which are sending it traffic, there are 819 issues in achieving this trust and at the same time scaling the relay 820 system to avoid overloading a small number of relays. 822 As authentication of such a relay service is very difficult to 823 achieve, and particularly so in some of the possible deployment 824 models, relays provide a potential vehicle for address spoofing, 825 (reflected) Denial-of-Service attacks, and other threats. 827 Threats related to 6to4 and measures to combat them are discussed in 829 [RFC3964]. [I-D.huitema-v6ops-teredo] incorporates extensive 830 discussion of the threats to Teredo and measures to combat them. 832 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 Network 833 Security Assumptions 835 NATs and firewalls have been deployed extensively in the IPv4 836 Internet, as discussed in Section 2.3. Operators who deploy them 837 typically have some security/operational requirements in mind (e.g. a 838 desire to block inbound connection attempts), which may or may not be 839 misguided. 841 The addition of tunneling can change the security model which such 842 deployments are seeking to enforce. IPv6-over-IPv4 tunneling using 843 protocol 41 is typically either explicitly allowed, or disallowed 844 implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes 845 a more difficult problem as UDP must usually be allowed to pass 846 through NATs and firewalls. Consequently, using UDP implies the 847 ability to punch holes in NAT's and firewalls although, depending on 848 the implementation, this ability may be limited or only achieved in a 849 stateful manner. In practice, the mechanisms have been explicitly 850 designed to traverse both NATs and firewalls in a similar fashion. 852 One possible view is that use of tunneling is especially questionable 853 in home/SOHO environments where the level of expertise in network 854 administration is typically not very high; in these environments the 855 hosts may not be as tightly managed as in others (e.g., network 856 services might be enabled unnecessarily), leading to possible 857 security break-ins or other vulnerabilities. 859 Holes can be punched both intentionally and unintentionally. In 860 cases where the administrator or user makes an explicit decision to 861 create the hole, this is less of a problem, although (for example) 862 some enterprises might want to block IPv6 tunneling explicitly if 863 employees were able to create such holes without reference to 864 administrators. On the other hand, if a hole is punched 865 transparently, it is likely that a proportion of users will not 866 understand the consequences: this will very probably result in a 867 serious threat sooner or later. 869 When deploying tunneling solutions, especially tunneling solutions 870 which are automatic and/or can be enabled easily by users who do not 871 understand the consequences, care should be taken not to compromise 872 the security assumptions held by the users. 874 For example, NAT traversal should not be performed by default unless 875 there is a firewall producing a similar by-default security policy to 876 that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is 877 less of a problem, as it is easier to block if necessary; however, if 878 the host is protected in IPv4, the IPv6 side should be protected as 879 well. 881 As has been shown in Appendix A, it is relatively easy to determine 882 the IPv6 address corresponding to an IPv4 address in tunneling 883 deployments. It is therefore vital NOT to rely on "security by 884 obscurity" i.e., assuming that nobody is able to guess or determine 885 the IPv6 address of the host especially when using automatic 886 tunneling transition mechanisms. 888 The network architecture must provide separate IPv4 and IPv6 889 firewalls with tunneled IPv6 traffic arriving encapsulated in IPv4 890 packets routed through the IPv4 firewall before being decapsulated, 891 and then through the IPv6 firewall as shown in Figure 1. 893 +--------+ +--------+ +--------+ 894 Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public 895 Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet 896 |Firewall| |Endpoint| |Firewall| 897 +--------+ +--------+ +--------+ 899 Figure 1: Tunneled Traffic and Firewalls 901 4. Issues Due to IPv6 Deployment 903 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting 905 Because IPv6 is a new service for many networks, network managers 906 will often opt to make a pilot deployment in a part of the network to 907 gain experience and understand the problems as well as the benefits 908 that may result from a full production quality IPv6 service. 910 Unless IPv6 service piloting is done in a manner which is as secure 911 as possible there is a risk that security in the pilot which does not 912 match up to what is achievable with current IPv4 production service 913 can adversely impact the overall assessment of the IPv6 pilot 914 deployment. This may result in a decision to delay or even avoid 915 deploying an IPv6 production service. For example, hosts and routers 916 might not be protected by IPv6 firewalls, even if the corresponding 917 IPv4 service is fully protected by firewalls as described in 918 [I-D.ietf-v6ops-v6onbydefault]. This is particularly critical where 919 IPv6 capabilities are turned on by default in new equipment or new 920 releases of operating systems: network managers may not be fully 921 aware of the security exposure that this creates. 923 In some cases a perceived lack of availability of IPv6 firewalls and 924 other security capabilities, such as intrusion detection systems may 925 have lead network managers to resist any kind of IPv6 service 926 deployment. These problems may be partly due to the relatively slow 927 development and deployment of IPv6-capable security equipment, but 928 the major problems appear to have been a lack of information, and 929 more importantly a lack of documented operational experience on which 930 managers can draw. In actual fact, as of the time of writing (2005) 931 there are a significant number of alternative IPv6 packet filters and 932 firewalls already in existence, which could be used for provide 933 sufficient access controls. 935 However, there are a small number of areas that where the available 936 equipment and capabilities may still be a barrier to secure 937 deployment: 938 o 'Personal firewalls' intended for use on hosts are not yet widely 939 available. 940 o Enterprise firewalls are at an early stage of development and may 941 not provide the full range of capabilities needed to implement the 942 necessary IPv6 filtering rules. network managers often expect the 943 same devices that support and are used for IPv4 today to also 944 become IPv6-capable -- even though this is not really required and 945 the equipment may not have the requisite hardware capabilities to 946 support fast packet filtering for IPv6. Suggestions for the 947 appropriate deployment of firewalls are given in Section 3.3 -- as 948 will be seen from this section it is usually desirable that the 949 firewalls are in separate boxes and there is no necessity for them 950 to be same model of equipment. 951 o A lesser factor may be that some design decisions in the IPv6 952 protocol make it more difficult for firewalls to be implemented 953 and work in all cases, and to be fully future proof (e.g. when new 954 extension headers are used) as discussed in Section 2.1.8: it is 955 significantly more difficult for intermediate nodes to process the 956 IPv6 header chains than IPv4 packets. 957 o Adequate Intrusion Detection Systems (IDS) are more difficult to 958 construct for IPv6. IDSs are now beginning to become available 959 but the pattern-based mechanisms used for IPv4 may not be the most 960 appropriate for long-term development of these systems as end-to- 961 end encryption becomes more prevalent. Future systems may be more 962 reliant on traffic flow pattern recognition. 963 o Implementations of high availability capabilities supporting IPv6 964 are also in short supply. In particular, development of the IPv6 965 version of the Virtual Router Redundancy Protocol (VRRP) 966 [I-D.ietf-vrrp-ipv6-spec] has lagged the development of the main 967 IPv6 protocol although alternatives may be available for some 968 environments. 970 In all these areas developments are ongoing and they should not be 971 considered a long-term bar to the deployment of IPv6 either as a 972 pilot or production service. The necessary tools are now available 973 to make a secure IPv6 deployment and with careful selection of 974 components and design of the network architecture a successful pilot 975 or production IPv6 service can be deployed. Recommendations for 976 secure deployment and appropriate management of IPv6 networks can be 977 found in the documentation archives of the European Union 6net 978 project [SIXNET] and in the Deployment Guide published by the IPv6 979 Promotion Council of Japan [JpIPv6DC]. 981 4.2. DNS Server Problems 983 Some DNS server implementations have flaws that severely affect DNS 984 queries for IPv6 addresses as discussed in [RFC4074]. These flaws 985 can be used for DoS attacks affecting both IPv4 and IPv6 by inducing 986 caching DNS servers to believe that a domain is broken and causing 987 the server to block access to all requests for the domain for a 988 precautionary period. 990 4.3. Addressing Schemes and Securing Routers 992 Whilst in general terms brute force scanning of IPv6 subnets is 993 essentially impossible due to the enormously larger address space of 994 IPv6 and the 64 bit interface identifiers (see Appendix A), this will 995 be obviated if administrators do not take advantage of the large 996 space to use unguessable interface identifiers. 998 Because the unmemorability of complete IPv6 addresses there is a 999 temptation for administrators to use small integers as interface 1000 identifiers when manually configuring them, as might happen on point- 1001 to-point links or when provisioning complete addresses from a DHCPv6 1002 server. Such allocations make it easy for an attacker to find active 1003 nodes that they can then port scan. 1005 To make use of the larger address space properly, administrators 1006 should be very careful when entering IPv6 addresses in their 1007 configurations (e.g. Access Control List), since numerical IPv6 1008 addresses are more prone to human error than IPv4 due to their length 1009 and unmemorability. 1011 It is also essential to ensure that the management interfaces of 1012 routers are well secured as the router will usually contain a 1013 significant cache of neighbor addresses in its neighbor cache. 1015 4.4. Consequences of Multiple Addresses in IPv6 1017 One positive consequence of IPv6 is that nodes which do not require 1018 global access can communicate locally just by the use of a link-local 1019 address (if very local access is sufficient) or across the site by 1020 using a Unique Local Address (ULA). In either case it is easy to 1021 ensure that access outside the assigned domain of activity can be 1022 controlled by simple filters (which may be the default for link- 1023 locals). However, the security hazards of using link-local addresses 1024 for non-management purposes as documented in Section 2.1.11 should be 1025 borne in mind. 1027 On the other hand, the possibility that a node or interface can have 1028 multiple global scope addresses makes access control filtering both 1029 on ingress and egress more complex and requires higher maintenance 1030 levels. Vendors and network administrators need to be aware that 1031 multiple addresses are the norm rather than the exception in IPv6: 1032 when building and selecting tools for security and management a 1033 highly desirable feature is the ability to be able to 'tokenize' 1034 access control lists and configurations in general to cater for 1035 multiple addresses and/or address prefixes. 1037 The addresses could be from the same network prefix (for example, 1038 privacy mechanisms [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] will 1039 periodically create new addresses taken from the same prefix and two 1040 or more of these may be active at the same time), or from different 1041 prefixes (for example, when a network is multihomed or is 1042 implementing anycast services). In either case, it is possible that 1043 a single host could be using several different addresses with 1044 different prefixes. It would be desirable that the security 1045 administrator should be able to identify that the same host is behind 1046 all these addresses. 1048 Some network administrators may find the mutability of addresses when 1049 privacy mechanisms are used in their network to be undesirable 1050 because of the current difficulties in maintaining access control 1051 lists and knowing the origin of traffic. In general, disabling the 1052 use of privacy addresses is only possible if the full stateful DHCPv6 1053 mechanism [RFC3315] is used to allocate IPv6 addresses and DHCPv6 1054 requests for privacy addresses are not honored. 1056 4.5. Deploying ICMPv6 1058 In IPv4 it is commonly accepted that some filtering of ICMP packets 1059 by firewalls is essential to maintain security. Because of the 1060 extended use that is made of ICMPv6 [RFC2461] with a multitude of 1061 functions, the simple set of dropping rules that are usually applied 1062 in IPv4 need to be significantly developed for IPv6. The blanket 1063 dropping of all ICMP messages that is used in some very strict 1064 environments is simply not possible for IPv6. 1066 In an IPv6 firewall, policy needs to allow some messages through the 1067 firewall but also has to permit certain messages to and from the 1068 firewall, especially those with link-local sources on links to which 1069 the firewall is attached. These messages must be permitted to ensure 1070 that Neighbor Discovery [RFC2462], Multicast Listener Discovery 1071 [RFC2710], [RFC3810] and Stateless Address Configuration [RFC2463] 1072 work as expected. 1074 Recommendations for filtering ICMPv6 messages can be found in 1075 [I-D.davies-v6ops-icmpv6-filtering-bcp]. 1077 4.5.1. Problems Resulting from ICMPv6 Transparency 1079 As described in Section 4.5, certain ICMPv6 error packets need to be 1080 passed through a firewall in both directions. This means that some 1081 ICMPv6 error packets can be exchanged between inside and outside 1082 without any filtering. 1084 Using this feature, malicious users can communicate between the 1085 inside and outside of a firewall bypassing the administrator's 1086 inspection (proxy, firewall etc.). For example it might be possible 1087 to carry out a covert conversation through the payload of ICMPv6 1088 error messages or tunnel inappropriate encapsulated IP packets in 1089 ICMPv6 error messages. This problem can be alleviated by filtering 1090 ICMPv6 errors using a stateful packet inspection mechanism to ensure 1091 that the packet carried as a payload is associated with legitimate 1092 traffic to or from the protected network. 1094 4.6. IPsec Transport Mode 1096 IPsec provides security to end-to-end communications at the network 1097 layer (layer 3). The security features available include access 1098 control, connectionless integrity, data origin authentication, 1099 protection against replay attacks, confidentiality, and limited 1100 traffic flow confidentiality (see [RFC2401] section 2.1). IPv6 1101 mandates the implementation of IPsec in all conforming nodes, making 1102 the usage of IPsec to secure end-to-end communication possible in a 1103 way which is generally not available to IPv4. 1105 To secure IPv6 end-to-end communications, IPsec transport mode would 1106 generally be the solution of choice. However, use of these IPsec 1107 security features can result in novel problems for network 1108 administrators and decrease the effectiveness of perimeter firewalls 1109 because of the increased prevalence of encrypted packets on which the 1110 firewalls cannot perform deep packet inspection and filtering. 1112 One example of such problems is the lack of security solutions in the 1113 middlebox, including effective content-filtering, ability to provide 1114 DoS prevention based on the expected TCP protocol behavior, and 1115 intrusion detection. Future solutions to this problem are discussed 1116 in Section 2.3.2. Another example is an IPsec-based DoS (e.g., 1117 sending malformed ESP/AH packets) which can be especially detrimental 1118 to software-based IPsec implementations. 1120 4.7. Reduced Functionality Devices 1122 With the deployment of IPv6 we can expect the attachment of a very 1123 large number of new IPv6-enabled devices with scarce resources and 1124 low computing capacity. The resource limitations are generally 1125 because of a market requirement for cost reduction. Although the 1126 IPv6 Node Requirements [I-D.ietf-ipv6-node-requirements] specifies 1127 some mandatory security capabilities for every conformant node, these 1128 do not include functions required for a node to be able to protect 1129 itself. Accordingly, some such devices may not be able even to 1130 perform the minimum set of functions required to protect themselves 1131 (e.g. 'personal' firewall, automatic firmware update, enough CPU 1132 power to endure DoS attacks). This means a different security scheme 1133 may be necessary for such reduced functionality devices. 1135 4.8. Operational Factors when Enabling IPv6 in the Network 1137 There are a number of reasons which make it essential to take 1138 particular care when enabling IPv6 in the network equipment: 1140 Initially, IPv6-enabled router software may be less mature than 1141 current IPv4-only implementations and there is less experience with 1142 configuring IPv6 routing, which can result in disruptions to the IPv6 1143 routing environment and (IPv6) network outages. 1145 IPv6 processing may not happen at (near) line speed (or at a 1146 comparable performance level to IPv4 in the same equipment). A high 1147 level of IPv6 traffic (even legitimate, e.g. Network News Transport 1148 Protocol, NNTP) could easily overload IPv6 processing especially when 1149 it is software-based without the hardware support typical in high-end 1150 routers. This may potentially have deleterious knock-on effects on 1151 IPv4 processing, affecting availability of both services. 1152 Accordingly, if people don't feel confident enough in the IPv6 1153 capabilities of their equipment, they will be reluctant to enable it 1154 in their "production" networks. 1156 Sometimes essential features may be missing from early releases of 1157 vendors' software; an example is provision of software enabling IPv6 1158 telnet/SSH access (e.g., to the configuration application of a 1159 router), but without the ability to turn it off or limit access to 1160 it! 1162 Sometimes the default IPv6 configuration is insecure. For example, 1163 in one vendor's implementation, if you have restricted IPv4 telnet to 1164 only a few hosts in the configuration, you need to be aware that IPv6 1165 telnet will be automatically enabled, that the configuration commands 1166 used previously do not block IPv6 telnet, IPv6 telnet is open to the 1167 world by default, and that you have to use a separate command to also 1168 lock down the IPv6 telnet access. 1170 Many operator networks have to run interior routing protocols for 1171 both IPv4 and IPv6. It is possible to run the both in one routing 1172 protocol, or have two separate routing protocols; either approach has 1173 its tradeoffs [RFC4029]. If multiple routing protocols are used, one 1174 should note that this causes double the amount of processing when 1175 links flap or recalculation is otherwise needed -- which might more 1176 easily overload the router's CPU, causing slightly slower convergence 1177 time. 1179 4.9. Ingress Filtering Issues Due to Privacy Addresses 1181 [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] describes a method for 1182 creating temporary addresses on IPv6 nodes to address privacy issues 1183 created by the use of a constant identifier. In a network, which 1184 implements such a mechanism, with a large number of nodes, new 1185 temporary addresses may be created at a fairly high rate. This might 1186 make it hard for ingress filtering mechanisms to distinguish between 1187 legitimately changing temporary addresses and spoofed source 1188 addresses, which are "in-prefix" (They use a topologically correct 1189 prefix and non-existent interface ID). This can be addressed by 1190 using finer grained access control mechanisms on the network egress 1191 point. 1193 4.10. Security Issues Due to ND Proxies 1195 In order to span a single subnet over multiple physical links, a new 1196 capability is being introduced in IPv6 to proxy Neighbor Discovery 1197 messages. This node will be called an NDProxy (see [I-D.ietf-ipv6- 1198 ndproxy]. NDProxies are susceptible to the same security issues as 1199 the ones faced by hosts using unsecured Neighbor Discovery or ARP. 1200 These proxies may process unsecured messages, and update the neighbor 1201 cache as a result of such processing, thus allowing a malicious node 1202 to divert or hijack traffic. This may undermine the advantages of 1203 using SEND [RFC3971]. 1205 To resolve the security issues introduced by NDProxies, SEND needs to 1206 be extended to be NDProxy aware. 1208 5. IANA Considerations 1210 This memo does not contain any actions for IANA. 1212 6. Security Considerations 1214 This memo attempts to give an overview of security considerations of 1215 the different aspects of IPv6, particularly as they relate to the 1216 transition to a network in which IPv4- and IPv6-based communications 1217 need to coexist. 1219 7. Acknowledgements 1221 Alain Durand, Alain Baudot, Luc Beloeil, Tim Chown, Andras Kis-Szabo, 1222 Alvaro Vives, Janos Mohacsi and Mark Smith provided feedback to 1223 improve this memo. Satoshi Kondo, Shinsuke Suzuki and Alvaro Vives 1224 provided additional inputs in cooperation with the Deployment Working 1225 Group of the Japanese IPv6 Promotion Council and the Euro6IX IST co- 1226 funded project, together with inputs from Jordi Palet, Brian 1227 Carpenter, and Peter Bieringer. Michael Wittsend and Michael Cole 1228 discussed issues relating to probing/mapping and privacy. 1230 8. References 1232 8.1. Normative References 1234 [I-D.huitema-v6ops-teredo] 1235 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1236 NATs", draft-huitema-v6ops-teredo-05 (work in progress), 1237 April 2005. 1239 [I-D.ietf-ipv6-privacy-addrs-v2] 1240 Narten, T., "Privacy Extensions for Stateless Address 1241 Autoconfiguration in IPv6", 1242 draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), 1243 May 2005. 1245 [I-D.ietf-v6ops-natpt-to-exprmntl] 1246 Aoun, C. and E. Davies, "Reasons to Move NAT-PT to 1247 Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work 1248 in progress), July 2005. 1250 [I-D.ietf-vrrp-ipv6-spec] 1251 Hinden, R., "Virtual Router Redundancy Protocol for IPv6", 1252 draft-ietf-vrrp-ipv6-spec-07 (work in progress), 1253 October 2004. 1255 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 1256 Assignments", RFC 2375, July 1998. 1258 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1259 (IPv6) Specification", RFC 2460, December 1998. 1261 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1262 Discovery for IP Version 6 (IPv6)", RFC 2461, 1263 December 1998. 1265 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1266 Autoconfiguration", RFC 2462, December 1998. 1268 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 1269 Protocol (ICMPv6) for the Internet Protocol Version 6 1270 (IPv6) Specification", RFC 2463, December 1998. 1272 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1273 Listener Discovery (MLD) for IPv6", RFC 2710, 1274 October 1999. 1276 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1277 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1278 January 2001. 1280 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1281 via IPv4 Clouds", RFC 3056, February 2001. 1283 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1284 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1286 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1287 in IPv6", RFC 3775, June 2004. 1289 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1290 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1292 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1293 6to4", RFC 3964, December 2004. 1295 8.2. Informative References 1297 [FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. 1298 Second Internet Measurement Workshop , November 2002, 1299 . 1301 [I-D.chown-v6ops-port-scanning-implications] 1302 Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 1303 draft-chown-v6ops-port-scanning-implications-01 (work in 1304 progress), July 2004. 1306 [I-D.cmetz-v6ops-v4mapped-api-harmful] 1307 Metz, C. and J. Hagino, "IPv4-Mapped Address API 1308 Considered Harmful", 1309 draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in 1310 progress), October 2003. 1312 [I-D.davies-v6ops-icmpv6-filtering-bcp] 1313 Davies, E. and J. Mohacsi, "Best Current Practice for 1314 Filtering ICMPv6 Messages in Firewalls", 1315 draft-davies-v6ops-icmpv6-filtering-bcp-00 (work in 1316 progress), July 2005. 1318 [I-D.dupont-ipv6-rfc3041harmful] 1319 Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", 1320 draft-dupont-ipv6-rfc3041harmful-05 (work in progress), 1321 June 2004. 1323 [I-D.ietf-dnsop-ipv6-dns-issues] 1324 Durand, A., "Operational Considerations and Issues with 1325 IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-11 (work in 1326 progress), July 2005. 1328 [I-D.ietf-ipv6-host-load-sharing] 1329 Hinden, R. and D. Thaler, "IPv6 Host to Router Load 1330 Sharing", draft-ietf-ipv6-host-load-sharing-04 (work in 1331 progress), June 2005. 1333 [I-D.ietf-ipv6-ndproxy] 1334 Thaler, D., "Neighbor Discovery Proxies (ND Proxy)", 1335 draft-ietf-ipv6-ndproxy-03 (work in progress), July 2005. 1337 [I-D.ietf-ipv6-node-requirements] 1338 Loughney, J., "IPv6 Node Requirements", 1339 draft-ietf-ipv6-node-requirements-11 (work in progress), 1340 August 2004. 1342 [I-D.ietf-ipv6-router-selection] 1343 Draves, R. and D. Thaler, "Default Router Preferences and 1344 More-Specific Routes", draft-ietf-ipv6-router-selection-07 1345 (work in progress), January 2005. 1347 [I-D.ietf-mip6-ro-sec] 1348 Nikander, P., "Mobile IP version 6 Route Optimization 1349 Security Design Background", draft-ietf-mip6-ro-sec-03 1350 (work in progress), May 2005. 1352 [I-D.ietf-v6ops-nap] 1353 Velde, G., "IPv6 Network Architecture Protection", 1354 draft-ietf-v6ops-nap-01 (work in progress), June 2005. 1356 [I-D.ietf-v6ops-v6onbydefault] 1357 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack 1358 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 1359 (work in progress), July 2004. 1361 [I-D.ietf-zeroconf-ipv4-linklocal] 1362 Aboba, B., "Dynamic Configuration of Link-Local IPv4 1363 Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in 1364 progress), July 2004. 1366 [I-D.itojun-v6ops-v4mapped-harmful] 1367 Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire 1368 Considered Harmful", 1369 draft-itojun-v6ops-v4mapped-harmful-02 (work in progress), 1370 October 2003. 1372 [I-D.krishnan-ipv6-hopbyhop] 1373 Krishnan, S., "Arrangement of Hop-by-Hop options", 1374 draft-krishnan-ipv6-hopbyhop-00 (work in progress), 1375 June 2004. 1377 [I-D.savola-ipv6-rh-ha-security] 1378 Savola, P., "Security of IPv6 Routing Header and Home 1379 Address Options", draft-savola-ipv6-rh-ha-security-02 1380 (work in progress), March 2002. 1382 [I-D.savola-ipv6-rh-hosts] 1383 Savola, P., "Note about Routing Header Processing on IPv6 1384 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), 1385 February 2002. 1387 [I-D.savola-v6ops-firewalling] 1388 Savola, P., "Firewalling Considerations for IPv6", 1389 draft-savola-v6ops-firewalling-02 (work in progress), 1390 October 2003. 1392 [I-D.savola-v6ops-transarch] 1393 Savola, P., "A View on IPv6 Transition Architecture", 1394 draft-savola-v6ops-transarch-03 (work in progress), 1395 January 2004. 1397 [I-D.schild-v6ops-guide-v4mapping] 1398 Schild, C., "Guide to Mapping IPv4 to IPv6 Subnets", 1399 draft-schild-v6ops-guide-v4mapping-00 (work in progress), 1400 January 2004. 1402 [JpIPv6DC] 1403 Deployment WG, "IPv6 Deployment Guideline (2005 Edition)", 1404 IPv6 Promotion Council (Japan) Deployment Working Group, 1405 2005, . 1407 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1408 Considerations for IP Fragment Filtering", RFC 1858, 1409 October 1995. 1411 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1412 Internet Protocol", RFC 2401, November 1998. 1414 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1415 (SIIT)", RFC 2765, February 2000. 1417 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1418 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1419 February 2000. 1421 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1422 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1424 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1425 and M. Carney, "Dynamic Host Configuration Protocol for 1426 IPv6 (DHCPv6)", RFC 3315, July 2003. 1428 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1429 Discovery (ND) Trust Models and Threats", RFC 3756, 1430 May 2004. 1432 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1433 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1435 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 1436 Savola, "Scenarios and Analysis for Introducing IPv6 into 1437 ISP Networks", RFC 4029, March 2005. 1439 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 1440 Castro, "Application Aspects of IPv6 Transition", 1441 RFC 4038, March 2005. 1443 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 1444 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 1446 [SIXNET] 6Net, "Large Scale International IPv6 Pilot Network", EU 1447 Information Society Technologies Project , 2005, 1448 . 1450 Appendix A. IPv6 Probing/Mapping Considerations 1452 One school of thought wants the IPv6 numbering topology (either at 1453 network or node level) [I-D.schild-v6ops-guide-v4mapping] to match 1454 IPv4 as exactly as possible, whereas others see IPv6 as giving more 1455 flexibility to the address plans, not wanting to constrain the design 1456 of IPv6 addressing. Mirroring the address plans may also be seen as 1457 a security threat because an IPv6 deployment may have different 1458 security properties from IPv4. 1460 Given the relatively immature state of IPv6 network security, if an 1461 attacker knows the IPv4 address of the node and believes it to be 1462 dual-stacked with IPv4 and IPv6, he might want to try to probe the 1463 corresponding IPv6 address, based on the assumption that the security 1464 defenses might be lower. This might be the case particularly for 1465 nodes which are behind a NAT in IPv4, but globally addressable in 1466 IPv6. Naturally, this is not a concern if similar and adequate 1467 security policies are in place. 1469 On the other hand, brute-force scanning or probing of addresses is 1470 computationally infeasible due to the large search space of interface 1471 identifiers on most IPv6 subnets (somewhat less than 64 bits wide, 1472 depending on how identifiers are chosen), always provided that 1473 identifiers are chosen at random out of the available space, as 1474 discussed in [I-D.chown-v6ops-port-scanning-implications]. 1476 For example, automatic tunneling mechanisms typically use 1477 deterministic methods for generating IPv6 addresses, so probing/ 1478 port-scanning an IPv6 node is simplified. The IPv4 address is 1479 embedded at least in 6to4, Teredo and ISATAP addresses. 1480 Additionally, it is possible (in the case of 6to4 in particular) to 1481 learn the address behind the prefix; for example, Microsoft 6to4 1482 implementation uses the address 2002:V4ADDR::V4ADDR while older Linux 1483 and FreeBSD implementations default to 2002:V4ADDR::1. This could 1484 also be used as one way to identify an implementation and hence 1485 target any specific weaknesses. 1487 One proposal has been to randomize the addresses or subnet identifier 1488 in the address of the 6to4 router. This does not really help, as the 1489 6to4 router (whether a host or a router) will return an ICMPv6 Hop 1490 Limit Exceeded message, revealing the IP address. Hosts behind the 1491 6to4 router can use methods such as RFC 3041 addresses to conceal 1492 themselves, provided that they are not meant to be reachable by 1493 sessions started from elsewhere: they would still require a globally 1494 accessible static address if they wish to receive communications 1495 initiated elsewhere. 1497 To conclude, it seems that when an automatic tunneling mechanism is 1498 being used, given an IPv4 address, the corresponding IPv6 address 1499 could possibly be guessed with relative ease. This has significant 1500 implications if the IPv6 security policy is less adequate than that 1501 for IPv4. 1503 Appendix B. IPv6 Privacy Considerations 1505 The generation of IPv6 addresses of IPv6 addresses from MAC addresses 1506 potentially allows the behavior of users to be tracked in a way which 1507 may infringe their privacy. [RFC3041] specifies mechanisms which can 1508 be used to reduce the risk of infringement. It has also been claimed 1509 that IPv6 harms the privacy of the user, either by exposing the MAC 1510 address, or by exposing the number of nodes connected to a site. 1512 Additional discussion of privacy issues can be found in the IPv6 1513 Network Architecture Protection document [I-D.ietf-v6ops-nap]. 1515 B.1. Exposing MAC Addresses 1517 Using stateless address autoconfiguration results in the MAC address 1518 being incorporated in an EUI64 that exposes the model of network 1519 card. The concern has been that a user might not want to expose the 1520 details of the system to outsiders, e.g., fearing a resulting 1521 burglary if a thief identifies expensive equipment from the vendor 1522 identifier embedded in MAC addresses. 1524 In most cases, this seems completely unfounded. First, such an 1525 address must be learned somehow -- this is a non-trivial process; the 1526 addresses are visible e.g., in web site access logs, but the chances 1527 that a random web site owner is collecting this kind of information 1528 (or whether it would be of any use) are quite slim. Being able to 1529 eavesdrop the traffic to learn such addresses (e.g., by the 1530 compromise of DSL or Cable modem physical media) seems also quite 1531 far-fetched. Further, using RFC 3041 addresses for such purposes is 1532 straightforward if worried about the risk. Second, the burglar would 1533 have to be able to map the IP address to the physical location; 1534 typically this would only be possible with information from the 1535 private customer database of the ISP and, for large sites, the 1536 administrative records of the site. 1538 B.2. Exposing Multiple Devices 1540 Another concern that has been aired involves the user wanting to 1541 conceal the presence of a large number of computers or other devices 1542 connected to a network; NAT can "hide" all this equipment behind a 1543 single address, but is not perfect either [FNAT]. 1545 One practical reason why some administrators may find this desirable 1546 is being able to thwart certain ISPs' business models. These models 1547 require payment based on the number of connected computers, rather 1548 than the connectivity as a whole. 1550 Similar feasibility issues as described above apply. To a degree, 1551 the number of machines present could be obscured by the sufficiently 1552 frequent re-use of RFC 3041 addresses -- that is, if during a short 1553 period, dozens of generated addresses seem to be in use, it's 1554 difficult to estimate whether they are generated by just one host or 1555 multiple hosts. 1557 B.3. Exposing the Site by a Stable Prefix 1559 When an ISP provides IPv6 connectivity to its customers, it delegates 1560 a fixed global routing prefix (usually a /48) to them. 1562 Due to this fixed allocation, it is easier to correlate the global 1563 routing prefix to a network site. In case of consumer users, this 1564 correlation leads to a privacy issue, since a site is often 1565 equivalent to an individual or a family in such a case. That is, 1566 some users might be concerned about being able to be tracked based on 1567 their /48 allocation if it is static [I-D.dupont-ipv6- 1568 rfc3041harmful]. On the other hand many users may find having a 1569 static allocation desirable as it allows them to offer services 1570 hosted in their network more easily. 1572 This problem remains unsolved even when a user changes his/her 1573 interface ID or subnet ID, because malicious users can still discover 1574 this binding. This problem can be solved by untraceable IPv6 1575 addresses as described in [I-D.ietf-v6ops-nap]. 1577 Authors' Addresses 1579 Elwyn B. Davies 1580 Consultant 1581 Soham, Cambs 1582 UK 1584 Phone: +44 7889 488 335 1585 Email: elwynd@dial.pipex.com 1587 Suresh Krishnan 1588 Ericsson 1589 8400 Decarie Blvd. 1590 Town of Mount Royal, QC H4P 2N2 1591 Canada 1593 Phone: +1 514-345-7900 1594 Email: suresh.krishnan@ericsson.com 1596 Pekka Savola 1597 CSC/Funet 1599 Email: psavola@funet.fi 1601 Intellectual Property Statement 1603 The IETF takes no position regarding the validity or scope of any 1604 Intellectual Property Rights or other rights that might be claimed to 1605 pertain to the implementation or use of the technology described in 1606 this document or the extent to which any license under such rights 1607 might or might not be available; nor does it represent that it has 1608 made any independent effort to identify any such rights. Information 1609 on the procedures with respect to rights in RFC documents can be 1610 found in BCP 78 and BCP 79. 1612 Copies of IPR disclosures made to the IETF Secretariat and any 1613 assurances of licenses to be made available, or the result of an 1614 attempt made to obtain a general license or permission for the use of 1615 such proprietary rights by implementers or users of this 1616 specification can be obtained from the IETF on-line IPR repository at 1617 http://www.ietf.org/ipr. 1619 The IETF invites any interested party to bring to its attention any 1620 copyrights, patents or patent applications, or other proprietary 1621 rights that may cover technology that may be required to implement 1622 this standard. Please address the information to the IETF at 1623 ietf-ipr@ietf.org. 1625 Disclaimer of Validity 1627 This document and the information contained herein are provided on an 1628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1630 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1631 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1632 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1633 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1635 Copyright Statement 1637 Copyright (C) The Internet Society (2005). This document is subject 1638 to the rights, licenses and restrictions contained in BCP 78, and 1639 except as set forth therein, the authors retain all their rights. 1641 Acknowledgment 1643 Funding for the RFC Editor function is currently provided by the 1644 Internet Society.