Skip to main content

Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
draft-ietf-v6ops-cpe-simple-security-16

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6092.
Author james woodyatt
Last updated 2022-05-25 (Latest revision 2010-10-21)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 6092 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ron Bonica
Send notices to (None)
draft-ietf-v6ops-cpe-simple-security-16
IPv6 Operations                                         j. woodyatt, Ed.
Internet-Draft                                                     Apple
Intended status: Informational                          October 21, 2010
Expires: April 24, 2011

Recommended Simple Security Capabilities in Customer Premises Equipment
            for Providing Residential IPv6 Internet Service
                draft-ietf-v6ops-cpe-simple-security-16

Abstract

   This document identifies a set of recommendations for the makers of
   devices describing 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 24, 2011.

Copyright Notice

   Copyright (c) 2010 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                 Expires April 24, 2011                 [Page 1]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

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  . . . . . . . . . . . . . . . . . . . .  6
     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  . . . . . . . . . . . . . . . . . . . . . 13
       3.3.2.  SCTP Filters . . . . . . . . . . . . . . . . . . . . . 17
       3.3.3.  DCCP Filters . . . . . . . . . . . . . . . . . . . . . 20
       3.3.4.  Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 22
     3.4.  Passive Listeners  . . . . . . . . . . . . . . . . . . . . 22
     3.5.  Management Applications  . . . . . . . . . . . . . . . . . 23
   4.  Summary of Recommendations . . . . . . . . . . . . . . . . . . 24
   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 34
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35

woodyatt                 Expires April 24, 2011                 [Page 2]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

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                 Expires April 24, 2011                 [Page 3]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

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, a Wi-Fi
   network, 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. anti-spoofing and "martian" [RFC4949] filters.

   o  Allow tracking of applications 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
   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

woodyatt                 Expires April 24, 2011                 [Page 4]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 residential gateways, the
   best current practice has not yet been established.

2.1.  Basic Sanitation

   In addition to the functions required of all Internet 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 the DEFAULT operating
   mode for residential IPv6 simple security is 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 the DEFAULT operating mode
   permit IPsec.  To facilitate the use of IPsec in support of IPv6
   Mobility, Internet Key Exchange (IKE) protocol [RFC5996] and "Host
   Identity Protocol (HIP)" [RFC5201] should also be permitted in the
   DEFAULT operating mode.

woodyatt                 Expires April 24, 2011                 [Page 5]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

2.3.  Transport Layer Protocols

   IPv6 simple security functions are principally concerned with the
   stateful filtering of Internet Control Message Protocol (ICMPv6)
   [RFC4443] and transport layers like User Datagram Protocol (UDP)
   [RFC0768], Lightweight User Datagram Protocol (UDP-Lite) [RFC3828],
   Transport 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.

3.1.  Stateless Filters

   Certain kinds of IPv6 packets MUST NOT be forwarded in either
   direction by residential Internet gateways regardless of network

woodyatt                 Expires April 24, 2011                 [Page 6]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 which bear in their outer IPv6 headers multicast
   source addresses MUST NOT be forwarded or transmitted on any
   interface.

   REC-2: Packets which bear in their outer IPv6 headers multicast
   destination addresses 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 addresses with IPv4-Mapped, IPv4-Compatible, Documentation and
   ORCHID prefixes.

   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.

   REC-8: By DEFAULT, inbound DNS queries received on exterior
   interfaces MUST NOT be processed by any integrated DNS resolving

woodyatt                 Expires April 24, 2011                 [Page 7]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 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.

   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.

woodyatt                 Expires April 24, 2011                 [Page 8]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   One key aspect of how a packet filter behaves is the way it evaluates
   the exterior address of an enpoint 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 filter"
   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 softare updates to patch
   vulnerabilties 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
   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.

woodyatt                 Expires April 24, 2011                 [Page 9]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

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
   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.

   As described in Section 5.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.

woodyatt                 Expires April 24, 2011                [Page 10]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   REC-17: If application transparency is most important, then a
   stateful packet filter SHOULD have "endpoint independent filter"
   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.

   Applications mechanisms may depend on the reception of ICMPv6 error
   messages triggered by the transmission of UDP messages.  One such
   mechanism is path MTU discovery.

   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, and 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 suite (IPsec) 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 "Authenticated
   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                 Expires April 24, 2011                [Page 11]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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
   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.

   "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
   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
   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.

woodyatt                 Expires April 24, 2011                [Page 12]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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.

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 (Fig. 8, [RFC0793]) 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

woodyatt                 Expires April 24, 2011                [Page 13]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 (Fig. 6,
   [RFC0793]).

   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 modes 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 filter"
   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.

   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

