GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6092

Internet Engineering Task Force (IETF) J. Woodyatt, Ed. Request for Comments: 6092 Apple Category: Informational January 2011 ISSN: 2070-1721

            Recommended Simple Security Capabilities in
               Customer Premises Equipment (CPE) for
            Providing Residential IPv6 Internet Service

Abstract

 This document identifies a set of recommendations for the makers of
 devices and describes how to provide for "simple security"
 capabilities at the perimeter of local-area IPv6 networks in
 Internet-enabled homes and small offices.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6092.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Woodyatt Informational [Page 1] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Table of Contents

 1. Introduction ....................................................3
    1.1. Special Language ...........................................3
    1.2. Use of Normative Keywords ..................................3
 2. Overview ........................................................4
    2.1. Basic Sanitation ...........................................5
    2.2. Internet Layer Protocols ...................................5
    2.3. Transport Layer Protocols ..................................6
 3. Detailed Recommendations ........................................6
    3.1. Stateless Filters ..........................................7
    3.2. Connection-Free Filters ....................................8
         3.2.1. Internet Control and Management .....................8
         3.2.2. Upper-Layer Transport Protocols .....................8
         3.2.3. UDP Filters ........................................10
         3.2.4. IPsec and Internet Key Exchange (IKE) ..............11
         3.2.5. Mobility Support in IPv6 ...........................12
    3.3. Connection-Oriented Filters ...............................13
         3.3.1. TCP Filters ........................................14
         3.3.2. SCTP Filters .......................................17
         3.3.3. DCCP Filters .......................................20
         3.3.4. Level 3 Multihoming Shim Protocol for IPv6
                (Shim6) ............................................23
    3.4. Passive Listeners .........................................23
    3.5. Management Applications ...................................24
 4. Summary of Recommendations .....................................25
 5. Contributors ...................................................31
 6. Security Considerations ........................................32
 7. References .....................................................33
    7.1. Normative References ......................................33
    7.2. Informative References ....................................35

Woodyatt Informational [Page 2] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

1. Introduction

 Some IPv6 gateway devices that enable delivery of Internet services
 in residential and small-office settings may be augmented with
 "simple security" capabilities as described in "Local Network
 Protection for IPv6" [RFC4864].  In general, these capabilities cause
 packets to be discarded in an attempt to make local networks and the
 Internet more secure.  However, it is worth noting that some packets
 sent by legitimate applications may also be discarded in this
 process, affecting reliability and ease of use for these
 applications.
 There is a constructive tension between the desires of users for
 transparent end-to-end connectivity on the one hand, and the need for
 local-area network administrators to detect and prevent intrusion by
 unauthorized public Internet users on the other.  This document is
 intended to highlight reasonable limitations on end-to-end
 transparency where security considerations are deemed important to
 promote local and Internet security.
 The reader is cautioned always to remember that the typical
 residential or small-office network administrator has no expertise
 whatsoever in Internet engineering.  Configuration interfaces for
 router/gateway appliances marketed toward them should be easy to
 understand and even easier to ignore.  In particular, extra care
 should be used in the design of baseline operating modes for
 unconfigured devices, since most devices will never be changed from
 their factory configurations.

1.1. Special Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].
 Additionally, the key word "DEFAULT" is to be interpreted in this
 document as pertaining to a configuration as applied by a vendor,
 prior to the administrator changing it for its initial activation.

1.2. Use of Normative Keywords

    NOTE WELL: This document is not a standard, and conformance with
    it is not required in order to claim conformance with IETF
    standards for IPv6.  It uses the normative keywords defined in the
    previous section only for precision.
 Particular attention is drawn to recommendation REC-49, which calls
 for an easy way to set a gateway to a transparent mode of operation.

Woodyatt Informational [Page 3] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

2. Overview

 For the purposes of this document, residential Internet gateways are
 assumed to be fairly simple devices with a limited subset of the full
 range of possible features.  They function as default routers
 [RFC4294] for a single local-area network, e.g., an Ethernet network,
 a Wi-Fi network, or a bridge between two or more such segments.  They
 have only one interface by which they can access the Internet service
 at any one time, using any of several possible sub-IP mechanisms,
 including tunnels and transition mechanisms.
 In referring to the security capabilities of residential gateways, it
 is reasonable to distinguish between their "interior" network, i.e.,
 the local-area network, and their "exterior" networks, e.g., the
 public Internet and the networks of Internet service providers.  This
 document is concerned only with the behavior of IP packet filters
 that police the flow of traffic between the interior IPv6 network and
 the exterior IPv6 networks of residential Internet gateways.
 The operational goals of security capabilities in Internet gateways
 are described with more detail in "Local Network Protection for IPv6"
 [RFC4864], but they can be summarized as follows.
 o  Check all traffic to and from the public Internet for basic
    sanity, e.g., filter for spoofs and misdirected (sometimes called
    "Martian") packets [RFC4949].
 o  Allow tracking of application usage by source and destination
    network addresses and ports.
 o  Provide a barrier against untrusted external influences on the
    interior network by requiring filter state to be activated by
    traffic originating at interior network nodes.
 o  Allow manually configured exceptions to the stateful filtering
    rules according to network administrative policy.
 o  Isolate local network DHCPv6 and DNS resolver services from the
    public Internet.
 Prior to the widespread availability of IPv6 Internet service, homes
 and small offices often used private IPv4 network address realms
 [RFC1918] with Network Address Translation (NAT) functions deployed
 to present all the hosts on the interior network as a single host to

Woodyatt Informational [Page 4] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 the Internet service provider.  The stateful packet filtering
 behavior of NAT set user expectations that persist today with
 residential IPv6 service.  "Local Network Protection for IPv6"
 [RFC4864] recommends applying stateful packet filtering at
 residential IPv6 gateways that conforms to the user expectations
 already in place.
 Conventional stateful packet filters activate new states as a side
 effect of forwarding outbound flow initiations from interior network
 nodes.  This requires applications to have advance knowledge of the
 addresses of exterior nodes with which they expect to communicate.
 Several proposals are currently under consideration for allowing
 applications to solicit inbound traffic from exterior nodes without
 advance knowledge of their addresses.  While consensus within the
 Internet engineering community has emerged that such protocols are
 necessary to implement in residential IPv6 gateways, the best current
 practice has not yet been established.

2.1. Basic Sanitation

 In addition to the functions required of all IPv6 routers [RFC4294],
 residential gateways are expected to have basic stateless filters for
 prohibiting certain kinds of traffic with invalid headers, e.g.,
 "Martian" packets, spoofs, routing header type code zero, etc.  (See
 Section 3.1 for more details.)
 Conversely, simple Internet gateways are not expected to prohibit the
 development of new applications.  In particular, packets with end-to-
 end network security and routing extension headers for mobility are
 expected to pass Internet gateways freely.
 Finally, Internet gateways that route multicast traffic are expected
 to implement appropriate filters for multicast traffic to limit the
 scope of multicast groups that span the demarcation between
 residential networks and service provider networks.

2.2. Internet Layer Protocols

 As virtual private networking tunnels are regarded as an unacceptably
 wide attack surface, this document recommends that the DEFAULT
 operating mode for residential IPv6 simple security be to treat
 Generic Packet Tunneling [RFC2473] and similar protocols as opaque
 transport layers, i.e., inbound tunnel initiations are denied and
 outbound tunnel initiations are accepted.
 IPsec transport and tunnel modes are explicitly secured by
 definition, so this document recommends that the DEFAULT operating
 mode permit IPsec.  To facilitate the use of IPsec in support of IPv6

Woodyatt Informational [Page 5] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 mobility, the Internet Key Exchange (IKE) protocol [RFC5996] and the
 Host Identity Protocol (HIP) [RFC5201] should also be permitted in
 the DEFAULT operating mode.

2.3. Transport Layer Protocols

 IPv6 simple security functions are principally concerned with the
 stateful filtering of the Internet Control Message Protocol (ICMPv6)
 [RFC4443] and transport layers like the User Datagram Protocol (UDP)
 [RFC0768], the Lightweight User Datagram Protocol (UDP-Lite)
 [RFC3828], the Transmission Control Protocol (TCP) [RFC0793], the
 Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram
 Congestion Control Protocol (DCCP) [RFC4340], and potentially any
 standards-track transport protocols to be defined in the future.
 The general operating principle is that transport layer traffic is
 not forwarded into the interior network of a residential IPv6 gateway
 unless it has been solicited explicitly by interior transport
 endpoints, e.g., by matching the reverse path for previously
 forwarded outbound traffic, or by matching configured exceptions set
 by the network administrator.  All other traffic is expected to be
 discarded or rejected with an ICMPv6 error message to indicate the
 traffic is administratively prohibited.

