idnits 2.17.1 draft-savola-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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1099. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 163 has weird spacing: '...defined in [R...' == Line 771 has weird spacing: '...le that it ca...' -- 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 25, 2004) is 7122 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.savola-v6ops-transarch' ** Downref: Normative reference to an Informational RFC: RFC 2375 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-misbehavior-against-aaaa-01 == Outdated reference: A later version (-02) exists of draft-chown-v6ops-port-scanning-implications-01 == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-02 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-02 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-ipv6-dns-issues-09 == Outdated reference: A later version (-05) exists of draft-krishnan-ipv6-hopbyhop-00 Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations E. Davies 3 Internet-Draft Nortel Networks 4 Expires: April 25, 2005 S. Krishnan 5 Ericsson 6 P. Savola 7 CSC/Funet 8 October 25, 2004 10 IPv6 Transition/Co-existence Security Considerations 11 draft-savola-v6ops-security-overview-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 25, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 The transition from a pure IPv4 network to a network where IPv4 and 47 IPv6 co-exist brings a number of extra security considerations that 48 need to be taken into account when deploying IPv6 and operating the 49 dual-protocol network and the associated transition mechanisms. This 50 document attempts to give an overview of the various issues grouped 51 into three categories: Issues due to the IPv6 protocol itself, due to 52 transition mechanisms, and due to the way in which IPv6 is being 53 deployed. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . 4 59 2.1 IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 4 60 2.1.1 Routing Headers and Hosts . . . . . . . . . . . . . . 4 61 2.1.2 Routing Headers for Mobile IPv6 and Other Purposes . . 5 62 2.1.3 Obsolete Home Address Option in Mobile IPv6 . . . . . 5 63 2.1.4 Site(and Larger)-scope Multicast Addresses . . . . . . 5 64 2.1.5 ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 6 65 2.1.6 Anycast traffic Identification and Security . . . . . 7 66 2.1.7 Address Privacy Extensions Interact with DDoS 67 Defenses . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.1.8 Dynamic DNS, Stateless Address Auto-Configuration 69 and Privacy Extensions . . . . . . . . . . . . . . . . 8 70 2.1.9 Extension Headers . . . . . . . . . . . . . . . . . . 8 71 2.1.10 Fragmentation: Reassembly and Deep Packet 72 Inspection . . . . . . . . . . . . . . . . . . . . . 10 73 2.1.11 Fragmentation Related DoS Attacks . . . . . . . . . 11 74 2.1.12 Areas of Improved Security in IPv6 . . . . . . . . . 11 75 2.2 IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 12 76 2.3 Increased End-to-End Transparency . . . . . . . . . . . . 12 77 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . 13 78 3.1 IPv6 Transition/Co-existence Mechanism-specific Issues . . 13 79 3.2 Automatic Tunneling and Relays . . . . . . . . . . . . . . 13 80 3.3 Tunneling May Break Security Assumptions . . . . . . . . . 14 81 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . 15 82 4.1 IPv6 Service Piloting Done Insecurely . . . . . . . . . . 15 83 4.2 Enabling IPv6 by Default Brings the Usability Down . . . . 16 84 4.3 Addressing Schemes and Securing Routers . . . . . . . . . 16 85 4.4 Consequences of Multiple Addresses in IPv6 . . . . . . . . 17 86 4.5 Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 17 87 4.6 Operational Factors when Enabling IPv6 in the Network . . 18 88 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 6. Security Considerations . . . . . . . . . . . . . . . . . . 19 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 92 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 94 A. IPv6 Probing/Mapping Considerations . . . . . . . . . . . . 22 95 B. IPv6 Privacy Considerations . . . . . . . . . . . . . . . . 23 96 B.1 Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 23 97 B.2 Exposing Multiple Devices . . . . . . . . . . . . . . . . 24 98 Intellectual Property and Copyright Statements . . . . . . . 25 100 1. Introduction 102 The transition from a pure IPv4 network to a network where IPv4 and 103 IPv6 co-exist brings a number of extra security considerations that 104 need to be taken into account when deploying IPv6 and operating the 105 dual-protocol network with its associated transition mechanisms. 106 This document attempts to give an overview of the various issues 107 grouped into three categories: 108 o issues due to the IPv6 protocol itself, 109 o issues due to transition mechanisms, and 110 o issues due to IPv6 deployment. 112 An architectural view of the transition has been presented in a 113 separate document [I-D.savola-v6ops-transarch]; it is important to 114 read it at least cursorily to understand that we have to be concerned 115 not about replacing IPv4 with IPv6 (in the short term), but with 116 adding IPv6 to be operated in parallel with IPv4. 118 This document also (at the moment, may be removed in future versions) 119 describes two "non-issues", in Appendix A and Appendix B: 120 considerations about probing/mapping IPv6 addresses, and 121 considerations with respect to privacy in IPv6. 123 2. Issues Due to IPv6 Protocol 125 2.1 IPv6 Protocol-specific Issues 127 There are significant differences between the features of IPv6 and 128 IPv4: some of these specification changes may result in potential 129 security issues. Several of these issues have been discussed in 130 separate drafts but are summarised here to avoid normative references 131 which may not become RFCs. The following specification-related 132 problems have been identified, but this is not necessarily a complete 133 list: 135 2.1.1 Routing Headers and Hosts 137 All IPv6 nodes must be able to process Routing Headers [RFC2460]. 138 This RFC can be interpreted, although it is not clearly stated, to 139 mean that all nodes (including hosts) must have this processing 140 enabled. This can result in hosts forwarding received traffic if 141 there are segments left in the Routing Header when it arrives at the 142 host. 144 A number of potential security issues associated with this behavior 145 were documented in [I-D.savola-ipv6-rh-hosts]. Some of these issues 146 have been resolved (a separate routing header type is now used for 147 Mobile IPv6 [RFC3775] and ICMP Traceback has not been standardized), 148 but two issues remain: 149 o Routing headers can be used to evade access controls based on 150 destination addresses. This could be achieved by sending a packet 151 ostensibly to a publically accessible host address but with a 152 routing header which will cause the publically accessible host to 153 forward the packet to a destination which would have been 154 forbidden by the packet filters if the address had been in the 155 destination field when the packet was checked. 156 o If the packet source address in the previous case can be spoofed, 157 any host could be used to mediate an anonymous reflection 158 denial-of-service attack by having any publically accessible host 159 redirect the attack packets. 161 2.1.2 Routing Headers for Mobile IPv6 and Other Purposes 163 A new type of Routing Header (type 2) has been defined in [RFC3775] 164 to handle 'interface local' forwarding needed when packets are sent 165 to the care-of address of a mobile node which is away from its home 166 address. 168 It is important that nodes treat the different types of routing 169 header appropriately. It should be possible to apply separate 170 filtering rules to the different types of Routing Header. By design 171 hosts must process Type 2 Routing Headers to support Mobile IPv6 but 172 routers should not: to avoid the issues in Section 2.1.1 it may be 173 desirable to forbid or limit the processing of Type 0 Routing Headers 174 in hosts and some routers. 176 Routing Headers are an extremely powerful and general capability. 177 Alternative uses of Routing Headers need to be carefully assessed to 178 ensure that they do not open new avenues of attack that can be 179 exploited. 181 2.1.3 Obsolete Home Address Option in Mobile IPv6 183 The Home Address option specified in early drafts of Mobile IPv6 184 would have allowed a trivial source spoofing attack as discussed in 185 [I-D.savola-ipv6-rh-ha-security]. The version of Mobile IPv6 as 186 standardised in [RFC3775] has removed this issue by ensuring that the 187 Home Address destination option is only processed if there is a 188 corresponding binding cache entry and securing Binding Update 189 messages. 191 2.1.4 Site(and Larger)-scope Multicast Addresses 193 IPv6 supports multicast addresses with site scope which can 194 potentially allow an attacker to identify certain important resources 195 on the site if misused. In principle these addresses also have 196 equivalents for organization-scope and global-scope which could also 197 be misused. 199 Particular examples are the 'all routers' (FF05::2) and 'all DHCP 200 servers' (FF05::1:3) addresses defined in [RFC2375]: an attacker that 201 is able to infiltrate a message destined for these addresses on to 202 the site will potentially receive in return information identifying 203 key resources on the site. This information can then be the target 204 of directed attacks ranging from simple flooding to more specific 205 mechanisms designed to subvert the device. 207 Some of these addresses have current legitimate uses within a site. 208 The risk from external sources can be minimised by ensuring that all 209 firewalls and site boundary routers are configured to drop packets 210 with site-scope and organization-scope destination addresses. Also 211 nodes should not join multicast groups for which there is no 212 legitimate use on the site and site routers should be configured to 213 drop packets directed to these unused addresses. 215 An attacker internal to the site could potentially use these 216 addresses as part of a scanning attack. 218 TBD: There needs to be more discussion of possible defences against 219 these attacks and ways that they could be carried out from outside 220 the site (use of source-specific join). Also consideration of the 221 difficulties of applying appropriate filtering for multicast 222 addresses at site boundaries. 224 2.1.5 ICMPv6 and Multicast 226 It is possible to launch a denial-of-service (DoS) attack using IPv6 227 which could be amplified by the multicast infrastructure. 229 Unlike ICMP for IPv4, ICMPv6 [RFC2463] allows error notification 230 responses to be sent when certain unprocessable packets are sent to 231 multicast addresses. 233 The cases in which responses are sent are: 234 o The received packet is longer than the next link MTU: 'Packet Too 235 Big' responses are needed to support Path MTU Discovery for 236 multicast traffic. 237 o The received packet contains an unrecognised option in a 238 hop-by-hop or destination options extension header with the first 239 two bits of the option type set to binary '10': 'Parameter 240 Problem' responses are intended to inform the source that some or 241 all of the recipients cannot handle the option in question. 243 If an attacker can craft a suitable packet sent to a multicast 244 destination, it may be possible to elicit multiple responses directed 245 at the victim (the spoofed source of the multicast packet). 247 In practice an attack using oversize packets is unlikely to cause 248 much amplification unless the attacker is able to carefully tune the 249 packet size to exploit a network with smaller MTU in the edge than 250 the core. Similarly a packet with an unrecognised hop-by-hop option 251 would be dropped by the first router. However a packet with an 252 unrecognised destination option could generate multiple responses. 253 On the other hand, the use of 'reverse path forwarding' checks to 254 eliminate loops in multicast forwarding limits the range of addresses 255 which can be spoofed, except where unicast-encapsulated register 256 messages are used. 258 In addition to amplification, this kind of attack would potentially 259 consume large amounts of forwarding state resources in routers on 260 multicast-enabled networks. See [I-D.savola-v6ops-firewalling]. 262 2.1.6 Anycast traffic Identification and Security 264 IPv6 introduces the notion of anycast addresses and services. A 265 request to an anycast service will return the global unicast address 266 of the server that actually implements the service thereby exposing 267 some knowledge about the internal structure of the network. It may 268 be desirable to consider using specialised addresses for anycast 269 servers which are not used for any other part of the network to 270 restrict the information exposed. Alternatively operators may wish 271 to restrict the use of anycast services from outside the domain, thus 272 requiring firewalls to filter anycast requests. For this purpose, 273 firewalls need to know which addresses are being used for anycast 274 services: these addresses are arbitrary and look just like any other 275 IPv6 unicast address. 277 It is also difficult to secure anycast communications using IPsec and 278 IKE. 280 2.1.7 Address Privacy Extensions Interact with DDoS Defenses 282 The purpose of the privacy extensions for stateless address 283 auto-configuration [RFC3041] is to change the interface identifier 284 (and hence the global scope addresses generated from it) from time to 285 time in order to make it more difficult for eavesdroppers and other 286 information collectors to identify when different addresses used in 287 different transactions actually correspond to the same node. 289 The security issue resulting from this is that if the frequency of 290 change of the addresses used by a node is sufficiently great to 291 achieve the intended aim of the privacy extensions, the observed 292 behavior of the node could look very like that of a compromised node 293 which was being used as the source of a distributed denial-of-service 294 (DDoS). It would thus be difficult to for any future defenses 295 against DDoS attacks to distinguish between a high rate change of 296 addresses resulting from genuine use of the privacy extensions and a 297 compromised node being used as the source of a DDoS with 'in-prefix' 298 spoofed source addresses as described in 299 [I-D.dupont-ipv6-rfc3041harmful]. 301 2.1.8 Dynamic DNS, Stateless Address Auto-Configuration and Privacy 302 Extensions 304 The introduction of Stateless Address Auto-Configuration (SLAAC) with 305 IPv6 provides an additional challenge to the security of Dynamic DNS. 306 With manual addressing or the use of DHCP, the number of hosts 307 trusted to make updates to the DNS server is limited, assuming any 308 necessary updates are carried out by the DHCP server. This is true 309 equally for IPv4 and IPv6. 311 Since SLAAC does not make use of a single and potentially trusted 312 DHCP server, but depends on the node obtaining the address, securing 313 the insertion of updates into DDNS may need a security association 314 between each node and the DDNS server. This is discussed further in 315 [I-D.ietf-dnsop-ipv6-dns-issues]. 317 Using the Privacy Extensions to SLAAC [RFC3041] may significantly 318 increase the rate of updates of Dynamic DNS, assuming a node which 319 wishes to use the privacy extensions wishes to publish its address in 320 some DNS server. If the rate of change needed to achieve real 321 privacy has to be increased as is mentioned in Section 2.1.7 the 322 update rate for DDNS may be excessive. 324 2.1.9 Extension Headers 326 A number of issues relating to the specification of IPv6 Extension 327 headers have been identified. Several of these are discussed in 328 [I-D.savola-v6ops-firewalling]. 330 2.1.9.1 Processing Extension Headers in Middleboxes 332 In IPv4 deep packet inspection techniques are used to implement 333 policing and filtering both as part of routers and in middleboxes 334 such as firewalls. Fully extending these techniques to IPv6 would 335 require inspection of all the extension headers in a packet to ensure 336 that policy constraints on the use of certain headers and options 337 were enforced and to remove packets containing potentially damaging 338 unknown options at the earliest opportunity. 340 This requirement appears to conflict with Section 4 of the IPv6 341 specification in [RFC2460] which requires that destination options 342 are not processed at all until the packet reaches the appropriate 343 destination (either the final destination or a routing header 344 waypoint). 346 Also [RFC2460] forbids processing the headers other than in the order 347 in which they appear in the packet. 349 A further ambiguity relates to whether an intermediate node should 350 discard a packet which contains a header or destination option which 351 it does not recognise. If the rules above are followed slaveishly, 352 it is not (or may not be) legitimate for the intermediate node to 353 discard the packet because it should not be processing those headers 354 or options. 356 [RFC2460] therefore does not appear to take account of the behavior 357 of middleboxes and other non-final destinations which may be 358 inspecting the packet, and thereby potentially limits the security 359 protection of these boxes. 361 2.1.9.2 Processing Extension Header Chains 363 There is a further problem for middleboxes that want to examine the 364 transport headers which are located at the end of the IPv6 header 365 chain. In order to locate the transport header or other protocol 366 data unit, the node has to parse the header chain. 368 The IPv6 specification [RFC2460] does not mandate the use of the 369 Type-Length-Value format with a fixed layout for the start of each 370 header although it is used for the majority of headers currently 371 defined. (Only the Type field is guaranteed in size and offset). 372 For example the fragment header does not conform to the TLV format 373 used for all the other headers. 375 A middlebox cannot therefore guarantee to be able to process header 376 chains which may contain headers defined after the box was 377 manufactured. As noted in Section 2.1.9.1, middleboxes ought not to 378 have to know about all header types in use but still need to be able 379 to skip over such headers to find the transport PDU start. This 380 either limits the security which can be applied in firewalls or makes 381 it difficult to deploy new extension header types. 383 As noted in Section 2.1.9.1, Destination Options may contain unknown 384 options. However, the options are encoded in TLV format so that 385 intermediate nodes can skip over them during processing, unlike the 386 enclosing extension headers. 388 2.1.9.3 Unknown Headers/Destination Options and Security Policy 390 A strict security policy might dictate that packets containing either 391 unknown headers or destination options are discarded by firewalls or 392 other filters. This requires the firewall to process the whole 393 extension header chain which may be currently in conflict with the 394 IPv6 specification as discussed in Section 2.1.9.1. 396 Even if the firewall does inspect the whole header chain, it may not 397 be sensible to discard packets with items unrecognised by the 398 firewall because the intermediate node has no knowledge of which 399 options and headers are implemented in the destination node. Hence 400 it is highly desirable to make the discard policy configurable to 401 avoid firewalls dropping packets with legitimate items that they do 402 not recognise because their hardware or software is not aware of a 403 new definition. 405 2.1.9.4 Excessive Hop-by-Hop Options 407 IPv6 does not limit the number of hop by hop options which can be 408 present in a hop-by-hop option header. This can be used for mounting 409 denial of service attacks affecting all nodes on a path as described 410 in [I-D.krishnan-ipv6-hopbyhop]. 412 2.1.9.5 Overuse of Router Alert Option 414 The IPv6 router alert option specifies a hop-by-hop option that, if 415 present, signals the router to take a closer look at the packet. 416 This can be used for denial of service attacks. By sending a large 417 number of packets with the router alert option present an attacker 418 can deplete the processor cycles on the routers available to 419 legitimate traffic. 421 2.1.10 Fragmentation: Reassembly and Deep Packet Inspection 423 The current specifications of IPv6 in [RFC2460] do not mandate any 424 minimum packet size for the fragments of a packet before the last 425 one, except for the need to carry the unfragmentable part in all 426 fragments. 428 The unfragmentable part does not include the transport port numbers 429 so that it is possible that the first fragment does not contain 430 sufficient information to carry out deep packet inspection involving 431 the port numbers. 433 Also the reassembly rules for fragmented packets in [RFC2460] do not 434 mandate behavior which would minimise the effects of overlapping 435 fragments. 437 Depending on the implementation of packet reassembly and the 438 treatment of packet fragments in firewalls and other nodes which use 439 deep packet inspection for traffic filtering, this potentially leaves 440 IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128] 441 for IPv4. 443 There is no reason to allow overlapping packet fragments and overlaps 444 could be prohibited in a future revision of the protocol 445 specification. Some implementations already drop all packets with 446 overlapped fragments. 448 Specifying a minimum size for packet fragments does not help in the 449 same way as it does for IPv4 because IPv6 extension headers can be 450 made to appear very long: an attacker could insert one or more 451 undefined destination options with long lengths and the 'ignore if 452 unknown' bit set. Given the guaranteed minimum MTU of IPv6 it seems 453 reasonable that hosts should be able to ensure that the transport 454 port numbers are in the first fragment in almost all cases and that 455 deep packet inspection should be very suspicious of first fragments 456 that do not contain them. 458 2.1.11 Fragmentation Related DoS Attacks 460 Packet reassembly in IPv6 hosts also opens up the possibility of 461 various fragment-related security attacks. Some of these are 462 analagous to attacks identified for IPv4. Of particular concern is a 463 DoS attack based on sending large numbers of small fragments without 464 a terminating last fragment which would potentially overload the 465 reconstruction buffers and consume large amounts of CPU resources. 467 Mandating the size of packet fragments could reduce the impact of 468 this kind of attack by limiting the rate at which fragments could 469 arrive. 471 2.1.12 Areas of Improved Security in IPv6 473 There are several areas where IPv4 security is weak which have been 474 made stronger either in the base IPv6 specifications or by additional 475 specifications. These areas include: 477 o Combatting threats related to local links, comparable to various 478 ARP spoofing techniques associated with IPv4; the Neighbor 479 Discovery (ND) threats have been documented in [RFC3756] and 480 mechanisms to combat them specified in Secure Neighbor Discovery 481 (SEND) [I-D.ietf-send-ndopt]. SEND is an optional mechanism which 482 is particularly applicable to wireless and other environments 483 where it is difficult to physically secure the link. 485 o Improving Mobile IP security: Mobile IPv6 offers significantly 486 enhanced security compared with Mobile IPv4 especially when using 487 optimized routing and care-of addresses. Return routability 488 checks are used to provide relatively robust assurance that the 489 different addresses which a mobile node uses as it moves through 490 the network do indeed all refer to the same node. The threats and 491 solutions are described in [RFC3775] and a more extensive 492 discussion of the security aspects of the design can be be found 493 in [I-D.ietf-mip6-ro-sec]. 495 Appendix A lists (typically bogus) considerations related to IPv6 496 network mapping or probing. Appendix B lists mainly unfounded claims 497 about the lack of privacy in IPv6. 499 2.2 IPv4-mapped IPv6 Addresses 501 Overloaded functionality is always a double-edged sword: it may yield 502 some deployment benefits, but often also incurs the price which comes 503 with ambiguity. 505 One example of such is IPv4-mapped IPv6 addresses: a representation 506 of an IPv4 address as an IPv6 address inside an operating system. 507 Since the original specification, IPv4-mapped addresses have been 508 extended to be used with a transition mechanism [RFC2765], on the 509 wire. 511 Therefore, it becomes difficult to unambiguously discern whether an 512 IPv4 mapped address is really an IPv4 address represented in the IPv6 513 address format *or* an IPv6 address received from the wire (which may 514 be subject to address forgery, etc.). 516 In addition, special cases like these, while giving deployment 517 benefits in some arenas, require a considerable amount of code 518 complexity (e.g. in the implementations of bind() system calls) 519 which is probably undesirable. These issues are discussed in 520 [I-D.cmetz-v6ops-v4mapped-api-harmful] and 521 [I-D.itojun-v6ops-v4mapped-harmful]. 523 Given the issues that have been identified, it seems appropriate that 524 mapped addresses should not be used on the wire. However, changing 525 application behavior by deprecating the use of mapped addresses in 526 the operating system interface would have significant impact on 527 application porting methods and needs further study. 529 2.3 Increased End-to-End Transparency 531 With IPv6, increased end-to-end transparency in general can sometimes 532 be seen as a threat. Some seem to want limited end-to-end 533 capabilities, e.g. in the form of private, local addressing, even 534 when it is not necessary. 536 People have gotten used to the perceived, dubious security benefits 537 of NATs and perimeter firewalls, and the bidirectionality and 538 transparency that IPv6 can provide may seem undesirable at times. 540 This is a really important issue especially for most enterprise 541 network managers. 543 It is worth noting that IPv6 does not *require* end-to-end 544 connectivity. It merely provides end-to-end addressability; the 545 connectivity can still be controlled using firewalls (or other 546 mechanisms), and it is indeed wise to do so. 548 3. Issues Due to Transition Mechanisms 550 3.1 IPv6 Transition/Co-existence Mechanism-specific Issues 552 The more complicated the IPv6 transition/co-existence becomes, the 553 greater the danger that security issues will be introduced in the 554 mechanisms (which may or may not be readily apparent). Therefore it 555 would be desirable to keep the mechanisms simple, and in as small 556 pieces as possible. 558 One case where such security issues have been analyzed is 559 [I-D.ietf-v6ops-6to4-security] . 561 As tunneling has been proposed as a model for several more cases than 562 are currently being used, its security properties should be analyzed 563 in more detail. There are some generic dangers to tunneling: 565 o it may be easier to avoid ingress filtering checks 566 o it is possible to attack the tunnel interface: several IPv6 567 security mechanisms depend on checking that Hop Limit equals 255 568 on receipt and that link-local addresses are used. Sending such 569 packets to the tunnel interface is much easier than gaining access 570 to a physical segment and sending them there. 571 o automatic tunneling mechanisms are typically particularly 572 dangerous as the other end-point is unspecified, and packets have 573 to be accepted and decapsulated from everywhere. Therefore, 574 special care should be observed when specifying automatic 575 tunneling techniques. 577 3.2 Automatic Tunneling and Relays 579 Two mechanisms have been (or are being) specified which use automatic 580 tunneling over IPv4 or UDP/IPv4 between the nodes enabling the same 581 mechanism for connectivity: 6to4 and Teredo (respectively). 583 The first obvious issue (as mentioned above) in such approaches is 584 that such nodes must allow decapsulation of traffic from anywhere in 585 the Internet. That kind of decapsulation function must be extremely 586 well secured as it's so wide open. 588 Even more difficult problem is how these mechanisms are able to 589 communicate with native IPv6 nodes or between the automatic tunneling 590 mechanisms: such connectivity requires the use of some kind of 591 "relays". These relays could be deployed e.g., in all native IPv6 592 nodes, native IPv6 sites, IPv6 ISPs, or just somewhere in the 593 Internet. This has some obvious trust and scaling issues. As 594 authentication of such a relay service is very difficult, and more so 595 in some of those deployment models, relays provide a means to for 596 address spoofing, (reflected) Denial-of-Service attacks, and other 597 threats. 599 Threats related to 6to4 are discussed in 600 [I-D.ietf-v6ops-6to4-security]. 602 3.3 Tunneling May Break Security Assumptions 604 NATs and firewalls have been deployed extensively in the IPv4 605 Internet, for the good or the bad. People who deploy them typically 606 have some security/operational requirements in mind (e.g. a desire 607 to block inbound connection attempts), whether misguided or not. 609 Tunneling can change that model. IPv6-over-IPv4 tunneling is 610 typically explicitly allowed or disallowed implicitly. Tunneling 611 IPv6 over IPv4 with UDP, however, is often an entirely different 612 thing: as UDP must usually be allowed through, at least in part and 613 in a possibly stateful manner, one can "punch holes" in NAT's and 614 firewalls using UDP. Actually, the mechanisms have been explicitly 615 designed to traverse both NATs and firewalls in a similar fashion. 617 One could say that tunneling is especially questionable in home/SOHO 618 environments where the level of network administration is not that 619 high; in these environments the hosts may not be as managed as in 620 others (e.g., network services might be enabled unnecessarily), 621 leading to possible security break-ins or other vulnerabilities. 623 Holes can be punched both intentionally and unintentionally. In case 624 it is a willing choice from the administrator/user, this is less of a 625 problem (but e.g., enterprises might want to block IPv6 tunneling 626 explicitly if some employees would do something like this willingly 627 on their own). On the other hand, if a hole is punched 628 transparently, without people understanding the consequences, it will 629 very probably result in a serious threat sooner or later. 631 When deploying tunneling solutions, especially tunneling solutions 632 which are automatic and/or can be enabled easily by users not 633 understanding the consequences, care should be taken not to 634 compromise the security assumptions held by the users. 636 For example, NAT traversal should not be performed by default unless 637 there is a firewall producing a similar by-default security policy as 638 IPv4 NAT provides. Protocol-41 tunneling is less of a problem, as it 639 is easier to block if necessary; however, if the host is protected in 640 IPv4, the IPv6 side should be protected as well. 642 As has been shown in Appendix A, it is relatively easy to find out 643 IPv6 address of corresponding to an IPv4 address, so one should never 644 rely on "security by obscurity" i.e., relying that nobody is able to 645 guess or know the IPv6 address of the host. 647 4. Issues Due to IPv6 Deployment 649 4.1 IPv6 Service Piloting Done Insecurely 651 In many cases, IPv6 service piloting is done in a manner which is 652 considered to be less secure than as one would do with IPv4. For 653 example, hosts and routers might not be protected by IPv6 firewalls, 654 even if in IPv4 firewalls are being used. 656 The other possible alternative, in some places, is that no service 657 piloting is done at all because IPv6 firewalls may not be widely used 658 -- and IPv6 deployment suffers (of course, this is also one of the 659 nice excuses for not doing IPv6). 661 This problem may be partially due to a slow speed of IPv6-capable 662 firewall development and deployment. However, it is also a problem 663 with a lack of information: actually, there are quite a few IPv6 664 packet filters and firewalls already, which could be used for 665 sufficient access controls, but network administrators may not be 666 aware of them yet. 668 However, there appears to be a real lack in two areas: 'personal 669 firewalls' and enterprise firewalls; the same devices that support 670 and are used for IPv4 today are often expected to also become 671 IPv6-capable -- even though this is not really required. That is, 672 IPv4 access could be filtered by one firewall, and when IPv6 access 673 is added, it could be protected by another firewall; they don't have 674 to be the same, and even their models don't have to be the same. 676 Another, smaller factor may be that due to a few decisions on how 677 IPv6 was built, it's more difficult for firewalls to be implemented 678 and work under all the cases (e.g. when new extension headers etc. 679 are used) as discussed in Section 2.1.9: it is significantly more 680 difficult for intermediate nodes to process the IPv6 header chains 681 than IPv4 packets. 683 A similar argument, which is often quoted as hindering IPv6 684 deployment, has been the lack of Intrusion Detection Systems (IDS). 685 It is not clear whether this is more of an excuse than a real reason. 687 4.2 Enabling IPv6 by Default Brings the Usability Down 689 A practical disadvantage of enabling IPv6 as of this writing is that 690 it typically brings the observed service level down a bit; that is, 691 the usability suffers. 693 This is due to at least three reasons: 695 o global IPv6 routing is still rather unstable, leading to packet 696 loss, lower throughput, and higher delay 697 [I-D.savola-v6ops-6bone-mess] 698 o some applications cannot properly handle both IPv4 and IPv6 or may 699 have problems handling all the fallbacks and failure modes (and in 700 some cases, e.g. if the TCP timeout kicks in, this may be very 701 difficult) 702 o some DNS server implementations have flaws that severely affect 703 DNS queries for IPv6 addresses 704 [I-D.ietf-dnsop-misbehavior-against-aaaa] 706 Actually, some would be 100% ready to release IPv6 services (e.g. 707 web) today, but that would mean trouble for many of their 708 dual-stacked customers or users all over the world so they don't: 709 these are often published under a separate domain or subdomain, and 710 are practically not used that often. 712 These issues are also described at some length in 713 [I-D.ietf-v6ops-v6onbydefault] . 715 4.3 Addressing Schemes and Securing Routers 717 Whilst in general terms brute force scanning of IPv6 subnets is 718 essentially impossible due to the enormously larger address space of 719 IPv6 and the 64 bit interface identifiers (see Appendix A), this will 720 be obviated if administrators do not take advantage of the large 721 space to use unguessable interface identifiers. 723 Because the unmemorability of complete IPv6 addresses there is a 724 temptation for administrators to use small integers as interface 725 identifiers when manually configuring them, as might happen on 726 point-to-point links. Such allocations make it easy for an attacker 727 to find active nodes that they can then port scan. 729 It is also essential to ensure that the management interfaces of 730 routers are well secured as the router will usually contain a 731 significant cache of neighbor addresses in its neighbor cache. 733 4.4 Consequences of Multiple Addresses in IPv6 735 One positive consequence of IPv6 is that nodes which do not require 736 global access can communicate locally just by the use of a link local 737 address (if very local access is sufficient) or across the site by 738 using a Unique Local Address (ULA). In either case it is easy to 739 ensure that access outside the assigned domain of activity can be 740 controlled by simple filters (which may be the default for link 741 locals). 743 On the other hand, the possibility that a node or interface can have 744 multiple global scope addresses makes access control filtering both 745 on ingress and egress more complex and requires higher maintenance 746 levels. 748 4.5 Deploying ICMPv6 750 In IPv4 it is generally accepted that stringent filtering of ICMP 751 packets by firewalls is essential to maintain security. Because of 752 the extended use that is made of ICMPv6 with a multitude of 753 functions, the simple set of dropping rules that are usually applied 754 in IPv4 need to be significantly developed for IPv6. The blanket 755 dropping of all ICMP messages that is used in some very strict 756 environments is simply not possible for IPv6. 758 In an IPv6 firewall, policy needs to allow some messages through the 759 firewall but also has to permit certain messages to and from the 760 firewall. 762 To support effective functioning of IPv6, firewalls should typically 763 allow the following messages to pass through the firewall (the first 764 four are equivalent to the typical IPv4 filtering allowance): 765 o ICMPv6 Type 1, Code 0 - No route to destination error 766 o ICMPv6 Type 3 - Time exceeded error 767 o ICMPv6 Type 128 - Echo request 768 o ICMPv6 Type 129 - Echo response 769 o ICMPv6 Type 2 - Packet too big (required for Path MTU Discovery) 770 o ICMPv6 Type 4 - Parameter problem (this type needs to be 771 investigated further as it is possible that it can be abused. 773 Additionally the following ICMPv6 messages may be required to be 774 supported to and from a firewall: 775 o ICMPv6 Type 2 - packet too big - The firewall itself has to 776 participate in Path MTU Discovery. 777 o ICMPv6 Type 130-132 - Multicast Listener Discovery messages have 778 to be accepted by routing devices to replace IGMP which is used in 779 IPv4[Check for MLDv2] 780 o ICMPv6 Type 133/134 - Router Solicitations and Advertisements - 781 assuming the firewall is also a router, it needs to support router 782 discovery and host auto-configuration. 783 o ICMPv6 Type 135/136 - Neigbor Solicitation and Advertisement - 784 Needed for duplicate address detection and Layer 2 address 785 resolution. 786 o ICMPv6 Type 4 - parameter Problem - Needs further investigation 787 because of possible abuse. 789 4.6 Operational Factors when Enabling IPv6 in the Network 791 You have to be careful when enabling IPv6 in the network gear for 792 multiple reasons: 794 IPv6-enabled router software may be unstable(r) yet; either IPv6 is 795 unstable, or the software you have to run to be able to run IPv6 is 796 different (from non-IPv6 parts) from the one you would run otherwise, 797 making the software in practice more unstable -- and raising the bar 798 for IPv6 adoption. 800 IPv6 processing may not happen at (near) line speed (or in the same 801 level as IPv4). A high amount of IPv6 traffic (even legitimate, e.g. 802 NNTP) could easily overload the software-based IPv6 processing and 803 cause harm also to IPv4 processing, affecting availability. That is, 804 if people don't feel confident enough in the IPv6 support, they will 805 be hesitant to enable it in their "production" networks. 807 Sometimes required features may be missing from the vendors' software 808 releases; an example is a software enabling IPv6 telnet/SSH access, 809 but having no ability to turn it off or limit access to it! 811 Sometimes the default IPv6 configuration is insecure. For example, 812 in one vendor, if you have restricted IPv4 telnet to only a few hosts 813 in the configuration, you need to be aware that IPv6 telnet will be 814 automatically enabled, that the configuration commands used 815 previously do not block IPv6 telnet, IPv6 telnet is open to the world 816 by default, and that you have to use a separate command to also lock 817 down the IPv6 telnet access. 819 Many operator networks have to run interior routing protocols for 820 both IPv4 and IPv6. It's possible to run the both in one routing 821 protocol, or have two separate routing protocols; either approach has 822 its tradeoffs. If multiple routing protocols are used, one should 823 note that this causes double the number of processing when links flap 824 or recalculation is otherwise needed -- which might more easily 825 overload the routers' CPU, causing slightly slower convergence time. 827 5. Acknowledgements 829 Alain Durand, Alain Baudot, Luc Beloeil, and Andras Kis-Szabo 830 provided feedback to improve this memo. Michael Wittsend and Michael 831 Cole discussed issues relating to probing/mapping and privacy. 833 6. Security Considerations 835 This memo tries to give an overview of security considerations of the 836 different aspects of IPv6. 838 7. References 840 7.1 Normative References 842 [I-D.savola-v6ops-transarch] 843 Savola, P., "A View on IPv6 Transition Architecture", 844 draft-savola-v6ops-transarch-03 (work in progress), 845 January 2004. 847 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 848 Assignments", RFC 2375, July 1998. 850 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 851 (IPv6) Specification", RFC 2460, December 1998. 853 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 854 Protocol (ICMPv6) for the Internet Protocol Version 6 855 (IPv6) Specification", RFC 2463, December 1998. 857 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 858 Stateless Address Autoconfiguration in IPv6", RFC 3041, 859 January 2001. 861 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 862 in IPv6", RFC 3775, June 2004. 864 7.2 Informative References 866 [I-D.dupont-ipv6-rfc3041harmful] 867 Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", 868 draft-dupont-ipv6-rfc3041harmful-05 (work in progress), 869 June 2004. 871 [I-D.savola-v6ops-6bone-mess] 872 Savola, P., "Moving from 6bone to IPv6 Internet", 873 draft-savola-v6ops-6bone-mess-01 (work in progress), 874 November 2002. 876 [I-D.ietf-v6ops-6to4-security] 877 Savola, P., "Security Considerations for 6to4", 878 draft-ietf-v6ops-6to4-security-04 (work in progress), July 879 2004. 881 [I-D.ietf-dnsop-misbehavior-against-aaaa] 882 Morishita, Y. and T. Jinmei, "Common Misbehavior against 883 DNS Queries for IPv6 Addresses", 884 draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in 885 progress), April 2004. 887 [FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. 888 Second Internet Measurement Workshop , November 2002, 889 . 891 [I-D.savola-v6ops-firewalling] 892 Savola, P., "Firewalling Considerations for IPv6", 893 draft-savola-v6ops-firewalling-02 (work in progress), 894 October 2003. 896 [I-D.schild-v6ops-guide-v4mapping] 897 Schild, C., "Guide to Mapping IPv4 to IPv6 Subnets", 898 draft-schild-v6ops-guide-v4mapping-00 (work in progress), 899 January 2004. 901 [I-D.ietf-v6ops-v6onbydefault] 902 Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack 903 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 904 (work in progress), July 2004. 906 [I-D.chown-v6ops-port-scanning-implications] 907 Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 908 draft-chown-v6ops-port-scanning-implications-01 (work in 909 progress), July 2004. 911 [I-D.savola-ipv6-rh-ha-security] 912 Savola, P., "Security of IPv6 Routing Header and Home 913 Address Options", draft-savola-ipv6-rh-ha-security-02 914 (work in progress), March 2002. 916 [I-D.savola-ipv6-rh-hosts] 917 Savola, P., "Note about Routing Header Processing on IPv6 918 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), 919 February 2002. 921 [I-D.ietf-mip6-ro-sec] 922 Nikander, P., "Mobile IP version 6 Route Optimization 923 Security Design Background", draft-ietf-mip6-ro-sec-02 924 (work in progress), October 2004. 926 [I-D.ietf-send-ndopt] 927 Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 928 Nikander, "SEcure Neighbor Discovery (SEND)", 929 draft-ietf-send-ndopt-06 (work in progress), July 2004. 931 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 932 Discovery (ND) Trust Models and Threats", RFC 3756, May 933 2004. 935 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 936 (SIIT)", RFC 2765, February 2000. 938 [RFC1858] Ziemba, G., Reed, D. and P. Traina, "Security 939 Considerations for IP Fragment Filtering", RFC 1858, 940 October 1995. 942 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 943 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 945 [I-D.cmetz-v6ops-v4mapped-api-harmful] 946 Metz, C. and J. Hagino, "IPv4-Mapped Address API 947 Considered Harmful", 948 draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in 949 progress), October 2003. 951 [I-D.itojun-v6ops-v4mapped-harmful] 952 Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire 953 Considered Harmful", 954 draft-itojun-v6ops-v4mapped-harmful-02 (work in progress), 955 October 2003. 957 [I-D.ietf-dnsop-ipv6-dns-issues] 958 Durand, A., Ihren, J. and P. Savola, "Operational 959 Considerations and Issues with IPv6 DNS", 960 draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress), 961 August 2004. 963 [I-D.krishnan-ipv6-hopbyhop] 964 Krishnan, S., "Arrangement of Hop-by-Hop options", 965 draft-krishnan-ipv6-hopbyhop-00 (work in progress), June 966 2004. 968 Authors' Addresses 970 Elwyn B. Davies 971 Nortel Networks 972 Harlow Laboratories 973 London Road 974 Harlow, Essex CM17 9NA 975 UK 977 Phone: +44 1279 405 498 978 EMail: elwynd@nortelnetworks.com 980 Suresh Krishnan 981 Ericsson 982 8400 Decarie Blvd. 983 Town of Mount Royal, QC H4P 2N2 984 Canada 986 Phone: +1 514-345-7900 987 EMail: suresh.krishnan@ericsson.com 989 Pekka Savola 990 CSC/Funet 992 EMail: psavola@funet.fi 994 Appendix A. IPv6 Probing/Mapping Considerations 996 Some want the IPv6 numbering topology (either at network or node 997 level) [I-D.schild-v6ops-guide-v4mapping] match IPv4 as exactly as 998 possible, the others see this as a security threat because IPv6 could 999 have different security properties than IPv4. 1001 That is, if an attacker knows the IPv4 address of the node, he might 1002 want to try to probe the corresponding IPv6 address, based on the 1003 assumption that the security defenses might be lower. This might be 1004 the case particularly for nodes which are behind a NAT in IPv4, but 1005 globally addressable in IPv6. Naturally, this is not a concern if 1006 the similar security policies are in place. 1008 On the other hand, brute-force scanning or probing is unfeasible 1009 [I-D.chown-v6ops-port-scanning-implications]. 1011 For example, automatic tunneling mechanisms use rather deterministic 1012 methods for generating IPv6 addresses, so probing/port-scanning an 1013 IPv6 node is simplified. The IPv4 address is embedded at least in 1014 6to4, Teredo and ISATAP address. Further than that, it's possible 1015 (in the case of 6to4 in particular) to learn the address behind the 1016 prefix; for example, Microsoft 6to4 implementation uses the address 1017 2002:V4ADDR::V4ADDR while Linux and BSD implementations default to 1018 2002:V4ADDR::1. This could also be used as one way to identify an 1019 implementation. 1021 One proposal has been to randomize the addresses or Subnet identifier 1022 in the address of the 6to4 router. This doesn't really help, as the 1023 6to4 router (whether a host or a router) will return an ICMPv6 Hop 1024 Limit Exceeded message, revealing the IP address. Hosts behind the 1025 6to4 router can use methods such as RFC 3041 addresses to conceal 1026 themselves, though. 1028 To conclude, it seems that with an IPv4 address, the respective IPv6 1029 address, when automatic tunneling mechanism is being used, could 1030 possibly be guessed with relative ease. This has significant 1031 implications if the IPv6 security policy isn't the same as IPv4. 1033 Appendix B. IPv6 Privacy Considerations 1035 It has been claimed that IPv6 harms the privacy of the user, either 1036 by exposing the MAC address, or by exposing the number of nodes 1037 connected to a site. 1039 B.1 Exposing MAC Addresses 1041 The MAC address, which with stateless address autoconfiguration, 1042 results in an EUI64, exposes the model of network card. The concern 1043 has been that a user might not want to expose the details of the 1044 system to outsiders, e.g., in the fear of a resulting burglary (e.g., 1045 if a crook identifies expensive equipment from the MAC addresses). 1047 In most cases, this seems completely unfounded. First, such an 1048 address must be learned somehow -- this is a non-trivial process; the 1049 addresses are visible e.g., in web site access logs, but the chances 1050 that a random web site owner is collecting this kind of information 1051 (or whether it would be of any use) are quite slim. Being able to 1052 eavesdrop the traffic to learn such addresses (e.g., by the 1053 compromise of DSL or Cable modem physical media) seems also quite 1054 far-fetched. Further, using RFC 3041 addresses for such purposes is 1055 straightforward if worried about the risk. Second, the burglar would 1056 have to be able to map the IP address to the physical location; this 1057 is typically only available in the private customer database of the 1058 ISP. 1060 B.2 Exposing Multiple Devices 1062 Another presented concern is whether the user wants to show off as 1063 having a lot of computers or other devices at a network; NAT "hides" 1064 everything behind an address, but is not perfect either [FNAT]. 1066 One practical reason why some may find this desirable is being able 1067 to thwart certain ISPs' business models, where one should pay extra 1068 for additional computers (and not the connectivity as a whole). 1070 Similar feasibility issues as described above apply. To a degree, 1071 the counting avoidance could be performed by the sufficiently 1072 frequent re-use of RFC 3041 addresses -- that is, if during a short 1073 period, dozens of generated addresses seem to be in use, it's 1074 difficult to estimate whether they are generated by just one host or 1075 multiple hosts. 1077 Intellectual Property Statement 1079 The IETF takes no position regarding the validity or scope of any 1080 Intellectual Property Rights or other rights that might be claimed to 1081 pertain to the implementation or use of the technology described in 1082 this document or the extent to which any license under such rights 1083 might or might not be available; nor does it represent that it has 1084 made any independent effort to identify any such rights. Information 1085 on the procedures with respect to rights in RFC documents can be 1086 found in BCP 78 and BCP 79. 1088 Copies of IPR disclosures made to the IETF Secretariat and any 1089 assurances of licenses to be made available, or the result of an 1090 attempt made to obtain a general license or permission for the use of 1091 such proprietary rights by implementers or users of this 1092 specification can be obtained from the IETF on-line IPR repository at 1093 http://www.ietf.org/ipr. 1095 The IETF invites any interested party to bring to its attention any 1096 copyrights, patents or patent applications, or other proprietary 1097 rights that may cover technology that may be required to implement 1098 this standard. Please address the information to the IETF at 1099 ietf-ipr@ietf.org. 1101 Disclaimer of Validity 1103 This document and the information contained herein are provided on an 1104 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1105 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1106 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1107 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1108 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1109 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1111 Copyright Statement 1113 Copyright (C) The Internet Society (2004). This document is subject 1114 to the rights, licenses and restrictions contained in BCP 78, and 1115 except as set forth therein, the authors retain all their rights. 1117 Acknowledgment 1119 Funding for the RFC Editor function is currently provided by the 1120 Internet Society.