woodyatt                 Expires April 24, 2011                [Page 14]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 (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.

   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

woodyatt                 Expires April 24, 2011                [Page 15]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 handing RST packets, or TCP flows in the TIME_WAIT state
   is left unspecified.  A gateway MAY hold state for a flow in
   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 (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
   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.

woodyatt                 Expires April 24, 2011                [Page 16]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

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 similar connection-
   oriented filtering behaviors as 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.

   Peer-to-peer 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 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 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 chunks is received
   at one end without an ERROR or ABORT chunk.

   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 (Fig. 3, [RFC4960]).

   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 simultaneous-open modes of operation
   MUST be supported.

woodyatt                 Expires April 24, 2011                [Page 17]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 simultaneous-open mode of operation.

   REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6
   "Destination Unreachable" error code 1 (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
   HEARTBEAT chunks and looking for the HEARTBEAT ACK response.  If the
   gateway cannot determine whether the endpoint is active, then the
   associated state records 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 [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

woodyatt                 Expires April 24, 2011                [Page 18]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 are relevant.

   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 (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"

woodyatt                 Expires April 24, 2011                [Page 19]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 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 (Section 8, [RFC4340]).

   REC-43: All valid sequences of DCCP packets (defined in [RFC4340])
   MUST be forwarded for all flows to exterior servers and those flows
   to interior servers with explicitly permitted service codes.

   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

woodyatt                 Expires April 24, 2011                [Page 20]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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 [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
   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 "established 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 handing DCCP-Reset packets, or flows in the TIMEWAIT
   state is left unspecified.  A gateway MAY hold state for a flow in
   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 exists 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 expires.  The decision
   either to discard or to respond with an ICMPv6 "Destination
   Unreachable" error code 1 (administratively prohibited) is left up to
   the implementation.

woodyatt                 Expires April 24, 2011                [Page 21]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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.

   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 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 [I-D.cheshire-nat-pmp] or [UPnP-IGD].  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.

woodyatt                 Expires April 24, 2011                [Page 22]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   While NAT for IPv6 is unlikely to be used in most residential
   gateways, the filtering effect of the simple security functions
   recommended by this document are derived from those in widespread use
   on the IPv4 Internet, and a similar barrier to communication at
   passive listeners is a natural outcome of its deployment.  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.

   One proposal that has been offered as an Internet Draft is the
   Application Listener Discovery Protocol [I-D.woodyatt-ald].  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 which require devices to be contacted
   inside the home directly, particularly in 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 security of

woodyatt                 Expires April 24, 2011                [Page 23]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   subscriber managed gateways merit special attention here.

   REC-50: By DEFAULT, subscriber managed residential gateways MUST NOT
   offer management application services to the exterior network.

4.  Summary of Recommendations

   This section collects all of the recommendations made in this
   document into a convenient list.

   REC-1   Packets bearing in their outer IPv6 headers multicast source
           addresses MUST NOT be forwarded or transmitted on any
           interface.

   REC-2   Packets which bear in their outer IPv6 headers multicast
           destination addresses 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 addresses with IPv4-
           Mapped, IPv4-Compatible, Documentation and ORCHID prefixes.

   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
           assigned 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                 Expires April 24, 2011                [Page 24]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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.

   REC-10  IPv6 gateways MUST forward ICMPv6 "Destination Unreachable"
           and "Packet Too Big" messages containing IP headers that
           match generic upper-layer transport state records.

   REC-11  If application transparency is most important, then a
           stateful packet filter SHOULD have "endpoint independent
           filter" 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.

woodyatt                 Expires April 24, 2011                [Page 25]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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.

   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
           filter" 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, and 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
           "Authenticated 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.

woodyatt                 Expires April 24, 2011                [Page 26]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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.

   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
           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.

woodyatt                 Expires April 24, 2011                [Page 27]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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.

   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 modes
           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
           filter" 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 (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.

woodyatt                 Expires April 24, 2011                [Page 28]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   REC-37  Receipt of any sort of ICMPv6 message MUST NOT terminate the
           state record for a TCP flow.

   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 simultaneous-open
           modes of operation MUST be supported.

   REC-39  By DEFAULT, a gateway MUST respond with an ICMPv6
           "Destination Unreachable" error code 1 (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 those
           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 "established
           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 a 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                 Expires April 24, 2011                [Page 29]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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  Gateways 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  Gateways 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. to disable 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        |
            | Boucadair Mohamed | Keith Moore                |
            | Robert Moskowitz  | Teemu Savolainen           |
            | Hemant Singh      | Yaron Sheffer              |
            | Mark Townsley     | Iljitsch van Beijnum       |
            | Magnus Westerlund | Dan Wing                   |
            +-------------------+----------------------------+

woodyatt                 Expires April 24, 2011                [Page 30]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   The IPv6 stateful filtering behavior described in this document is
   intended to be similar in function to the filtering behavior of
   commonly use 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 Better-Than-Nothing-Security: An
   Unauthenticated Mode of IPsec [RFC5386], and this may be a departure

woodyatt                 Expires April 24, 2011                [Page 31]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   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
   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.

   IETF makes no statement, expressed or implied, as to whether using
   the capabilities described in this document ultimately improve
   security for any individual users or for the Internet community as a
   whole.

8.  References

8.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

woodyatt                 Expires April 24, 2011                [Page 32]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

              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.

   [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                 Expires April 24, 2011                [Page 33]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

8.2.  Informative References

   [I-D.cheshire-nat-pmp]
              Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
              draft-cheshire-nat-pmp-03 (work in progress), April 2008.

   [I-D.woodyatt-ald]
              Woodyatt, J., "Application Listener Discovery (ALD) for
              IPv6", draft-woodyatt-ald-03 (work in progress),
              July 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.

   [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                 Expires April 24, 2011                [Page 34]
Internet-Draft     Simple Security in IPv6 Gateway CPE      October 2010

   [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 Gateway Device Protocol",
              September 2010, <http://upnp.org/specs/gw/igd2/>.

Author's Address

   james woodyatt (editor)
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   US

   Email: jhw@apple.com

woodyatt                 Expires April 24, 2011                [Page 35]