3. Detailed Recommendations

 This section describes the specific recommendations made by this
 document in full detail.  Section 4 is a summary.
 Some recommended filters are to be applied to all traffic that passes
 through residential Internet gateways regardless of the direction
 they are to be forwarded.  Other recommended filters are intended to
 be sensitive to the "direction" of traffic flows.  Applied to
 bidirectional transport flows, "direction" has a specific meaning in
 this document.
 Packets are said to be "outbound" if they originate at nodes located
 in the interior network for exterior destinations, and "inbound" if
 they arrive from exterior sources with interior destinations.
 Flows are said to be "outbound" if the originator of the initial
 packet in any given transport association is an interior node and one
 or more of the participants are located in the exterior.  Flows are
 said to be "inbound" if the originator of the initial packet is an
 exterior node and one or more of the participants are nodes on the
 interior network.

Woodyatt Informational [Page 6] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

3.1. Stateless Filters

 Certain kinds of IPv6 packets MUST NOT be forwarded in either
 direction by residential Internet gateways regardless of network
 state.  These include packets with multicast source addresses,
 packets to destinations with certain non-routable and/or reserved
 prefixes, and packets with deprecated extension headers.
 Other stateless filters are recommended to implement ingress
 filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
 boundaries, and to isolate certain local network services from the
 public Internet.
 REC-1: Packets bearing multicast source addresses in their outer IPv6
 headers MUST NOT be forwarded or transmitted on any interface.
 REC-2: Packets bearing multicast destination addresses in their outer
 IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
 Architecture" [RFC4007]) than the configured scope boundary level of
 the gateway MUST NOT be forwarded in any direction.  The DEFAULT
 scope boundary level SHOULD be organization-local scope, and it
 SHOULD be configurable by the network administrator.
 REC-3: Packets bearing source and/or destination addresses forbidden
 to appear in the outer headers of packets transmitted over the public
 Internet MUST NOT be forwarded.  In particular, site-local addresses
 are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use
 of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible
 Addresses, Documentation Prefix, and Overlay Routable Cryptographic
 Hash IDentifiers (ORCHID).
 REC-4: Packets bearing deprecated extension headers prior to their
 first upper-layer-protocol header SHOULD NOT be forwarded or
 transmitted on any interface.  In particular, all packets with
 routing extension header type 0 [RFC2460] preceding the first upper-
 layer-protocol header MUST NOT be forwarded.  See [RFC5095] for
 additional background.
 REC-5: Outbound packets MUST NOT be forwarded if the source address
 in their outer IPv6 header does not have a unicast prefix configured
 for use by globally reachable nodes on the interior network.
 REC-6: Inbound packets MUST NOT be forwarded if the source address in
 their outer IPv6 header has a global unicast prefix assigned for use
 by globally reachable nodes on the interior network.

Woodyatt Informational [Page 7] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-7: By DEFAULT, packets with unique local source and/or
 destination addresses [RFC4193] SHOULD NOT be forwarded to or from
 the exterior network.
 REC-8: By DEFAULT, inbound DNS queries received on exterior
 interfaces MUST NOT be processed by any integrated DNS resolving
 server.
 REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
 exterior interfaces MUST NOT be processed by any integrated DHCPv6
 server or relay agent.
    NOTE WELL: Nothing in this document relieves residential Internet
    gateways, when processing headers to identify valid sequences of
    upper-layer transport packets, from any of the requirements of the
    "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460],
    including any and all future updates and revisions.

3.2. Connection-Free Filters

 Some Internet applications use connection-free transport protocols
 with no release semantics, e.g., UDP.  These protocols pose a special
 difficulty for stateful packet filters because most of the
 application state is not carried at the transport level.  State
 records are created when communication is initiated and are abandoned
 when no further communication is detected after some period of time.

3.2.1. Internet Control and Management

 Recommendations for filtering ICMPv6 messages in firewall devices are
 described separately in [RFC4890] and apply to residential gateways,
 with the additional recommendation that incoming "Destination
 Unreachable" and "Packet Too Big" error messages that don't match any
 filtering state should be dropped.
 REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
 Unreachable" and "Packet Too Big" messages containing IP headers that
 do not match generic upper-layer transport state records.

3.2.2. Upper-Layer Transport Protocols

 Residential IPv6 gateways are not expected to prohibit the use of
 applications to be developed using future upper-layer transport
 protocols.  In particular, transport protocols not otherwise
 discussed in subsequent sections of this document are expected to be
 treated consistently, i.e., as having connection-free semantics and
 no special requirements to inspect the transport headers.

Woodyatt Informational [Page 8] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 In general, upper-layer transport filter state records are expected
 to be created when an interior endpoint sends a packet to an exterior
 address.  The filter allocates (or reuses) a record for the duration
 of communications, with an idle timer to delete the state record when
 no further communications are detected.
 One key aspect of how a packet filter behaves is the way it evaluates
 the exterior address of an endpoint when applying a filtering rule.
 A gateway is said to have "endpoint-independent filtering" behavior
 when the exterior address is not evaluated when matching a packet
 with a flow.  A gateway is said to have "address-dependent filtering"
 behavior when the exterior address of a packet is required to match
 the exterior address for its flow.
 REC-11: If application transparency is most important, then a
 stateful packet filter SHOULD have "endpoint-independent filtering"
 behavior for generic upper-layer transport protocols.  If a more
 stringent filtering behavior is most important, then a filter SHOULD
 have "address-dependent filtering" behavior.  The filtering behavior
 MAY be an option configurable by the network administrator, and it
 MAY be independent of the filtering behavior for other protocols.
 Filtering behavior SHOULD be endpoint independent by DEFAULT in
 gateways intended for provisioning without service-provider
 management.
 REC-12: Filter state records for generic upper-layer transport
 protocols MUST NOT be deleted or recycled until an idle timer not
 less than two minutes has expired without having forwarded a packet
 matching the state in some configurable amount of time.  By DEFAULT,
 the idle timer for such state records is five minutes.
 The Internet security community is never completely at rest.  New
 attack surfaces, and vulnerabilities in them, are typically
 discovered faster than they can be patched by normal equipment
 upgrade cycles.  It's therefore important for vendors of residential
 gateway equipment to provide automatic software updates to patch
 vulnerabilities as they are discovered.
 REC-13: Residential IPv6 gateways SHOULD provide a convenient means
 to update their firmware securely, for the installation of security
 patches and other manufacturer-recommended changes.
 Vendors can expect users and operators to have differing viewpoints
 on the maintenance of patches, with some preferring automatic update
 and some preferring manual procedures.  Those preferring automatic
 update may also prefer either to download from a vendor site or from
 one managed by their network provider.  To handle the disparity,
 vendors are advised to provide both manual and automatic options.  In

Woodyatt Informational [Page 9] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 the automatic case, they would do well to facilitate
 pre-configuration of the download URL and a means of validating the
 software image, such as a certificate.

3.2.3. UDP Filters

 "Network Address Translation (NAT) Behavioral Requirements for
 Unicast UDP" [RFC4787] defines the terminology and best current
 practice for stateful filtering of UDP applications in IPv4 with NAT,
 which serves as the model for behavioral requirements for simple UDP
 security in IPv6 gateways, notwithstanding the requirements related
 specifically to network address translation.
 An interior endpoint initiates a UDP flow through a stateful packet
 filter by sending a packet to an exterior address.  The filter
 allocates (or reuses) a filter state record for the duration of the
 flow.  The state record defines the interior and exterior IP
 addresses and ports used between all packets in the flow.
 State records for UDP flows remain active while they are in use and
 are only abandoned after an idle period of some time.
 REC-14: A state record for a UDP flow where both source and
 destination ports are outside the well-known port range
 (ports 0-1023) MUST NOT expire in less than two minutes of idle time.
 The value of the UDP state record idle timer MAY be configurable.
 The DEFAULT is five minutes.
 REC-15: A state record for a UDP flow where one or both of the source
 and destination ports are in the well-known port range (ports 0-1023)
 MAY expire after a period of idle time shorter than two minutes to
 facilitate the operation of the IANA-registered service assigned to
 the port in question.
 As [RFC4787] notes, outbound refresh is necessary for allowing the
 interior endpoint to keep the state record alive.  Inbound refresh
 may be useful for applications with no outbound UDP traffic.
 However, allowing inbound refresh can allow an attacker in the
 exterior or a misbehaving application to keep a state record alive
 indefinitely.  This could be a security risk.  Also, if the process
 is repeated with different ports, over time, it could use up all the
 state record memory and resources in the filter.
 REC-16: A state record for a UDP flow MUST be refreshed when a packet
 is forwarded from the interior to the exterior, and it MAY be
 refreshed when a packet is forwarded in the reverse direction.

