idnits 2.17.00 (12 Aug 2021) /tmp/idnits28055/draft-ietf-v6ops-icmpv6-filtering-recs-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1601. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (July 9, 2006) is 5794 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ipngwg-icmp-name-lookups' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-tcpm-icmp-attacks' is defined on line 912, but no explicit reference was found in the text == Outdated reference: draft-ietf-ipngwg-icmp-name-lookups has been published as RFC 4620 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipngwg-icmp-name-lookups (ref. 'I-D.ietf-ipngwg-icmp-name-lookups') == Outdated reference: draft-ietf-ipngwg-icmp-v3 has been published as RFC 4443 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipngwg-icmp-v3' ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4065 == Outdated reference: draft-ietf-v6ops-scanning-implications has been published as RFC 5157 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations E. Davies 3 Internet-Draft Consultant 4 Expires: January 10, 2007 J. Mohacsi 5 NIIF/HUNGARNET 6 July 9, 2006 8 Recommendations for Filtering ICMPv6 Messages in Firewalls 9 draft-ietf-v6ops-icmpv6-filtering-recs-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 10, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 In networks supporting IPv6 the Internet Control Message Protocol 43 version 6 (ICMPv6) plays a fundamental role with a large number of 44 functions, and a correspondingly large number of message types and 45 options. ICMPv6 is essential to the functioning of IPv6 but there 46 are a number of security risks associated with uncontrolled 47 forwarding of ICMPv6 messages. Filtering strategies designed for the 48 corresponding protocol, ICMP, in IPv4 networks are not directly 49 applicable, because these strategies are intended to accommodate a 50 useful auxiliary protocol that may not be required for correct 51 functioning. 53 This document provides some recommendations for ICMPv6 firewall 54 filter configuration that will allow propagation of ICMPv6 messages 55 that are needed to maintain the functioning of the network but drop 56 messages which are potential security risks. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6 62 2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6 63 2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6 64 2.3. Network Topology and Address Scopes . . . . . . . . . . . 7 65 2.4. Role in Establishing Communication . . . . . . . . . . . . 7 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 9 68 3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 9 70 3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 9 71 3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10 72 4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10 73 4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11 74 4.2. Interaction of Link Local Messages with 75 Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12 76 4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 12 77 4.3.1. Traffic that Must Not be Dropped . . . . . . . . . . . 13 78 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 13 79 4.3.3. Traffic that will be Dropped Anyway - No Special 80 Attention Needed . . . . . . . . . . . . . . . . . . . 13 81 4.3.4. Traffic for which a Dropping Policy Should be 82 Defined . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.3.5. Traffic which Should be Dropped Unless a Good Case 84 can be Made . . . . . . . . . . . . . . . . . . . . . 15 85 4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 16 86 4.4.1. Traffic that Must Not be Dropped . . . . . . . . . . . 16 87 4.4.2. Traffic that Normally Should Not be Dropped . . . . . 17 88 4.4.3. Traffic that will be Dropped Anyway - No Special 89 Attention Needed . . . . . . . . . . . . . . . . . . . 17 90 4.4.4. Traffic for which a Dropping Policy Should be 91 Defined . . . . . . . . . . . . . . . . . . . . . . . 17 92 4.4.5. Traffic which Should be Dropped Unless a Good Case 93 can be Made . . . . . . . . . . . . . . . . . . . . . 18 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 95 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 98 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 99 Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 21 100 A.1. Destination Unreachable Error Message . . . . . . . . . . 21 101 A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 21 102 A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 22 103 A.4. Parameter Problem Error Message . . . . . . . . . . . . . 22 104 A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 23 105 A.6. Neighbor Solicitation and Neighbor Advertisement 106 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 A.7. Router Solicitation and Router Advertisement Messages . . 24 108 A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 24 109 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 24 110 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 24 111 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 25 112 A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 25 113 A.13. Node Information Query and Reply . . . . . . . . . . . . . 25 114 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 25 115 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 26 116 Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 27 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 118 Intellectual Property and Copyright Statements . . . . . . . . . . 36 120 1. Introduction 122 When a network supports IPv6 [RFC2460], the Internet Control Message 123 Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3] 124 plays a fundamental role including being an essential component in 125 establishing communications both at the interface level and for 126 sessions to remote nodes. This means that overly aggressive 127 filtering of ICMPv6 may have a detrimental effect on the 128 establishment of IPv6 communications. On the other hand, allowing 129 indiscriminate passage of all ICMPv6 messages can be a major security 130 risk. This document recommends a set of rules which seek to balance 131 effective IPv6 communication against the needs of site security. 133 Readers familiar with ICMPv6 can skip to the recommended filtering 134 rules in Section 4 and an example configuration script for Linux 135 netfilter in Appendix B. 137 ICMPv6 has a large number of functions defined in a number of sub- 138 protocols, and there are a correspondingly large number of messages 139 and options within these messages. The functions currently defined 140 fall into a number of categories: 141 Returning Error Messages 142 * Returning error messages to the source if a packet could not 143 be delivered. Four different error messages, each with a 144 number of sub-types are specified in [RFC4443]. 145 Connection Checking 146 * Simple monitoring of connectivity through echo requests and 147 responses used by the ping and traceroute utilities. The 148 Echo Request and Echo Response messages are specified in 149 [RFC4443]. 150 Discovery Functions 151 * Finding neighbors (both routers and hosts) connected to the 152 same link and determining their IP and link layer addresses. 153 These messages are also used to check the uniqueness of any 154 addresses that an interface proposes to use (Duplicate 155 Address Detection - DAD)). Four messages - Neighbor 156 Solicitation (NS), Neighbor Advertisement (NA), Router 157 Solicitation (RS) and Router Advertisement (RA) - are 158 specified in [RFC2461]. 159 * Ensuring that neighbors remain reachable using the same IP 160 and link layer addresses after initial discovery (Neighbor 161 Unreachability Discovery - NUD) and notifying neighbors of 162 changes to link layer addresses. Uses NS and NA [RFC2461]. 163 * Finding routers and determining how to obtain IP addresses 164 to join the subnets supported by the routers. Uses RS and 165 RA [RFC2461].[[anchor2: [RFC Editor: Please update 166 references to RFC2461 when the new version of RFC2461 is 167 published.] --Authors]] 169 * If stateless auto-configuration of hosts is enabled, 170 communicating prefixes and other configuration information 171 (including the link MTU and suggested hop limit default) 172 from routers to hosts. Uses RS and RA [RFC2462]. [[anchor3: 173 [RFC Editor: Please update references to RFC2462 when the 174 new version of RFC2462 is published.] --Authors]] 175 * Using SEcure Neighbor Discovery (SEND) to authenticate a 176 router attached to a link, the Certificate Path Solicitation 177 and Advertisement messages specified in [RFC3971] are used 178 by hosts to retrieve the trust chain between a trust anchor 179 and the router certificate from the router. 180 * Determining the Maximum Transmission Unit (MTU) along a 181 path. The Packet Too Big error message is essential to this 182 function [RFC1981]. 183 * Providing a means to discover the IPv6 addresses associated 184 with the link layer address of an interface (the inverse of 185 Neighbor Discovery, where the link layer address is 186 discovered given an IPv6 address). Two messages, Inverse 187 Neighbor Discovery Solicitation and Advertisement messages 188 are specified in [RFC3122]. 189 * Communicating which multicast groups have listeners on a 190 link to the multicast capable routers connected to the link. 191 Uses messages Multicast Listener Query, Multicast Listener 192 Report (two versions) and Multicast Listener Done (version 1 193 only) as specified in Multicast Listener Discovery MLDv1 194 [RFC2710] and MLDv2[RFC3810]. 195 * Discovering multicast routers attached to the local link. 196 Uses messages Multicast Router Advertisement, Multicast 197 Router Solicitation and Multicast Router Termination as 198 specified in Multicast Router Discovery [RFC4286]. 199 Reconfiguration Functions 200 * Redirecting packets to a more appropriate router on the 201 local link for the destination address or pointing out that 202 a destination is actually on the local link even if it is 203 not obvious from the IP address (where a link supports 204 multiple subnets). The Redirect message is specified in 205 [RFC2461]. 206 * Supporting renumbering of networks by allowing the prefixes 207 advertised by routers to be altered. Uses NS, NA, RS and RA 208 together with the Router Renumbering message specified in 209 [RFC2894]. 210 Mobile IPv6 Support 211 * Providing support for some aspects of Mobile IPv6 especially 212 dealing with the IPv6 Mobile Home Agent functionality 213 provided in routers and needed to support a Mobile node 214 homed on the link. The Home Agent Address Discovery Request 215 and Reply; and Mobile Prefix Solicitation and Advertisement 216 messages are specified in [RFC3775] 218 Experimental Extensions 219 * An experimental extension to ICMPv6 specifies the ICMP Node 220 Information Query and Response messages which can be used to 221 retrieve some basic information about nodes [I-D.ietf- 222 ipngwg-icmp-name-lookups]. 223 * The SEAmless IP MOBility (seamoby) working group specified a 224 pair of experimental protocols which use an ICMPv6 message 225 specified in [RFC4065] to help in locating an access router 226 and moving the attachment point of a mobile node from one 227 access router to another. 229 Many of these messages should only be used in a link-local context 230 rather than end-to-end, and filters need to be concerned with the 231 type of addresses in ICMPv6 packets as well as the specific source 232 and destination addresses. 234 Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be 235 treated as an auxiliary function with packets that can be dropped in 236 most cases without damaging the functionality of the network. This 237 means that firewall filters for ICMPv6 have to be more carefully 238 configured than was the case for ICMP, where typically a small set of 239 blanket rules could be applied. 241 2. Classifying ICMPv6 Messages 243 2.1. Error and Informational ICMPv6 Messages 245 ICMPv6 messages contain an eight bit Type field interpreted as an 246 integer between 0 and 255. Messages with Type values less than or 247 equal to 127 are Error Messages. The remainder are Informational 248 Messages. In general terms, Error Messages with well-known 249 (standardized) Type values would normally be expected to be allowed 250 to be sent to or pass through firewalls, and may be essential to the 251 establishment of communications (see Section 2.4) whereas 252 Informational Messages will generally be the subject of policy rules, 253 and those passing through firewalls can, in many but by no means all 254 cases, be dropped without damaging IPv6 communications. 256 2.2. Addressing of ICMPv6 258 ICMPv6 messages are sent using various kinds of source and 259 destination address types. The source address is usually a unicast 260 address, but during address autoconfiguration message exchanges, the 261 unspecified address :: is also used as a source address [RFC2462]. 263 Multicast Listener Discovery (MLD) Report and Done messages are sent 264 with a link-local address as the IPv6 source address, if a valid 265 address is available on the interface. If a valid link-local address 266 is not available (e.g., one has not been configured), the message is 267 sent with the unspecified address (::) as the IPv6 source address. 268 Subsequently the node will generate new MLD Report messages with 269 proper link-local source address once it has been configured 270 [RFC3590]. 272 The destination address can be either a well-known multicast address, 273 a generated multicast address such as the solicited-node multicast 274 address, an anycast address or a unicast address. While many ICMPv6 275 messages use multicast addresses most of the time, some also use 276 unicast addresses. For instance, the Router Advertisement messages 277 are sent to the all-nodes multicast address when unsolicited, but can 278 also be sent to a unicast address in response to a specific Router 279 Solicitation. 281 2.3. Network Topology and Address Scopes 283 ICMPv6 messages can be classified according to whether they are meant 284 for end-to-end communications or communications within a link. There 285 are also messages that we can classify as 'any-to-end', which can be 286 sent from any point within a path back to the source; typically these 287 are used to announce an error in processing the original packet. For 288 instance, the address resolution messages are solely for local 289 communications [RFC2461], whereas the Destination Unreachable 290 messages are any-to-end in nature. Generally end-to-end and any-to- 291 end messages might be expected to pass through firewalls depending on 292 policies but local communications must not. 294 Local communications will use link-local addresses in many cases but 295 may also use global unicast addresses when configuring global 296 addresses, for example. Also some ICMPv6 messages used in local 297 communications may contravene the usual rules requiring compatible 298 scopes for source and destination addresses. 300 2.4. Role in Establishing Communication 302 Many ICMPv6 messages have a role in establishing communications to 303 and from the firewall and such messages have to be accepted by 304 firewalls for local delivery. Generally a firewall will also be 305 acting as a router so that all the messages that might be used in 306 configuring a router interface need to be accepted and generated. 307 This type of communication establishment messages should not be 308 passed through a firewall as they are normally intended for use 309 within a link. 311 On the other hand, most ICMPv6 error messages traveling end-to-end or 312 any-to-end are essential to the establishment of communications. 314 These messages must be passed through firewalls and might also be 315 sent to and from firewalls to assist with establishment of 316 communications. For example the Packet Too Big error message is 317 needed to establish the MTU along a path. 319 The remaining ICMPv6 messages which are not associated with 320 communication establishment will normally be legitimately attempting 321 to pass through a firewall from inside to out or vice versa, but in 322 most cases decisions as to whether to allow them to pass or not can 323 be made on the basis of local policy without interfering with the 324 establishment of IPv6 communications. 326 The filtering rules for the various message roles will generally be 327 different. 329 3. Security Considerations 331 This memo recommends filtering configurations for firewalls designed 332 to minimize the security vulnerabilities that can arise in using the 333 many different sub-protocols of ICMPv6 in support of IPv6 334 communication. 336 A major concern is that it is generally not possible to use IPsec or 337 other means to authenticate the sender and validate the contents of 338 many ICMPv6 messages. To a large extent this is because a site can 339 legitimately expect to receive certain error and other messages from 340 almost any location in the wider Internet, and these messages may 341 occur as a result of the first message sent to a destination. 342 Establishing security associations with all possible sources of 343 ICMPv6 messages is therefore impossible. 345 The inability to establish security associations to protect some 346 messages that are needed to establish communications means that 347 alternative means have to used to reduce the vulnerability of sites 348 to ICMPv6 based attacks. The most common way of doing this is to 349 establish strict filtering policies in site firewalls to limit the 350 unauthenticated ICMPv6 messages that can pass between the site and 351 the wider Internet. This makes control of ICMPv6 filtering a 352 delicate balance between protecting the site by dropping some of the 353 ICMPv6 traffic passing through the firewall and allowing enough of 354 the traffic through to make sure that efficient communication can be 355 established. 357 SEND [RFC3971] has been specified as a means to improve the security 358 of local ICMPv6 communications. SEND sidesteps security association 359 bootstrapping problems that would result if IPsec was used. SEND 360 affects only link local messages and does not limit the filtering 361 which firewalls can apply and its role in security is therefore not 362 discussed further in this document. 364 Firewalls will normally be used to monitor ICMPv6 to control the 365 following security concerns: 367 3.1. Denial of Service Attacks 369 ICMPv6 can be used to cause a Denial of Service(DoS) in a number of 370 ways, including simply sending excessive numbers of ICMPv6 packets to 371 destinations in the site and sending error messages which disrupt 372 established communications by causing sessions to be dropped. Also 373 if spurious communication establishment messages can be infiltrated 374 on to a link it might be possible to invalidate legitimate addresses 375 or disable interfaces. 377 3.2. Probing 379 A major security consideration is preventing attackers probing the 380 site to determine the topology and identify hosts that might be 381 vulnerable to attack. Carefully crafted but, often, malformed 382 messages can be used to provoke ICMPv6 responses from hosts thereby 383 informing attackers of potential targets for future attacks. However 384 the very large address space of IPv6 makes probing a less effective 385 weapon as compared with IPv4 provided that addresses are not 386 allocated in an easily guessable fashion. This subject is explored 387 in more depth in [I-D.ietf-v6ops-scanning-implications]. 389 3.3. Redirection Attacks 391 A redirection attack could be used by a malicious sender to perform 392 man-in-the-middle attacks or divert packets either to a malicious 393 monitor or to cause DoS by blackholing the packets. These attacks 394 would normally have to be carried out locally on a link using the 395 Redirect message. Administrators need to decide if the improvement 396 in efficiency from using Redirect messages is worth the risk of 397 malicious use. Factors to consider include the physical security of 398 the link and the complexity of addressing on the link. For example, 399 on a wireless link, redirection would be a serious hazard due to the 400 lack of physical security. On the other hand, with a wired link in a 401 secure building with complex addressing and redundant routers, the 402 efficiency gains might well outweigh the small risk of a rogue node 403 being connected. 405 3.4. Renumbering Attacks 407 Spurious Renumbering messages can lead to the disruption of a site. 408 Although Renumbering messages are required to be authenticated with 409 IPsec, so that it is difficult to carry out such attacks in practice, 410 they should not be allowed through a firewall. 412 3.5. Problems Resulting from ICMPv6 Transparency 414 Because some ICMPv6 error packets need to be passed through a 415 firewall in both directions, malicious users can potentially use 416 these messages to communicate between inside and outside, bypassing 417 administrative inspection. For example it might be possible to carry 418 out a covert conversation through the payload of ICMPv6 error 419 messages or tunnel inappropriate encapsulated IP packets in ICMPv6 420 error messages. This problem can be alleviated by filtering ICMPv6 421 errors using a deep packet inspection mechanism to ensure that the 422 packet carried as a payload is associated with legitimate traffic to 423 or from the protected network. 425 4. Filtering Recommendations 427 When designing firewall filtering rules for ICMPv6, the rules can be 428 divided into two classes: 429 o Rules for ICMPv6 traffic transiting the firewall 430 o Rules for ICMPv6 directed to interfaces on the firewall 432 This section suggests some common considerations which should be 433 borne in mind when designing filtering rules and then categorizes the 434 rules for each class. The categories are: 435 o Messages that must not be dropped: usually because establishment 436 of communications will be prevented or severely impacted. 437 o Messages that should not be dropped: administrators need to have a 438 very good reason for dropping this category 439 o Messages that may be dropped in firewall/routers but it is not 440 essential because they would normally be dropped for other reasons 441 (e.g., because they would be using link-local addresses) or the 442 protocol specification would cause them to be rejected if they had 443 passed through a router. Special considerations apply to transit 444 traffic if the firewall is not a router as discussed in 445 Section 4.2. 446 o Messages that administrators may or may not want to drop depending 447 on local policy. 448 o Messages that administrators should consider dropping (e.g., ICMP 449 node information name lookup queries) 451 More detailed analysis of each of the message types can be found in 452 Appendix A. 454 4.1. Common Considerations 456 Depending on the classification of the message to be filtered (see 457 Section 2), ICMPv6 messages should be filtered based on the ICMPv6 458 type of the message and the type (unicast, multicast, etc.) and scope 459 (link-local, global unicast, etc) of source and destination 460 addresses. In some cases it may be desirable to filter on the Code 461 field of ICMPv6 error messages. 463 Messages that are authenticated by means of an IPsec AH or ESP header 464 may be subject to less strict policies than unauthenticated messages. 465 In the remainder of this section, we are generally considering what 466 should be configured for unauthenticated messages. In many cases it 467 is not realistic to expect more than a tiny fraction of the messages 468 to be authenticated. 470 Where messages are not essential to the establishment of 471 communications, local policy can be used to determine whether a 472 message should be allowed or dropped. 474 Depending on the capabilities of the firewall being configured, it 475 may be possible for the firewall to maintain state about packets that 476 may result in error messages being returned or about ICMPv6 packets 477 (e.g., Echo Requests) that are expected to receive a specific 478 response. This state may allow the firewall to perform more precise 479 checks based on this state, and to apply limits on the number of 480 ICMPv6 packets accepted incoming or outgoing as a result of a packet 481 traveling in the opposite direction. The capabilities of firewalls 482 to perform such stateful packet inspection vary from model to model, 483 and it is not assumed that firewalls are uniformly capable in this 484 respect. 486 Firewalls which are able to perform deep packet inspection may be 487 able to check the header fields in the start of the errored packet 488 which is carried by ICMPv6 error messages. If the embedded packet 489 has a source address which does not match the destination of the 490 error message the packet can be dropped. This provides a partial 491 defense against some possible attacks on TCP that use spoofed ICMPv6 492 error messages, but the checks can also be carried out at the 493 destination. For further information on these attacks see [I-D.gont- 494 tcpm-icmp-attacks]. 496 In general, the scopes of source and destination addresses of ICMPv6 497 messages should be matched, and packets with mismatched addresses 498 should be dropped if they attempt to transit a router. However some 499 of the address configuration messages carried locally on a link may 500 legitimately have mismatched addresses. Node implementations must 501 accept these messages delivered locally on a link and administrators 502 should be aware that they can exist. 504 4.2. Interaction of Link Local Messages with Firewall/Routers and 505 Firewall/Bridges 507 Firewalls can be implemented both as IP routers (firewall/routers) 508 and as link layer bridges (e.g., Ethernet bridges) that are 509 transparent to the IP layer although they will actually be inspecting 510 the IP packets as they pass through (firewall/bridges). 512 Many of the messages used for establishment of communications on the 513 local link will be sent with link-local addresses for at least one of 514 their source and destination. Routers conforming to the IPv6 515 standards will not forward these packets; there is no need to 516 configure additional rules to prevent these packets traversing a 517 firewall/router, although administrators may wish to configure rules 518 that would drop these packets for insurance and as a means of 519 monitoring for attacks. Also the specifications of ICMPv6 messages 520 intended for use only on the local link specify various measures 521 which would allow receivers to detect if the message had passed 522 through a router, including: 523 o Requiring that the hop limit in the IPv6 header is set to 255 on 524 transmission. Receivers verify that the hop limit is still 255, 525 to ensure that the packet has not passed through a router. 526 o Checking that the source address is a link-local unicast address. 527 Accordingly it is not essential to configure firewall/router rules to 528 drop out-of-specification packets of these types. If they have non- 529 link-local source and destination addresses, allowing them to 530 traverse the firewall/router, they would be rejected because of the 531 checks performed at the destination. Again, firewall administrators 532 may still wish to configure rules to log or drop such out-of- 533 specification packets. 535 For firewall/bridges, slightly different considerations apply. The 536 physical links on either side of the firewall/bridge are treated as a 537 single logical link for the purposes of IP. Hence the link local 538 messages used for discovery functions on the link must be allowed to 539 transit the transparent bridge. Administrators should assure for 540 themselves that routers and hosts attached to the link containing the 541 firewall/bridge are built to the correct specifications so that out- 542 of-specification packets are actually dropped as described in the 543 earlier part of this section. 545 4.3. Recommendations for ICMPv6 Transit Traffic 547 This section recommends rules that should be applied to ICMPv6 548 traffic attempting to transit a firewall. 550 4.3.1. Traffic that Must Not be Dropped 552 Error messages that are essential to the establishment of 553 communications: 554 o Destination Unreachable (Type 1) - All codes 555 o Packet Too Big (Type 2) 556 o Time Exceeded (Type 3) - Code 0 only 557 o Parameter Problem (Type 4) - Codes 1 and 2 only 558 Appendix A.4 suggests some more specific checks that could be 559 performed on Parameter Problem messages if a firewall has the 560 necessary packet inspection capabilities. 562 Connectivity checking messages: 563 o Echo Request (Type 128) 564 o Echo Response (Type 129) 565 For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be 566 possible, it is essential that the connectivity checking messages are 567 allowed through the firewall. It has been common practice in IPv4 568 networks to drop Echo Request messages in firewalls to minimize the 569 risk of scanning attacks on the protected network. As discussed in 570 Section 3.2, the risks from port scanning in an IPv6 network are much 571 less severe and it is not necessary to filter IPv6 Echo Request 572 messages. 574 4.3.2. Traffic that Normally Should Not be Dropped 576 Error messages other than those listed in Section 4.3.1 577 o Time Exceeded (Type 3) - Code 1 578 o Parameter Problem (Type 4) - Code 0 580 Mobile IPv6 messages that are needed to assist mobility: 581 o Home Agent Address Discovery Request (Type 144) 582 o Home Agent Address Discovery Reply (Type 145) 583 o Mobile Prefix Solicitation (Type 146) 584 o Mobile Prefix Advertisement(Type 147) 585 Administrators may wish to apply more selective rules as described in 586 Appendix A.14 depending on whether the site is catering for mobile 587 nodes which would normally be at home on the site and/or foreign 588 mobile nodes roaming onto the site. 590 4.3.3. Traffic that will be Dropped Anyway - No Special Attention 591 Needed 593 The messages listed in this section are all involved with local 594 management of nodes connected to the logical link on which they were 595 initially transmitted. All these messages should never be propagated 596 beyond the link on which they were initially transmitted. If the 597 firewall is a firewall/bridge rather than a firewall/router, these 598 messages should be allowed to transit the firewall as they would be 599 intended for establishing communications between the two physical 600 parts of the link that are bridged into a single logical link. 602 During normal operations these messages will have destination 603 addresses, mostly link local but in some cases global unicast 604 addresses, of interfaces on the local link. No special action is 605 needed to filter messages with link-local addresses in a firewall/ 606 router. As discussed in Section 4.1 these messages are specified so 607 that either the receiver is able to check that the message has not 608 passed through a router or it will be dropped at the first router it 609 encounters. 611 Administrators may also wish to consider providing rules in firewall/ 612 routers to catch illegal packets sent with hop limit = 1 to avoid 613 ICMPv6 Time Exceeded messages being generated for these packets. 615 Address Configuration and Router Selection messages (must be received 616 with hop limit = 255): 617 o Router Solicitation (Type 133) 618 o Router Advertisement (Type 134) 619 o Neighbor Solicitation (Type 135) 620 o Neighbor Advertisement (Type 136) 621 o Redirect (Type 137) 622 o Inverse Neighbor Discovery Solicitation (Type 141) 623 o Inverse Neighbor Discovery Advertisement (Type 142) 625 Link-local multicast receiver notification messages (must have link- 626 local source address): 627 o Listener Query (Type 130) 628 o Listener Report (Type 131) 629 o Listener Done (Type 132) 630 o Listener Report v2 (Type 143) 632 SEND Certificate Path notification messages (must be received with 633 hop limit = 255): 634 o Certificate Path Solicitation (Type 148) 635 o Certificate Path Advertisement (type 149) 637 Multicast Router Discovery messages (must have link-local source 638 address and hop limit = 1): 639 o Multicast Router Advertisement (Type 151) 640 o Multicast Router Solicitation (Type 152) 641 o Multicast Router Termination (Type 153) 643 4.3.4. Traffic for which a Dropping Policy Should be Defined 645 The message type that the experimental Seamoby protocols are using 646 will be expected to have to cross site boundaries in normal 647 operation. Administrators should determine if they need to support 648 these experiments and otherwise messages of this type should be 649 dropped: 650 o Seamoby Experimental (Type 150) 652 Error messages not currently defined by IANA: 653 o Unallocated Error messages (Types 5-99 and 102-126, inclusive) 655 The base ICMPv6 specification suggests that error messages which are 656 not explicitly known to a node should be forwarded and passed to any 657 higher level protocol that might be able to interpret them. There is 658 a small risk that such messages could be used to provide a covert 659 channel or form part of a DoS attack. Administrators should be aware 660 of this and determine whether they wish to allow these messages 661 through the firewall. 663 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made 665 Node Information enquiry messages should generally not be forwarded 666 across site boundaries. Some of these messages will be using non- 667 link-local unicast addresses so that they will not necessarily be 668 dropped by address scope limiting rules: 669 o Node Information Query (Type 139) 670 o Node Information Response (Type 140) 672 Router Renumbering messages should not be forwarded across site 673 boundaries. As originally specified, these messages may use a site 674 scope multicast address or a site local unicast address. They should 675 be caught by standard rules that are intended to stop any packet with 676 a multicast site scope or site local destination being forwarded 677 across a site boundary provided these are correctly configured. 678 Since site local addresses have now been deprecated it seems likely 679 that changes may be made to allow the use of unique local addresses 680 or global unicast addresses. Should this happen, it will be 681 essential to explicitly filter these messages: 682 o Router Renumbering (Type 139) 684 Messages with types in the experimental allocations: 685 o Types 100, 101, 200 and 201. 687 Messages using the extension type numbers until such time as ICMPv6 688 needs to use such extensions: 689 o Types 127 and 255. 691 All informational messages with types not explicitly assigned by 692 IANA, currently: 694 o Types 154 - 199 inclusive and 202 - 254 inclusive. 696 Note that the base ICMPv6 specification requires that informational 697 messages with unknown types must be silently discarded. 699 4.4. Recommendations for ICMPv6 Local Configuration Traffic 701 This section recommends filtering rules for ICMPv6 traffic addressed 702 to an interface on a firewall. For a small number of messages, the 703 desired behavior may differ between interfaces on the site or private 704 side of the firewall and the those on the public Internet side of the 705 firewall. 707 4.4.1. Traffic that Must Not be Dropped 709 Error messages that are essential to the establishment of 710 communications: 711 o Destination Unreachable (Type 1) - All codes 712 o Packet Too Big (Type 2) 713 o Time Exceeded (Type 3) - Code 0 only 714 o Parameter Problem (Type 4) - Codes 1 and 2 only 716 Connectivity checking messages: 717 o Echo Request (Type 128) 718 o Echo Response (Type 129) 719 As discussed in Section 4.3.1, dropping connectivity checking 720 messages will prevent the firewall being the destination of a Teredo 721 tunnel and it is not considered necessary to disable connectivity 722 checking in IPv6 networks because port scanning is less of a security 723 risk. 725 There are a number of other sets of messages which play a role in 726 configuring the node and maintaining unicast and multicast 727 communications through the interfaces of a node. These messages must 728 not be dropped if the node is to successfully participate in an IPv6 729 network. The exception to this is the Redirect message for which an 730 explicit policy decision should be taken (see Section 4.4.4). 732 Address Configuration and Router Selection messages: 733 o Router Solicitation (Type 133) 734 o Router Advertisement (Type 134) 735 o Neighbor Solicitation (Type 135) 736 o Neighbor Advertisement (Type 136) 737 o Inverse Neighbor Discovery Solicitation (Type 141) 738 o Inverse Neighbor Discovery Advertisement (Type 142) 740 Link-local multicast receiver notification messages: 742 o Listener Query (Type 130) 743 o Listener Report (Type 131) 744 o Listener Done (Type 132) 745 o Listener Report v2 (Type 143) 747 SEND Certificate Path notification messages: 748 o Certificate Path Solicitation (Type 148) 749 o Certificate Path Advertisement (type 149) 751 Multicast Router Discovery messages : 752 o Multicast Router Advertisement (Type 151) 753 o Multicast Router Solicitation (Type 152) 754 o Multicast Router Termination (Type 153) 756 4.4.2. Traffic that Normally Should Not be Dropped 758 Error messages other than those listed in Section 4.4.1: 759 o Time Exceeded (Type 3) - Code 1 760 o Parameter Problem (Type 4) - Code 0 762 4.4.3. Traffic that will be Dropped Anyway - No Special Attention 763 Needed 765 Router Renumbering messages must be authenticated using IPsec, so it 766 is not essential to filter these messages even if they are not 767 allowed at the firewall/router: 768 o Router Renumbering (Type 139) 770 Mobile IPv6 messages that are needed to assist mobility: 771 o Home Agent Address Discovery Request (Type 144) 772 o Home Agent Address Discovery Reply (Type 145) 773 o Mobile Prefix Solicitation (Type 146) 774 o Mobile Prefix Advertisement(Type 147) 775 It may be desirable to drop these messages, especially on public 776 interfaces, if the firewall is not also providing mobile Home Agent 777 services, but they will be ignored otherwise. 779 The message used by the experimental Seamoby protocols may be dropped 780 but will be ignored if the service is not implemented: 781 o Seamoby Experimental (Type 150) 783 4.4.4. Traffic for which a Dropping Policy Should be Defined 785 Redirect messages provide a significant security risk and 786 administrators should take a case-by-case view of whether firewalls, 787 routers in general and other nodes should accept these messages: 789 o Redirect (Type 137) 790 Conformant nodes must provide configuration controls which allow 791 nodes to control their behavior with respect to Redirect messages so 792 that it should only be necessary to install specific filtering rules 793 under special circumstances, such as if Redirect messages are 794 accepted on private interfaces but not public ones. 796 If a node implements the experimental Node Information service, the 797 administrator needs to make an explicit decision as to whether the 798 node should respond to or accept Node Information messages on each 799 interface: 800 o Node Information Query (Type 139) 801 o Node Information Response (Type 140) 802 It may be possible to disable the service on the node if it is not 803 wanted in which case these messages will ignored and no filtering is 804 necessary. 806 Error messages not currently defined by IANA: 807 o Unallocated Error messages (Types 5-99 and 102-126, inclusive) 809 The base ICMPv6 specification suggests that error messages which are 810 not explicitly known to a node should be forwarded and passed to any 811 higher level protocol that might be able to interpret them. There is 812 a small risk that such messages could be used to provide a covert 813 channel or form part of a DoS attack. Administrators should be aware 814 of this and determine whether they wish to allow these messages to be 815 sent to the firewall. 817 4.4.5. Traffic which Should be Dropped Unless a Good Case can be Made 819 Messages with types in the experimental allocations: 820 o Types 100, 101, 200 and 201. 822 Messages using the extension type numbers until such time as ICMPv6 823 needs to use such extensions: 824 o Types 127 and 255. 826 All informational messages with types not explicitly assigned by 827 IANA, currently: 828 o Types 154 - 199 inclusive and 202 - 254 inclusive. 830 Note that the base ICMPv6 specification requires that informational 831 messages with unknown types must be silently discarded. 833 5. IANA Considerations 835 There are no IANA considerations defined in this document. 837 6. Acknowledgements 839 Pekka Savola created the original IPv6 Security Overview document 840 which contained suggestions for ICMPv6 filter setups. This 841 information has been incorporated into this document. He has also 842 provided important comments. Some analysis of the classification of 843 ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in 844 a draft relating to ICMPv6 and IKE. 846 The Netfilter configuration script in Appendix C was contributed by 847 Suresh Krishnan. 849 7. References 851 7.1. Normative References 853 [I-D.ietf-ipngwg-icmp-name-lookups] 854 Crawford, M. and B. Haberman, "IPv6 Node Information 855 Queries", draft-ietf-ipngwg-icmp-name-lookups-15 (work in 856 progress), February 2006. 858 [I-D.ietf-ipngwg-icmp-v3] 859 Conta, A., "Internet Control Message Protocol (ICMPv6) for 860 the Internet Protocol Version 6 (IPv6) Specification", 861 draft-ietf-ipngwg-icmp-v3-07 (work in progress), 862 July 2005. 864 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 865 for IP version 6", RFC 1981, August 1996. 867 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 868 (IPv6) Specification", RFC 2460, December 1998. 870 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 871 Discovery for IP Version 6 (IPv6)", RFC 2461, 872 December 1998. 874 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 875 Autoconfiguration", RFC 2462, December 1998. 877 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 878 Listener Discovery (MLD) for IPv6", RFC 2710, 879 October 1999. 881 [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, 882 August 2000. 884 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 885 Inverse Discovery Specification", RFC 3122, June 2001. 887 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 888 Listener Discovery (MLD) Protocol", RFC 3590, 889 September 2003. 891 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 892 in IPv6", RFC 3775, June 2004. 894 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 895 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 897 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 898 Neighbor Discovery (SEND)", RFC 3971, March 2005. 900 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 901 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 903 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 904 RFC 4286, December 2005. 906 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 907 Message Protocol (ICMPv6) for the Internet Protocol 908 Version 6 (IPv6) Specification", RFC 4443, March 2006. 910 7.2. Informative References 912 [I-D.gont-tcpm-icmp-attacks] 913 Gont, F., "ICMP attacks against TCP", 914 draft-gont-tcpm-icmp-attacks-05 (work in progress), 915 October 2005. 917 [I-D.ietf-v6ops-scanning-implications] 918 Chown, T., "IPv6 Implications for Network Scanning", 919 draft-ietf-v6ops-scanning-implications-00 (work in 920 progress), June 2006. 922 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 923 Stateless Address Autoconfiguration in IPv6", RFC 3041, 924 January 2001. 926 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 927 Network Address Translations (NATs)", RFC 4380, 928 February 2006. 930 [netfilter] 931 netfilter.org, "The netfilter.org project", Firewalling, 932 NAT and Packet Mangling for Linux , 2006, 933 . 935 Appendix A. Notes on Individual ICMPv6 Messages 937 A.1. Destination Unreachable Error Message 939 Destination Unreachable (Type 1) error messages [RFC4443] are sent 940 any-to-end between unicast addresses. The message can be generated 941 from any node which a packet traverses when the node is unable to 942 forward the packet for any reason except congestion. 944 Destination Unreachable messages are useful for debugging but are 945 also important to speed up cycling through possible addresses, as 946 they can avoid the need to wait through timeouts and hence can be 947 part of the process of establishing communications. It is a common 948 practice in IPv4 to refrain from generating ICMP Destination 949 Unreachable messages in an attempt to hide the networking topology 950 and/or service structure. The same idea could be applied to IPv6 but 951 this can slow down connection if a host has multiple addresses, some 952 of which are deprecated, as they may be when using privacy addresses 953 [RFC3041]. If policy allows the generation of ICMPv6 Destination 954 Unreachable messages, it is important that nodes provide the correct 955 reason code, one of: no route to destination, administratively 956 prohibited, beyond scope of source address, address unreachable, port 957 unreachable, source address failed ingress/egress policy, reject 958 route to destination. 960 A.2. Packet Too Big Error Message 962 Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end 963 between unicast addresses. The message can be generated from any 964 node which a packet traverses on the path when the node is unable to 965 forward the packet because the packet is too large for the MTU of the 966 next link. This message is vital to the correct functioning of Path 967 MTU Discovery and hence is part of the establishment of 968 communications. Since routers are not allowed to fragment packets, 969 informing sources of the need to fragment large packets is more 970 important than for IPv4. If these messages are not generated when 971 appropriate, hosts will continue to send packets which are too large 972 or may assume that the route is congested. Effectively parts of the 973 Internet will become inaccessible. 975 If a network chooses to generate packets that are no larger than the 976 Guaranteed Minimum MTU (1280 octets) and the site's links to the 977 wider internet have corresponding MTUs, Packet Too Big messages 978 should not be expected at the firewall and could be dropped if they 979 arrive. 981 A.3. Time Exceeded Error Message 983 Time Exceeded (Type 3) error messages [RFC4443] can occur in two 984 contexts: 985 o Code 0 are generated at any node on the path being taken by the 986 packet and sent, any-to-end between unicast addresses, if the Hop 987 Limit value is decremented to zero at that node. 988 o Code 1 messages are generated at the destination node and sent 989 end-to-end between unicast addresses if all the segments of a 990 fragmented message are not received within the reassembly time 991 limit 993 Code 0 messages can be needed as part of the establishment of 994 communications if the path to a particular destination requires an 995 unusually large number of hops. 997 Code 1 messages will generally only result from congestion in the 998 network and it is less essential to propagate these messages. 1000 A.4. Parameter Problem Error Message 1002 The great majority of Parameter Problem (Type 4) error messages will 1003 be generated by the destination node when processing destination 1004 options and other extension headers, and hence are sent end-to-end 1005 between unicast addresses. Exceptionally, these messages might be 1006 generated by any node on the path if a faulty or unrecognized hop-by- 1007 hop option is included or from any routing waypoint if there are 1008 faulty or unrecognized destination options associated with a Type 0 1009 routing header. In these cases the message will be sent any-to-end 1010 using unicast source and destination addresses. 1012 Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 1013 (Unrecognized IPv6 Option) messages may result if a node on the path 1014 (usually the destination) is unable to process a correctly formed 1015 extension header or option. If these messages are not returned to 1016 the source communication cannot be established, as the source would 1017 need to adapt its choice of options probably because the destination 1018 does not implement these capabilities. Hence these messages need to 1019 be generated and allowed for effective IPv6 communications. 1021 Code 0 (Erroneous Header) messages indicate a malformed extension 1022 header generally as a result of incorrectly generated packets. Hence 1023 these messages are useful for debugging purposes but it is unlikely 1024 that a node generating such packets could establish communications 1025 without human intervention to correct the problem. 1027 Code 2 messages, only, can be generated for packets with multicast 1028 destination addresses. 1030 It is possible that attackers may seek to probe or scan a network by 1031 deliberately generating packets with unknown extension headers or 1032 options, or faulty headers. If nodes generate Parameter Problem 1033 error messages in all cases and these outgoing messages are allowed 1034 through firewalls, the attacker may be able to identify active 1035 addresses that can be probed further or learn about the network 1036 topology. The vulnerability could be mitigated whilst helping to 1037 establish communications if the firewall was able to examine such 1038 error messages in depth and was configured to only allow Parameter 1039 Problem messages for headers which had been standardized but were not 1040 supported in the protected network. If the network administrator 1041 believes that all nodes in the network support all legitimate 1042 extension headers then it would be reasonable to drop all outgoing 1043 Parameter Problem messages. Note that this is not a major 1044 vulnerability in a well-designed IPv6 network because of the 1045 difficulties of performing scanning attacks (see Section 3.2). 1047 A.5. ICMPv6 Echo Request and Echo Response 1049 Echo Request (Type 128) uses unicast addresses as source addresses, 1050 but may be sent to any legal IPv6 address, including multicast and 1051 anycast addresses [RFC4443]. Echo Requests travel end-to-end. 1052 Similarly Echo Responses (Type 129) travel end-to-end and would have 1053 a unicast address as destination and either a unicast or anycast 1054 address as source. They are mainly used in combination for 1055 monitoring and debugging connectivity. Their only role in 1056 establishing communication is that they are required when verifying 1057 connectivity through Teredo tunnels[RFC4380]: Teredo tunneling to 1058 IPv6 nodes on the site will not be possible if these messages are 1059 blocked. It is not thought that there is a significant risk from 1060 scanning attacks on a well-designed IPv6 network (see Section 3.2) 1061 and so connectivity checks should be allowed by default. 1063 A.6. Neighbor Solicitation and Neighbor Advertisement Messages 1065 ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 1066 136) messages are essential to the establishment of communications on 1067 the local link. Firewalls need to generate and accept these messages 1068 to allow them to establish interfaces onto their connected links. 1070 Note that the address scopes of the source and destination addresses 1071 on Neighbor Solicitations and Neighbor Advertisements may not match. 1072 The exact functions which these messages will be carrying out depends 1073 on the mechanism being used to configure IPv6 addresses on the link 1074 (Stateless, Stateful or Static configuration). 1076 A.7. Router Solicitation and Router Advertisement Messages 1078 ICMPv6 Router Solicitation and Router Advertisement(Type 133 and 134) 1079 messages are essential to the establishment of communications on the 1080 local link. Firewalls need to generate (since the firewall will 1081 generally be behaving as a router) and accept these messages to allow 1082 them to establish interfaces onto their connected links. 1084 A.8. Redirect Messages 1086 ICMPv6 Redirect Messages(Type 137) are used on the local link to 1087 indicate that nodes are actually link-local and communications need 1088 not go via a router, or to indicate a more appropriate first hop 1089 router. Although they can be used to make communications more 1090 efficient, they are not essential to the establishment of 1091 communications and may be a security vulnerability, particularly if a 1092 link is not physically secured. Conformant nodes are required to 1093 provide configuration controls which suppress the generation of 1094 Redirect messages and allow them to be ignored on reception. Using 1095 Redirect messages on, for example, a wireless link without link level 1096 encryption/authentication is particularly hazardous because the link 1097 is open to eavesdroppring and packet injection. 1099 A.9. SEND Certificate Path Messages 1101 SEND [RFC3971] uses two messages (Certificate Path Solicitation and 1102 Advertisement - Types 148 and 149) sent from nodes to supposed 1103 routers on the same local link to obtain a certificate path which 1104 will allow the node to authenticate the router's claim to provide 1105 routing services for certain prefixes. If a link connected to a 1106 firewall/router is using SEND, the firewall must be able to exchange 1107 these messages with nodes on the link that will use its routing 1108 services. 1110 A.10. Multicast Listener Discovery Messages 1112 Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener 1113 Query, Listener Report and Listener Done - Types 130, 131 and 132) 1114 and version 2 [RFC3810] (Listener Query and Listener Report Version 2 1115 - Types 130 and 143) messages are sent on the local link to 1116 communicate between multicast capable routers and nodes which wish to 1117 join or leave specific multicast groups. Firewalls need to be able 1118 to generate Listener messages in order to establish communications 1119 and may generate all the messages if they also provide multicast 1120 routing services. 1122 A.11. Multicast Router Discovery Messages 1124 Multicast Router Discovery [RFC4286] (Router Advertisement, Router 1125 Solicitation and Router Termination - Types 151, 152 and 153) 1126 messages are sent by nodes on the local link to discover multicast 1127 capable routers on the link, and by multicast capable routers to 1128 notify other nodes of their existence or change of state. Firewalls 1129 which also act as multicast routers need to process these messages on 1130 their interfaces. 1132 A.12. Router Renumbering Messages 1134 ICMPv6 Router Renumbering (Type 138) command messages can be received 1135 and results messages sent by routers to change the prefixes which 1136 they advertise as part of Stateless Address Configuration [RFC2461], 1137 [RFC2462]. These messages are sent end-to-end to either the all- 1138 routers multicast address (site or local scope) or specific unicast 1139 addresses from a unicast address. 1141 Router Renumbering messages are required to be protected by IPsec 1142 authentication since they could be readily misused by attackers to 1143 disrupt or divert site communications. Renumbering messages should 1144 generally be confined to sites for this reason. 1146 A.13. Node Information Query and Reply 1148 ICMPv6 Node Information Query and Reply (Type 139 and 140) messages 1149 are sent end-to-end between unicast addresses, and can also be sent 1150 to link-local multicast addresses. They can, in theory, be sent from 1151 any node to any other but it would generally not be desirable for 1152 nodes outside the local site to be able to send queries to nodes 1153 within the site. Also these messages are not required to be 1154 authenticated. 1156 A.14. Mobile IPv6 Messages 1158 Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to 1159 support mobile operations: Home Agent Address Discovery Request, Home 1160 Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP 1161 Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages. 1162 These messages are sent end-to-end between unicast addresses of a 1163 mobile node and its home agent. They must be expected to be sent 1164 from outside a site and must traverse site-boundary firewalls toreach 1165 the home agent in order for Mobile IPv6 to function. The two Mobile 1166 prefix messages should be protected by the use of IPsec 1167 authentication. 1169 o If the site provides home agents for mobile nodes, the firewall 1170 must allow incoming Home Agent Address Discovery Request and 1171 Mobile Prefix Solicitation messages, and outgoing Home Agent 1172 Address Discovery Reply and ICMP Mobile Prefix Advertisement 1173 messages. It may be desirable to limit the destination addresses 1174 for the incoming messages to links that are known to support home 1175 agents. 1176 o If the site is prepared to host roaming mobile nodes, the firewall 1177 must allow outgoing Home Agent Address Discovery Request and 1178 Mobile Prefix Solicitation messages, and incoming Home Agent 1179 Address Discovery Reply and ICMP Mobile Prefix Advertisement 1180 messages. 1181 o Administrators may find it desirable to prevent static nodes which 1182 are normally resident on the site from behaving as mobile nodes by 1183 dropping Mobile IPv6 messages from these nodes. 1185 A.15. Unused and Experimental Messages 1187 A large number of ICMPv6 Type values are currently unused. These 1188 values have not had a specific function registered with IANA. This 1189 section describes how to treat messages which attempt to use these 1190 Type values in a way of which the network administrator (and hence 1191 the firewall) is not aware. 1193 [I-D.ietf-ipngwg-icmp-v3] defines a number of experimental Type 1194 values for ICMPv6 Error and Informational messages, which could be 1195 used in site specific ways. These values should be treated in the 1196 same way as values which are not registered by IANA unless the 1197 network administrator is explicitly made aware of usage. 1199 The codes reserved for future extension of the ICMPv6 Type space 1200 should currently be dropped as this functionality is as yet 1201 undefined. 1203 Any ICMPv6 Informational messages of which the firewall is not aware 1204 should not be allowed to pass through the firewall or be accepted for 1205 local delivery on any of its interfaces. 1207 Any incoming ICMPv6 Error messages of which the firewall is not aware 1208 may be allowed through the firewall in line with the specification in 1209 [RFC4443], which requests delivery of unknown error messages to 1210 higher layer protocol processes. However, administrators may wish to 1211 disallow forwarding of these incoming messages as a potential 1212 security risk. Unknown outgoing Error messages should be dropped as 1213 the administrator should be aware of all messages that could be 1214 generated on the site. 1216 Also the Seamoby working group has had an ICMPv6 message (Type 150) 1217 allocated for experimental use in two protocols. This message is 1218 sent end-to-end and may need to pass through firewalls on sites that 1219 are supporting the experimental protocols. 1221 Appendix B. Example Script to Configure ICMPv6 Firewall Rules 1223 This appendix contains an example script to implement most of the 1224 rules suggested in this document when using the Netfilter packet 1225 filtering system for Linux [netfilter]. When used with IPv6, the 1226 'ip6tables' command is used to configure packet filtering rules for 1227 the Netfilter system. The script is targeted at a simple enterprise 1228 site that may or may not support Mobile IPv6. 1230 #!/bin/bash 1231 # Set of prefixes on the trusted ("inner") side of the firewall 1232 export INNER_PREFIXES="2001:DB8:85::/60" 1233 # Set of hosts providing services so that they can be made pingable 1234 export PINGABLE_HOSTS="2001:DB8:85::/64" 1235 # Configuration option: Change this to 1 if errors allowed only for 1236 # existing sessions 1237 export STATE_ENABLED=0 1238 # Configuration option: Change this to 1 if messages to/from link 1239 # local addresses should be filtered. 1240 # Do not use this if the firewall is a bridge. 1241 # Optional for firewalls that are routers. 1242 export FILTER_LINK_LOCAL_ADDRS=0 1243 # Configuration option: Change this to 0 if the site does not support 1244 # Mobile IPv6 Home Agents - see Appendix A.14 1245 export HOME_AGENTS_PRESENT=1 1246 # Configuration option: Change this to 0 if the site does not support 1247 # Mobile IPv6 mobile nodes being present on the site - 1248 # see Appendix A.14 1249 export MOBILE_NODES_PRESENT=1 1251 ip6tables -N icmpv6-filter 1252 ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter 1254 # Match scope of src and dest else deny 1255 # This capability is not provided for in base ip6tables functionality 1256 # An extension (agr) exists which may support it. 1257 #@TODO@ 1259 # ECHO REQUESTS AND RESPONSES 1260 # =========================== 1262 # Allow outbound echo requests from prefixes which belong to the site 1263 for inner_prefix in $INNER_PREFIXES 1264 do 1265 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1266 --icmpv6-type echo-request -j ACCEPT 1267 done 1269 # Allow inbound echo requests towards only predetermined hosts 1270 for pingable_host in $PINGABLE_HOSTS 1271 do 1272 ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ 1273 --icmpv6-type echo-request -j ACCEPT 1274 done 1276 if [ "$STATE_ENABLED" -eq "1" ] 1277 then 1278 # Allow incoming and outgoing echo reply messages 1279 # only for existing sessions 1280 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1281 --state ESTABLISHED,RELATED --icmpv6-type \ 1282 echo-reply -j ACCEPT 1283 else 1284 # Allow both incoming and outgoing echo replies 1285 for pingable_host in $PINGABLE_HOSTS 1286 do 1287 # Outgoing echo replies from pingable hosts 1288 ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \ 1289 --icmpv6-type echo-reply -j ACCEPT 1290 done 1291 # Incoming echo replies to prefixes which belong to the site 1292 for inner_prefix in $INNER_PREFIXES 1293 do 1294 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1295 --icmpv6-type echo-reply -j ACCEPT 1296 done 1297 fi 1299 # Deny icmps to/from link local addresses 1300 # If the firewall is a router: 1301 # These rules should be redundant as routers should not forward 1302 # link local addresses but to be sure... 1303 # DO NOT ENABLE these rules if the firewall is a bridge 1304 if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ] 1305 then 1306 ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP 1307 ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP 1308 fi 1310 # Drop echo replies which have a multicast address as a 1311 # destination 1312 ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ 1313 --icmpv6-type echo-reply -j DROP 1315 # DESTINATION UNREACHABLE ERROR MESSAGES 1316 # ====================================== 1318 if [ "$STATE_ENABLED" -eq "1" ] 1319 then 1320 # Allow incoming destination unreachable messages 1321 # only for existing sessions 1322 for inner_prefix in $INNER_PREFIXES 1323 do 1324 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1325 -d $inner_prefix \ 1326 --state ESTABLISHED,RELATED --icmpv6-type \ 1327 destination-unreachable -j ACCEPT 1328 done 1329 else 1330 # Allow incoming destination unreachable messages 1331 for inner_prefix in $INNER_PREFIXES 1332 do 1333 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1334 --icmpv6-type destination-unreachable -j ACCEPT 1335 done 1336 fi 1338 # Allow outgoing destination unreachable messages 1339 for inner_prefix in $INNER_PREFIXES 1340 do 1341 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1342 --icmpv6-type destination-unreachable -j ACCEPT 1343 done 1345 # PACKET TOO BIG ERROR MESSAGES 1346 # ============================= 1348 if [ "$STATE_ENABLED" -eq "1" ] 1349 then 1350 # Allow incoming Packet Too Big messages 1351 # only for existing sessions 1352 for inner_prefix in $INNER_PREFIXES 1353 do 1354 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1355 -d $inner_prefix \ 1356 --state ESTABLISHED,RELATED \ 1357 --icmpv6-type packet-too-big \ 1358 -j ACCEPT 1359 done 1361 else 1362 # Allow incoming Packet Too Big messages 1363 for inner_prefix in $INNER_PREFIXES 1364 do 1365 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1366 --icmpv6-type packet-too-big -j ACCEPT 1367 done 1368 fi 1370 # Allow outgoing Packet Too Big messages 1371 for inner_prefix in $INNER_PREFIXES 1372 do 1373 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1374 --icmpv6-type packet-too-big -j ACCEPT 1375 done 1377 # TIME EXCEEDED ERROR MESSAGES 1378 # ============================ 1380 if [ "$STATE_ENABLED" -eq "1" ] 1381 then 1382 # Allow incoming time exceeded code 0 messages 1383 # only for existing sessions 1384 for inner_prefix in $INNER_PREFIXES 1385 do 1386 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1387 -d $inner_prefix \ 1388 --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ 1389 -j ACCEPT 1390 done 1391 else 1392 # Allow incoming time exceeded code 0 messages 1393 for inner_prefix in $INNER_PREFIXES 1394 do 1395 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1396 --icmpv6-type ttl-zero-during-transit -j ACCEPT 1397 done 1398 fi 1400 #@POLICY@ 1401 # Allow incoming time exceeded code 1 messages 1402 for inner_prefix in $INNER_PREFIXES 1403 do 1404 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1405 --icmpv6-type ttl-zero-during-reassembly -j ACCEPT 1406 done 1408 # Allow outgoing time exceeded code 0 messages 1409 for inner_prefix in $INNER_PREFIXES 1410 do 1411 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1412 --icmpv6-type ttl-zero-during-transit -j ACCEPT 1413 done 1415 #@POLICY@ 1416 # Allow outgoing time exceeded code 1 messages 1417 for inner_prefix in $INNER_PREFIXES 1418 do 1419 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1420 --icmpv6-type ttl-zero-during-reassembly -j ACCEPT 1421 done 1423 # PARAMETER PROBLEM ERROR MESSAGES 1424 # ================================ 1426 if [ "$STATE_ENABLED" -eq "1" ] 1427 then 1428 # Allow incoming parameter problem code 1 and 2 messages 1429 # for an existing session 1430 for inner_prefix in $INNER_PREFIXES 1431 do 1432 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1433 -d $inner_prefix \ 1434 --state ESTABLISHED,RELATED --icmpv6-type \ 1435 unknown-header-type \ 1436 -j ACCEPT 1437 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1438 -d $inner_prefix \ 1439 --state ESTABLISHED,RELATED \ 1440 --icmpv6-type unknown-option \ 1441 -j ACCEPT 1442 done 1443 fi 1445 # Allow outgoing parameter problem code 1 and code 2 messages 1446 for inner_prefix in $INNER_PREFIXES 1447 do 1448 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1449 --icmpv6-type unknown-header-type -j ACCEPT 1450 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1451 --icmpv6-type unknown-option -j ACCEPT 1452 done 1454 #@POLICY@ 1455 # Allow incoming and outgoing parameter 1456 # problem code 0 messages 1457 for inner_prefix in $INNER_PREFIXES 1458 do 1459 ip6tables -A icmpv6-filter -p icmpv6 \ 1460 --icmpv6-type bad-header \ 1461 -j ACCEPT 1462 done 1464 # NEIGHBOR DISCOVERY MESSAGES 1465 # =========================== 1467 # Drop NS/NA messages both incoming and outgoing 1468 ip6tables -A icmpv6-filter -p icmpv6 \ 1469 --icmpv6-type neighbor-solicitation -j DROP 1470 ip6tables -A icmpv6-filter -p icmpv6 \ 1471 --icmpv6-type neighbor-advertisement -j DROP 1473 # Drop RS/RA messages both incoming and outgoing 1474 ip6tables -A icmpv6-filter -p icmpv6 \ 1475 --icmpv6-type router-solicitation -j DROP 1476 ip6tables -A icmpv6-filter -p icmpv6 \ 1477 --icmpv6-type router-advertisement -j DROP 1479 # Drop Redirect messages both incoming and outgoing 1480 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP 1482 # MLD MESSAGES 1483 # ============ 1485 # Drop incoming and outgoing 1486 # Multicast Listener queries (MLDv1 and MLDv2) 1487 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP 1489 # Drop incoming and outgoing Multicast Listener reports (MLDv1) 1490 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP 1492 # Drop incoming and outgoing Multicast Listener Done messages (MLDv1) 1493 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP 1495 # Drop incoming and outgoing Multicast Listener reports (MLDv2) 1496 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP 1498 # ROUTER RENUMBERING MESSAGES 1499 # =========================== 1501 # Drop router renumbering messages 1502 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP 1503 # NODE INFORMATION QUERIES 1504 # ======================== 1506 # Drop node information queries (139) and replies (140) 1507 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP 1508 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP 1510 # MOBILE IPv6 MESSAGES 1511 # ==================== 1513 # If there are mobile ipv6 home agents present on the 1514 # trusted side allow 1515 if [ "$HOME_AGENTS_PRESENT" -eq "1" ] 1516 then 1517 for inner_prefix in $INNER_PREFIXES 1518 do 1519 #incoming Home Agent address discovery request 1520 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1521 --icmpv6-type 144 -j ACCEPT 1522 #outgoing Home Agent address discovery reply 1523 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1524 --icmpv6-type 145 -j ACCEPT 1525 #incoming Mobile prefix solicitation 1526 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1527 --icmpv6-type 146 -j ACCEPT 1528 #outgoing Mobile prefix advertisement 1529 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1530 --icmpv6-type 147 -j ACCEPT 1531 done 1532 fi 1534 # If there are roaming mobile nodes present on the 1535 # trusted side allow 1536 if [ "$MOBILE_NODES_PRESENT" -eq "1" ] 1537 then 1538 for inner_prefix in $INNER_PREFIXES 1539 do 1540 #outgoing Home Agent address discovery request 1541 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1542 --icmpv6-type 144 -j ACCEPT 1543 #incoming Home Agent address discovery reply 1544 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1545 --icmpv6-type 145 -j ACCEPT 1546 #outgoing Mobile prefix solicitation 1547 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1548 --icmpv6-type 146 -j ACCEPT 1549 #incoming Mobile prefix advertisement 1550 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1551 --icmpv6-type 147 -j ACCEPT 1552 done 1553 fi 1555 # DROP EVERYTHING ELSE 1556 # ==================== 1558 ip6tables -A icmpv6-filter -p icmpv6 -j DROP 1560 Authors' Addresses 1562 Elwyn B. Davies 1563 Consultant 1564 Soham, Cambs 1565 UK 1567 Phone: +44 7889 488 335 1568 Email: elwynd@dial.pipex.com 1570 Janos Mohacsi 1571 NIIF/HUNGARNET 1572 Victor Hugo u. 18-22 1573 Budapest, H-1132 1574 Hungary 1576 Phone: +36 1 4503070 1577 Email: mohacsi@niif.hu 1579 Intellectual Property Statement 1581 The IETF takes no position regarding the validity or scope of any 1582 Intellectual Property Rights or other rights that might be claimed to 1583 pertain to the implementation or use of the technology described in 1584 this document or the extent to which any license under such rights 1585 might or might not be available; nor does it represent that it has 1586 made any independent effort to identify any such rights. Information 1587 on the procedures with respect to rights in RFC documents can be 1588 found in BCP 78 and BCP 79. 1590 Copies of IPR disclosures made to the IETF Secretariat and any 1591 assurances of licenses to be made available, or the result of an 1592 attempt made to obtain a general license or permission for the use of 1593 such proprietary rights by implementers or users of this 1594 specification can be obtained from the IETF on-line IPR repository at 1595 http://www.ietf.org/ipr. 1597 The IETF invites any interested party to bring to its attention any 1598 copyrights, patents or patent applications, or other proprietary 1599 rights that may cover technology that may be required to implement 1600 this standard. Please address the information to the IETF at 1601 ietf-ipr@ietf.org. 1603 Disclaimer of Validity 1605 This document and the information contained herein are provided on an 1606 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1607 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1608 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1609 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1610 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1611 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1613 Copyright Statement 1615 Copyright (C) The Internet Society (2006). This document is subject 1616 to the rights, licenses and restrictions contained in BCP 78, and 1617 except as set forth therein, the authors retain all their rights. 1619 Acknowledgment 1621 Funding for the RFC Editor function is currently provided by the 1622 Internet Society.