idnits 2.17.1 draft-ietf-v6ops-cpe-simple-security-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2010) is 4934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5156 (Obsoleted by RFC 6890) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations j. woodyatt, Ed. 3 Internet-Draft Apple 4 Intended status: Informational October 21, 2010 5 Expires: April 24, 2011 7 Recommended Simple Security Capabilities in Customer Premises Equipment 8 for Providing Residential IPv6 Internet Service 9 draft-ietf-v6ops-cpe-simple-security-16 11 Abstract 13 This document identifies a set of recommendations for the makers of 14 devices describing how to provide for "simple security" capabilities 15 at the perimeter of local-area IPv6 networks in Internet-enabled 16 homes and small offices. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 24, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Use of Normative Keywords . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5 58 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 59 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 60 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 62 3.2.1. Internet Control and Management . . . . . . . . . . . 8 63 3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8 64 3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10 65 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 11 66 3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 12 67 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 13 68 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13 69 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 17 70 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 20 71 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 22 72 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22 73 3.5. Management Applications . . . . . . . . . . . . . . . . . 23 74 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 24 75 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 83 1. Introduction 85 Some IPv6 gateway devices that enable delivery of Internet services 86 in residential and small office settings may be augmented with 87 'simple security' capabilities as described in "Local Network 88 Protection for IPv6" [RFC4864]. In general, these capabilities cause 89 packets to be discarded in an attempt to make local networks and the 90 Internet more secure. However, it is worth noting that some packets 91 sent by legitimate applications may also be discarded in this 92 process, affecting reliability and ease of use for these 93 applications. 95 There is a constructive tension between the desires of users for 96 transparent end-to-end connectivity on the one hand, and the need for 97 local-area network administrators to detect and prevent intrusion by 98 unauthorized public Internet users on the other. This document is 99 intended to highlight reasonable limitations on end-to-end 100 transparency where security considerations are deemed important to 101 promote local and Internet security. 103 The reader is cautioned always to remember that the typical 104 residential or small office network administrator has no expertise 105 whatsoever in Internet engineering. Configuration interfaces for 106 router/gateway appliances marketed toward them should be easy to 107 understand and even easier to ignore. In particular, extra care 108 should be used in the design of baseline operating modes for 109 unconfigured devices, since most devices will never be changed from 110 their factory configurations. 112 1.1. Special Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 Additionally, the key word "DEFAULT" is to be interpreted in this 119 document as pertaining to a configuration as applied by a vendor, 120 prior to the administrator changing it for its initial activation. 122 1.2. Use of Normative Keywords 124 NOTE WELL: This document is not a standard, and conformance with it 125 is not required in order to claim conformance with IETF standards for 126 IPv6. It uses the normative keywords defined in the previous section 127 only for precision. 129 Particular attention is drawn to recommendation REC-49, which calls 130 for an easy way to set a gateway to a transparent mode of operation. 132 2. Overview 134 For the purposes of this document, residential Internet gateways are 135 assumed to be fairly simple devices with a limited subset of the full 136 range of possible features. They function as default routers 137 [RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi 138 network, a bridge between two or more such segments. They have only 139 one interface by which they can access the Internet service at any 140 one time, using any of several possible sub-IP mechanisms including 141 tunnels and transition mechanisms. 143 In referring to the security capabilities of residential gateways, it 144 is reasonable to distinguish between their "interior" network, i.e. 145 the local-area network, and their "exterior" networks, e.g. the 146 public Internet and the networks of Internet service providers. This 147 document is concerned only with the behavior of IP packet filters 148 that police the flow of traffic between the interior IPv6 network and 149 the exterior IPv6 networks of residential Internet gateways. 151 The operational goals of security capabilities in Internet gateways 152 are described with more detail in "Local Network Protection for IPv6" 153 [RFC4864], but they can be summarized as follows. 155 o Check all traffic to and from the public Internet for basic 156 sanity, e.g. anti-spoofing and "martian" [RFC4949] filters. 158 o Allow tracking of applications usage by source and destination 159 network addresses and ports. 161 o Provide a barrier against untrusted external influences on the 162 interior network by requiring filter state to be activated by 163 traffic originating at interior network nodes. 165 o Allow manually configured exceptions to the stateful filtering 166 rules according to network administrative policy. 168 o Isolate local network DHCPv6 and DNS resolver services from the 169 public Internet. 171 Prior to the widespread availability of IPv6 Internet service, homes 172 and small offices often used private IPv4 network address realms 173 [RFC1918] with Network Address Translation (NAT) functions deployed 174 to present all the hosts on the interior network as a single host to 175 the Internet service provider. The stateful packet filtering 176 behavior of NAT set user expectations that persist today with 177 residential IPv6 service. "Local Network Protection for IPv6" 178 [RFC4864] recommends applying stateful packet filtering at 179 residential IPv6 gateways that conforms to the user expectations 180 already in place. 182 Conventional stateful packet filters activate new states as a side 183 effect of forwarding outbound flow initiations from interior network 184 nodes. This requires applications to have advance knowledge of the 185 addresses of exterior nodes with which they expect to communicate. 186 Several proposals are currently under consideration for allowing 187 applications to solicit inbound traffic from exterior nodes without 188 advance knowledge of their addresses. While consensus within the 189 Internet engineering community has emerged that such protocols are 190 necessary to implement in residential IPv6 residential gateways, the 191 best current practice has not yet been established. 193 2.1. Basic Sanitation 195 In addition to the functions required of all Internet routers 196 [RFC4294], residential gateways are expected to have basic stateless 197 filters for prohibiting certain kinds of traffic with invalid 198 headers, e.g. "martian" packets, spoofs, routing header type code 199 zero, etc. (See Section 3.1 for more details.) 201 Conversely, simple Internet gateways are not expected to prohibit the 202 development of new applications. In particular, packets with end-to- 203 end network security and routing extension headers for mobility are 204 expected to pass Internet gateways freely. 206 Finally, Internet gateways that route multicast traffic are expected 207 to implement appropriate filters for multicast traffic to limit the 208 scope of multicast groups that span the demarcation between 209 residential networks and service provider networks. 211 2.2. Internet Layer Protocols 213 As virtual private networking tunnels are regarded as an unacceptably 214 wide attack surface, this document recommends the DEFAULT operating 215 mode for residential IPv6 simple security is to treat Generic Packet 216 Tunneling [RFC2473] and similar protocols as opaque transport layers, 217 i.e. inbound tunnel initiations are denied and outbound tunnel 218 initiations are accepted. 220 IPsec transport and tunnel modes are explicitly secured by 221 definition, so this document recommends the DEFAULT operating mode 222 permit IPsec. To facilitate the use of IPsec in support of IPv6 223 Mobility, Internet Key Exchange (IKE) protocol [RFC5996] and "Host 224 Identity Protocol (HIP)" [RFC5201] should also be permitted in the 225 DEFAULT operating mode. 227 2.3. Transport Layer Protocols 229 IPv6 simple security functions are principally concerned with the 230 stateful filtering of Internet Control Message Protocol (ICMPv6) 231 [RFC4443] and transport layers like User Datagram Protocol (UDP) 232 [RFC0768], Lightweight User Datagram Protocol (UDP-Lite) [RFC3828], 233 Transport Control Protocol (TCP) [RFC0793], the Stream Control 234 Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion 235 Control Protocol (DCCP) [RFC4340], and potentially any standards- 236 track transport protocols to be defined in the future. 238 The general operating principle is that transport layer traffic is 239 not forwarded into the interior network of a residential IPv6 gateway 240 unless it has been solicited explicitly by interior transport 241 endpoints, e.g. by matching the reverse path for previously forwarded 242 outbound traffic, or by matching configured exceptions set by the 243 network administrator. All other traffic is expected to be discarded 244 or rejected with an ICMPv6 error message to indicate the traffic is 245 administratively prohibited. 247 3. Detailed Recommendations 249 This section describes the specific recommendations made by this 250 document in full detail. Section 4 is a summary. 252 Some recommended filters are to be applied to all traffic that passes 253 through residential Internet gateways regardless of the direction 254 they are to be forwarded. Other recommended filters are intended to 255 be sensitive to the "direction" of traffic flows. Applied to 256 bidirectional transport flows, "direction" has a specific meaning in 257 this document. 259 Packets are said to be "outbound" if they originate at nodes located 260 in the interior network for exterior destinations, and "inbound" if 261 they arrive from exterior sources with interior destinations. 263 Flows are said to be "outbound" if the originator of the initial 264 packet in any given transport association is an interior node and one 265 or more of the participants are located in the exterior. Flows are 266 said to be "inbound" if the originator of the initial packet is an 267 exterior node and one or more of the participants are nodes on the 268 interior network. 270 3.1. Stateless Filters 272 Certain kinds of IPv6 packets MUST NOT be forwarded in either 273 direction by residential Internet gateways regardless of network 274 state. These include packets with multicast source addresses, 275 packets to destinations with certain non-routable and/or reserved 276 prefixes and packets with deprecated extension headers. 278 Other stateless filters are recommended to implement ingress 279 filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope 280 boundaries, and to isolate certain local network services from the 281 public Internet. 283 REC-1: Packets which bear in their outer IPv6 headers multicast 284 source addresses MUST NOT be forwarded or transmitted on any 285 interface. 287 REC-2: Packets which bear in their outer IPv6 headers multicast 288 destination addresses of equal or narrower scope (see IPv6 Scoped 289 Address Architecture [RFC4007]) than the configured scope boundary 290 level of the gateway MUST NOT be forwarded in any direction. The 291 DEFAULT scope boundary level SHOULD be organization-local scope, and 292 it SHOULD be configurable by the network administrator. 294 REC-3: Packets bearing source and/or destination addresses forbidden 295 to appear in the outer headers of packets transmitted over the public 296 Internet MUST NOT be forwarded. In particular, site-local addresses 297 are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use 298 of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and 299 ORCHID prefixes. 301 REC-4: Packets bearing deprecated extension headers prior to their 302 first upper-layer-protocol header SHOULD NOT be forwarded or 303 transmitted on any interface. In particular, all packets with 304 routing extension header type 0 [RFC2460] preceding the first upper- 305 layer-protocol header MUST NOT be forwarded. See [RFC5095] for 306 additional background. 308 REC-5: Outbound packets MUST NOT be forwarded if the source address 309 in their outer IPv6 header does not have a unicast prefix configured 310 for use by globally reachable nodes on the interior network. 312 REC-6: Inbound packets MUST NOT be forwarded if the source address in 313 their outer IPv6 header has a global unicast prefix assigned for use 314 by globally reachable nodes on the interior network. 316 REC-7: By DEFAULT, packets with unique local source and/or 317 destination addresses [RFC4193] SHOULD NOT be forwarded to or from 318 the exterior network. 320 REC-8: By DEFAULT, inbound DNS queries received on exterior 321 interfaces MUST NOT be processed by any integrated DNS resolving 322 server. 324 REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on 325 exterior interfaces MUST NOT be processed by any integrated DHCPv6 326 server or relay agent. 328 NOTE WELL: nothing in this document relieves residential Internet 329 gateways, when processing headers to identify valid sequences of 330 upper-layer transport packets, from any of the requirements of the 331 Internet Protocol, Version 6 (IPv6) Specification [RFC2460], 332 including any and all future updates and revisions. 334 3.2. Connection-free Filters 336 Some Internet applications use connection-free transport protocols 337 with no release semantics, e.g. UDP. These protocols pose a special 338 difficulty for stateful packet filters because most of the 339 application state is not carried at the transport level. State 340 records are created when communication is initiated and abandoned 341 when no further communication is detected after some period of time. 343 3.2.1. Internet Control and Management 345 Recommendations for filtering ICMPv6 messages in firewall devices are 346 described separately in [RFC4890] and apply to residential gateways 347 with the additional recommendation that incoming "Destination 348 Unreachable" and "Packet Too Big" error messages that don't match any 349 filtering state should be dropped. 351 REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination 352 Unreachable" and "Packet Too Big" messages containing IP headers that 353 do not match generic upper-layer transport state records. 355 3.2.2. Upper-layer Transport Protocols 357 Residential IPv6 gateways are not expected to prohibit the use of 358 applications to be developed using future upper-layer transport 359 protocols. In particular, transport protocols not otherwise 360 discussed in subsequent sections of this document are expected to be 361 treated consistently, i.e. as having connection-free semantics and no 362 special requirements to inspect the transport headers. 364 In general, upper-layer transport filter state records are expected 365 to be created when an interior endpoint sends a packet to an exterior 366 address. The filter allocates (or reuses) a record for the duration 367 of communications, with an idle timer to delete the state record when 368 no further communications are detected. 370 One key aspect of how a packet filter behaves is the way it evaluates 371 the exterior address of an enpoint when applying a filtering rule. A 372 gateway is said to have "endpoint independent filtering" behavior 373 when the exterior address is not evaluated when matching a packet 374 with a flow. A gateway is said to have "address dependent filtering" 375 behavior when the exterior address of a packet is required to match 376 the exterior address for its flow. 378 REC-11: If application transparency is most important, then a 379 stateful packet filter SHOULD have "endpoint independent filter" 380 behavior for generic upper-layer transport protocols. If a more 381 stringent filtering behavior is most important, then a filter SHOULD 382 have "address dependent filtering" behavior. The filtering behavior 383 MAY be an option configurable by the network administrator, and it 384 MAY be independent of the filtering behavior for other protocols. 385 Filtering behavior SHOULD be endpoint independent by DEFAULT in 386 gateways intended for provisioning without service-provider 387 management. 389 REC-12: Filter state records for generic upper-layer transport 390 protocols MUST NOT be deleted or recycled until an idle timer not 391 less than two minutes has expired without having forwarded a packet 392 matching the state in some configurable amount of time. By DEFAULT, 393 the idle timer for such state records is five minutes. 395 The Internet security community is never completely at rest. New 396 attack surfaces, and vulnerabilities in them, are typically 397 discovered faster than they can be patched by normal equipment 398 upgrade cycles. It's therefore important for vendors of residential 399 gateway equipment to provide automatic softare updates to patch 400 vulnerabilties as they are discovered. 402 REC-13: Residential IPv6 gateways SHOULD provide a convenient means 403 to update their firmware securely, for the installation of security 404 patches and other manufacturer-recommended changes. 406 Vendors can expect users and operators to have differing viewpoints 407 on the maintenance of patches, with some preferring automatic update 408 and some preferring manual procedures. Those preferring automatic 409 update may also prefer either to download from a vendor site or from 410 one managed by their network provider. To handle the disparity, 411 vendors are advised to provide both manual and automatic options. In 412 the automatic case, they would do well to facilitate pre- 413 configuration of the download URL and a means of validating the 414 software image such as a certificate. 416 3.2.3. UDP Filters 418 "Network Address Translation (NAT) Behavioral Requirements for 419 Unicast UDP" [RFC4787] defines the terminology and best current 420 practice for stateful filtering of UDP applications in IPv4 with NAT, 421 which serves as the model for behavioral requirements for simple UDP 422 security in IPv6 gateways, notwithstanding the requirements related 423 specifically to network address translation. 425 An interior endpoint initiates a UDP flow through a stateful packet 426 filter by sending a packet to an exterior address. The filter 427 allocates (or reuses) a filter state record for the duration of the 428 flow. The state record defines the interior and exterior IP 429 addresses and ports used between all packets in the flow. 431 State records for UDP flows remain active while they are in use and 432 only abandoned after an idle period of some time. 434 REC-14: A state record for a UDP flow where both source and 435 destination ports are outside the well-known port range (ports 436 0-1023) MUST NOT expire in less than two minutes of idle time. The 437 value of the UDP state record idle timer MAY be configurable. The 438 DEFAULT is five minutes. 440 REC-15: A state record for a UDP flow where one or both of the source 441 and destination ports are in the well-known port range (ports 0-1023) 442 MAY expire after a period of idle time shorter than two minutes to 443 facilitate the operation of the IANA-registered service assigned to 444 the port in question. 446 As [RFC4787] notes, outbound refresh is necessary for allowing the 447 interior endpoint to keep the state record alive. Inbound refresh 448 may be useful for applications with no outbound UDP traffic. 449 However, allowing inbound refresh can allow an attacker in the 450 exterior or a misbehaving application to keep a state record alive 451 indefinitely. This could be a security risk. Also, if the process 452 is repeated with different ports, over time, it could use up all the 453 state record memory and resources in the filter. 455 REC-16: A state record for a UDP flow MUST be refreshed when a packet 456 is forwarded from the interior to the exterior, and it MAY be 457 refreshed when a packet is forwarded in the reverse direction. 459 As described in Section 5.5 of [RFC4787], the connection-free 460 semantics of UDP pose a difficulty for packet filters in trying to 461 recognize which packets comprise an application flow and which are 462 unsolicited. Various strategies have been used in IPv4/NAT gateways 463 with differing effects. 465 REC-17: If application transparency is most important, then a 466 stateful packet filter SHOULD have "endpoint independent filter" 467 behavior for UDP. If a more stringent filtering behavior is most 468 important, then a filter SHOULD have "address dependent filtering" 469 behavior. The filtering behavior MAY be an option configurable by 470 the network administrator, and it MAY be independent of the filtering 471 behavior for TCP and other protocols. Filtering behavior SHOULD be 472 endpoint independent by DEFAULT in gateways intended for provisioning 473 without service-provider management. 475 Applications mechanisms may depend on the reception of ICMPv6 error 476 messages triggered by the transmission of UDP messages. One such 477 mechanism is path MTU discovery. 479 REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6 480 "Destination Unreachable" and "Packet Too Big" messages containing 481 UDP headers that match the flow state record. 483 REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the 484 state record for a UDP flow. 486 REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as 487 UDP flows, except that the upper-layer transport protocol identifier 488 for UDP-Lite is not the same as UDP, and therefore UDP packets MUST 489 NOT match UDP-Lite state records, and vice versa. 491 3.2.4. IPsec and Internet Key Exchange (IKE) 493 The Internet protocol security suite (IPsec) offers greater 494 flexibility and better overall security than the simple security of 495 stateful packet filtering at network perimeters. Therefore, 496 residential IPv6 gateways need not prohibit IPsec traffic flows. 498 REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT 499 prohibit the forwarding of packets, to and from legitimate node 500 addresses, with destination extension headers of type "Authenticated 501 Header (AH)" [RFC4302] in their outer IP extension header chain. 503 REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT 504 prohibit the forwarding of packets, to and from legitimate node 505 addresses, with an upper layer protocol of type "Encapsulating 506 Security Payload (ESP)" [RFC4303] in their outer IP extension header 507 chain. 509 REC-23: If a gateway forwards an ESP flow, it MUST also forward (in 510 the reverse direction) ICMPv6 "Destination Unreachable" and "Packet 511 Too Big" messages containing ESP headers that match the flow state 512 record. 514 Internet Key Exchange (IKE) is a secure mechanism for performing 515 mutual authentication, exchanging cryptographic material and 516 establishing IPsec Security Associations between peers. Residential 517 IPv6 gateways are expected to facilitate the use of IPsec security 518 policies by allowing inbound IKE flows. 520 REC-24: In their DEFAULT operating mode, IPv6 gateways MUST NOT 521 prohibit the forwarding of any UDP packets, to and from legitimate 522 node addresses, with a destination port of 500, i.e. the port 523 reserved by IANA for the Internet Key Exchange (IKE) protocol 524 [RFC5996]. 526 REC-25: In all operating modes, IPv6 gateways SHOULD use filter state 527 records for Encapsulating Security Payload (ESP) [RFC4303] that are 528 indexable by a 3-tuple comprising the interior node address, the 529 exterior node address and the ESP protocol identifier. In 530 particular, the IPv4/NAT method of indexing state records also by 531 security parameters index (SPI) SHOULD NOT be used. Likewise, any 532 mechanism that depends on detection of Internet Key Exchange (IKE) 533 [RFC5996] initiations SHOULD NOT be used. 535 "Host Identity Protocol (HIP)" is a secure mechanism for establishing 536 host identity and secure communications between authenticated hosts. 537 Residential IPv6 gateways need not prohibit inbound HIP flows. 539 REC-26: In their DEFAULT operating mode, IPv6 gateways MUST NOT 540 prohibit the forwarding of packets, to and from legitimate node 541 addresses, with destination extension headers of type "Host Identity 542 Protocol (HIP)" [RFC5201] in their outer IP extension header chain. 544 3.2.5. Mobility Support in IPv6 546 Mobility support in IPv6 [RFC3775] relies on the use of an 547 encapsulation mechanism in flows between mobile nodes and their 548 correspondent nodes, involving the use of the type 2 IPv6 routing 549 header, the Home Address destination header option and the Mobility 550 extension header. In contrast to mobility support in IPv4, mobility 551 is a standard feature of IPv6, and no security benefit is generally 552 to be gained by denying communications with either interior or 553 exterior mobile nodes. 555 Not all usage scenarios of Mobility support in IPv6 are expected to 556 compatible with IPv6 simple security. In particular, exterior mobile 557 nodes are expected to be prohibited from establishing bindings with 558 interior correspondent nodes by the filtering of unsolicited inbound 559 Mobility Header messages unless they are the subject of an IPsec 560 security policy. 562 REC-27: The state records for flows initiated by outbound packets 563 that bear a Home Address destination option [RFC3775] are 564 distinguished by the addition of the home address of the flow as well 565 as the interior care-of address. IPv6 gateways MUST NOT prohibit the 566 forwarding of any inbound packets bearing type 2 routing headers, 567 which otherwise match a flow state record, and where A) the address 568 in the destination field of the IPv6 header matches the interior 569 care-of address of the flow, and B) the Home Address field in the 570 Type 2 Routing Header matches the home address of the flow. 572 REC-28: Valid sequences of Mobility Header [RFC3775] packets MUST be 573 forwarded for all outbound and explicitly permitted inbound Mobility 574 Header flows. 576 REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then 577 it MUST also forward, in both directions, the IPv4 and IPv6 packets 578 that are encapsulated in IPv6 associated with the tunnel between the 579 home agent and the correspondent node. 581 REC-30: If a gateway forwards a Mobility Header [RFC3775] flow, then 582 it MUST also forward (in the reverse direction) ICMPv6 "Destination 583 Unreachable" and "Packet Too Big" messages containing any headers 584 that match the associated flow state records. 586 3.3. Connection-oriented Filters 588 Most Internet applications use connection-oriented transport 589 protocols with orderly release semantics. These protocols include 590 TCP, SCTP, DCCP, and potentially any future IETF standards-track 591 transport protocols that use such semantics. Stateful packet filters 592 track the state of individual transport flows and prohibit the 593 forwarding of packets that do not match the state of an active flow 594 and do not conform to a rule for the automatic creation of such 595 state. 597 3.3.1. TCP Filters 599 An interior endpoint initiates a TCP flow through a stateful packet 600 filter by sending a SYN packet. The filter allocates (or reuses) a 601 filter state record for the flow. The state record defines the 602 interior and exterior IP addresses and ports used for forwarding all 603 packets for that flow. 605 Some peer-to-peer applications use an alternate method of connection 606 initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse 607 stateful filters. In the simultaneous-open mode of operation, both 608 peers send SYN packets for the same TCP flow. The SYN packets cross 609 in the network. Upon receiving the other end's SYN packet, each end 610 responds with a SYN-ACK packet, which also cross in the network. The 611 connection is established at each endpoint once the SYN-ACK packets 612 are received. 614 To provide stateful packet filtering service for TCP, it is necessary 615 for a filter to receive, process and forward all packets for a flow 616 that conform to valid transitions of the TCP state machine (Fig. 6, 617 [RFC0793]). 619 REC-31: All valid sequences of TCP packets (defined in [RFC0793]) 620 MUST be forwarded for outbound flows and explicitly permitted inbound 621 flows. In particular, both the normal TCP 3-way handshake mode of 622 operation and the simultaneous-open modes of operation MUST be 623 supported. 625 It is possible to reconstruct enough of the state of a TCP flow to 626 allow forwarding between an interior and exterior node even when the 627 filter starts operating after TCP enters the established state. In 628 this case, because the filter has not seen the TCP window-scale 629 option, it is not possible for the filter to enforce the TCP window 630 invariant by dropping out-of-window segments. 632 REC-32: The TCP window invariant MUST NOT be enforced on flows for 633 which the filter did not detect whether the window-scale option (see 634 [RFC1323]) was sent in the 3-way handshake or simultaneous open. 636 A stateful filter can allow an existing state record to be reused by 637 an externally initiated flow if its security policy permits. Several 638 different policies are possible as described in [RFC4787] and 639 extended in [RFC5382]. 641 REC-33: If application transparency is most important, then a 642 stateful packet filter SHOULD have "endpoint independent filter" 643 behavior for TCP. If a more stringent filtering behavior is most 644 important, then a filter SHOULD have "address dependent filtering" 645 behavior. The filtering behavior MAY be an option configurable by 646 the network administrator, and it MAY be independent of the filtering 647 behavior for UDP and other protocols. Filtering behavior SHOULD be 648 endpoint independent by DEFAULT in gateways intended for provisioning 649 without service-provider management. 651 If an inbound SYN packet is filtered, either because a corresponding 652 state record does not exist or because of the filter's normal 653 behavior, a filter has two basic choices: to discard the packet 654 silently, or to signal an error to the sender. Signaling an error 655 through ICMPv6 messages allows the sender to detect that the SYN did 656 not reach the intended destination. Discarding the packet, on the 657 other hand, allows applications to perform simultaneous-open more 658 reliably. A more detailed discussion of this issue can be found in 659 [RFC5382], but the basic outcome of it is that filters need to wait 660 on signaling errors until simultaneous-open will not be impaired. 662 REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6 663 "Destination Unreachable" error code 1 (administratively prohibited) 664 to any unsolicited inbound SYN packet after waiting at least 6 665 seconds without first forwarding the associated outbound SYN or SYN/ 666 ACK from the interior peer. 668 A TCP filter maintains state associated with in-progress connections 669 and established flows. Because of this, a filter is susceptible to a 670 resource-exhaustion attack whereby an attacker (or virus) on the 671 interior attempts to cause the filter to exhaust its capacity for 672 creating state records. To defend against such attacks, a filter 673 needs to abandon unused state records after a sufficiently long 674 period of idleness. 676 A common method used for TCP filters in IPv4/NAT gateways is to 677 abandon preferentially flow state records for crashed endpoints, 678 followed by closed flows and partially-open flows. A gateway can 679 check if an endpoint for a session has crashed by sending a TCP keep- 680 alive packet on behalf of the other endpoint and receiving a TCP RST 681 packet in response. If the gateway cannot determine whether the 682 endpoint is active, then the associated state record needs to be 683 retained until the TCP flow has been idle for some time. Note: an 684 established TCP flow can stay idle (but live) indefinitely; hence, 685 there is no fixed value for an idle-timeout that accommodates all 686 applications. However, a large idle-timeout motivated by 687 recommendations in [RFC1122] and [RFC4294] can reduce the chances of 688 abandoning a live flow. 690 TCP flows can stay in the established phase indefinitely without 691 exchanging packets. Some end-hosts can be configured to send keep- 692 alive packets on such idle flows; by default, such packets are sent 693 every two hours, if enabled [RFC1122]. Consequently, a filter that 694 waits for slightly over two hours can detect idle flows with keep- 695 alive packets being sent at the default rate. TCP flows in the 696 partially-open or closing phases, on the other hand, can stay idle 697 for at most four minutes while waiting for in-flight packets to be 698 delivered [RFC1122]. 700 The "established flow idle-timeout" for a stateful packet filter is 701 defined as the minimum time a TCP flow in the established phase must 702 remain idle before the filter considers the associated state record a 703 candidate for collection. The "transitory flow idle-timeout" for a 704 filter is defined as the minimum time a TCP flow in the partially- 705 open or closing phases must remain idle before the filter considers 706 the associated state record a candidate for collection. TCP flows in 707 the TIME_WAIT state are not affected by the "transitory flow idle- 708 timeout" parameter. 710 REC-35: If a gateway cannot determine whether the endpoints of a TCP 711 flow are active, then it MAY abandon the state record if it has been 712 idle for some time. In such cases, the value of the "established 713 flow idle-timeout" MUST NOT be less than two hours four minutes, as 714 discussed in [RFC5382]. The value of the "transitory flow idle- 715 timeout" MUST NOT be less than four minutes. The value of the idle- 716 timeouts MAY be configurable by the network administrator. 718 Behavior for handing RST packets, or TCP flows in the TIME_WAIT state 719 is left unspecified. A gateway MAY hold state for a flow in 720 TIME_WAIT state to accommodate retransmissions of the last ACK. 721 However, since the TIME_WAIT state is commonly encountered by 722 interior endpoints properly closing the TCP flow, holding state for a 723 closed flow can limit the throughput of flows through a gateway with 724 limited resources. [RFC1337] discusses hazards associated with 725 TIME_WAIT assassination. 727 The handling of non-SYN packets for which there is no active state 728 record is left unspecified. Such packets can be received if the 729 gateway abandons a live flow, or abandons a flow in the TIME_WAIT 730 state before the four minute TIME_WAIT period expires. The decision 731 either to discard or to respond with an ICMPv6 "Destination 732 Unreachable" error code 1 (administratively prohibited) is left up to 733 the implementation. 735 Behavior for notifying endpoints when abandoning live flows is left 736 unspecified. When a gateway abandons a live flow, for example due to 737 a timeout expiring, the filter MAY send a TCP RST packet to each 738 endpoint on behalf of the other. Sending a RST notification allows 739 endpoint applications to recover more quickly, however, notifying 740 endpoints might not always be possible if, for example, state records 741 are lost due to power interruption. 743 Several TCP mechanisms depend on the reception of ICMPv6 error 744 messages triggered by the transmission of TCP segments. One such 745 mechanism is path MTU discovery, which is required for correct 746 operation of TCP. 748 REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6 749 "Destination Unreachable" and "Packet Too Big" messages containing 750 TCP headers that match the flow state record. 752 REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the 753 state record for a TCP flow. 755 3.3.2. SCTP Filters 757 Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows 758 can be terminated at multiple network addresses, IPv6 simple security 759 functions cannot achieve full transparency for SCTP applications. In 760 multipath traversal scenarios, full transparency requires 761 coordination between all the packet filter processes in the various 762 paths between the endpoint network addresses. Such coordination is 763 not "simple" and it is, therefore, beyond the scope of this 764 recommendation. 766 However, some SCTP applications are capable of tolerating the 767 inherent unipath restriction of IPv6 simple security, even in 768 multipath traversal scenarios. They expect similar connection- 769 oriented filtering behaviors as for TCP, but at the level of SCTP 770 associations, not stream connections. This section describes 771 specific recommendations for SCTP filtering for such traversal 772 scenarios. 774 An interior endpoint initiates SCTP associations through a stateful 775 packet filter by sending a packet comprising a single INIT chunk. 776 The filter allocates (or reuses) a filter state record for the 777 association. The state record defines the interior and exterior IP 778 addresses and the observed verification tag used for forwarding 779 packets in that association. 781 Peer-to-peer applications use an alternate method of association 782 initiation termed simultaneous-open to traverse stateful filters. In 783 the simultaneous-open mode of operation, both peers send INIT chunks 784 at the same time to establish an association. Upon receiving the 785 other end's INIT chunk, each end responds with an INIT-ACK packet, 786 which is expected to traverse the same path in reverse. Because only 787 one SCTP association may exist between any two network addresses, one 788 of the peers in simultaneous-open mode of operation will send an 789 ERROR or ABORT chunk along with the INIT-ACK chunk. The association 790 is established at each endpoint once an INIT-ACK chunks is received 791 at one end without an ERROR or ABORT chunk. 793 To provide stateful packet filtering service for SCTP, it is 794 necessary for a filter to receive, process and forward all packets 795 for an association that conform to valid transitions of the SCTP 796 state machine (Fig. 3, [RFC4960]). 798 REC-38: All valid sequences of SCTP packets (defined in [RFC4960]) 799 MUST be forwarded for outbound associations and explicitly permitted 800 inbound associations. In particular, both the normal SCTP 801 association establishment and simultaneous-open modes of operation 802 MUST be supported. 804 If an inbound INIT packet is filtered, either because a corresponding 805 state record does not exist or because of the filter's normal 806 behavior, a filter has two basic choices: to discard the packet 807 silently, or to signal an error to the sender. Signaling an error 808 through ICMPv6 messages allows the sender to detect that the INIT 809 packet did not reach the intended destination. Discarding the 810 packet, on the other hand, allows applications to perform 811 simultaneous-open more reliably. Delays in signaling errors can 812 prevent the impairment of simultaneous-open mode of operation. 814 REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6 815 "Destination Unreachable" error code 1 (administratively prohibited), 816 to any unsolicited inbound INIT packet after waiting at least 6 817 seconds without first forwarding the associated outbound INIT from 818 the interior peer. 820 An SCTP filter maintains state associated with in-progress and 821 established associations. Because of this, a filter is susceptible 822 to a resource-exhaustion attack whereby an attacker (or virus) on the 823 interior attempts to cause the filter to exhaust its capacity for 824 creating state records. To defend against such attacks, a filter 825 needs to abandon unused state records after a sufficiently long 826 period of idleness. 828 A common method used for TCP filters in IPv4/NAT gateways is to 829 abandon preferentially sessions for crashed endpoints, followed by 830 closed associations and partially opened associations. A similar 831 method is an option for SCTP filters in IPv6 gateways. A gateway can 832 check if an endpoint for an association has crashed by sending 833 HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the 834 gateway cannot determine whether the endpoint is active, then the 835 associated state records needs to be retained until the SCTP 836 association has been idle for some time. Note: an established SCTP 837 association can stay idle (but live) indefinitely, hence there is no 838 fixed value of an idle-timeout that accommodates all applications. 839 However, a large idle-timeout motivated by [RFC4294] can reduce the 840 chances of abandoning a live association. 842 SCTP associations can stay in the ESTABLISHED state indefinitely 843 without exchanging packets. Some end-hosts can be configured to send 844 HEARTBEAT chunks on such idle associations, but [RFC4960] does not 845 specify (or even suggest) a default time interval. A filter that 846 waits for slightly over two hours can detect idle associations with 847 HEARTBEAT packets being sent at the same rate as most hosts use for 848 TCP keep-alive, which is a reasonably similar system for this 849 purpose. SCTP associations in the partially-open or closing states, 850 on the other hand, can stay idle for at most four minutes while 851 waiting for in-flight packets to be delivered (assuming the suggested 852 SCTP protocol parameter values in Section 15 of [RFC4960]). 854 The "established association idle-timeout" for a stateful packet 855 filter is defined as the minimum time an SCTP association in the 856 established phase must remain idle before the filter considers the 857 corresponding state record a candidate for collection. The 858 "transitory association idle-timeout" for a filter is defined as the 859 minimum time an SCTP association in the partially-open or closing 860 phases must remain idle before the filter considers the corresponding 861 state record a candidate for collection. 863 REC-40: If a gateway cannot determine whether the endpoints of an 864 SCTP association are active, then it MAY abandon the state record if 865 it has been idle for some time. In such cases, the value of the 866 "established association idle-timeout" MUST NOT be less than two 867 hours four minutes. The value of the "transitory association idle- 868 timeout" MUST NOT be less than four minutes. The value of the idle- 869 timeouts MAY be configurable by the network administrator. 871 Behavior for handling ERROR and ABORT packets is left unspecified. A 872 gateway MAY hold state for an association after its closing phases 873 have completed to accommodate retransmissions of its final SHUTDOWN 874 ACK packets. However, holding state for a closed association can 875 limit the throughput of associations traversing a gateway with 876 limited resources. The discussion in [RFC1337] regarding the hazards 877 of TIME_WAIT assassination are relevant. 879 The handling of inbound non-INIT packets for which there is no active 880 state record is left unspecified. Such packets can be received if 881 the gateway abandons a live flow, or abandons an association in the 882 closing states before the transitory association idle-timeout 883 expires. The decision either to discard or to respond with an ICMPv6 884 "Destination Unreachable" error code 1 (administratively prohibited) 885 is left to the implementation. 887 Behavior for notifying endpoints when abandoning live associations is 888 left unspecified. When a gateway abandons a live association, for 889 example due to a timeout expiring, the filter MAY send an ABORT 890 packet to each endpoint on behalf of the other. Sending an ABORT 891 notification allows endpoint applications to recover more quickly, 892 however, notifying endpoints might not always be possible if, for 893 example, state records are lost due to power interruption. 895 Several SCTP mechanisms depend on the reception of ICMPv6 error 896 messages triggered by the transmission of SCTP packets. 898 REC-41: If a gateway forwards an SCTP association, it MUST also 899 forward ICMPv6 "Destination Unreachable" and "Packet Too Big" 900 messages containing SCTP headers that match the association state 901 record. 903 REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the 904 state record for an SCTP association. 906 3.3.3. DCCP Filters 908 The connection semantics described in Datagram Congestion Control 909 Protocol (DCCP) [RFC4340] are very similar to those of TCP. An 910 interior endpoint initiates a DCCP flow through a stateful packet 911 filter by sending a DCCP-Request packet. Simultaneous open is not 912 defined for DCCP. 914 In order to provide stateful packet filtering service for DCCP, it is 915 necessary for a filter to receive, process and forward all packets 916 for a flow that conform to valid transitions of the DCCP state 917 machine (Section 8, [RFC4340]). 919 REC-43: All valid sequences of DCCP packets (defined in [RFC4340]) 920 MUST be forwarded for all flows to exterior servers and those flows 921 to interior servers with explicitly permitted service codes. 923 It is possible to reconstruct enough of the state of a DCCP flow to 924 allow forwarding between an interior and exterior node even when the 925 filter starts operating after DCCP enters the OPEN state. Also, a 926 filter can allow an existing state record to be reused by an 927 externally initiated flow if its security policy permits. As with 928 TCP, several different policies are possible, with a good discussion 929 of the issue involved presented in [RFC4787] and extended in 930 [RFC5382]. 932 If an inbound DCCP-Request packet is filtered, either because a 933 corresponding state record does not already exist for it or because 934 of the filter's normal behavior of refusing flows not explicitly 935 permitted, then a filter has two basic choices: to discard the packet 936 silently, or to signal an error to the sender. Signaling an error 937 through ICMPv6 messages allows the sender to detect that the DCCP- 938 Request did not reach the intended destination. Discarding the 939 packet, on the other hand, only delays the failure to connect and 940 provides no measurable security. 942 A DCCP filter maintains state associated with in-progress connections 943 and established flows. Because of this, a filter is susceptible to a 944 resource-exhaustion attack whereby an attacker (or virus) on the 945 interior attempts to cause the filter to exhaust its capacity for 946 creating state records. To prevent such an attack, a filter needs to 947 abandon unused state records after a sufficiently long period of 948 idleness. 950 A common method used for TCP filters in IPv4/NAT gateways is to 951 abandon preferentially sessions for crashed endpoints, followed by 952 closed TCP flows and partially-open flows. No such method exists for 953 DCCP, and flows can stay in the OPEN phase indefinitely without 954 exchanging packets. Hence, there is no fixed value for an idle- 955 timeout that accommodates all applications. However, a large idle- 956 timeout motivated by [RFC4294] can reduce the chances of abandoning a 957 live flow. 959 DCCP flows in the partially-open or closing phases can stay idle for 960 at most eight minutes while waiting for in-flight packets to be 961 delivered. 963 The "open flow idle-timeout" for a stateful packet filter is defined 964 as the minimum time a DCCP flow in the open state must remain idle 965 before the filter considers the associated state record a candidate 966 for collection. The "transitory flow idle-timeout" for a filter is 967 defined as the minimum time a DCCP flow in the partially-open or 968 closing phases must remain idle before the filter considers the 969 associated state record a candidate for collection. DCCP flows in 970 the TIMEWAIT state are not affected by the "transitory flow idle- 971 timeout" parameter. 973 REC-44: A gateway MAY abandon a DCCP state record if it has been idle 974 for some time. In such cases, the value of the "established flow 975 idle-timeout" MUST NOT be less than two hours four minutes. The 976 value of the "transitory flow idle-timeout" MUST NOT be less than 977 eight minutes. The value of the idle-timeouts MAY be configurable by 978 the network administrator. 980 Behavior for handing DCCP-Reset packets, or flows in the TIMEWAIT 981 state is left unspecified. A gateway MAY hold state for a flow in 982 TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset. 983 However, since the TIMEWAIT state is commonly encountered by interior 984 endpoints properly closing the DCCP flow, holding state for a closed 985 flow can limit the throughput of flows through a gateway with limited 986 resources. [RFC1337] discusses hazards associated with TIME_WAIT 987 assassination in TCP, and similar hazards exists for DCCP. 989 The handling of non-SYN packets for which there is no active state 990 record is left unspecified. Such packets can be received if the 991 gateway abandons a live flow, or abandons a flow in the TIMEWAIT 992 state before the four minute 2MSL period expires. The decision 993 either to discard or to respond with an ICMPv6 "Destination 994 Unreachable" error code 1 (administratively prohibited) is left up to 995 the implementation. 997 Behavior for notifying endpoints when abandoning live flows is left 998 unspecified. When a gateway abandons a live flow, for example due to 999 a timeout expiring, the filter MAY send a DCCP-Reset packet to each 1000 endpoint on behalf of the other. Sending a DCCP-Reset notification 1001 allows endpoint applications to recover more quickly, however, 1002 notifying endpoints might not always be possible if, for example, 1003 state records are lost due to power interruption. 1005 Several DCCP mechanisms depend on the reception of ICMPv6 error 1006 messages triggered by the transmission of DCCP packets. One such 1007 mechanism is path MTU discovery, which is required for correct 1008 operation. 1010 REC-45: If an Internet gateway forwards a DCCP flow, it MUST also 1011 forward ICMPv6 "Destination Unreachable" and "Packet Too Big" 1012 messages containing DCCP headers that match the flow state record. 1014 REC-46: Receipt of any sort of ICMPv6 message MUST NOT terminate the 1015 state record for a DCCP flow. 1017 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) 1019 While IPv6 simple security is applicable to residential networks with 1020 only one Internet service provider at a time, the use of Level 3 1021 Multihoming Shim Protocol for IPv6 (SHIM6) [RFC5533] is necessary for 1022 communications with some multihomed exterior destinations. No 1023 special recommendations are made in this document for processing the 1024 SHIM6 message format (protocol 140) beyond the recommendations in 1025 Section 3.2.2. The content of the SHIM6 payload extension header may 1026 be ignored. 1028 REC-47: Valid sequences of packets bearing SHIM6 payload extension 1029 headers in their outer IP extension header chains MUST be forwarded 1030 for all outbound and explicitly permitted flows. The content of the 1031 SHIM6 payload extension header MAY be ignored for the purpose of 1032 state tracking. 1034 3.4. Passive Listeners 1036 Some applications expect to solicit traffic from exterior nodes 1037 without advance knowledge of the exterior addresses of their peers. 1038 This requirement is met by IPv4/NAT gateways typically by the use of 1039 either [I-D.cheshire-nat-pmp] or [UPnP-IGD]. On IPv4/NAT networks 1040 connected by gateways without such services, applications must use 1041 techniques like Session Traversal Utilities for NAT (STUN) [RFC5389] 1042 to obtain and maintain connectivity, despite the translation and 1043 filtering effects of NAT. 1045 While NAT for IPv6 is unlikely to be used in most residential 1046 gateways, the filtering effect of the simple security functions 1047 recommended by this document are derived from those in widespread use 1048 on the IPv4 Internet, and a similar barrier to communication at 1049 passive listeners is a natural outcome of its deployment. To avoid 1050 the need for IPv6 applications to use techniques like STUN for 1051 opening and maintaining dynamic filter state, something similar to 1052 NAT-PMP and UPnP-IGD but without actually supporting NAT could be 1053 deployed. Alas, no consensus has yet emerged in the Internet 1054 engineering community as to what is most appropriate for residential 1055 IPv6 usage scenarios. 1057 One proposal that has been offered as an Internet Draft is the 1058 Application Listener Discovery Protocol [I-D.woodyatt-ald]. It 1059 remains to be seen whether the Internet Gateway Device profile of the 1060 Universal Plug And Play protocol will be extended for IPv6. Other 1061 proposals of note include the Middlebox Communication Protocol 1062 [RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until 1063 a consensus emerges around a specific method, the following 1064 recommendations are the best guidance available. 1066 REC-48: Internet gateways with IPv6 simple security capabilities 1067 SHOULD implement a protocol to permit applications to solicit inbound 1068 traffic without advance knowledge of the addresses of exterior nodes 1069 with which they expect to communicate. 1071 REC-49: Internet gateways with IPv6 simple security capabilities MUST 1072 provide an easily selected configuration option that permits a 1073 "transparent mode" of operation that forwards all unsolicited flows 1074 regardless of forwarding direction, i.e. not to use the IPv6 simple 1075 security capabilities of the gateway. The transparent mode of 1076 operation MAY be the default configuration. 1078 In general, "transparent mode" will enable more flexibility and 1079 reliability for applications which require devices to be contacted 1080 inside the home directly, particularly in absence of a protocol as 1081 described in REC-48. Operating in transparent mode may come at the 1082 expense of security if there are IPv6 nodes in the home that do not 1083 have their own host-based firewall capability and require a firewall 1084 in the gateway in order not to be compromised. 1086 3.5. Management Applications 1088 Subscriber managed residential gateways are unlikely ever to be 1089 completely zero-configuration, but their administrators will very 1090 often possess no particular expertise in Internet engineering. In 1091 general, the specification of management interfaces for residential 1092 gateways is out of scope for this document, but security of 1093 subscriber managed gateways merit special attention here. 1095 REC-50: By DEFAULT, subscriber managed residential gateways MUST NOT 1096 offer management application services to the exterior network. 1098 4. Summary of Recommendations 1100 This section collects all of the recommendations made in this 1101 document into a convenient list. 1103 REC-1 Packets bearing in their outer IPv6 headers multicast source 1104 addresses MUST NOT be forwarded or transmitted on any 1105 interface. 1107 REC-2 Packets which bear in their outer IPv6 headers multicast 1108 destination addresses of equal or narrower scope (see IPv6 1109 Scoped Address Architecture [RFC4007]) than the configured 1110 scope boundary level of the gateway MUST NOT be forwarded in 1111 any direction. The DEFAULT scope boundary level SHOULD be 1112 organization-local scope, and it SHOULD be configurable by 1113 the network administrator. 1115 REC-3 Packets bearing source and/or destination addresses forbidden 1116 to appear in the outer headers of packets transmitted over 1117 the public Internet MUST NOT be forwarded. In particular, 1118 site-local addresses are deprecated by [RFC3879], and 1119 [RFC5156] explicitly forbids the use of addresses with IPv4- 1120 Mapped, IPv4-Compatible, Documentation and ORCHID prefixes. 1122 REC-4 Packets bearing deprecated extension headers prior to their 1123 first upper-layer-protocol header SHOULD NOT be forwarded or 1124 transmitted on any interface. In particular, all packets 1125 with routing extension header type 0 [RFC2460] preceding the 1126 first upper-layer-protocol header MUST NOT be forwarded. 1127 (See [RFC5095] for additional background.) 1129 REC-5 Outbound packets MUST NOT be forwarded if the source address 1130 in their outer IPv6 header does not have a unicast prefix 1131 assigned for use by globally reachable nodes on the interior 1132 network. 1134 REC-6 Inbound packets MUST NOT be forwarded if the source address 1135 in their outer IPv6 header has a global unicast prefix 1136 assigned for use by globally reachable nodes on the interior 1137 network. 1139 REC-7 By DEFAULT, packets with unique local source and/or 1140 destination addresses [RFC4193] SHOULD NOT be forwarded to or 1141 from the exterior network. 1143 REC-8 By DEFAULT, inbound DNS queries received on exterior 1144 interfaces MUST NOT be processed by any integrated DNS 1145 resolving server. 1147 REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on 1148 exterior interfaces MUST NOT be processed by any integrated 1149 DHCPv6 server or relay agent. 1151 REC-10 IPv6 gateways MUST forward ICMPv6 "Destination Unreachable" 1152 and "Packet Too Big" messages containing IP headers that 1153 match generic upper-layer transport state records. 1155 REC-11 If application transparency is most important, then a 1156 stateful packet filter SHOULD have "endpoint independent 1157 filter" behavior for generic upper-layer transport protocols. 1158 If a more stringent filtering behavior is most important, 1159 then a filter SHOULD have "address dependent filtering" 1160 behavior. The filtering behavior MAY be an option 1161 configurable by the network administrator, and it MAY be 1162 independent of the filtering behavior for other protocols. 1163 Filtering behavior SHOULD be endpoint independent by DEFAULT 1164 in gateways intended for provisioning without service- 1165 provider management. 1167 REC-12 Filter state records for generic upper-layer transport 1168 protocols MUST NOT be deleted or recycled until an idle timer 1169 not less than two minutes has expired without having 1170 forwarded a packet matching the state in some configurable 1171 amount of time. By DEFAULT, the idle timer for such state 1172 records is five minutes. 1174 REC-13 Residential IPv6 gateways SHOULD provide a convenient means 1175 to update their firmware securely, for the installation of 1176 security patches and other manufacturer-recommended changes. 1178 REC-14 A state record for a UDP flow where both source and 1179 destination ports are outside the well-known port range 1180 (ports 0-1023) MUST NOT expire in less than two minutes of 1181 idle time. The value of the UDP state record idle timer MAY 1182 be configurable. The DEFAULT is five minutes. 1184 REC-15 A state record for a UDP flow where one or both of the source 1185 and destination ports are in the well-known port range (ports 1186 0-1023) MAY expire after a period of idle time shorter than 1187 two minutes to facilitate the operation of the IANA- 1188 registered service assigned to the port in question. 1190 REC-16 A state record for a UDP flow MUST be refreshed when a packet 1191 is forwarded from the interior to the exterior, and it MAY be 1192 refreshed when a packet is forwarded in the reverse 1193 direction. 1195 REC-17 If application transparency is most important, then a 1196 stateful packet filter SHOULD have "endpoint independent 1197 filter" behavior for UDP. If a more stringent filtering 1198 behavior is most important, then a filter SHOULD have 1199 "address dependent filtering" behavior. The filtering 1200 behavior MAY be an option configurable by the network 1201 administrator, and it MAY be independent of the filtering 1202 behavior for TCP and other protocols. Filtering behavior 1203 SHOULD be endpoint independent by DEFAULT in gateways 1204 intended for provisioning without service-provider 1205 management. 1207 REC-18 If a gateway forwards a UDP flow, it MUST also forward ICMPv6 1208 "Destination Unreachable" and "Packet Too Big" messages 1209 containing UDP headers that match the flow state record. 1211 REC-19 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1212 state record for a UDP flow. 1214 REC-20 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as 1215 UDP flows, except that the upper-layer transport protocol 1216 identifier for UDP-Lite is not the same as UDP, and therefore 1217 UDP packets MUST NOT match UDP-Lite state records, and vice 1218 versa. 1220 REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1221 prohibit the forwarding of packets, to and from legitimate 1222 node addresses, with destination extension headers of type 1223 "Authenticated Header (AH)" [RFC4302] in their outer IP 1224 extension header chain. 1226 REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1227 prohibit the forwarding of packets, to and from legitimate 1228 node addresses, with an upper layer protocol of type 1229 "Encapsulating Security Payload (ESP)" [RFC4303] in their 1230 outer IP extension header chain. 1232 REC-23 If a gateway forwards an ESP flow, it MUST also forward (in 1233 the reverse direction) ICMPv6 "Destination Unreachable" and 1234 "Packet Too Big" messages containing ESP headers that match 1235 the flow state record. 1237 REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1238 prohibit the forwarding of any UDP packets, to and from 1239 legitimate node addresses, with a destination port of 500, 1240 i.e. the port reserved by IANA for the Internet Key Exchange 1241 Protocol [RFC5996]. 1243 REC-25 In all operating modes, IPv6 gateways SHOULD use filter state 1244 records for Encapsulating Security Payload (ESP) [RFC4303] 1245 that are indexable by a 3-tuple comprising the interior node 1246 address, the exterior node address and the ESP protocol 1247 identifier. In particular, the IPv4/NAT method of indexing 1248 state records also by security parameters index (SPI) SHOULD 1249 NOT be used. Likewise, any mechanism that depends on 1250 detection of Internet Key Exchange (IKE) [RFC5996] 1251 initiations SHOULD NOT be used. 1253 REC-26 In their DEFAULT operating mode, IPv6 gateways MUST NOT 1254 prohibit the forwarding of packets, to and from legitimate 1255 node addresses, with destination extension headers of type 1256 "Host Identity Protocol (HIP)" [RFC5201] in their outer IP 1257 extension header chain. 1259 REC-27 The state records for flows initiated by outbound packets 1260 that bear a Home Address destination option [RFC3775] are 1261 distinguished by the addition of the home address of the flow 1262 as well as the interior care-of address. IPv6 gateways MUST 1263 NOT prohibit the forwarding of any inbound packets bearing 1264 type 2 routing headers, which otherwise match a flow state 1265 record, and where A) the address in the destination field of 1266 the IPv6 header matches the interior care-of address of the 1267 flow, and B) the Home Address field in the Type 2 Routing 1268 Header matches the home address of the flow. 1270 REC-28 Valid sequences of Mobility Header [RFC3775] packets MUST be 1271 forwarded for all outbound and explicitly permitted inbound 1272 Mobility Header flows. 1274 REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then 1275 it MUST also forward, in both directions, the IPv4 and IPv6 1276 packets that are encapsulated in IPv6 associated with the 1277 tunnel between the home agent and the correspondent node. 1279 REC-30 If a gateway forwards a Mobility Header [RFC3775] flow, then 1280 it MUST also forward (in the reverse direction) ICMPv6 1281 "Destination Unreachable" and "Packet Too Big" messages 1282 containing any headers that match the associated flow state 1283 records. 1285 REC-31 All valid sequences of TCP packets (defined in [RFC0793]) 1286 MUST be forwarded for outbound flows and explicitly permitted 1287 inbound flows. In particular, both the normal TCP 3-way 1288 handshake mode of operation and the simultaneous-open modes 1289 of operation MUST be supported. 1291 REC-32 The TCP window invariant MUST NOT be enforced on flows for 1292 which the filter did not detect whether the window-scale 1293 option (see [RFC1323]) was sent in the 3-way handshake or 1294 simultaneous open. 1296 REC-33 If application transparency is most important, then a 1297 stateful packet filter SHOULD have "endpoint independent 1298 filter" behavior for TCP. If a more stringent filtering 1299 behavior is most important, then a filter SHOULD have 1300 "address dependent filtering" behavior. The filtering 1301 behavior MAY be an option configurable by the network 1302 administrator, and it MAY be independent of the filtering 1303 behavior for UDP and other protocols. Filtering behavior 1304 SHOULD be endpoint independent by DEFAULT in gateways 1305 intended for provisioning without service-provider 1306 management. 1308 REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 1309 "Destination Unreachable" error code 1 (administratively 1310 prohibited) to any unsolicited inbound SYN packet after 1311 waiting at least 6 seconds without first forwarding the 1312 associated outbound SYN or SYN/ACK from the interior peer. 1314 REC-35 If a gateway cannot determine whether the endpoints of a TCP 1315 flow are active, then it MAY abandon the state record if it 1316 has been idle for some time. In such cases, the value of the 1317 "established flow idle-timeout" MUST NOT be less than two 1318 hours four minutes, as discussed in [RFC5382]. The value of 1319 the "transitory flow idle-timeout" MUST NOT be less than four 1320 minutes. The value of the idle-timeouts MAY be configurable 1321 by the network administrator. 1323 REC-36 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 1324 "Destination Unreachable" and "Packet Too Big" messages 1325 containing TCP headers that match the flow state record. 1327 REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1328 state record for a TCP flow. 1330 REC-38 All valid sequences of SCTP packets (defined in [RFC4960]) 1331 MUST be forwarded for outbound associations and explicitly 1332 permitted inbound associations. In particular, both the 1333 normal SCTP association establishment and simultaneous-open 1334 modes of operation MUST be supported. 1336 REC-39 By DEFAULT, a gateway MUST respond with an ICMPv6 1337 "Destination Unreachable" error code 1 (administratively 1338 prohibited) to any unsolicited inbound INIT packet after 1339 waiting at least 6 seconds without first forwarding the 1340 associated outbound INIT from the interior peer. 1342 REC-40 If a gateway cannot determine whether the endpoints of an 1343 SCTP association are active, then it MAY abandon the state 1344 record if it has been idle for some time. In such cases, the 1345 value of the "established association idle-timeout" MUST NOT 1346 be less than two hours four minutes. The value of the 1347 "transitory association idle-timeout" MUST NOT be less than 1348 four minutes. The value of the idle-timeouts MAY be 1349 configurable by the network administrator. 1351 REC-41 If a gateway forwards an SCTP association, it MUST also 1352 forward ICMPv6 "Destination Unreachable" and "Packet Too Big" 1353 messages containing SCTP headers that match the association 1354 state record. 1356 REC-42 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1357 state record for an SCTP association. 1359 REC-43 All valid sequences of DCCP packets (defined in [RFC4340]) 1360 MUST be forwarded for all flows to exterior servers and those 1361 flows to interior servers with explicitly permitted service 1362 codes. 1364 REC-44 A gateway MAY abandon a DCCP state record if it has been idle 1365 for some time. In such cases, the value of the "established 1366 flow idle-timeout" MUST NOT be less than two hours four 1367 minutes. The value of the "transitory flow idle-timeout" 1368 MUST NOT be less than eight minutes. The value of the idle- 1369 timeouts MAY be configurable by the network administrator. 1371 REC-45 If a gateway forwards a DCCP flow, it MUST also forward 1372 ICMPv6 "Destination Unreachable" and "Packet Too Big" 1373 messages containing DCCP headers that match the flow state 1374 record. 1376 REC-46 Receipt of any sort of ICMPv6 message MUST NOT terminate the 1377 state record for a DCCP flow. 1379 REC-47 Valid sequences of packets bearing SHIM6 payload extension 1380 headers in their outer IP extension header chains MUST be 1381 forwarded for all outbound and explicitly permitted flows. 1382 The content of the SHIM6 payload extension header MAY be 1383 ignored for the purpose of state tracking. 1385 REC-48 Gateways SHOULD implement a protocol to permit applications 1386 to solicit inbound traffic without advance knowledge of the 1387 addresses of exterior nodes with which they expect to 1388 communicate. 1390 REC-49 Gateways MUST provide an easily selected configuration option 1391 that permits a "transparent mode" of operation that forwards 1392 all unsolicited flows regardless of forwarding direction, 1393 i.e. to disable the IPv6 simple security capabilities of the 1394 gateway. The transparent mode of operation MAY be the 1395 default configuration. 1397 REC-50 By DEFAULT, subscriber managed residential gateways MUST NOT 1398 offer management application services to the exterior 1399 network. 1401 5. Contributors 1403 Comments and criticisms during the development of this document were 1404 received from the following IETF participants: 1406 +-------------------+----------------------------+ 1407 | Jari Arkko | Ran Atkinson | 1408 | Fred Baker | Norbert Bollow | 1409 | Cameron Byrne | Brian Carpenter | 1410 | Remi Despres | Arnaud Ebalard | 1411 | Fabrice Fontaine | Jun-ichiro "itojun" Hagino | 1412 | Thomas Herbst | Christian Huitema | 1413 | Joel Jaeggli | Cullen Jennings | 1414 | Suresh Krishnan | Erik Kline | 1415 | Julien Laganier | Kurt Erik Lindqvist | 1416 | Boucadair Mohamed | Keith Moore | 1417 | Robert Moskowitz | Teemu Savolainen | 1418 | Hemant Singh | Yaron Sheffer | 1419 | Mark Townsley | Iljitsch van Beijnum | 1420 | Magnus Westerlund | Dan Wing | 1421 +-------------------+----------------------------+ 1423 The editor thanks them all for their contributions. 1425 It must be noted that a substantial portion of the text describing 1426 the detailed requirements for TCP and UDP filtering is derived or 1427 transposed from [RFC4787] and [RFC5382]. The editors of those 1428 documents, Francois Audet and Saikat Guha, also deserve substantial 1429 credit for the form of the present document. 1431 6. IANA Considerations 1433 This memo includes no request to IANA. 1435 7. Security Considerations 1437 The IPv6 stateful filtering behavior described in this document is 1438 intended to be similar in function to the filtering behavior of 1439 commonly use IPv4/NAT gateways, which have been widely sold as a 1440 security tool for residential and small-office/home-office networks. 1441 As noted in the security considerations section of [RFC2993], the 1442 true impact of these tools may be a reduction in security. It may be 1443 generally assumed that the impacts discussed in that document related 1444 to filtering (and not translation) are to be expected with the simple 1445 IPv6 security mechanisms described here. 1447 In particular, it is worth noting that stateful filters create the 1448 illusion of a security barrier, but without the managed intent of a 1449 firewall. Appropriate security mechanisms implemented in the end 1450 nodes, in conjunction with the [RFC4864] local network protection 1451 methods, function without reliance on network layer hacks and 1452 transport filters that may change over time. Also, defined security 1453 barriers assume that threats originate in the exterior, which may 1454 lead to practices that result in applications being fully exposed to 1455 interior attack and which therefore make breaches much easier. 1457 The security functions described in this document may be considered 1458 redundant in the event that all IPv6 hosts using a particular gateway 1459 have their own IPv6 host firewall capabilities enabled. At the time 1460 of this writing, the vast majority of commercially available 1461 operating systems with support for IPv6 include IPv6 host firewall 1462 capability. 1464 Also worth noting explicitly, a practical side-effect of the 1465 recommendations in Section 3.2.4, to allow inbound IPsec and IKE 1466 flows from exterior to interior, is to facilitate more transparent 1467 communication by the use of Better-Than-Nothing-Security: An 1468 Unauthenticated Mode of IPsec [RFC5386], and this may be a departure 1469 from expectations of transparency set by traditional IPv4/NAT 1470 residential gateways. 1472 Finally, residential gateways that implement simple security 1473 functions are a bastion between the interior and the exterior, and 1474 therefore are a target of denial of service attacks against the 1475 interior network itself by processes designed to consume the 1476 resources of the gateway, e.g. a ping or SYN flood. Gateways should 1477 employ the same sorts of protection techniques as application servers 1478 on the Internet. 1480 IETF makes no statement, expressed or implied, as to whether using 1481 the capabilities described in this document ultimately improve 1482 security for any individual users or for the Internet community as a 1483 whole. 1485 8. References 1487 8.1. Normative References 1489 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1490 August 1980. 1492 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1493 RFC 793, September 1981. 1495 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1496 for High Performance", RFC 1323, May 1992. 1498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1499 Requirement Levels", BCP 14, RFC 2119, March 1997. 1501 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1502 (IPv6) Specification", RFC 2460, December 1998. 1504 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1505 and M. Carney, "Dynamic Host Configuration Protocol for 1506 IPv6 (DHCPv6)", RFC 3315, July 2003. 1508 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1509 in IPv6", RFC 3775, June 2004. 1511 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1512 G. Fairhurst, "The Lightweight User Datagram Protocol 1513 (UDP-Lite)", RFC 3828, July 2004. 1515 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1516 Addresses", RFC 3879, September 2004. 1518 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1519 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1520 March 2005. 1522 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1523 Addresses", RFC 4193, October 2005. 1525 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1526 December 2005. 1528 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1529 RFC 4303, December 2005. 1531 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1532 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1534 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1535 Message Protocol (ICMPv6) for the Internet Protocol 1536 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1538 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1539 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1540 RFC 4787, January 2007. 1542 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1543 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1545 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1546 RFC 4960, September 2007. 1548 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1549 of Type 0 Routing Headers in IPv6", RFC 5095, 1550 December 2007. 1552 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 1553 April 2008. 1555 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1556 "Host Identity Protocol", RFC 5201, April 2008. 1558 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1559 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1560 RFC 5996, September 2010. 1562 8.2. Informative References 1564 [I-D.cheshire-nat-pmp] 1565 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1566 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1568 [I-D.woodyatt-ald] 1569 Woodyatt, J., "Application Listener Discovery (ALD) for 1570 IPv6", draft-woodyatt-ald-03 (work in progress), 1571 July 2008. 1573 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1574 Communication Layers", STD 3, RFC 1122, October 1989. 1576 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 1577 RFC 1337, May 1992. 1579 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1580 E. Lear, "Address Allocation for Private Internets", 1581 BCP 5, RFC 1918, February 1996. 1583 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1584 IPv6 Specification", RFC 2473, December 1998. 1586 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1587 Defeating Denial of Service Attacks which employ IP Source 1588 Address Spoofing", BCP 38, RFC 2827, May 2000. 1590 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1591 November 2000. 1593 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1594 Networks", BCP 84, RFC 3704, March 2004. 1596 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1597 Bosch, "Next Steps in Signaling (NSIS): Framework", 1598 RFC 4080, June 2005. 1600 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 1601 April 2006. 1603 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1604 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1605 May 2007. 1607 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1608 RFC 4949, August 2007. 1610 [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 1611 Communication (MIDCOM) Protocol Semantics", RFC 5189, 1612 March 2008. 1614 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1615 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1616 RFC 5382, October 2008. 1618 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 1619 Security: An Unauthenticated Mode of IPsec", RFC 5386, 1620 November 2008. 1622 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1623 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1624 October 2008. 1626 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1627 Shim Protocol for IPv6", RFC 5533, June 2009. 1629 [UPnP-IGD] 1630 UPnP Forum, "Universal Plug and Play Internet Gateway 1631 Device Standardized Gateway Device Protocol", 1632 September 2010, . 1634 Author's Address 1636 james woodyatt (editor) 1637 Apple Inc. 1638 1 Infinite Loop 1639 Cupertino, CA 95014 1640 US 1642 Email: jhw@apple.com