Woodyatt Informational [Page 10] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 As described in Section 5 of [RFC4787], the connection-free semantics
 of UDP pose a difficulty for packet filters in trying to recognize
 which packets comprise an application flow and which are unsolicited.
 Various strategies have been used in IPv4/NAT gateways with differing
 effects.
 REC-17: If application transparency is most important, then a
 stateful packet filter SHOULD have "endpoint-independent filtering"
 behavior for UDP.  If a more stringent filtering behavior is most
 important, then a filter SHOULD have "address-dependent filtering"
 behavior.  The filtering behavior MAY be an option configurable by
 the network administrator, and it MAY be independent of the filtering
 behavior for TCP and other protocols.  Filtering behavior SHOULD be
 endpoint independent by DEFAULT in gateways intended for provisioning
 without service-provider management.
 Application mechanisms may depend on the reception of ICMPv6 error
 messages triggered by the transmission of UDP messages.  One such
 mechanism is path MTU discovery [RFC1981].
 REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
 "Destination Unreachable" and "Packet Too Big" messages containing
 UDP headers that match the flow state record.
 REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
 state record for a UDP flow.
 REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
 UDP flows, except that the upper-layer transport protocol identifier
 for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT
 match UDP-Lite state records, and vice versa.

3.2.4. IPsec and Internet Key Exchange (IKE)

 The Internet Protocol security (IPsec) suite offers greater
 flexibility and better overall security than the simple security of
 stateful packet filtering at network perimeters.  Therefore,
 residential IPv6 gateways need not prohibit IPsec traffic flows.
 REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT
 prohibit the forwarding of packets, to and from legitimate node
 addresses, with destination extension headers of type "Authentication
 Header (AH)" [RFC4302] in their outer IP extension header chain.

Woodyatt Informational [Page 11] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT
 prohibit the forwarding of packets, to and from legitimate node
 addresses, with an upper-layer protocol of type "Encapsulating
 Security Payload (ESP)" [RFC4303] in their outer IP extension header
 chain.
 REC-23: If a gateway forwards an ESP flow, it MUST also forward (in
 the reverse direction) ICMPv6 "Destination Unreachable" and "Packet
 Too Big" messages containing ESP headers that match the flow state
 record.
 Internet Key Exchange (IKE) is a secure mechanism for performing
 mutual authentication, exchanging cryptographic material, and
 establishing IPsec Security Associations between peers.  Residential
 IPv6 gateways are expected to facilitate the use of IPsec security
 policies by allowing inbound IKE flows.
 REC-24: In their DEFAULT operating mode, IPv6 gateways MUST NOT
 prohibit the forwarding of any UDP packets, to and from legitimate
 node addresses, with a destination port of 500, i.e., the port
 reserved by IANA for the Internet Key Exchange (IKE) protocol
 [RFC5996].
 REC-25: In all operating modes, IPv6 gateways SHOULD use filter state
 records for Encapsulating Security Payload (ESP) [RFC4303] that are
 indexable by a 3-tuple comprising the interior node address, the
 exterior node address, and the ESP protocol identifier.  In
 particular, the IPv4/NAT method of indexing state records also by the
 security parameters index (SPI) SHOULD NOT be used.  Likewise, any
 mechanism that depends on detection of Internet Key Exchange (IKE)
 [RFC5996] initiations SHOULD NOT be used.
 The Host Identity Protocol (HIP) is a secure mechanism for
 establishing host identity and secure communications between
 authenticated hosts.  Residential IPv6 gateways need not prohibit
 inbound HIP flows.
 REC-26: In their DEFAULT operating mode, IPv6 gateways MUST NOT
 prohibit the forwarding of packets, to and from legitimate node
 addresses, with destination extension headers of type "Host Identity
 Protocol (HIP)" [RFC5201] in their outer IP extension header chain.

3.2.5. Mobility Support in IPv6

 Mobility support in IPv6 [RFC3775] relies on the use of an
 encapsulation mechanism in flows between mobile nodes and their
 correspondent nodes, involving the use of the Type 2 IPv6 Routing
 Header, the Home Address destination header option, and the Mobility

Woodyatt Informational [Page 12] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 extension header.  In contrast to mobility support in IPv4, mobility
 is a standard feature of IPv6, and no security benefit is generally
 to be gained by denying communications with either interior or
 exterior mobile nodes.
 Not all usage scenarios of mobility support in IPv6 are expected to
 be compatible with IPv6 simple security.  In particular, exterior
 mobile nodes are expected to be prohibited from establishing bindings
 with interior correspondent nodes by the filtering of unsolicited
 inbound Mobility Header messages, unless they are the subject of an
 IPsec security policy.
 REC-27: The state records for flows initiated by outbound packets
 that bear a Home Address destination option [RFC3775] are
 distinguished by the addition of the home address of the flow as well
 as the interior care-of address.  IPv6 gateways MUST NOT prohibit the
 forwarding of any inbound packets bearing type 2 routing headers,
 which otherwise match a flow state record, and where A) the address
 in the destination field of the IPv6 header matches the interior
 care-of address of the flow, and B) the Home Address field in the
 Type 2 Routing Header matches the home address of the flow.
 REC-28: Valid sequences of Mobility Header [RFC3775] packets MUST be
 forwarded for all outbound and explicitly permitted inbound Mobility
 Header flows.
 REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then
 it MUST also forward, in both directions, the IPv4 and IPv6 packets
 that are encapsulated in IPv6 associated with the tunnel between the
 home agent and the correspondent node.
 REC-30: If a gateway forwards a Mobility Header [RFC3775] flow, then
 it MUST also forward (in the reverse direction) ICMPv6 "Destination
 Unreachable" and "Packet Too Big" messages containing any headers
 that match the associated flow state records.

3.3. Connection-Oriented Filters

 Most Internet applications use connection-oriented transport
 protocols with orderly release semantics.  These protocols include
 TCP, SCTP, DCCP, and potentially any future IETF Standards-Track
 transport protocols that use such semantics.  Stateful packet filters
 track the state of individual transport flows and prohibit the
 forwarding of packets that do not match the state of an active flow
 and do not conform to a rule for the automatic creation of such
 state.

Woodyatt Informational [Page 13] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

3.3.1. TCP Filters

 An interior endpoint initiates a TCP flow through a stateful packet
 filter by sending a SYN packet.  The filter allocates (or reuses) a
 filter state record for the flow.  The state record defines the
 interior and exterior IP addresses and ports used for forwarding all
 packets for that flow.
 Some peer-to-peer applications use an alternate method of connection
 initiation termed "simultaneous-open" ([RFC0793], Figure 8) to
 traverse stateful filters.  In the simultaneous-open mode of
 operation, both peers send SYN packets for the same TCP flow.  The
 SYN packets cross in the network.  Upon receiving the other end's SYN
 packet, each end responds with a SYN-ACK packet, which also cross in
 the network.  The connection is established at each endpoint once the
 SYN-ACK packets are received.
 To provide stateful packet filtering service for TCP, it is necessary
 for a filter to receive, process, and forward all packets for a flow
 that conform to valid transitions of the TCP state machine
 ([RFC0793], Figure 6).
 REC-31: All valid sequences of TCP packets (defined in [RFC0793])
 MUST be forwarded for outbound flows and explicitly permitted inbound
 flows.  In particular, both the normal TCP 3-way handshake mode of
 operation and the simultaneous-open mode of operation MUST be
 supported.
 It is possible to reconstruct enough of the state of a TCP flow to
 allow forwarding between an interior and exterior node, even when the
 filter starts operating after TCP enters the established state.  In
 this case, because the filter has not seen the TCP window-scale
 option, it is not possible for the filter to enforce the TCP window
 invariant by dropping out-of-window segments.
 REC-32: The TCP window invariant MUST NOT be enforced on flows for
 which the filter did not detect whether the window-scale option (see
 [RFC1323]) was sent in the 3-way handshake or simultaneous-open.
 A stateful filter can allow an existing state record to be reused by
 an externally initiated flow if its security policy permits.  Several
 different policies are possible, as described in [RFC4787] and
 extended in [RFC5382].
 REC-33: If application transparency is most important, then a
 stateful packet filter SHOULD have "endpoint-independent filtering"
 behavior for TCP.  If a more stringent filtering behavior is most
 important, then a filter SHOULD have "address-dependent filtering"

