idnits 2.17.1 draft-savola-v6ops-security-overview-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 -- 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 (February 2004) is 7369 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: 'PORTSCAN' is defined on line 480, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'TRANS' == Outdated reference: A later version (-05) exists of draft-dupont-ipv6-rfc3041harmful-04 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-6to4-security-01 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-v6onbydefault-00 == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: August 2004 5 February 2004 7 IPv6 Transition/Co-existence Security Considerations 9 draft-savola-v6ops-security-overview-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The transition/co-existance from IPv4 to IPv4/IPv6 causes one to 35 consider the security considerations of such a process. In this 36 memo, I try to give an overview of different aspects relating to IPv6 37 grouped in three categories: issues due to IPv6 protocol itself, 38 issues due to transition mechanisms, and issues due to IPv6 39 deployment. 41 Table of Contents 43 1. Introduction ............................................... 2 44 2. Issues Due to IPv6 Protocol ................................ 3 45 2.1. IPv6 Protocol-specific Issues .......................... 3 46 2.2. IPv4-mapped IPv6 Addresses ............................. 4 47 2.3. Increased End-to-End Transparency ...................... 4 48 3. Issues Due to Transition Mechanisms ........................ 5 49 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . 5 50 3.2. Automatic Tunneling and Relays ......................... 5 51 3.3. Tunneling May Break Security Assumptions ............... 6 52 4. Issues Due to IPv6 Deployment .............................. 7 53 4.1. IPv6 Service Piloting Done Insecurely .................. 7 54 4.2. Enabling IPv6 by Default Brings the Usability Down ..... 8 55 4.3. Operational Factors when Enabling IPv6 in the Network .. 8 56 5. Acknowledgements ........................................... 9 57 6. Security Considerations .................................... 9 58 7. References ................................................. 9 59 7.1. Normative .............................................. 9 60 7.2. Informative ............................................ 9 61 Author's Address ............................................... 11 62 A. IPv6 Probing/Mapping Considerations ........................ 11 63 B. IPv6 Privacy Considerations ................................ 12 64 B.1. Exposing MAC Addresses ................................. 12 65 B.2. Exposing Multiple Devices .............................. 12 66 Intellectual Property Statement ................................ 13 67 Full Copyright Statement ....................................... 13 69 1. Introduction 71 The transition/co-existance from IPv4 to IPv4/IPv6 causes one to 72 consider the security considerations of such a process. In this 73 memo, I try to give an overview of different aspects relating to IPv6 74 grouped in three categories: issues due to IPv6 protocol itself, 75 issues due to transition mechanisms, and issues due to IPv6 76 deployment. 78 A view of IPv6 transition has been presented in a separate document 79 [TRANS]; it is important to read it at least cursorily to understand 80 that the point is not about replacing IPv4 with IPv6 (in the short 81 term), but adding IPv6 alongside IPv4. 83 This document also (at the moment, may be removed in future versions) 84 describes two "non-issues", in Appedix A and B: considerations about 85 probing/mapping IPv6 addresses, and considerations wrt. privacy in 86 IPv6. 88 2. Issues Due to IPv6 Protocol 90 2.1. IPv6 Protocol-specific Issues 92 Some features of IPv6 are a bit different from IPv4, and may include 93 some potential problems specification-wise. Some examples include at 94 least: 96 o how hosts should interact with routing headers (they must act as 97 forwarders) [RHHOSTS] 99 o how routing headers may be too generic contructs to be useful for 100 e.g. MIPv6 purposes [RHHAOSEC] 102 o how home address option was previously specified (fixed now) 103 [RHHAOSEC] 105 o how ICMPv6 messages, in some cases, may be generated in response 106 to multicast packets (where in IPv4 they can't) [FW] 108 o how the privacy IPv6 addresses may not actually provide all that 109 much privacy (ie. the applicability is unclear) [3041HARM] 111 o how IPv6 has been specified wrt. middleboxes such as firewalls 112 (e.g. when new extension headers etc. are used) [FW] 114 On the other hand, there are several aspects where IPv4 security is 115 weak have been made stronger (at least by additional specifications), 116 at least: 118 o threats related to local links, comparable to different ARP 119 spoofing techniques; the ND threats have been documented 120 [SENDREQ] and fixes specified [SEND] 122 o Mobile IPv6 depends on the return routability checks for its 123 security; this seems relatively robust form of security; the 124 design has been described in [RRSEC] 126 Appendix A lists (typically bogus) considerations related to IPv6 127 network mapping or probing. Appendix B lists mainly unfound claims 128 about the lack of privacy in IPv6. 130 2.2. IPv4-mapped IPv6 Addresses 132 Overloaded functionality is always a double-edged sword: it may yield 133 some deployment benefits, but often also incurs the price which comes 134 with ambiguity. 136 One example of such is IPv4-mapped IPv6 addresses: a representation 137 of IPv4 address as an IPv6 address inside an operating system. Since 138 then, IPv4-mapped addresses have been extended to be used with a 139 transition mechanism [SIIT], on the wire. 141 Therefore, it becomes difficult to unambiguously discern whether an 142 IPv4 mapped address is really an IPv4 address represented in the IPv6 143 address format *or* an IPv6 address received from the wire (which may 144 be subject to address forgery, etc.). 146 In addition, special cases like these, while giving deployment 147 benefits in some arenas, require some amount of code complexity (e.g. 148 in the implementations of bind() system calls) which we might be 149 better off without [V4MAPPEDA] [V4MAPPEDW]. 151 At least, the mapped addresses should be disallowed on the wire. 152 Changing the application behavior would have significant impact on 153 application porting methods, though. 155 2.3. Increased End-to-End Transparency 157 With IPv6, increased end-to-end transparency in general can sometimes 158 be seen as a threat. Some seem to want limited end-to-end 159 capabilities, e.g. in the form of private, local addressing, even 160 when it is not necessary. 162 People have gotten used to the perceived, dubious security benefits 163 of NATs and perimeter firewalls, and the bidirectionality and 164 transparency that IPv6 can provide may seem undesirable at times. 166 This is a really important issue especially for most enterprise 167 network managers. 169 It is worth noting that IPv6 does not *require* end-to-end 170 connectivity. It merely provides end-to-end addressability; the 171 connectivity can still be controlled using firewalls (or other 172 mechanisms), and it is indeed wise to do so. 174 3. Issues Due to Transition Mechanisms 176 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues 178 The more complicated the IPv6 transition/co-existence becomes, the 179 more danger there is to introduce security issues in the mechanisms 180 (which may or may not be readily apparent). Therefore it would be 181 desirable to keep the mechanisms simple, in as small pieces as 182 possible. 184 One case where such security issues have been analyzed is [6TO4SEC]. 186 As tunneling has been proposed as a model for quite a bit more cases 187 than are currently being used, its security properties should be 188 analyzed in more detail. There are some generic dangers to 189 tunneling: 191 o it may be easier to avoid ingress filtering checks 193 o it is possible to attack the tunnel interface: several IPv6 194 security mechanisms depend on checking that Hop Limit equals 255 195 on receipt and that link-local addresses are used. Sending such 196 packets to the tunnel interface is much easier than gaining 197 access to a physical segment and sending them there. 199 o automatic tunneling mechanisms are typically particularly 200 dangerous as the other end-point is unspecified, and packets have 201 to be accepted and decapsulated from everywhere. Therefore, 202 special care should be observed when specifying automatic 203 tunneling techniques. 205 3.2. Automatic Tunneling and Relays 207 Two mechanisms have been (or are being) specified which use automatic 208 tunneling over IPv4 or UDP/IPv4 between the nodes enabling the same 209 mechanism for connectivity: 6to4 and Teredo (respectively). 211 The first obvious issue (as mentioned above) in such approaches is 212 that such nodes must allow decapsulation of traffic from anywhere in 213 the Internet. That kind of decapsulation function must be extremely 214 well secured as it's so wide open. 216 Even more difficult problem is how these mechanisms are able to 217 communicate with native IPv6 nodes or between the automatic tunneling 218 mechanisms: such connectivity requires the use of some kind of 219 "relays". These relays could be deployed e.g., in all native IPv6 220 nodes, native IPv6 sites, IPv6 ISPs, or just somewhere in the 221 Internet. This has some obvious trust and scaling issues. As 222 authentication of such a relay service is very difficult, and more so 223 in some of those deployment models, relays provide a means to for 224 address spoofing, (reflected) Denial-of-Service attacks, and other 225 threats. 227 Threats related to 6to4 are discussed in [6TO4SEC]. 229 3.3. Tunneling May Break Security Assumptions 231 NATs and firewalls have been deployed extensively in the IPv4 232 Internet, for the good or the bad. People who deploy them typically 233 have some security/operational requirements in mind (e.g. a desire to 234 block inbound connection attempts), whether misguided or not. 236 Tunneling can change that model. IPv6-over-IPv4 tunneling is 237 typically explicitly allowed or disallowed implicitly. Tunneling 238 IPv6 over IPv4 with UDP, however, is often an entirely different 239 thing: as UDP must usually be allowed through, at least in part and 240 in a possibly stateful manner, one can "punch holes" in NAT's and 241 firewalls using UDP. Actually, the mechanisms have been explicitly 242 designed to traverse both NATs and firewalls in a similar fashion. 244 One could say that tunneling is especially questionable in home/SOHO 245 environments where the level of network administration is not that 246 high; in these environments the hosts may not be as managed as in 247 others (e.g., network services might be enabled unnecessarily), 248 leading to possible security break-ins or other vulnerabilities. 250 Holes can be punched both intentionally and unintentionally. In case 251 it is a willing choice from the administrator/user, this is less of a 252 problem (but e.g., enterprises might want to block IPv6 tunneling 253 explicitly if some employees would do something like this willingly 254 on their own). On the other hand, if a hole is punched 255 transparently, without people understanding the consequences, it will 256 very probably result in a serious threat sooner or later. 258 When deploying tunneling solutions, especially tunneling solutions 259 which are automatic and/or can be enabled easily by users not 260 understanding the consequences, care should be taken not to 261 compromise the security assumptions held by the users. 263 For example, NAT traversal should not be performed by default unless 264 there is a firewall producing a similar by-default security policy as 265 IPv4 NAT provides. Protocol-41 tunneling is less of a problem, as it 266 is easier to block if necessary; however, if the host is protected in 267 IPv4, the IPv6 side should be protected as well. 269 As has been shown in Appendix A, it is relatively easy to find out 270 IPv6 address of an IPv4, so one should never rely on "security by 271 obscurity" i.e., relying that nobody is able to guess or know the 272 IPv6 address of the host. 274 4. Issues Due to IPv6 Deployment 276 4.1. IPv6 Service Piloting Done Insecurely 278 In many cases, IPv6 service piloting is done in a manner which is 279 considered to be less secure than as one would do with IPv4. For 280 example, hosts and routers might not be protected by IPv6 firewalls, 281 even if in IPv4 firewalls are being used. 283 The other possible alternative, in some places, is that no service 284 piloting is done at all because IPv6 firewalls may not be widely used 285 -- and IPv6 deployment suffers (of course, this is also one of the 286 nice excuses for not doing IPv6). 288 This problem may be partially due to a slow speed of IPv6-capable 289 firewall development and deployment. However, it is also a problem 290 with a lack of information: actually, there are quite a few IPv6 291 packet filters and firewalls already, which could be used for 292 sufficient access controls, but network administrators may not be 293 aware of them yet. 295 However, there appears to be a real lack in two areas: "personal 296 firewalls" and enterprise firewalls; the same devices that support 297 and are used for IPv4 today are often expected to also become 298 IPv6-capable -- even though this is not really required. That is, 299 IPv4 access could be filtered by one firewall, and when IPv6 access 300 is added, it could be protected by another firewall; they don't have 301 to be the same, and even their models don't have to be the same. 303 Another, smaller factor may be that due to a few decisions on how 304 IPv6 was built, it's more difficult for firewalls to be implemented 305 and work under all the cases (e.g. when new extension headers etc. 306 are used) [FW]: it's a bit more difficult for intermediate nodes to 307 process the IPv6 header chains than IPv4 packets. 309 A similar argument, stated to hinder IPv6 deployment, has been the 310 lack of Intrusion Detection Systems (IDS). It's not clear whether 311 this is more of an excuse than a real reason. 313 4.2. Enabling IPv6 by Default Brings the Usability Down 315 A practical disadvantage of enabling IPv6 as of this writing is that 316 it typically brings the observed service level down a bit; that is, 317 the usability suffers. 319 This is due to at least three reasons: 321 o global IPv6 routing is still rather unstable, leading to packet 322 loss, lower throughput, and higher delay [6BMESS] 324 o some applications can not properly handle both IPv4 and IPv6 or 325 may have problems handling all the fallbacks and failure modes 326 (and in some cases, e.g. if the TCP timeout kicks in, this may be 327 very difficult) 329 o some DNS server implementations have flaws that severely affect 330 DNS queries for IPv6 addresses [DNSA4] 332 Actually, some would be 100% ready to release IPv6 services (e.g. 333 web) today, but that would mean trouble for many of their dual- 334 stacked customers or users all over the world so they don't: these 335 are often published under a separate domain or subdomain, and are 336 practically not used that often. 338 These issues are also described at some length in [ONBYDEF]. 340 4.3. Operational Factors when Enabling IPv6 in the Network 342 You have to be careful when enabling IPv6 in the network gear for 343 multiple reasons: 345 IPv6-enabled router software may be unstable(r) yet; either IPv6 is 346 unstable, or the software you have to run to be able to run IPv6 is 347 different (from non-IPv6 parts) from the one you would run otherwise, 348 making the software in practice more unstable -- and raising the bar 349 for IPv6 adoption. 351 IPv6 processing may not happen at (near) line speed (or in the same 352 level as IPv4). A high amount of IPv6 traffic (even legitimate, e.g. 353 NNTP) could easily overload the software-based IPv6 processing and 354 cause harm also to IPv4 processing, affecting availability. That is, 355 if people don't feel confident enough in the IPv6 support, they will 356 be hesitant to enable it in their "production" networks. 358 Sometimes required features may be missing from the vendors' software 359 releases; an example is a software enabling IPv6 telnet/SSH access, 360 but having no ability to turn it off or limit access to it! 361 Sometimes the default IPv6 configuration is insecure. For example, 362 in one vendor, if you've restricted IPv4 telnet to only a few hosts 363 in the configuration, you need to be aware that IPv6 telnet will be 364 automatically enabled, that the configuration commands used 365 previously do not block IPv6 telnet, IPv6 telnet is open to the world 366 by default, and that you have to use a separate command to also lock 367 down the IPv6 telnet access. 369 Many operator networks have to run interior routing protocols for 370 both IPv4 and IPv6. It's possible to run the both in one routing 371 protocol, or have two separate routing protocols; either approach has 372 its tradeoffs. If multiple routing protocols are used, one should 373 note that this causes double the number of processing when links flap 374 or recalculation is otherwise needed -- which might more easily 375 overload the routers' CPU, causing slightly slower convergence time. 377 5. Acknowledgements 379 Alain Durand, Alain Baudot, Luc Beloeil, and Andras Kis-Szabo 380 provided feedback to improve this memo. Michael Wittsend and Michael 381 Cole discussed issues relating to probing/mapping and privacy. 383 6. Security Considerations 385 This memo tries to give an overview of security considerations of the 386 different aspects of IPv6. 388 7. References 390 7.1. Normative 392 [TRANS] Savola, P., "A View on IPv6 Transition Architecture", 393 draft-savola-v6ops-transarch-03.txt, Jan 2004. 395 7.2. Informative 397 [3041HARM] Dupont, F., Savola, P., "RFC 3041 Considered Harmful", 398 draft-dupont-ipv6-rfc3041harmful-04.txt, Feb 2004. 400 [6BMESS] Savola, P., "Moving from 6bone to IPv6 Internet", 401 draft-savola-v6ops-6bone-mess-01.txt, Nov 2002. 403 [6TO4SEC] Savola, P., Patel, C., "Security Considerations for 404 6to4", draft-ietf-v6ops-6to4-security-01.txt, Feb 2004. 406 [DNSA4] Morishita., Y., Jinmei, T., "Common Misbehavior against 407 DNS Queries for IPv6 Addresses", draft-morishita-dnsop- 408 misbehavior-against-aaaa-00.txt, Jun 2003. 410 [FNAT] Bellovin, S., "A Technique for Counting NATted Hosts", 411 Second Internet Measurement Workshop, 412 http://www.research.att.com/~smb/papers/fnat.pdf, 413 Nov 2003. 415 [FW] Savola, P. "Firewalling Considerations for IPv6", 416 draft-savola-v6ops-firewalling-02.txt, Oct 2003. 418 [MAPPING] Schild, C., Strauf, C., "Guide to Mapping IPv4 to IPv6 419 Subnets", draft-schild-v6ops-guide-v4mapping-00.txt, 420 Dec 2003. 422 [ONBYDEF] Roy, S., et al., "Dual Stack IPv6 on by Default", 423 draft-ietf-v6ops-v6onbydefault-00.txt, Jun 2003. 425 [PORTSCAN] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 426 draft-chown-v6ops-port-scanning-implications-00.txt, 427 Oct 2003. 429 [RHHAOSEC] Savola, P. "Security of IPv6 Routing Header and 430 Home Address Options", 431 draft-savola-ipv6-rh-ha-security-03.txt, Dec 2002. 433 [RHHOSTS] Savola, P. "Note about Routing Header Processing on IPv6 434 Hosts", draft-savola-ipv6-rh-hosts-00.txt, Feb 2002. 436 [RRSEC] Nikander, P, et al., "Mobile IP version 6 Route 437 Optimization Security Design Background", 438 draft-nikander-mobileip-v6-ro-sec-02.txt, Dec 2003. 440 [SEND] Arkko, J., et al., "SEcure Neighbor Discovery (SEND)", 441 draft-ietf-send-ndopt-03.txt, Jan 2004. 443 [SENDREQ] Nikander, P., et al., "IPv6 Neighbor Discovery trust 444 models and threats", draft-ietf-send-psreq-04.txt, 445 Oct 2003. 447 [SIIT] Nordmark, E., "Stateless IP/ICMP Translation Algorithm", 448 RFC276, February 2000. 450 [V4MAPPEDA] Metz, C., Hagino, J., "IPv4-Mapped address API considered 451 harmful", draft-cmetz-v6ops-v4mapped-api-harmful-01.txt, 452 Oct 2003. 454 [V4MAPPEDW] Metz, C., Hagino, J., "IPv4-Mapped Addresses on the Wire 455 Considered Harmful", 456 draft-itojun-v6ops-v4mapped-harmful-02.txt, Oct 2003. 458 Author's Address 460 Pekka Savola 461 CSC/FUNET 462 Espoo, Finland 463 EMail: psavola@funet.fi 465 A. IPv6 Probing/Mapping Considerations 467 Some want the IPv6 numbering topology (either at network or node 468 level) [MAPPING] match IPv4 as exactly as possible, the others see 469 this as a security threat because IPv6 could have different security 470 properties than IPv4. 472 That is, if an attacker knows the IPv4 address of the node, he might 473 want to try to probe the corresponding IPv6 address, based on the 474 assumption that the security defenses might be lower. This might be 475 the case particularly for nodes which are behind a NAT in IPv4, but 476 globally addressable in IPv6. Naturally, this is not a concern if 477 the similar security policies are in place. 479 On the other hand, brute-force scanning or probing is unfeasible 480 [PORTSCAN]. 482 For example, automatic tunneling mechanisms use rather deterministic 483 methods for generating IPv6 addresses, so probing/port-scanning an 484 IPv6 node is simplified. The IPv4 address is embedded at least in 485 6to4, Teredo and ISATAP address. Further than that, it's possible 486 (in the case of 6to4 in particular) to learn the address behind the 487 prefix; for example, Microsoft 6to4 implementation uses the address 488 2002:V4ADDR::V4ADDR while Linux and BSD implementations default to 489 2002:V4ADDR::1. This could also be used as one way to identify an 490 implementation. 492 One proposal has been to randomize the addresses or Subnet identifier 493 in the address of the 6to4 router. This doesn't really help, as the 494 6to4 router (whether a host or a router) will return an ICMPv6 Hop 495 Limit Exceeded message, revealing the IP address. Hosts behind the 496 6to4 router can use methods such as RFC 3041 addresses to conceal 497 themselves, though. 499 To conclude, it seems that with an IPv4 address, the respective IPv6 500 address, when automatic tunneling mechanism is being used, could 501 possibly be guessed with relative ease. This has significant 502 implications if the IPv6 security policy isn't the same as IPv4. 504 B. IPv6 Privacy Considerations 506 It has been claimed that IPv6 harms the privacy of the user, either 507 by exposing the MAC address, or by exposing the number of nodes 508 connected to a site. 510 B.1. Exposing MAC Addresses 512 The MAC address, which with stateless address autoconfiguration, 513 results in an EUI64, exposes the model of network card. The concern 514 has been that a user might not want to expose the details of the 515 system to outsiders, e.g., in the fear of a resulting burglary (e.g., 516 if a crook identifies expensive equipment from the MAC addresses). 518 In most cases, this seems completely unfounded. First, such an 519 address must be learned somehow -- this is a non-trivial process; the 520 addresses are visible e.g., in web site access logs, but the chances 521 that a random web site owner is collecting this kind of information 522 (or whether it would be of any use) are quite slim. Being able to 523 eavesdrop the traffic to learn such addresses (e.g., by the 524 compromise of DSL or Cable modem physical media) seems also quite 525 far-fetched. Further, using RFC 3041 addresses for such purposes is 526 straightforward if worried about the risk. Second, the burglar would 527 have to be able to map the IP address to the physical location; this 528 is typically only available in the private customer database of the 529 ISP. 531 B.2. Exposing Multiple Devices 533 Another presented concern is whether the user wants to show off as 534 having a lot of computers or other devices at a network; NAT "hides" 535 everything behind an address, but is not perfect either [FNAT]. 537 One practical reason why some may find this desirable is being able 538 to thwart certain ISPs' business models, where one should pay extra 539 for additional computers (and not the connectivity as a whole). 541 Similar feasibility issues as described above apply. To a degree, 542 the counting avoidance could be performed by the sufficiently 543 frequent re-use of RFC 3041 addresses -- that is, if during a short 544 period, dozens of generated addresses seem to be in use, it's 545 difficult to estimate whether they are generated by just one host or 546 multiple hosts. 548 Intellectual Property Statement 550 The IETF takes no position regarding the validity or scope of any 551 intellectual property or other rights that might be claimed to 552 pertain to the implementation or use of the technology described in 553 this document or the extent to which any license under such rights 554 might or might not be available; neither does it represent that it 555 has made any effort to identify any such rights. Information on the 556 IETF's procedures with respect to rights in standards-track and 557 standards-related documentation can be found in BCP-11. Copies of 558 claims of rights made available for publication and any assurances of 559 licenses to be made available, or the result of an attempt made to 560 obtain a general license or permission for the use of such 561 proprietary rights by implementors or users of this specification can 562 be obtained from the IETF Secretariat. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights which may cover technology that may be required to practice 567 this standard. Please address the information to the IETF Executive 568 Director. 570 Full Copyright Statement 572 Copyright (C) The Internet Society (2003). All Rights Reserved. 574 This document and translations of it may be copied and furnished to 575 others, and derivative works that comment on or otherwise explain it 576 or assist in its implementation may be prepared, copied, published 577 and distributed, in whole or in part, without restriction of any 578 kind, provided that the above copyright notice and this paragraph are 579 included on all such copies and derivative works. However, this 580 document itself may not be modified in any way, such as by removing 581 the copyright notice or references to the Internet Society or other 582 Internet organizations, except as needed for the purpose of 583 developing Internet standards in which case the procedures for 584 copyrights defined in the Internet Standards process must be 585 followed, or as required to translate it into languages other than 586 English. 588 The limited permissions granted above are perpetual and will not be 589 revoked by the Internet Society or its successors or assignees. 591 This document and the information contained herein is provided on an 592 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 593 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 594 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 595 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 596 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 Acknowledgement 600 Funding for the RFC Editor function is currently provided by the 601 Internet Society.