idnits 2.17.1 draft-ietf-v6ops-scanning-implications-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 577. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 5, 2007) is 6262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '1') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '2') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '3') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4214 (ref. '10') (Obsoleted by RFC 5214) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Intended status: Informational March 5, 2007 5 Expires: September 6, 2007 7 IPv6 Implications for Network Scanning 8 draft-ietf-v6ops-scanning-implications-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 6, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The 128 bits of IPv6 address space is considerably bigger than the 32 42 bits of address space of IPv4. In particular, the IPv6 subnets to 43 which hosts attach will by default have 64 bits of host address 44 space. As a result, traditional methods of remote TCP or UDP network 45 scanning to discover open or running services on a host will 46 potentially become less feasible, due to the larger search space in 47 the subnet. In addition automated attacks, such as those performed 48 by network worms, may be hampered. This document discusses this 49 property of IPv6, and describes related issues for site 50 administrators of IPv6 networks to consider, which may be of 51 importance when planning site address allocation and management 52 strategies. While traditional network scanning probes (whether by 53 individuals or automated via network worms) may become less common, 54 administrators should be aware of other methods attackers may use to 55 discover IPv6 addresses on a target network, and be aware of 56 appropriate measures to mitigate them. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Target Address Space for Network Scanning . . . . . . . . . . 4 62 2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Reducing the IPv6 Search Space . . . . . . . . . . . . . . 4 65 2.4. Dual-stack Networks . . . . . . . . . . . . . . . . . . . 5 66 2.5. Defensive Scanning . . . . . . . . . . . . . . . . . . . . 5 67 3. Alternatives for Attackers: Off-link . . . . . . . . . . . . . 5 68 3.1. Gleaning IPv6 prefix information . . . . . . . . . . . . . 6 69 3.2. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 6 70 3.3. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 6 71 3.4. Log File Analysis . . . . . . . . . . . . . . . . . . . . 6 72 3.5. Application Participation . . . . . . . . . . . . . . . . 6 73 3.6. Transition Methods . . . . . . . . . . . . . . . . . . . . 7 74 4. Alternatives for Attackers: On-link . . . . . . . . . . . . . 7 75 4.1. General on-link methods . . . . . . . . . . . . . . . . . 7 76 4.2. Multicast or Other Service Discovery . . . . . . . . . . . 8 77 5. Site Administrator Tools . . . . . . . . . . . . . . . . . . . 8 78 5.1. IPv6 Privacy Addresses . . . . . . . . . . . . . . . . . . 8 79 5.2. Cryptographically Generated Addresses (CGAs) . . . . . . . 9 80 5.3. Non-use of MAC addresses in EUI-64 format . . . . . . . . 9 81 5.4. DHCP Service Configuration Options . . . . . . . . . . . . 9 82 5.5. Rolling Server Addresses . . . . . . . . . . . . . . . . . 10 83 5.6. Application-Specific Addresses . . . . . . . . . . . . . . 10 84 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 88 10. Informative References . . . . . . . . . . . . . . . . . . . . 11 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 Intellectual Property and Copyright Statements . . . . . . . . . . 13 92 1. Introduction 94 One of the key differences between IPv4 and IPv6 is the much larger 95 address space for IPv6, which also goes hand-in-hand with much larger 96 subnet sizes. This change has a significant impact on the 97 feasibility of TCP and UDP network scanning, whereby an automated 98 process is run to detect open ports (services) on systems that may 99 then be subject of a subsequent attack. Today many IPv4 sites are 100 subjected to such probing on a recurring basis. 102 The 128 bits of IPv6 [1] address space is considerably bigger than 103 the 32 bits of address space in IPv4. In particular, the IPv6 104 subnets to which hosts attach will by default have 64 bits of host 105 address space [2]. As a result, traditional methods of remote TCP or 106 UDP network scanning to discover open or running services on a host 107 will potentially become less feasible, due to the larger search space 108 in the subnet. This document discusses this property of IPv6, and 109 describes related issues for site administrators of IPv6 networks to 110 consider, which may be of importance when planning site address 111 allocation and management strategies. 113 This document complements the transition-centric discussion of the 114 issues that can be found in Appendix A of the IPv6 Transition/ 115 Co-existence Security Considerations text [12], which takes a broad 116 view of security issues for transitioning networks. 118 The reader is also referred to a recent paper by Bellovin on worm 119 propagation strategies in IPv6 networks [13]. This paper discusses 120 some of the issues included in this document, from a slightly 121 different perspective. 123 Network scanning is quite a prevalent tactic used by would-be 124 attackers. There are two general classes of such scanning. In one 125 case, the probes are from an attacker outside a site boundary who is 126 trying to find weaknesses on any system in that network which they 127 may then subsequently be able to compromise. The other case is 128 scanning by worms that spread through (site) networks, looking for 129 further hosts to compromise. Many worms, like Slammer, rely on such 130 address scanning methods to propagate, whether they pick subnets 131 numerically (and thus probably topologically) close to the current 132 victim, or subnets in random remote networks. 134 It must be remembered that the defence of a network must not rely 135 solely on the obscurity of the hosts on that network. Such a feature 136 or property is only one measure in a set of measures that may be 137 applied. However, with a growth in usage of IPv6 devices in open 138 networks likely, and security becoming more likely an issue for the 139 end devices, such obfuscation can be useful where its use is of 140 little or no cost to the administrator to implement it. However, a 141 law of diminishing returns does apply. An administrator who 142 undertakes an address hiding policy should be aware that while IPv6 143 host addresses may be picked that are likely to take significant time 144 to discover by traditional scanning methods, there are other means by 145 which such addresses may be discovered. Implementing all of them may 146 be deemed unwarranted effort. But it is up to the site administrator 147 to be aware of the context and the options available, and in 148 particular what new methods may attackers use to glean IPv6 address 149 information, and how these can potentially be mitigated against. 150 This document is intended to be informational; there is not yet 151 sufficient deployment experience for it to be considered BCP. 153 2. Target Address Space for Network Scanning 155 There are significantly different considerations for the feasibility 156 of plain, brute force IPv4 and IPv6 address scanning. 158 2.1. IPv4 160 A typical IPv4 subnet may have 8 bits reserved for host addressing. 161 In such a case, a remote attacker need only probe at most 256 162 addresses to determine if a particular service is running publicly on 163 a host in that subnet. Even at only one probe per second, such a 164 scan would take under 5 minutes to complete. 166 2.2. IPv6 168 A typical IPv6 subnet will have 64 bits reserved for host addressing. 169 In such a case, a remote attacker in principle needs to probe 2^64 170 addresses to determine if a particular open service is running on a 171 host in that subnet. At a very conservative one probe per second, 172 such a scan may take some 5 billion years to complete. A more rapid 173 probe will still be limited to (effectively) infinite time for the 174 whole address space. However, there are ways for the attacker to 175 reduce the address search space to scan against within the target 176 subnet, as we discuss below. 178 2.3. Reducing the IPv6 Search Space 180 The IPv6 host address space through which an attacker may search can 181 be reduced in at least two ways. 183 First, the attacker may rely on the administrator conveniently 184 numbering their hosts from [prefix]::1 upward. This makes scanning 185 trivial, and thus should be avoided unless the host's address is 186 readily obtainable from other sources (for example it is the site's 187 primary DNS or email MX server). Alternatively if hosts are numbered 188 sequentially, or using any regular scheme, knowledge of one address 189 may expose other available addresses to scan. 191 Second, in the case of statelessly autoconfiguring [1] hosts, the 192 host part of the address will usually take a well-known format that 193 includes the Ethernet vendor prefix and the "fffe" stuffing. For 194 such hosts, the search space can be reduced to 48 bits. Further, if 195 the Ethernet vendor is also known, the search space may be reduced to 196 24 bits, with a one probe per second scan then taking a less daunting 197 194 days. Even where the exact vendor is not known, using a set of 198 common vendor prefixes can reduce the search. In addition, many 199 nodes in a site network may be procured in batches, and thus have 200 sequential or near sequential MAC addresses; if one node's 201 autoconfigured address is known, scanning around that address may 202 yield results for the attacker. Again, any form of sequential host 203 addressing should be avoided if possible. 205 2.4. Dual-stack Networks 207 Full advantage of the increased IPv6 address space in terms of 208 resilience to network scanning may not be gained until IPv6-only 209 networks and devices become more commonplace, given that most IPv6 210 hosts are currently dual stack, with (more readily scannable) IPv4 211 connectivity. However, many applications or services (e.g. new peer- 212 to-peer applications) on the (dual stack) hosts may emerge that are 213 only accessible over IPv6, and that thus can only be discovered by 214 IPv6 address scanning. 216 2.5. Defensive Scanning 218 The problem faced by the attacker for an IPv6 network is also faced 219 by a site administrator looking for vulnerabilities in their own 220 network's systems. The administrator should have the advantage of 221 being on-link for scanning purposes though. 223 3. Alternatives for Attackers: Off-link 225 If IPv6 hosts in subnets are allocated addresses 'randomly', and as a 226 result IPv6 network scanning becomes relatively infeasible, attackers 227 will need to find new methods to identify IPv6 addresses for 228 subsequent scanning. In this section, we discuss some possible paths 229 attackers may take. In these cases, the attacker will attempt to 230 identify specific IPv6 addresses for subsequent targeted probes. 232 3.1. Gleaning IPv6 prefix information 234 Note that in IPv6 an attacker would not be able to search across the 235 entire IPv6 address space as they might in IPv4. An attacker may 236 learn general prefixes to focus their efforts on by observing route 237 view information (e.g. from public looking glass services) or 238 information on allocated address space from RIRs. In general this 239 would only yield information at most at the /48 prefix granularity, 240 but specific /64 prefixes may be observed from route views on some 241 parts of some networks. 243 3.2. DNS Advertised Hosts 245 Any servers that are DNS listed, e.g. MX mail relays, or web 246 servers, will remain open to probing from the very fact that their 247 IPv6 addresses will be published in the DNS. Where a site uses 248 sequential host numbering, publishing just one address may lead to a 249 threat upon the other hosts. 251 Sites may use a two-faced DNS where internal system DNS information 252 is only published in an internal DNS. It is also worth noting that 253 the reverse DNS tree may also expose address information. In such 254 cases, populating the reverse DNS tree for the entire subnet, even if 255 not all addresses are actually used, may reduce that exposure. 257 3.3. DNS Zone Transfers 259 In the IPv6 world a DNS zone transfer is much more likely to narrow 260 the number of hosts an attacker needs to target. This implies 261 restricting zone transfers is (more) important for IPv6, even if it 262 is already good practice to restrict them in the IPv4 world. 264 There are some projects that provide Internet mapping data from 265 access to such transfers. Administrators may of course agree to 266 provide such transfers where they choose to do so. 268 3.4. Log File Analysis 270 IPv6 addresses may be harvested from recorded logs such as web site 271 logs. Anywhere else where IPv6 addresses are explicitly recorded may 272 prove a useful channel for an attacker, e.g. by inspection of the 273 (many) Received from: or other header lines in archived email or 274 Usenet news messages. 276 3.5. Application Participation 278 More recent peer-to-peer applications often include some centralised 279 server which coordinates the transfer of data between peers. The 280 BitTorrent application builds swarms of nodes that exchange chunks of 281 files, with a tracker passing information about peers with available 282 chunks of data between the peers. Such applications may offer an 283 attacker a source of peer IP addresses to probe. 285 3.6. Transition Methods 287 Specific knowledge of the target network may be gleaned if that 288 attacker knows it is using 6to4 [4], ISATAP [10], Teredo [11] or 289 other techniques that derive low-order bits from IPv4 addresses 290 (though in this case, unless they are using IPv4 NAT, the IPv4 291 addresses may be probed anyway). 293 For example, the current Microsoft 6to4 implementation uses the 294 address 2002:V4ADDR::V4ADDR while older Linux and FreeBSD 295 implementations default to 2002:V4ADDR::1. This leads to specific 296 knowledge of specific hosts in the network. Given one host in the 297 network is observed as using a given transition technique, it is 298 likely that there are more. 300 In the case of Teredo, the 64 bit node identifier is generated from 301 the IPv4 address observed at a Teredo server along with a UDP port 302 number. The Teredo specification also allows for discovery of other 303 Teredo clients on the same IPv4 subnet via a well-known IPv4 304 multicast address (see Section 2.17 of RFC4380 [11]). 306 4. Alternatives for Attackers: On-link 308 4.1. General on-link methods 310 If the attacker is on link, then traffic on the link, be it Neighbour 311 Discovery or application based traffic, can invariably be observed, 312 and target addresses learnt. In this document we are assuming the 313 attacker is off link, but traffic to or from other nodes (in 314 particular server systems) is likely to show up if an attacker can 315 gain a presence on any one subnet in a site's network. 317 IPv6-enabled hosts on local subnets may be discovered through probing 318 the "all hosts" link local multicast address. Likewise any routers 319 on link may be found via the "all routers" link local multicast 320 address. An attacker may choose to probe in a slightly more 321 obfuscated way by probing the solicited node multicast address of a 322 potential target host. 324 Where a host has already been compromised, its Neighbour Discovery 325 cache is also likely to include information about active nodes on 326 link, just as an ARP cache would do for IPv4. 328 4.2. Multicast or Other Service Discovery 330 A site may also have site or organisational scope multicast 331 configured, in which case application traffic, or service discovery, 332 may be exposed site wide. An attacker may choose to use any other 333 service discovery methods supported by the site. 335 There are also issues with disclosure from multicast itself. Where 336 an Embedded RP [7] multicast group address is known, the unicast 337 address of the rendezvous point is implied by the group address. 338 Where unicast prefix based multicast group addresses [5] are used, 339 specific /64 link prefixes may also be disclosed in traffic that goes 340 off-site. An administrator may thus choose to put aside /64 bit 341 prefixes for multicast group addresses that are not in use for normal 342 unicast routing and addressing. 344 5. Site Administrator Tools 346 There are some tools that site administrators can apply to make the 347 task for IPv6 network scanning attackers harder. These methods arise 348 from the considerations in the previous section. 350 The author notes that at his current (university) site, there is no 351 evidence of general network scanning running across subnets. 352 However, there is network scanning over IPv6 connections to systems 353 whose IPv6 addresses are advertised (DNS servers, MX relays, web 354 servers, etc), which are presumably looking for other open ports on 355 these hosts to probe. 357 5.1. IPv6 Privacy Addresses 359 By using the IPv6 Privacy Extensions [3] hosts in a network may only 360 be able to connect to external systems using their current 361 (temporary) privacy address. While an attacker may be able to port 362 scan that address if they do so quickly upon observing or otherwise 363 learning of the address, the threat or risk is reduced due to the 364 time-constrained value of the address. One implementation of RFC3041 365 already deployed has privacy addresses active for one day, with such 366 addresses reachable for seven days. 368 Note that an RFC3041 host will usually also have a separate static 369 global IPv6 address by which it can also be reached, and that may be 370 DNS-advertised if an externally reachable service is running on it. 371 Both of these can be served by DHCPv6. 373 The implication is that while Privacy Addresses can mitigate the 374 long-term value of harvested addresses, an attacker creating an IPv6 375 application server to which clients connect will still be able to 376 probe the clients by their Privacy Address as and when they visit 377 that server. In the general context of hiding the addresses exposed 378 from a site, an administrator may choose to use IPv6 Privacy 379 Addresses. The duration for which these are valid will impact on the 380 usefulness of such observed addresses to an external attacker. The 381 frequency with which such address get recycled could be increased, 382 though this will present the site administrator with more addresses 383 to track the usage of. 385 It may be worth exploring whether firewalls can be adapted to allow 386 the option to block traffic initiated to a known IPv6 Privacy Address 387 from outside a network boundary. While some applications may 388 genuinely require such capability, it may be useful to be able to 389 differentiate in some circumstances. 391 5.2. Cryptographically Generated Addresses (CGAs) 393 The use of Cryptographically Generated Addresses (CGAs) [9] may also 394 cause the search space to be increased from that presented by default 395 use of Stateless Autoconfiguration. Such addresses would be seen 396 where Secure Neighbour Discovery (SEND) [8] is in use. 398 5.3. Non-use of MAC addresses in EUI-64 format 400 The EUI-64 identifier format does not require the use of MAC 401 addresses for identifier construction. At least one well-known 402 operating system currently defaults to generation of the 64 bit 403 interface identifier by use of random bits, and thus does not embed 404 the MAC address. Where such a method exists as an option, an 405 administrator may wish consider use of that option. 407 5.4. DHCP Service Configuration Options 409 The administrator should configure DHCPv6 so that the first addresses 410 allocated from the pool begins much higher in the address space than 411 at [prefix]::1. Further, it is desirable that allocated addresses 412 are not sequential, nor have any predictable pattern to them. DHCPv6 413 implementors should support configuration options to allow such 414 behaviour. 416 DHCPv6 also includes an option to use Privacy Extension [3] 417 addresses, i.e. temporary addresses, as described in Section 12 of 418 the DHCPv6 [6] specification. 420 5.5. Rolling Server Addresses 422 Given the huge address space in an IPv6 subnet/link, and the support 423 for IPv6 multiaddressing, whereby a node or interface may have 424 multiple IPv6 valid addresses of which one is preferred for sending, 425 it may be possible to periodically change the advertised addresses 426 that certain long standing services use (where 'short' exchanges to 427 those services are used). 429 For example, an MX server could be assigned a new primary address on 430 a weekly basis, and old addresses expired monthly. Where MX server 431 IP addresses are detected and cached by spammers, such a defence may 432 prove useful to reduce spam volumes, especially as such IP lists may 433 also be passed between potential attackers for subsequent probing. 435 5.6. Application-Specific Addresses 437 By a similar reasoning, it may be possible to consider using 438 application-specific addresses for systems, such that a given 439 application may have exclusive use of an address, meaning that 440 disclosure of the address should not expose other applications or 441 services running on the same system. 443 6. Conclusions 445 Due to the much larger size of IPv6 subnets in comparison to IPv4 it 446 will become less feasible for network scanning methods to detect open 447 services for subsequent attacks. If administrators number their IPv6 448 subnets in 'random', non-predictable ways, attackers, whether they be 449 in the form of automated network scanners or dynamic worm 450 propagation, will need to use new methods to determine IPv6 host 451 addresses to target. Of course, if those systems are dual-stack, and 452 have open IPv4 services running, they will remain exposed to 453 traditional probes over IPv4 transport. 455 This document has discussed the considerations a site administrator 456 should bear in mind when considering IPv6 address planning issues and 457 configuring various service elements. It highlights relevant issues 458 and offers some informational guidance for administrators. While 459 some suggestions are currently more practical than others, it is up 460 to individual administrators to determine how much effort they wish 461 to invest in 'address hiding' schemes, given that this is only one 462 aspect of network security, and certainly not one to rely solely on. 463 But by implementing the basic principle of allocating 'random', non 464 predictable addresses, some level of obfuscation can be cheaply 465 deployed. 467 7. Security Considerations 469 There are no specific security considerations in this document 470 outside of the topic of discussion itself. 472 8. IANA Considerations 474 There are no IANA considerations for this document. 476 9. Acknowledgements 478 Thanks are due to people in the 6NET project (www.6net.org) for 479 discussion of this topic, including Pekka Savola, Christian Strauf 480 and Martin Dunmore, as well as other contributors from the IETF v6ops 481 and other mailing lists, including Tony Finch, David Malone, Bernie 482 Volz, Fred Baker, Andrew Sullivan and Alex Petrescu. 484 10. Informative References 486 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 487 Specification", RFC 2460, December 1998. 489 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 490 Autoconfiguration", RFC 2462, December 1998. 492 [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless 493 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 495 [4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 496 IPv4 Clouds", RFC 3056, February 2001. 498 [5] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 499 Multicast Addresses", RFC 3306, August 2002. 501 [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 502 Carney, "Dynamic Host Configuration Protocol for IPv6 503 (DHCPv6)", RFC 3315, July 2003. 505 [7] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 506 (RP) Address in an IPv6 Multicast Address", RFC 3956, 507 November 2004. 509 [8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 510 Neighbor Discovery (SEND)", RFC 3971, March 2005. 512 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", 513 RFC 3972, March 2005. 515 [10] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 516 Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, 517 October 2005. 519 [11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 520 Address Translations (NATs)", RFC 4380, February 2006. 522 [12] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 523 Co-existence Security Considerations 524 (draft-ietf-v6ops-security-overview-06)", October 2007. 526 [13] Bellovin, S. et al, "Worm Propagation Strategies in an IPv6 527 Internet (http://www.cs.columbia.edu/~smb/papers/v6worms.pdf)", 528 ;login:, February 2006. 530 Author's Address 532 Tim Chown 533 University of Southampton 534 Southampton, Hampshire SO17 1BJ 535 United Kingdom 537 Email: tjc@ecs.soton.ac.uk 539 Full Copyright Statement 541 Copyright (C) The IETF Trust (2007). 543 This document is subject to the rights, licenses and restrictions 544 contained in BCP 78, and except as set forth therein, the authors 545 retain all their rights. 547 This document and the information contained herein are provided on an 548 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 549 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 550 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 551 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 552 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 553 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 555 Intellectual Property 557 The IETF takes no position regarding the validity or scope of any 558 Intellectual Property Rights or other rights that might be claimed to 559 pertain to the implementation or use of the technology described in 560 this document or the extent to which any license under such rights 561 might or might not be available; nor does it represent that it has 562 made any independent effort to identify any such rights. Information 563 on the procedures with respect to rights in RFC documents can be 564 found in BCP 78 and BCP 79. 566 Copies of IPR disclosures made to the IETF Secretariat and any 567 assurances of licenses to be made available, or the result of an 568 attempt made to obtain a general license or permission for the use of 569 such proprietary rights by implementers or users of this 570 specification can be obtained from the IETF on-line IPR repository at 571 http://www.ietf.org/ipr. 573 The IETF invites any interested party to bring to its attention any 574 copyrights, patents or patent applications, or other proprietary 575 rights that may cover technology that may be required to implement 576 this standard. Please address the information to the IETF at 577 ietf-ipr@ietf.org. 579 Acknowledgment 581 Funding for the RFC Editor function is provided by the IETF 582 Administrative Support Activity (IASA).