Woodyatt Informational [Page 14] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 behavior.  The filtering behavior MAY be an option configurable by
 the network administrator, and it MAY be independent of the filtering
 behavior for UDP and other protocols.  Filtering behavior SHOULD be
 endpoint independent by DEFAULT in gateways intended for provisioning
 without service-provider management.
 If an inbound SYN packet is filtered, either because a corresponding
 state record does not exist or because of the filter's normal
 behavior, a filter has two basic choices: to discard the packet
 silently, or to signal an error to the sender.  Signaling an error
 through ICMPv6 messages allows the sender to detect that the SYN did
 not reach the intended destination.  Discarding the packet, on the
 other hand, allows applications to perform simultaneous-open more
 reliably.  A more detailed discussion of this issue can be found in
 [RFC5382], but the basic outcome of it is that filters need to wait
 on signaling errors until simultaneous-open will not be impaired.
 REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6
 "Destination Unreachable" error code 1 (Communication with
 destination administratively prohibited) to any unsolicited inbound
 SYN packet after waiting at least 6 seconds without first forwarding
 the associated outbound SYN or SYN/ACK from the interior peer.
 A TCP filter maintains state associated with in-progress connections
 and established flows.  Because of this, a filter is susceptible to a
 resource-exhaustion attack whereby an attacker (or virus) on the
 interior attempts to cause the filter to exhaust its capacity for
 creating state records.  To defend against such attacks, a filter
 needs to abandon unused state records after a sufficiently long
 period of idleness.
 A common method used for TCP filters in IPv4/NAT gateways is to
 abandon preferentially flow state records for crashed endpoints,
 followed by closed flows and partially open flows.  A gateway can
 check if an endpoint for a session has crashed by sending a TCP keep-
 alive packet on behalf of the other endpoint and receiving a TCP RST
 packet in response.  If the gateway cannot determine whether the
 endpoint is active, then the associated state record needs to be
 retained until the TCP flow has been idle for some time.
    Note: An established TCP flow can stay idle (but live)
    indefinitely; hence, there is no fixed value for an idle-timeout
    that accommodates all applications.  However, a large idle-timeout
    motivated by recommendations in [RFC1122] and [RFC4294] can reduce
    the chances of abandoning a live flow.

Woodyatt Informational [Page 15] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 TCP flows can stay in the established phase indefinitely without
 exchanging packets.  Some end-hosts can be configured to send keep-
 alive packets on such idle flows; by default, such packets are sent
 every two hours, if enabled [RFC1122].  Consequently, a filter that
 waits for slightly over two hours can detect idle flows with keep-
 alive packets being sent at the default rate.  TCP flows in the
 partially open or closing phases, on the other hand, can stay idle
 for at most four minutes while waiting for in-flight packets to be
 delivered [RFC1122].
 The "established flow idle-timeout" for a stateful packet filter is
 defined as the minimum time a TCP flow in the established phase must
 remain idle before the filter considers the associated state record a
 candidate for collection.  The "transitory flow idle-timeout" for a
 filter is defined as the minimum time a TCP flow in the partially
 open or closing phases must remain idle before the filter considers
 the associated state record a candidate for collection.  TCP flows in
 the TIME-WAIT state are not affected by the "transitory flow idle-
 timeout" parameter.
 REC-35: If a gateway cannot determine whether the endpoints of a TCP
 flow are active, then it MAY abandon the state record if it has been
 idle for some time.  In such cases, the value of the "established
 flow idle-timeout" MUST NOT be less than two hours four minutes, as
 discussed in [RFC5382].  The value of the "transitory flow idle-
 timeout" MUST NOT be less than four minutes.  The value of the idle-
 timeouts MAY be configurable by the network administrator.
 Behavior for handling RST packets or TCP flows in the TIME-WAIT state
 is left unspecified.  A gateway MAY hold state for a flow in the
 TIME-WAIT state to accommodate retransmissions of the last ACK.
 However, since the TIME-WAIT state is commonly encountered by
 interior endpoints properly closing the TCP flow, holding state for a
 closed flow can limit the throughput of flows through a gateway with
 limited resources.  [RFC1337] discusses hazards associated with
 TIME-WAIT assassination.
 The handling of non-SYN packets for which there is no active state
 record is left unspecified.  Such packets can be received if the
 gateway abandons a live flow, or abandons a flow in the TIME-WAIT
 state before the four-minute TIME-WAIT period expires.  The decision
 either to discard or to respond with an ICMPv6 "Destination
 Unreachable" error code 1 (Communication with destination
 administratively prohibited) is left up to the implementation.
 Behavior for notifying endpoints when abandoning live flows is left
 unspecified.  When a gateway abandons a live flow, for example due to
 a timeout expiring, the filter MAY send a TCP RST packet to each

Woodyatt Informational [Page 16] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 endpoint on behalf of the other.  Sending a RST notification allows
 endpoint applications to recover more quickly; however, notifying
 endpoints might not always be possible if, for example, state records
 are lost due to power interruption.
 Several TCP mechanisms depend on the reception of ICMPv6 error
 messages triggered by the transmission of TCP segments.  One such
 mechanism is path MTU discovery, which is required for correct
 operation of TCP.
 REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
 "Destination Unreachable" and "Packet Too Big" messages containing
 TCP headers that match the flow state record.
 REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the
 state record for a TCP flow.

3.3.2. SCTP Filters

 Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows
 can be terminated at multiple network addresses, IPv6 simple security
 functions cannot achieve full transparency for SCTP applications.  In
 multipath traversal scenarios, full transparency requires
 coordination between all the packet filter processes in the various
 paths between the endpoint network addresses.  Such coordination is
 not "simple", and it is, therefore, beyond the scope of this
 recommendation.
 However, some SCTP applications are capable of tolerating the
 inherent unipath restriction of IPv6 simple security, even in
 multipath traversal scenarios.  They expect connection-oriented
 filtering behaviors similar to those for TCP, but at the level of
 SCTP associations, not stream connections.  This section describes
 specific recommendations for SCTP filtering for such traversal
 scenarios.
 An interior endpoint initiates SCTP associations through a stateful
 packet filter by sending a packet comprising a single INIT chunk.
 The filter allocates (or reuses) a filter state record for the
 association.  The state record defines the interior and exterior IP
 addresses and the observed verification tag used for forwarding
 packets in that association.
 Some peer-to-peer SCTP applications use an alternate method of
 association initiation, termed "simultaneous-open", to traverse
 stateful filters.  In the simultaneous-open mode of operation, both
 peers send INIT chunks at the same time to establish an association.
 Upon receiving the other end's INIT chunk, each end responds with an

Woodyatt Informational [Page 17] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 INIT-ACK packet, which is expected to traverse the same path in
 reverse.  Because only one SCTP association may exist between any two
 network addresses, one of the peers in the simultaneous-open mode of
 operation will send an ERROR or ABORT chunk along with the INIT-ACK
 chunk.  The association is established at each endpoint once an
 INIT-ACK chunk without an ERROR or ABORT chunk is received at one
 end.
 To provide stateful packet filtering service for SCTP, it is
 necessary for a filter to receive, process, and forward all packets
 for an association that conform to valid transitions of the SCTP
 state machine ([RFC4960], Figure 3).
 REC-38: All valid sequences of SCTP packets (defined in [RFC4960])
 MUST be forwarded for outbound associations and explicitly permitted
 inbound associations.  In particular, both the normal SCTP
 association establishment and the simultaneous-open mode of operation
 MUST be supported.
 If an inbound INIT packet is filtered, either because a corresponding
 state record does not exist or because of the filter's normal
 behavior, a filter has two basic choices: to discard the packet
 silently, or to signal an error to the sender.  Signaling an error
 through ICMPv6 messages allows the sender to detect that the INIT
 packet did not reach the intended destination.  Discarding the
 packet, on the other hand, allows applications to perform
 simultaneous-open more reliably.  Delays in signaling errors can
 prevent the impairment of the simultaneous-open mode of operation.
 REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6
 "Destination Unreachable" error code 1 (Communication with
 destination administratively prohibited), to any unsolicited inbound
 INIT packet after waiting at least 6 seconds without first forwarding
 the associated outbound INIT from the interior peer.
 An SCTP filter maintains state associated with in-progress and
 established associations.  Because of this, a filter is susceptible
 to a resource-exhaustion attack whereby an attacker (or virus) on the
 interior attempts to cause the filter to exhaust its capacity for
 creating state records.  To defend against such attacks, a filter
 needs to abandon unused state records after a sufficiently long
 period of idleness.
 A common method used for TCP filters in IPv4/NAT gateways is to
 abandon preferentially sessions for crashed endpoints, followed by
 closed associations and partially opened associations.  A similar
 method is an option for SCTP filters in IPv6 gateways.  A gateway can
 check if an endpoint for an association has crashed by sending

Woodyatt Informational [Page 18] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 HEARTBEAT chunks and looking for the HEARTBEAT ACK response.  If the
 gateway cannot determine whether the endpoint is active, then the
 associated state record needs to be retained until the SCTP
 association has been idle for some time.
    Note: An established SCTP association can stay idle (but live)
    indefinitely; hence, there is no fixed value of an idle-timeout
    that accommodates all applications.  However, a large idle-timeout
    motivated by recommendations in [RFC4294] can reduce the chances
    of abandoning a live association.
 SCTP associations can stay in the ESTABLISHED state indefinitely
 without exchanging packets.  Some end-hosts can be configured to send
 HEARTBEAT chunks on such idle associations, but [RFC4960] does not
 specify (or even suggest) a default time interval.  A filter that
 waits for slightly over two hours can detect idle associations with
 HEARTBEAT packets being sent at the same rate as most hosts use for
 TCP keep-alive, which is a reasonably similar system for this
 purpose.  SCTP associations in the partially open or closing states,
 on the other hand, can stay idle for at most four minutes while
 waiting for in-flight packets to be delivered (assuming the suggested
 SCTP protocol parameter values in Section 15 of [RFC4960]).
 The "established association idle-timeout" for a stateful packet
 filter is defined as the minimum time an SCTP association in the
 established phase must remain idle before the filter considers the
 corresponding state record a candidate for collection.  The
 "transitory association idle-timeout" for a filter is defined as the
 minimum time an SCTP association in the partially open or closing
 phases must remain idle before the filter considers the corresponding
 state record a candidate for collection.
 REC-40: If a gateway cannot determine whether the endpoints of an
 SCTP association are active, then it MAY abandon the state record if
 it has been idle for some time.  In such cases, the value of the
 "established association idle-timeout" MUST NOT be less than
 two hours four minutes.  The value of the "transitory association
 idle-timeout" MUST NOT be less than four minutes.  The value of the
 idle-timeouts MAY be configurable by the network administrator.
 Behavior for handling ERROR and ABORT packets is left unspecified.  A
 gateway MAY hold state for an association after its closing phases
 have completed to accommodate retransmissions of its final SHUTDOWN
 ACK packets.  However, holding state for a closed association can
 limit the throughput of associations traversing a gateway with
 limited resources.  The discussion in [RFC1337] regarding the hazards
 of TIME-WAIT assassination is relevant.

Woodyatt Informational [Page 19] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 The handling of inbound non-INIT packets for which there is no active
 state record is left unspecified.  Such packets can be received if
 the gateway abandons a live flow, or abandons an association in the
 closing states before the transitory association idle-timeout
 expires.  The decision either to discard or to respond with an ICMPv6
 "Destination Unreachable" error code 1 (Communication with
 destination administratively prohibited) is left to the
 implementation.
 Behavior for notifying endpoints when abandoning live associations is
 left unspecified.  When a gateway abandons a live association, for
 example due to a timeout expiring, the filter MAY send an ABORT
 packet to each endpoint on behalf of the other.  Sending an ABORT
 notification allows endpoint applications to recover more quickly;
 however, notifying endpoints might not always be possible if, for
 example, state records are lost due to power interruption.
 Several SCTP mechanisms depend on the reception of ICMPv6 error
 messages triggered by the transmission of SCTP packets.
 REC-41: If a gateway forwards an SCTP association, it MUST also
 forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
 messages containing SCTP headers that match the association state
 record.
 REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the
 state record for an SCTP association.

3.3.3. DCCP Filters

 The connection semantics described in the "Datagram Congestion
 Control Protocol (DCCP)" [RFC4340] are very similar to those of TCP.
 An interior endpoint initiates a DCCP flow through a stateful packet
 filter by sending a DCCP-Request packet.  Simultaneous-open is not
 defined for DCCP.
 In order to provide stateful packet filtering service for DCCP, it is
 necessary for a filter to receive, process, and forward all packets
 for a flow that conform to valid transitions of the DCCP state
 machine ([RFC4340], Section 8).
 REC-43: All valid sequences of DCCP packets (defined in [RFC4340])
 MUST be forwarded for all flows to exterior servers, and for any
 flows to interior servers that have explicitly permitted service
 codes.

Woodyatt Informational [Page 20] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 It is possible to reconstruct enough of the state of a DCCP flow to
 allow forwarding between an interior and exterior node, even when the
 filter starts operating after DCCP enters the OPEN state.  Also, a
 filter can allow an existing state record to be reused by an
 externally initiated flow if its security policy permits.  As with
 TCP, several different policies are possible, with a good discussion
 of the issue involved presented in [RFC4787] and extended in
 [RFC5382].
 If an inbound DCCP-Request packet is filtered, either because a
 corresponding state record does not already exist for it or because
 of the filter's normal behavior of refusing flows not explicitly
 permitted, then a filter has two basic choices: to discard the packet
 silently, or to signal an error to the sender.  Signaling an error
 through ICMPv6 messages allows the sender to detect that the
 DCCP-Request did not reach the intended destination.  Discarding the
 packet, on the other hand, only delays the failure to connect and
 provides no measurable security.
 A DCCP filter maintains state associated with in-progress connections
 and established flows.  Because of this, a filter is susceptible to a
 resource-exhaustion attack whereby an attacker (or virus) on the
 interior attempts to cause the filter to exhaust its capacity for
 creating state records.  To prevent such an attack, a filter needs to
 abandon unused state records after a sufficiently long period of
 idleness.
 A common method used for TCP filters in IPv4/NAT gateways is to
 abandon preferentially sessions for crashed endpoints, followed by
 closed TCP flows and partially open flows.  No such method exists for
 DCCP, and flows can stay in the OPEN phase indefinitely without
 exchanging packets.  Hence, there is no fixed value for an idle-
 timeout that accommodates all applications.  However, a large idle-
 timeout motivated by recommendations in [RFC4294] can reduce the
 chances of abandoning a live flow.
 DCCP flows in the partially open or closing phases can stay idle for
 at most eight minutes while waiting for in-flight packets to be
 delivered.
 The "open flow idle-timeout" for a stateful packet filter is defined
 as the minimum time a DCCP flow in the open state must remain idle
 before the filter considers the associated state record a candidate

Woodyatt Informational [Page 21] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 for collection.  The "transitory flow idle-timeout" for a filter is
 defined as the minimum time a DCCP flow in the partially open or
 closing phases must remain idle before the filter considers the
 associated state record a candidate for collection.  DCCP flows in
 the TIMEWAIT state are not affected by the "transitory flow idle-
 timeout" parameter.
 REC-44: A gateway MAY abandon a DCCP state record if it has been idle
 for some time.  In such cases, the value of the "open flow idle-
 timeout" MUST NOT be less than two hours four minutes.  The value of
 the "transitory flow idle-timeout" MUST NOT be less than eight
 minutes.  The value of the idle-timeouts MAY be configurable by the
 network administrator.
 Behavior for handling DCCP-Reset packets or flows in the TIMEWAIT
 state is left unspecified.  A gateway MAY hold state for a flow in
 the TIMEWAIT state to accommodate retransmissions of the last
 DCCP-Reset.  However, since the TIMEWAIT state is commonly
 encountered by interior endpoints properly closing the DCCP flow,
 holding state for a closed flow can limit the throughput of flows
 through a gateway with limited resources.  [RFC1337] discusses
 hazards associated with TIME-WAIT assassination in TCP, and similar
 hazards exist for DCCP.
 The handling of non-SYN packets for which there is no active state
 record is left unspecified.  Such packets can be received if the
 gateway abandons a live flow, or abandons a flow in the TIMEWAIT
 state before the four-minute 2MSL period (two times the maximum
 segment lifetime [RFC4340]) expires.  The decision either to discard
 or to respond with an ICMPv6 "Destination Unreachable" error code 1
 (Communication with destination administratively prohibited) is left
 up to the implementation.
 Behavior for notifying endpoints when abandoning live flows is left
 unspecified.  When a gateway abandons a live flow, for example due to
 a timeout expiring, the filter MAY send a DCCP-Reset packet to each
 endpoint on behalf of the other.  Sending a DCCP-Reset notification
 allows endpoint applications to recover more quickly; however,
 notifying endpoints might not always be possible if, for example,
 state records are lost due to power interruption.
 Several DCCP mechanisms depend on the reception of ICMPv6 error
 messages triggered by the transmission of DCCP packets.  One such
 mechanism is path MTU discovery, which is required for correct
 operation.

Woodyatt Informational [Page 22] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-45: If an Internet gateway forwards a DCCP flow, it MUST also
 forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
 messages containing DCCP headers that match the flow state record.
 REC-46: Receipt of any sort of ICMPv6 message MUST NOT terminate the
 state record for a DCCP flow.

3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (Shim6)

 While IPv6 simple security is applicable to residential networks with
 only one Internet service provider at a time, the use of the Level 3
 Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] is necessary for
 communications with some multihomed exterior destinations.  No
 special recommendations are made in this document for processing the
 Shim6 message format (protocol 140) beyond the recommendations in
 Section 3.2.2.  The content of the Shim6 payload extension header may
 be ignored.
 REC-47: Valid sequences of packets bearing Shim6 payload extension
 headers in their outer IP extension header chains MUST be forwarded
 for all outbound and explicitly permitted flows.  The content of the
 Shim6 payload extension header MAY be ignored for the purpose of
 state tracking.

3.4. Passive Listeners

 Some applications expect to solicit traffic from exterior nodes
 without advance knowledge of the exterior addresses of their peers.
 This requirement is met by IPv4/NAT gateways, typically by the use of
 either the NAT Port Mapping Protocol [NAT-PMP] or the Universal Plug
 and Play Internet Gateway Device [UPnP-IGD] standardized device
 control protocol.  On IPv4/NAT networks connected by gateways without
 such services, applications must use techniques like Session
 Traversal Utilities for NAT (STUN) [RFC5389] to obtain and maintain
 connectivity, despite the translation and filtering effects of NAT.
 While NAT for IPv6 is unlikely to be used in most residential
 gateways, the simple security functions recommended by this document,
 and their filtering effects, are derived from comparable functions
 already in widespread use on the IPv4 Internet.  A similar barrier to
 communication at passive listeners is a natural outcome of the
 deployment of NAT for IPv6.  To avoid the need for IPv6 applications
 to use techniques like STUN for opening and maintaining dynamic
 filter state, something similar to NAT-PMP and UPnP-IGD, but without
 actually supporting NAT, could be deployed.  Alas, no consensus has
 yet emerged in the Internet engineering community as to what is most
 appropriate for residential IPv6 usage scenarios.

Woodyatt Informational [Page 23] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 One proposal that has been offered is the Application Listener
 Discovery Protocol [WOODYATT-ALD] document.  It remains to be seen
 whether the Internet Gateway Device profile of the Universal Plug and
 Play protocol will be extended for IPv6.  Other proposals of note
 include the Middlebox Communication Protocol [RFC5189] and the Next
 Steps in Signaling framework [RFC4080].  Until a consensus emerges
 around a specific method, the following recommendations are the best
 guidance available.
 REC-48: Internet gateways with IPv6 simple security capabilities
 SHOULD implement a protocol to permit applications to solicit inbound
 traffic without advance knowledge of the addresses of exterior nodes
 with which they expect to communicate.
 REC-49: Internet gateways with IPv6 simple security capabilities MUST
 provide an easily selected configuration option that permits a
 "transparent mode" of operation that forwards all unsolicited flows
 regardless of forwarding direction, i.e., not to use the IPv6 simple
 security capabilities of the gateway.  The transparent mode of
 operation MAY be the default configuration.
 In general, "transparent mode" will enable more flexibility and
 reliability for applications that require devices to be contacted
 inside the home directly, particularly in the absence of a protocol
 as described in REC-48.  Operating in transparent mode may come at
 the expense of security if there are IPv6 nodes in the home that do
 not have their own host-based firewall capability and require a
 firewall in the gateway in order not to be compromised.

3.5. Management Applications

 Subscriber-managed residential gateways are unlikely ever to be
 completely zero-configuration, but their administrators will very
 often possess no particular expertise in Internet engineering.  In
 general, the specification of management interfaces for residential
 gateways is out of scope for this document, but the security of
 subscriber-managed gateways merits special attention here.
 REC-50: By DEFAULT, subscriber-managed residential gateways MUST NOT
 offer management application services to the exterior network.

Woodyatt Informational [Page 24] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

4. Summary of Recommendations

 This section collects all of the recommendations made in this
 document into a convenient list.
 REC-1   Packets bearing multicast source addresses in their outer
         IPv6 headers MUST NOT be forwarded or transmitted on any
         interface.
 REC-2   Packets bearing multicast destination addresses in their
         outer IPv6 headers of equal or narrower scope (see "IPv6
         Scoped Address Architecture" [RFC4007]) than the configured
         scope boundary level of the gateway MUST NOT be forwarded in
         any direction.  The DEFAULT scope boundary level SHOULD be
         organization-local scope, and it SHOULD be configurable by
         the network administrator.
 REC-3   Packets bearing source and/or destination addresses forbidden
         to appear in the outer headers of packets transmitted over
         the public Internet MUST NOT be forwarded.  In particular,
         site-local addresses are deprecated by [RFC3879], and
         [RFC5156] explicitly forbids the use of address blocks of
         types IPv4-Mapped Addresses, IPv4-Compatible Addresses,
         Documentation Prefix, and Overlay Routable Cryptographic Hash
         IDentifiers (ORCHID).
 REC-4   Packets bearing deprecated extension headers prior to their
         first upper-layer-protocol header SHOULD NOT be forwarded or
         transmitted on any interface.  In particular, all packets
         with routing extension header type 0 [RFC2460] preceding the
         first upper-layer-protocol header MUST NOT be forwarded.  See
         [RFC5095] for additional background.
 REC-5   Outbound packets MUST NOT be forwarded if the source address
         in their outer IPv6 header does not have a unicast prefix
         configured for use by globally reachable nodes on the
         interior network.
 REC-6   Inbound packets MUST NOT be forwarded if the source address
         in their outer IPv6 header has a global unicast prefix
         assigned for use by globally reachable nodes on the interior
         network.
 REC-7   By DEFAULT, packets with unique local source and/or
         destination addresses [RFC4193] SHOULD NOT be forwarded to or
         from the exterior network.

Woodyatt Informational [Page 25] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-8   By DEFAULT, inbound DNS queries received on exterior
         interfaces MUST NOT be processed by any integrated DNS
         resolving server.
 REC-9   Inbound DHCPv6 discovery packets [RFC3315] received on
         exterior interfaces MUST NOT be processed by any integrated
         DHCPv6 server or relay agent.
 REC-10  IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
         Unreachable" and "Packet Too Big" messages containing IP
         headers that do not match generic upper-layer transport state
         records.
 REC-11  If application transparency is most important, then a
         stateful packet filter SHOULD have "endpoint-independent
         filtering" behavior for generic upper-layer transport
         protocols.  If a more stringent filtering behavior is most
         important, then a filter SHOULD have "address-dependent
         filtering" behavior.  The filtering behavior MAY be an option
         configurable by the network administrator, and it MAY be
         independent of the filtering behavior for other protocols.
         Filtering behavior SHOULD be endpoint independent by DEFAULT
         in gateways intended for provisioning without service-
         provider management.
 REC-12  Filter state records for generic upper-layer transport
         protocols MUST NOT be deleted or recycled until an idle timer
         not less than two minutes has expired without having
         forwarded a packet matching the state in some configurable
         amount of time.  By DEFAULT, the idle timer for such state
         records is five minutes.
 REC-13  Residential IPv6 gateways SHOULD provide a convenient means
         to update their firmware securely, for the installation of
         security patches and other manufacturer-recommended changes.
 REC-14  A state record for a UDP flow where both source and
         destination ports are outside the well-known port range
         (ports 0-1023) MUST NOT expire in less than two minutes of
         idle time.  The value of the UDP state record idle timer MAY
         be configurable.  The DEFAULT is five minutes.
 REC-15  A state record for a UDP flow where one or both of the source
         and destination ports are in the well-known port range
         (ports 0-1023) MAY expire after a period of idle time shorter
         than two minutes to facilitate the operation of the IANA-
         registered service assigned to the port in question.

Woodyatt Informational [Page 26] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-16  A state record for a UDP flow MUST be refreshed when a packet
         is forwarded from the interior to the exterior, and it MAY be
         refreshed when a packet is forwarded in the reverse
         direction.
 REC-17  If application transparency is most important, then a
         stateful packet filter SHOULD have "endpoint-independent
         filtering" behavior for UDP.  If a more stringent filtering
         behavior is most important, then a filter SHOULD have
         "address-dependent filtering" behavior.  The filtering
         behavior MAY be an option configurable by the network
         administrator, and it MAY be independent of the filtering
         behavior for TCP and other protocols.  Filtering behavior
         SHOULD be endpoint independent by DEFAULT in gateways
         intended for provisioning without service-provider
         management.
 REC-18  If a gateway forwards a UDP flow, it MUST also forward ICMPv6
         "Destination Unreachable" and "Packet Too Big" messages
         containing UDP headers that match the flow state record.
 REC-19  Receipt of any sort of ICMPv6 message MUST NOT terminate the
         state record for a UDP flow.
 REC-20  UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
         UDP flows, except that the upper-layer transport protocol
         identifier for UDP-Lite is not the same as UDP; therefore,
         UDP packets MUST NOT match UDP-Lite state records, and vice
         versa.
 REC-21  In their DEFAULT operating mode, IPv6 gateways MUST NOT
         prohibit the forwarding of packets, to and from legitimate
         node addresses, with destination extension headers of type
         "Authentication Header (AH)" [RFC4302] in their outer IP
         extension header chain.
 REC-22  In their DEFAULT operating mode, IPv6 gateways MUST NOT
         prohibit the forwarding of packets, to and from legitimate
         node addresses, with an upper-layer protocol of type
         "Encapsulating Security Payload (ESP)" [RFC4303] in their
         outer IP extension header chain.
 REC-23  If a gateway forwards an ESP flow, it MUST also forward (in
         the reverse direction) ICMPv6 "Destination Unreachable" and
         "Packet Too Big" messages containing ESP headers that match
         the flow state record.

Woodyatt Informational [Page 27] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-24  In their DEFAULT operating mode, IPv6 gateways MUST NOT
         prohibit the forwarding of any UDP packets, to and from
         legitimate node addresses, with a destination port of 500,
         i.e., the port reserved by IANA for the Internet Key Exchange
         (IKE) Protocol [RFC5996].
 REC-25  In all operating modes, IPv6 gateways SHOULD use filter state
         records for Encapsulating Security Payload (ESP) [RFC4303]
         that are indexable by a 3-tuple comprising the interior node
         address, the exterior node address, and the ESP protocol
         identifier.  In particular, the IPv4/NAT method of indexing
         state records also by security parameters index (SPI) SHOULD
         NOT be used.  Likewise, any mechanism that depends on
         detection of Internet Key Exchange (IKE) [RFC5996]
         initiations SHOULD NOT be used.
 REC-26  In their DEFAULT operating mode, IPv6 gateways MUST NOT
         prohibit the forwarding of packets, to and from legitimate
         node addresses, with destination extension headers of type
         "Host Identity Protocol (HIP)" [RFC5201] in their outer IP
         extension header chain.
 REC-27  The state records for flows initiated by outbound packets
         that bear a Home Address destination option [RFC3775] are
         distinguished by the addition of the home address of the flow
         as well as the interior care-of address.  IPv6 gateways MUST
         NOT prohibit the forwarding of any inbound packets bearing
         type 2 routing headers, which otherwise match a flow state
         record, and where A) the address in the destination field of
         the IPv6 header matches the interior care-of address of the
         flow, and B) the Home Address field in the Type 2 Routing
         Header matches the home address of the flow.
 REC-28  Valid sequences of Mobility Header [RFC3775] packets MUST be
         forwarded for all outbound and explicitly permitted inbound
         Mobility Header flows.
 REC-29  If a gateway forwards a Mobility Header [RFC3775] flow, then
         it MUST also forward, in both directions, the IPv4 and IPv6
         packets that are encapsulated in IPv6 associated with the
         tunnel between the home agent and the correspondent node.
 REC-30  If a gateway forwards a Mobility Header [RFC3775] flow, then
         it MUST also forward (in the reverse direction) ICMPv6
         "Destination Unreachable" and "Packet Too Big" messages
         containing any headers that match the associated flow state
         records.

Woodyatt Informational [Page 28] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-31  All valid sequences of TCP packets (defined in [RFC0793])
         MUST be forwarded for outbound flows and explicitly permitted
         inbound flows.  In particular, both the normal TCP 3-way
         handshake mode of operation and the simultaneous-open mode of
         operation MUST be supported.
 REC-32  The TCP window invariant MUST NOT be enforced on flows for
         which the filter did not detect whether the window-scale
         option (see [RFC1323]) was sent in the 3-way handshake or
         simultaneous-open.
 REC-33  If application transparency is most important, then a
         stateful packet filter SHOULD have "endpoint-independent
         filtering" behavior for TCP.  If a more stringent filtering
         behavior is most important, then a filter SHOULD have
         "address-dependent filtering" behavior.  The filtering
         behavior MAY be an option configurable by the network
         administrator, and it MAY be independent of the filtering
         behavior for UDP and other protocols.  Filtering behavior
         SHOULD be endpoint independent by DEFAULT in gateways
         intended for provisioning without service-provider
         management.
 REC-34  By DEFAULT, a gateway MUST respond with an ICMPv6
         "Destination Unreachable" error code 1 (Communication with
         destination administratively prohibited), to any unsolicited
         inbound SYN packet after waiting at least 6 seconds without
         first forwarding the associated outbound SYN or SYN/ACK from
         the interior peer.
 REC-35  If a gateway cannot determine whether the endpoints of a TCP
         flow are active, then it MAY abandon the state record if it
         has been idle for some time.  In such cases, the value of the
         "established flow idle-timeout" MUST NOT be less than
         two hours four minutes, as discussed in [RFC5382].  The value
         of the "transitory flow idle-timeout" MUST NOT be less than
         four minutes.  The value of the idle-timeouts MAY be
         configurable by the network administrator.
 REC-36  If a gateway forwards a TCP flow, it MUST also forward ICMPv6
         "Destination Unreachable" and "Packet Too Big" messages
         containing TCP headers that match the flow state record.
 REC-37  Receipt of any sort of ICMPv6 message MUST NOT terminate the
         state record for a TCP flow.

Woodyatt Informational [Page 29] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-38  All valid sequences of SCTP packets (defined in [RFC4960])
         MUST be forwarded for outbound associations and explicitly
         permitted inbound associations.  In particular, both the
         normal SCTP association establishment and the simultaneous-
         open mode of operation MUST be supported.
 REC-39  By DEFAULT, a gateway MUST respond with an ICMPv6
         "Destination Unreachable" error code 1 (Communication with
         destination administratively prohibited) to any unsolicited
         inbound INIT packet after waiting at least 6 seconds without
         first forwarding the associated outbound INIT from the
         interior peer.
 REC-40  If a gateway cannot determine whether the endpoints of an
         SCTP association are active, then it MAY abandon the state
         record if it has been idle for some time.  In such cases, the
         value of the "established association idle-timeout" MUST NOT
         be less than two hours four minutes.  The value of the
         "transitory association idle-timeout" MUST NOT be less than
         four minutes.  The value of the idle-timeouts MAY be
         configurable by the network administrator.
 REC-41  If a gateway forwards an SCTP association, it MUST also
         forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
         messages containing SCTP headers that match the association
         state record.
 REC-42  Receipt of any sort of ICMPv6 message MUST NOT terminate the
         state record for an SCTP association.
 REC-43  All valid sequences of DCCP packets (defined in [RFC4340])
         MUST be forwarded for all flows to exterior servers, and for
         any flows to interior servers with explicitly permitted
         service codes.
 REC-44  A gateway MAY abandon a DCCP state record if it has been
         idle for some time.  In such cases, the value of the "open
         flow idle-timeout" MUST NOT be less than two hours
         four minutes.  The value of the "transitory flow idle-
         timeout" MUST NOT be less than eight minutes.  The value of
         the idle-timeouts MAY be configurable by the network
         administrator.
 REC-45  If an Internet gateway forwards a DCCP flow, it MUST also
         forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
         messages containing DCCP headers that match the flow state
         record.

Woodyatt Informational [Page 30] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 REC-46  Receipt of any sort of ICMPv6 message MUST NOT terminate the
         state record for a DCCP flow.
 REC-47  Valid sequences of packets bearing Shim6 payload extension
         headers in their outer IP extension header chains MUST be
         forwarded for all outbound and explicitly permitted flows.
         The content of the Shim6 payload extension header MAY be
         ignored for the purpose of state tracking.
 REC-48  Internet gateways with IPv6 simple security capabilities
         SHOULD implement a protocol to permit applications to solicit
         inbound traffic without advance knowledge of the addresses of
         exterior nodes with which they expect to communicate.
 REC-49  Internet gateways with IPv6 simple security capabilities MUST
         provide an easily selected configuration option that permits
         a "transparent mode" of operation that forwards all
         unsolicited flows regardless of forwarding direction, i.e.,
         not to use the IPv6 simple security capabilities of the
         gateway.  The transparent mode of operation MAY be the
         default configuration.
 REC-50  By DEFAULT, subscriber-managed residential gateways MUST NOT
         offer management application services to the exterior
         network.

5. Contributors

 Comments and criticisms during the development of this document were
 received from the following IETF participants:
          +-------------------+----------------------------+
          | Jari Arkko        | Ran Atkinson               |
          | Fred Baker        | Norbert Bollow             |
          | Cameron Byrne     | Brian Carpenter            |
          | Remi Despres      | Arnaud Ebalard             |
          | Fabrice Fontaine  | Jun-ichiro "itojun" Hagino |
          | Thomas Herbst     | Christian Huitema          |
          | Joel Jaeggli      | Cullen Jennings            |
          | Suresh Krishnan   | Erik Kline                 |
          | Julien Laganier   | Kurt Erik Lindqvist        |
          | Mohamed Boucadair | Keith Moore                |
          | Robert Moskowitz  | Teemu Savolainen           |
          | Hemant Singh      | Yaron Sheffer              |
          | Mark Townsley     | Iljitsch van Beijnum       |
          | Magnus Westerlund | Dan Wing                   |
          +-------------------+----------------------------+

Woodyatt Informational [Page 31] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 The editor thanks them all for their contributions.
 It must be noted that a substantial portion of the text describing
 the detailed requirements for TCP and UDP filtering is derived or
 transposed from [RFC4787] and [RFC5382].  The editors of those
 documents, Francois Audet and Saikat Guha, also deserve substantial
 credit for the form of the present document.

6. Security Considerations

 The IPv6 stateful filtering behavior described in this document is
 intended to be similar in function to the filtering behavior of
 commonly used IPv4/NAT gateways, which have been widely sold as a
 security tool for residential and small-office/home-office networks.
 As noted in the Security Considerations section of [RFC2993], the
 true impact of these tools may be a reduction in security.  It may be
 generally assumed that the impacts discussed in that document related
 to filtering (and not translation) are to be expected with the simple
 IPv6 security mechanisms described here.
 In particular, it is worth noting that stateful filters create the
 illusion of a security barrier, but without the managed intent of a
 firewall.  Appropriate security mechanisms implemented in the end
 nodes, in conjunction with the [RFC4864] local network protection
 methods, function without reliance on network layer hacks and
 transport filters that may change over time.  Also, defined security
 barriers assume that threats originate in the exterior, which may
 lead to practices that result in applications being fully exposed to
 interior attack and which therefore make breaches much easier.
 The security functions described in this document may be considered
 redundant in the event that all IPv6 hosts using a particular gateway
 have their own IPv6 host firewall capabilities enabled.  At the time
 of this writing, the vast majority of commercially available
 operating systems with support for IPv6 include IPv6 host firewall
 capability.
 Also worth noting explicitly, a practical side-effect of the
 recommendations in Section 3.2.4, to allow inbound IPsec and IKE
 flows from exterior to interior, is to facilitate more transparent
 communication by the use of an unauthenticated mode of IPsec, as
 described in "Better-Than-Nothing-Security: An Unauthenticated Mode
 of IPsec" [RFC5386], and this may be a departure from expectations of
 transparency set by traditional IPv4/NAT residential gateways.
 Finally, residential gateways that implement simple security
 functions are a bastion between the interior and the exterior, and
 therefore are a target of denial-of-service attacks against the

Woodyatt Informational [Page 32] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 interior network itself by processes designed to consume the
 resources of the gateway, e.g., a ping or SYN flood.  Gateways should
 employ the same sorts of protection techniques as application servers
 on the Internet.
 The IETF makes no statement, expressed or implied, as to whether
 using the capabilities described in this document ultimately improves
 security for any individual users or for the Internet community as a
 whole.

7. References

7.1. Normative References

 [RFC0768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.
 [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7,
             RFC 793, September 1981.
 [RFC1323]   Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
             for High Performance", RFC 1323, May 1992.
 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.
 [RFC3315]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
             and M. Carney, "Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6)", RFC 3315, July 2003.
 [RFC3775]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
             in IPv6", RFC 3775, June 2004.
 [RFC3828]   Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
             G. Fairhurst, "The Lightweight User Datagram Protocol
             (UDP-Lite)", RFC 3828, July 2004.
 [RFC3879]   Huitema, C. and B. Carpenter, "Deprecating Site Local
             Addresses", RFC 3879, September 2004.
 [RFC4007]   Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
             B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
             March 2005.

Woodyatt Informational [Page 33] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 [RFC4193]   Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
             Addresses", RFC 4193, October 2005.
 [RFC4302]   Kent, S., "IP Authentication Header", RFC 4302,
             December 2005.
 [RFC4303]   Kent, S., "IP Encapsulating Security Payload (ESP)",
             RFC 4303, December 2005.
 [RFC4340]   Kohler, E., Handley, M., and S. Floyd, "Datagram
             Congestion Control Protocol (DCCP)", RFC 4340,
             March 2006.
 [RFC4443]   Conta, A., Deering, S., and M. Gupta, "Internet Control
             Message Protocol (ICMPv6) for the Internet Protocol
             Version 6 (IPv6) Specification", RFC 4443, March 2006.
 [RFC4787]   Audet, F. and C. Jennings, "Network Address Translation
             (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
             RFC 4787, January 2007.
 [RFC4890]   Davies, E. and J. Mohacsi, "Recommendations for Filtering
             ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
 [RFC4960]   Stewart, R., "Stream Control Transmission Protocol",
             RFC 4960, September 2007.
 [RFC5095]   Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
             of Type 0 Routing Headers in IPv6", RFC 5095,
             December 2007.
 [RFC5156]   Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
             April 2008.
 [RFC5201]   Moskowitz, R., Nikander, P., Jokela, P., and T.
             Henderson, "Host Identity Protocol", RFC 5201,
             April 2008.
 [RFC5996]   Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
             "Internet Key Exchange Protocol Version 2 (IKEv2)",
             RFC 5996, September 2010.

Woodyatt Informational [Page 34] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

7.2. Informative References

 [NAT-PMP]   Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
             Mapping Protocol (NAT-PMP)", Work in Progress,
             April 2008.
 [RFC1122]   Braden, R., "Requirements for Internet Hosts -
             Communication Layers", STD 3, RFC 1122, October 1989.
 [RFC1337]   Braden, B., "TIME-WAIT Assassination Hazards in TCP",
             RFC 1337, May 1992.
 [RFC1918]   Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
             and E. Lear, "Address Allocation for Private Internets",
             BCP 5, RFC 1918, February 1996.
 [RFC1981]   McCann, J., Deering, S., and J. Mogul, "Path MTU
             Discovery for IP version 6", RFC 1981, August 1996.
 [RFC2473]   Conta, A. and S. Deering, "Generic Packet Tunneling in
             IPv6 Specification", RFC 2473, December 1998.
 [RFC2827]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
             Defeating Denial of Service Attacks which employ IP
             Source Address Spoofing", BCP 38, RFC 2827, May 2000.
 [RFC2993]   Hain, T., "Architectural Implications of NAT", RFC 2993,
             November 2000.
 [RFC3704]   Baker, F. and P. Savola, "Ingress Filtering for
             Multihomed Networks", BCP 84, RFC 3704, March 2004.
 [RFC4080]   Hancock, R., Karagiannis, G., Loughney, J., and S. Van
             den Bosch, "Next Steps in Signaling (NSIS): Framework",
             RFC 4080, June 2005.
 [RFC4294]   Loughney, J., "IPv6 Node Requirements", RFC 4294,
             April 2006.
 [RFC4864]   Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
             E. Klein, "Local Network Protection for IPv6", RFC 4864,
             May 2007.
 [RFC4949]   Shirey, R., "Internet Security Glossary, Version 2",
             RFC 4949, August 2007.

Woodyatt Informational [Page 35] RFC 6092 Simple Security in IPv6 Gateway CPE January 2011

 [RFC5189]   Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
             Communication (MIDCOM) Protocol Semantics", RFC 5189,
             March 2008.
 [RFC5382]   Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
             Srisuresh, "NAT Behavioral Requirements for TCP",
             BCP 142, RFC 5382, October 2008.
 [RFC5386]   Williams, N. and M. Richardson, "Better-Than-Nothing
             Security: An Unauthenticated Mode of IPsec", RFC 5386,
             November 2008.
 [RFC5389]   Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
             "Session Traversal Utilities for NAT (STUN)", RFC 5389,
             October 2008.
 [RFC5533]   Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
             Shim Protocol for IPv6", RFC 5533, June 2009.
 [UPnP-IGD]  UPnP Forum, "Universal Plug and Play Internet Gateway
             Device Standardized Device Control Protocol",
             September 2010, <http://upnp.org/specs/gw/igd2/>.
 [WOODYATT-ALD]
             Woodyatt, J., "Application Listener Discovery (ALD) for
             IPv6", Work in Progress, July 2008.

Author's Address

 James Woodyatt (editor)
 Apple Inc.
 1 Infinite Loop
 Cupertino, CA  95014
 US
 EMail: jhw@apple.com

Woodyatt Informational [Page 36]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6092.txt · Last modified: 2011/01/25 01:26 (external edit)