draft-ietf-v6ops-cpe-simple-security-16.txt   rfc6092.txt 
IPv6 Operations j. woodyatt, Ed. Internet Engineering Task Force (IETF) J. Woodyatt, Ed.
Internet-Draft Apple Request for Comments: 6092 Apple
Intended status: Informational October 21, 2010 Category: Informational January 2011
Expires: April 24, 2011 ISSN: 2070-1721
Recommended Simple Security Capabilities in Customer Premises Equipment Recommended Simple Security Capabilities in
for Providing Residential IPv6 Internet Service Customer Premises Equipment (CPE) for
draft-ietf-v6ops-cpe-simple-security-16 Providing Residential IPv6 Internet Service
Abstract Abstract
This document identifies a set of recommendations for the makers of This document identifies a set of recommendations for the makers of
devices describing how to provide for "simple security" capabilities devices and describes how to provide for "simple security"
at the perimeter of local-area IPv6 networks in Internet-enabled capabilities at the perimeter of local-area IPv6 networks in
homes and small offices. Internet-enabled homes and small offices.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on April 24, 2011. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 1.1. Special Language ...........................................3
1.2. Use of Normative Keywords . . . . . . . . . . . . . . . . 3 1.2. Use of Normative Keywords ..................................3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview ........................................................4
2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5 2.1. Basic Sanitation ...........................................5
2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5 2.2. Internet Layer Protocols ...................................5
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 2.3. Transport Layer Protocols ..................................6
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 3. Detailed Recommendations ........................................6
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6 3.1. Stateless Filters ..........................................7
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 3.2. Connection-Free Filters ....................................8
3.2.1. Internet Control and Management . . . . . . . . . . . 8 3.2.1. Internet Control and Management .....................8
3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8 3.2.2. Upper-Layer Transport Protocols .....................8
3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. UDP Filters ........................................10
3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 11 3.2.4. IPsec and Internet Key Exchange (IKE) ..............11
3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 12 3.2.5. Mobility Support in IPv6 ...........................12
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 13 3.3. Connection-Oriented Filters ...............................13
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. TCP Filters ........................................14
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 17 3.3.2. SCTP Filters .......................................17
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 20 3.3.3. DCCP Filters .......................................20
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 22 3.3.4. Level 3 Multihoming Shim Protocol for IPv6
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22 (Shim6) ............................................23
3.5. Management Applications . . . . . . . . . . . . . . . . . 23 3.4. Passive Listeners .........................................23
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 24 3.5. Management Applications ...................................24
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Summary of Recommendations .....................................25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. Contributors ...................................................31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations ........................................32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. References .....................................................33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 7.1. Normative References ......................................33
8.2. Informative References . . . . . . . . . . . . . . . . . . 34 7.2. Informative References ....................................35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Some IPv6 gateway devices that enable delivery of Internet services Some IPv6 gateway devices that enable delivery of Internet services
in residential and small office settings may be augmented with in residential and small-office settings may be augmented with
'simple security' capabilities as described in "Local Network "simple security" capabilities as described in "Local Network
Protection for IPv6" [RFC4864]. In general, these capabilities cause Protection for IPv6" [RFC4864]. In general, these capabilities cause
packets to be discarded in an attempt to make local networks and the packets to be discarded in an attempt to make local networks and the
Internet more secure. However, it is worth noting that some packets Internet more secure. However, it is worth noting that some packets
sent by legitimate applications may also be discarded in this sent by legitimate applications may also be discarded in this
process, affecting reliability and ease of use for these process, affecting reliability and ease of use for these
applications. applications.
There is a constructive tension between the desires of users for There is a constructive tension between the desires of users for
transparent end-to-end connectivity on the one hand, and the need for transparent end-to-end connectivity on the one hand, and the need for
local-area network administrators to detect and prevent intrusion by local-area network administrators to detect and prevent intrusion by
unauthorized public Internet users on the other. This document is unauthorized public Internet users on the other. This document is
intended to highlight reasonable limitations on end-to-end intended to highlight reasonable limitations on end-to-end
transparency where security considerations are deemed important to transparency where security considerations are deemed important to
promote local and Internet security. promote local and Internet security.
The reader is cautioned always to remember that the typical The reader is cautioned always to remember that the typical
residential or small office network administrator has no expertise residential or small-office network administrator has no expertise
whatsoever in Internet engineering. Configuration interfaces for whatsoever in Internet engineering. Configuration interfaces for
router/gateway appliances marketed toward them should be easy to router/gateway appliances marketed toward them should be easy to
understand and even easier to ignore. In particular, extra care understand and even easier to ignore. In particular, extra care
should be used in the design of baseline operating modes for should be used in the design of baseline operating modes for
unconfigured devices, since most devices will never be changed from unconfigured devices, since most devices will never be changed from
their factory configurations. their factory configurations.
1.1. Special Language 1.1. Special Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Additionally, the key word "DEFAULT" is to be interpreted in this Additionally, the key word "DEFAULT" is to be interpreted in this
document as pertaining to a configuration as applied by a vendor, document as pertaining to a configuration as applied by a vendor,
prior to the administrator changing it for its initial activation. prior to the administrator changing it for its initial activation.
1.2. Use of Normative Keywords 1.2. Use of Normative Keywords
NOTE WELL: This document is not a standard, and conformance with it NOTE WELL: This document is not a standard, and conformance with
is not required in order to claim conformance with IETF standards for it is not required in order to claim conformance with IETF
IPv6. It uses the normative keywords defined in the previous section standards for IPv6. It uses the normative keywords defined in the
only for precision. previous section only for precision.
Particular attention is drawn to recommendation REC-49, which calls Particular attention is drawn to recommendation REC-49, which calls
for an easy way to set a gateway to a transparent mode of operation. for an easy way to set a gateway to a transparent mode of operation.
2. Overview 2. Overview
For the purposes of this document, residential Internet gateways are For the purposes of this document, residential Internet gateways are
assumed to be fairly simple devices with a limited subset of the full assumed to be fairly simple devices with a limited subset of the full
range of possible features. They function as default routers range of possible features. They function as default routers
[RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi [RFC4294] for a single local-area network, e.g., an Ethernet network,
network, a bridge between two or more such segments. They have only a Wi-Fi network, or a bridge between two or more such segments. They
one interface by which they can access the Internet service at any have only one interface by which they can access the Internet service
one time, using any of several possible sub-IP mechanisms including at any one time, using any of several possible sub-IP mechanisms,
tunnels and transition mechanisms. including tunnels and transition mechanisms.
In referring to the security capabilities of residential gateways, it In referring to the security capabilities of residential gateways, it
is reasonable to distinguish between their "interior" network, i.e. is reasonable to distinguish between their "interior" network, i.e.,
the local-area network, and their "exterior" networks, e.g. the the local-area network, and their "exterior" networks, e.g., the
public Internet and the networks of Internet service providers. This public Internet and the networks of Internet service providers. This
document is concerned only with the behavior of IP packet filters document is concerned only with the behavior of IP packet filters
that police the flow of traffic between the interior IPv6 network and that police the flow of traffic between the interior IPv6 network and
the exterior IPv6 networks of residential Internet gateways. the exterior IPv6 networks of residential Internet gateways.
The operational goals of security capabilities in Internet gateways The operational goals of security capabilities in Internet gateways
are described with more detail in "Local Network Protection for IPv6" are described with more detail in "Local Network Protection for IPv6"
[RFC4864], but they can be summarized as follows. [RFC4864], but they can be summarized as follows.
o Check all traffic to and from the public Internet for basic o Check all traffic to and from the public Internet for basic
sanity, e.g. anti-spoofing and "martian" [RFC4949] filters. sanity, e.g., filter for spoofs and misdirected (sometimes called
"Martian") packets [RFC4949].
o Allow tracking of applications usage by source and destination o Allow tracking of application usage by source and destination
network addresses and ports. network addresses and ports.
o Provide a barrier against untrusted external influences on the o Provide a barrier against untrusted external influences on the
interior network by requiring filter state to be activated by interior network by requiring filter state to be activated by
traffic originating at interior network nodes. traffic originating at interior network nodes.
o Allow manually configured exceptions to the stateful filtering o Allow manually configured exceptions to the stateful filtering
rules according to network administrative policy. rules according to network administrative policy.
o Isolate local network DHCPv6 and DNS resolver services from the o Isolate local network DHCPv6 and DNS resolver services from the
skipping to change at page 5, line 14 skipping to change at page 5, line 19
already in place. already in place.
Conventional stateful packet filters activate new states as a side Conventional stateful packet filters activate new states as a side
effect of forwarding outbound flow initiations from interior network effect of forwarding outbound flow initiations from interior network
nodes. This requires applications to have advance knowledge of the nodes. This requires applications to have advance knowledge of the
addresses of exterior nodes with which they expect to communicate. addresses of exterior nodes with which they expect to communicate.
Several proposals are currently under consideration for allowing Several proposals are currently under consideration for allowing
applications to solicit inbound traffic from exterior nodes without applications to solicit inbound traffic from exterior nodes without
advance knowledge of their addresses. While consensus within the advance knowledge of their addresses. While consensus within the
Internet engineering community has emerged that such protocols are Internet engineering community has emerged that such protocols are
necessary to implement in residential IPv6 residential gateways, the necessary to implement in residential IPv6 gateways, the best current
best current practice has not yet been established. practice has not yet been established.
2.1. Basic Sanitation 2.1. Basic Sanitation
In addition to the functions required of all Internet routers In addition to the functions required of all IPv6 routers [RFC4294],
[RFC4294], residential gateways are expected to have basic stateless residential gateways are expected to have basic stateless filters for
filters for prohibiting certain kinds of traffic with invalid prohibiting certain kinds of traffic with invalid headers, e.g.,
headers, e.g. "martian" packets, spoofs, routing header type code "Martian" packets, spoofs, routing header type code zero, etc. (See
zero, etc. (See Section 3.1 for more details.) Section 3.1 for more details.)
Conversely, simple Internet gateways are not expected to prohibit the Conversely, simple Internet gateways are not expected to prohibit the
development of new applications. In particular, packets with end-to- development of new applications. In particular, packets with end-to-
end network security and routing extension headers for mobility are end network security and routing extension headers for mobility are
expected to pass Internet gateways freely. expected to pass Internet gateways freely.
Finally, Internet gateways that route multicast traffic are expected Finally, Internet gateways that route multicast traffic are expected
to implement appropriate filters for multicast traffic to limit the to implement appropriate filters for multicast traffic to limit the
scope of multicast groups that span the demarcation between scope of multicast groups that span the demarcation between
residential networks and service provider networks. residential networks and service provider networks.
2.2. Internet Layer Protocols 2.2. Internet Layer Protocols
As virtual private networking tunnels are regarded as an unacceptably As virtual private networking tunnels are regarded as an unacceptably
wide attack surface, this document recommends the DEFAULT operating wide attack surface, this document recommends that the DEFAULT
mode for residential IPv6 simple security is to treat Generic Packet operating mode for residential IPv6 simple security be to treat
Tunneling [RFC2473] and similar protocols as opaque transport layers, Generic Packet Tunneling [RFC2473] and similar protocols as opaque
i.e. inbound tunnel initiations are denied and outbound tunnel transport layers, i.e., inbound tunnel initiations are denied and
initiations are accepted. outbound tunnel initiations are accepted.
IPsec transport and tunnel modes are explicitly secured by IPsec transport and tunnel modes are explicitly secured by
definition, so this document recommends the DEFAULT operating mode definition, so this document recommends that the DEFAULT operating
permit IPsec. To facilitate the use of IPsec in support of IPv6 mode permit IPsec. To facilitate the use of IPsec in support of IPv6
Mobility, Internet Key Exchange (IKE) protocol [RFC5996] and "Host mobility, the Internet Key Exchange (IKE) protocol [RFC5996] and the
Identity Protocol (HIP)" [RFC5201] should also be permitted in the Host Identity Protocol (HIP) [RFC5201] should also be permitted in
DEFAULT operating mode. the DEFAULT operating mode.
2.3. Transport Layer Protocols 2.3. Transport Layer Protocols
IPv6 simple security functions are principally concerned with the IPv6 simple security functions are principally concerned with the
stateful filtering of Internet Control Message Protocol (ICMPv6) stateful filtering of the Internet Control Message Protocol (ICMPv6)
[RFC4443] and transport layers like User Datagram Protocol (UDP) [RFC4443] and transport layers like the User Datagram Protocol (UDP)
[RFC0768], Lightweight User Datagram Protocol (UDP-Lite) [RFC3828], [RFC0768], the Lightweight User Datagram Protocol (UDP-Lite)
Transport Control Protocol (TCP) [RFC0793], the Stream Control [RFC3828], the Transmission Control Protocol (TCP) [RFC0793], the
Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram
Control Protocol (DCCP) [RFC4340], and potentially any standards- Congestion Control Protocol (DCCP) [RFC4340], and potentially any
track transport protocols to be defined in the future. standards-track transport protocols to be defined in the future.
The general operating principle is that transport layer traffic is The general operating principle is that transport layer traffic is
not forwarded into the interior network of a residential IPv6 gateway not forwarded into the interior network of a residential IPv6 gateway
unless it has been solicited explicitly by interior transport unless it has been solicited explicitly by interior transport
endpoints, e.g. by matching the reverse path for previously forwarded endpoints, e.g., by matching the reverse path for previously
outbound traffic, or by matching configured exceptions set by the forwarded outbound traffic, or by matching configured exceptions set
network administrator. All other traffic is expected to be discarded by the network administrator. All other traffic is expected to be
or rejected with an ICMPv6 error message to indicate the traffic is discarded or rejected with an ICMPv6 error message to indicate the
administratively prohibited. traffic is administratively prohibited.
3. Detailed Recommendations 3. Detailed Recommendations
This section describes the specific recommendations made by this This section describes the specific recommendations made by this
document in full detail. Section 4 is a summary. document in full detail. Section 4 is a summary.
Some recommended filters are to be applied to all traffic that passes Some recommended filters are to be applied to all traffic that passes
through residential Internet gateways regardless of the direction through residential Internet gateways regardless of the direction
they are to be forwarded. Other recommended filters are intended to they are to be forwarded. Other recommended filters are intended to
be sensitive to the "direction" of traffic flows. Applied to be sensitive to the "direction" of traffic flows. Applied to
skipping to change at page 7, line 6 skipping to change at page 7, line 11
said to be "inbound" if the originator of the initial packet is an 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 exterior node and one or more of the participants are nodes on the
interior network. interior network.
3.1. Stateless Filters 3.1. Stateless Filters
Certain kinds of IPv6 packets MUST NOT be forwarded in either Certain kinds of IPv6 packets MUST NOT be forwarded in either
direction by residential Internet gateways regardless of network direction by residential Internet gateways regardless of network
state. These include packets with multicast source addresses, state. These include packets with multicast source addresses,
packets to destinations with certain non-routable and/or reserved packets to destinations with certain non-routable and/or reserved
prefixes and packets with deprecated extension headers. prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to implement ingress Other stateless filters are recommended to implement ingress
filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope
boundaries, and to isolate certain local network services from the boundaries, and to isolate certain local network services from the
public Internet. public Internet.
REC-1: Packets which bear in their outer IPv6 headers multicast REC-1: Packets bearing multicast source addresses in their outer IPv6
source addresses MUST NOT be forwarded or transmitted on any headers MUST NOT be forwarded or transmitted on any interface.
interface.
REC-2: Packets which bear in their outer IPv6 headers multicast REC-2: Packets bearing multicast destination addresses in their outer
destination addresses of equal or narrower scope (see IPv6 Scoped IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address
Address Architecture [RFC4007]) than the configured scope boundary Architecture" [RFC4007]) than the configured scope boundary level of
level of the gateway MUST NOT be forwarded in any direction. The the gateway MUST NOT be forwarded in any direction. The DEFAULT
DEFAULT scope boundary level SHOULD be organization-local scope, and scope boundary level SHOULD be organization-local scope, and it
it SHOULD be configurable by the network administrator. SHOULD be configurable by the network administrator.
REC-3: Packets bearing source and/or destination addresses forbidden REC-3: Packets bearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over the public to appear in the outer headers of packets transmitted over the public
Internet MUST NOT be forwarded. In particular, site-local addresses Internet MUST NOT be forwarded. In particular, site-local addresses
are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use
of addresses with IPv4-Mapped, IPv4-Compatible, Documentation and of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible
ORCHID prefixes. Addresses, Documentation Prefix, and Overlay Routable Cryptographic
Hash IDentifiers (ORCHID).
REC-4: Packets bearing deprecated extension headers prior to their REC-4: Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be forwarded or first upper-layer-protocol header SHOULD NOT be forwarded or
transmitted on any interface. In particular, all packets with transmitted on any interface. In particular, all packets with
routing extension header type 0 [RFC2460] preceding the first upper- routing extension header type 0 [RFC2460] preceding the first upper-
layer-protocol header MUST NOT be forwarded. See [RFC5095] for layer-protocol header MUST NOT be forwarded. See [RFC5095] for
additional background. additional background.
REC-5: Outbound packets MUST NOT be forwarded if the source address REC-5: Outbound packets MUST NOT be forwarded if the source address
in their outer IPv6 header does not have a unicast prefix configured in their outer IPv6 header does not have a unicast prefix configured
skipping to change at page 8, line 10 skipping to change at page 8, line 17
the exterior network. the exterior network.
REC-8: By DEFAULT, inbound DNS queries received on exterior REC-8: By DEFAULT, inbound DNS queries received on exterior
interfaces MUST NOT be processed by any integrated DNS resolving interfaces MUST NOT be processed by any integrated DNS resolving
server. server.
REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
exterior interfaces MUST NOT be processed by any integrated DHCPv6 exterior interfaces MUST NOT be processed by any integrated DHCPv6
server or relay agent. server or relay agent.
NOTE WELL: nothing in this document relieves residential Internet NOTE WELL: Nothing in this document relieves residential Internet
gateways, when processing headers to identify valid sequences of gateways, when processing headers to identify valid sequences of
upper-layer transport packets, from any of the requirements of the upper-layer transport packets, from any of the requirements of the
Internet Protocol, Version 6 (IPv6) Specification [RFC2460], "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460],
including any and all future updates and revisions. including any and all future updates and revisions.
3.2. Connection-free Filters 3.2. Connection-Free Filters
Some Internet applications use connection-free transport protocols Some Internet applications use connection-free transport protocols
with no release semantics, e.g. UDP. These protocols pose a special with no release semantics, e.g., UDP. These protocols pose a special
difficulty for stateful packet filters because most of the difficulty for stateful packet filters because most of the
application state is not carried at the transport level. State application state is not carried at the transport level. State
records are created when communication is initiated and abandoned records are created when communication is initiated and are abandoned
when no further communication is detected after some period of time. when no further communication is detected after some period of time.
3.2.1. Internet Control and Management 3.2.1. Internet Control and Management
Recommendations for filtering ICMPv6 messages in firewall devices are Recommendations for filtering ICMPv6 messages in firewall devices are
described separately in [RFC4890] and apply to residential gateways described separately in [RFC4890] and apply to residential gateways,
with the additional recommendation that incoming "Destination with the additional recommendation that incoming "Destination
Unreachable" and "Packet Too Big" error messages that don't match any Unreachable" and "Packet Too Big" error messages that don't match any
filtering state should be dropped. filtering state should be dropped.
REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
Unreachable" and "Packet Too Big" messages containing IP headers that Unreachable" and "Packet Too Big" messages containing IP headers that
do not match generic upper-layer transport state records. do not match generic upper-layer transport state records.
3.2.2. Upper-layer Transport Protocols 3.2.2. Upper-Layer Transport Protocols
Residential IPv6 gateways are not expected to prohibit the use of Residential IPv6 gateways are not expected to prohibit the use of
applications to be developed using future upper-layer transport applications to be developed using future upper-layer transport
protocols. In particular, transport protocols not otherwise protocols. In particular, transport protocols not otherwise
discussed in subsequent sections of this document are expected to be discussed in subsequent sections of this document are expected to be
treated consistently, i.e. as having connection-free semantics and no treated consistently, i.e., as having connection-free semantics and
special requirements to inspect the transport headers. no special requirements to inspect the transport headers.
In general, upper-layer transport filter state records are expected In general, upper-layer transport filter state records are expected
to be created when an interior endpoint sends a packet to an exterior to be created when an interior endpoint sends a packet to an exterior
address. The filter allocates (or reuses) a record for the duration address. The filter allocates (or reuses) a record for the duration
of communications, with an idle timer to delete the state record when of communications, with an idle timer to delete the state record when
no further communications are detected. no further communications are detected.
One key aspect of how a packet filter behaves is the way it evaluates 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 the exterior address of an endpoint when applying a filtering rule.
gateway is said to have "endpoint independent filtering" behavior A gateway is said to have "endpoint-independent filtering" behavior
when the exterior address is not evaluated when matching a packet when the exterior address is not evaluated when matching a packet
with a flow. A gateway is said to have "address dependent filtering" with a flow. A gateway is said to have "address-dependent filtering"
behavior when the exterior address of a packet is required to match behavior when the exterior address of a packet is required to match
the exterior address for its flow. the exterior address for its flow.
REC-11: If application transparency is most important, then a REC-11: If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent filter" stateful packet filter SHOULD have "endpoint-independent filtering"
behavior for generic upper-layer transport protocols. If a more behavior for generic upper-layer transport protocols. If a more
stringent filtering behavior is most important, then a filter SHOULD stringent filtering behavior is most important, then a filter SHOULD
have "address dependent filtering" behavior. The filtering behavior have "address-dependent filtering" behavior. The filtering behavior
MAY be an option configurable by the network administrator, and it MAY be an option configurable by the network administrator, and it
MAY be independent of the filtering behavior for other protocols. MAY be independent of the filtering behavior for other protocols.
Filtering behavior SHOULD be endpoint independent by DEFAULT in Filtering behavior SHOULD be endpoint independent by DEFAULT in
gateways intended for provisioning without service-provider gateways intended for provisioning without service-provider
management. management.
REC-12: Filter state records for generic upper-layer transport REC-12: Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer not protocols MUST NOT be deleted or recycled until an idle timer not
less than two minutes has expired without having forwarded a packet less than two minutes has expired without having forwarded a packet
matching the state in some configurable amount of time. By DEFAULT, matching the state in some configurable amount of time. By DEFAULT,
the idle timer for such state records is five minutes. the idle timer for such state records is five minutes.
The Internet security community is never completely at rest. New The Internet security community is never completely at rest. New
attack surfaces, and vulnerabilities in them, are typically attack surfaces, and vulnerabilities in them, are typically
discovered faster than they can be patched by normal equipment discovered faster than they can be patched by normal equipment
upgrade cycles. It's therefore important for vendors of residential upgrade cycles. It's therefore important for vendors of residential
gateway equipment to provide automatic softare updates to patch gateway equipment to provide automatic software updates to patch
vulnerabilties as they are discovered. vulnerabilities as they are discovered.
REC-13: Residential IPv6 gateways SHOULD provide a convenient means REC-13: Residential IPv6 gateways SHOULD provide a convenient means
to update their firmware securely, for the installation of security to update their firmware securely, for the installation of security
patches and other manufacturer-recommended changes. patches and other manufacturer-recommended changes.
Vendors can expect users and operators to have differing viewpoints Vendors can expect users and operators to have differing viewpoints
on the maintenance of patches, with some preferring automatic update on the maintenance of patches, with some preferring automatic update
and some preferring manual procedures. Those preferring automatic and some preferring manual procedures. Those preferring automatic
update may also prefer either to download from a vendor site or from update may also prefer either to download from a vendor site or from
one managed by their network provider. To handle the disparity, one managed by their network provider. To handle the disparity,
vendors are advised to provide both manual and automatic options. In vendors are advised to provide both manual and automatic options. In
the automatic case, they would do well to facilitate pre- the automatic case, they would do well to facilitate
configuration of the download URL and a means of validating the pre-configuration of the download URL and a means of validating the
software image such as a certificate. software image, such as a certificate.
3.2.3. UDP Filters 3.2.3. UDP Filters
"Network Address Translation (NAT) Behavioral Requirements for "Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP" [RFC4787] defines the terminology and best current Unicast UDP" [RFC4787] defines the terminology and best current
practice for stateful filtering of UDP applications in IPv4 with NAT, practice for stateful filtering of UDP applications in IPv4 with NAT,
which serves as the model for behavioral requirements for simple UDP which serves as the model for behavioral requirements for simple UDP
security in IPv6 gateways, notwithstanding the requirements related security in IPv6 gateways, notwithstanding the requirements related
specifically to network address translation. specifically to network address translation.
An interior endpoint initiates a UDP flow through a stateful packet An interior endpoint initiates a UDP flow through a stateful packet
filter by sending a packet to an exterior address. The filter filter by sending a packet to an exterior address. The filter
allocates (or reuses) a filter state record for the duration of the allocates (or reuses) a filter state record for the duration of the
flow. The state record defines the interior and exterior IP flow. The state record defines the interior and exterior IP
addresses and ports used between all packets in the flow. addresses and ports used between all packets in the flow.
State records for UDP flows remain active while they are in use and State records for UDP flows remain active while they are in use and
only abandoned after an idle period of some time. are only abandoned after an idle period of some time.
REC-14: A state record for a UDP flow where both source and REC-14: A state record for a UDP flow where both source and
destination ports are outside the well-known port range (ports destination ports are outside the well-known port range
0-1023) MUST NOT expire in less than two minutes of idle time. The (ports 0-1023) MUST NOT expire in less than two minutes of idle time.
value of the UDP state record idle timer MAY be configurable. The The value of the UDP state record idle timer MAY be configurable.
DEFAULT is five minutes. The DEFAULT is five minutes.
REC-15: A state record for a UDP flow where one or both of the source 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) 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 MAY expire after a period of idle time shorter than two minutes to
facilitate the operation of the IANA-registered service assigned to facilitate the operation of the IANA-registered service assigned to
the port in question. the port in question.
As [RFC4787] notes, outbound refresh is necessary for allowing the As [RFC4787] notes, outbound refresh is necessary for allowing the
interior endpoint to keep the state record alive. Inbound refresh interior endpoint to keep the state record alive. Inbound refresh
may be useful for applications with no outbound UDP traffic. may be useful for applications with no outbound UDP traffic.
However, allowing inbound refresh can allow an attacker in the However, allowing inbound refresh can allow an attacker in the
exterior or a misbehaving application to keep a state record alive exterior or a misbehaving application to keep a state record alive
indefinitely. This could be a security risk. Also, if the process indefinitely. This could be a security risk. Also, if the process
is repeated with different ports, over time, it could use up all the is repeated with different ports, over time, it could use up all the
state record memory and resources in the filter. state record memory and resources in the filter.
REC-16: A state record for a UDP flow MUST be refreshed when a packet 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 is forwarded from the interior to the exterior, and it MAY be
refreshed when a packet is forwarded in the reverse direction. refreshed when a packet is forwarded in the reverse direction.
As described in Section 5.5 of [RFC4787], the connection-free As described in Section 5 of [RFC4787], the connection-free semantics
semantics of UDP pose a difficulty for packet filters in trying to of UDP pose a difficulty for packet filters in trying to recognize
recognize which packets comprise an application flow and which are which packets comprise an application flow and which are unsolicited.
unsolicited. Various strategies have been used in IPv4/NAT gateways Various strategies have been used in IPv4/NAT gateways with differing
with differing effects. effects.
REC-17: If application transparency is most important, then a REC-17: If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent filter" stateful packet filter SHOULD have "endpoint-independent filtering"
behavior for UDP. If a more stringent filtering behavior is most behavior for UDP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "address dependent filtering" important, then a filter SHOULD have "address-dependent filtering"
behavior. The filtering behavior MAY be an option configurable by behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the filtering the network administrator, and it MAY be independent of the filtering
behavior for TCP and other protocols. Filtering behavior SHOULD be behavior for TCP and other protocols. Filtering behavior SHOULD be
endpoint independent by DEFAULT in gateways intended for provisioning endpoint independent by DEFAULT in gateways intended for provisioning
without service-provider management. without service-provider management.
Applications mechanisms may depend on the reception of ICMPv6 error Application mechanisms may depend on the reception of ICMPv6 error
messages triggered by the transmission of UDP messages. One such messages triggered by the transmission of UDP messages. One such
mechanism is path MTU discovery. mechanism is path MTU discovery [RFC1981].
REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6 REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing "Destination Unreachable" and "Packet Too Big" messages containing
UDP headers that match the flow state record. UDP headers that match the flow state record.
REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP flow. state record for a UDP flow.
REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
UDP flows, except that the upper-layer transport protocol identifier UDP flows, except that the upper-layer transport protocol identifier
for UDP-Lite is not the same as UDP, and therefore UDP packets MUST for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT
NOT match UDP-Lite state records, and vice versa. match UDP-Lite state records, and vice versa.
3.2.4. IPsec and Internet Key Exchange (IKE) 3.2.4. IPsec and Internet Key Exchange (IKE)
The Internet protocol security suite (IPsec) offers greater The Internet Protocol security (IPsec) suite offers greater
flexibility and better overall security than the simple security of flexibility and better overall security than the simple security of
stateful packet filtering at network perimeters. Therefore, stateful packet filtering at network perimeters. Therefore,
residential IPv6 gateways need not prohibit IPsec traffic flows. residential IPv6 gateways need not prohibit IPsec traffic flows.
REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with destination extension headers of type "Authenticated addresses, with destination extension headers of type "Authentication
Header (AH)" [RFC4302] in their outer IP extension header chain. Header (AH)" [RFC4302] in their outer IP extension header chain.
REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with an upper layer protocol of type "Encapsulating addresses, with an upper-layer protocol of type "Encapsulating
Security Payload (ESP)" [RFC4303] in their outer IP extension header Security Payload (ESP)" [RFC4303] in their outer IP extension header
chain. chain.
REC-23: If a gateway forwards an ESP flow, it MUST also forward (in REC-23: If a gateway forwards an ESP flow, it MUST also forward (in
the reverse direction) ICMPv6 "Destination Unreachable" and "Packet the reverse direction) ICMPv6 "Destination Unreachable" and "Packet
Too Big" messages containing ESP headers that match the flow state Too Big" messages containing ESP headers that match the flow state
record. record.
Internet Key Exchange (IKE) is a secure mechanism for performing Internet Key Exchange (IKE) is a secure mechanism for performing
mutual authentication, exchanging cryptographic material and mutual authentication, exchanging cryptographic material, and
establishing IPsec Security Associations between peers. Residential establishing IPsec Security Associations between peers. Residential
IPv6 gateways are expected to facilitate the use of IPsec security IPv6 gateways are expected to facilitate the use of IPsec security
policies by allowing inbound IKE flows. policies by allowing inbound IKE flows.
REC-24: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-24: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of any UDP packets, to and from legitimate prohibit the forwarding of any UDP packets, to and from legitimate
node addresses, with a destination port of 500, i.e. the port node addresses, with a destination port of 500, i.e., the port
reserved by IANA for the Internet Key Exchange (IKE) protocol reserved by IANA for the Internet Key Exchange (IKE) protocol
[RFC5996]. [RFC5996].
REC-25: In all operating modes, IPv6 gateways SHOULD use filter state REC-25: In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] that are records for Encapsulating Security Payload (ESP) [RFC4303] that are
indexable by a 3-tuple comprising the interior node address, the indexable by a 3-tuple comprising the interior node address, the
exterior node address and the ESP protocol identifier. In exterior node address, and the ESP protocol identifier. In
particular, the IPv4/NAT method of indexing state records also by particular, the IPv4/NAT method of indexing state records also by the
security parameters index (SPI) SHOULD NOT be used. Likewise, any security parameters index (SPI) SHOULD NOT be used. Likewise, any
mechanism that depends on detection of Internet Key Exchange (IKE) mechanism that depends on detection of Internet Key Exchange (IKE)
[RFC5996] initiations SHOULD NOT be used. [RFC5996] initiations SHOULD NOT be used.
"Host Identity Protocol (HIP)" is a secure mechanism for establishing The Host Identity Protocol (HIP) is a secure mechanism for
host identity and secure communications between authenticated hosts. establishing host identity and secure communications between
Residential IPv6 gateways need not prohibit inbound HIP flows. authenticated hosts. Residential IPv6 gateways need not prohibit
inbound HIP flows.
REC-26: In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-26: In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with destination extension headers of type "Host Identity addresses, with destination extension headers of type "Host Identity
Protocol (HIP)" [RFC5201] in their outer IP extension header chain. Protocol (HIP)" [RFC5201] in their outer IP extension header chain.
3.2.5. Mobility Support in IPv6 3.2.5. Mobility Support in IPv6
Mobility support in IPv6 [RFC3775] relies on the use of an Mobility support in IPv6 [RFC3775] relies on the use of an
encapsulation mechanism in flows between mobile nodes and their encapsulation mechanism in flows between mobile nodes and their
correspondent nodes, involving the use of the type 2 IPv6 routing correspondent nodes, involving the use of the Type 2 IPv6 Routing
header, the Home Address destination header option and the Mobility Header, the Home Address destination header option, and the Mobility
extension header. In contrast to mobility support in IPv4, mobility extension header. In contrast to mobility support in IPv4, mobility
is a standard feature of IPv6, and no security benefit is generally is a standard feature of IPv6, and no security benefit is generally
to be gained by denying communications with either interior or to be gained by denying communications with either interior or
exterior mobile nodes. exterior mobile nodes.
Not all usage scenarios of Mobility support in IPv6 are expected to Not all usage scenarios of mobility support in IPv6 are expected to
compatible with IPv6 simple security. In particular, exterior mobile be compatible with IPv6 simple security. In particular, exterior
nodes are expected to be prohibited from establishing bindings with mobile nodes are expected to be prohibited from establishing bindings
interior correspondent nodes by the filtering of unsolicited inbound with interior correspondent nodes by the filtering of unsolicited
Mobility Header messages unless they are the subject of an IPsec inbound Mobility Header messages, unless they are the subject of an
security policy. IPsec security policy.
REC-27: The state records for flows initiated by outbound packets REC-27: The state records for flows initiated by outbound packets
that bear a Home Address destination option [RFC3775] are that bear a Home Address destination option [RFC3775] are
distinguished by the addition of the home address of the flow as well 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 as the interior care-of address. IPv6 gateways MUST NOT prohibit the
forwarding of any inbound packets bearing type 2 routing headers, forwarding of any inbound packets bearing type 2 routing headers,
which otherwise match a flow state record, and where A) the address which otherwise match a flow state record, and where A) the address
in the destination field of the IPv6 header matches the interior 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 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. Type 2 Routing Header matches the home address of the flow.
skipping to change at page 13, line 29 skipping to change at page 13, line 40
REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward, in both directions, the IPv4 and IPv6 packets it MUST also forward, in both directions, the IPv4 and IPv6 packets
that are encapsulated in IPv6 associated with the tunnel between the that are encapsulated in IPv6 associated with the tunnel between the
home agent and the correspondent node. home agent and the correspondent node.
REC-30: If a gateway forwards a Mobility Header [RFC3775] flow, then REC-30: If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward (in the reverse direction) ICMPv6 "Destination it MUST also forward (in the reverse direction) ICMPv6 "Destination
Unreachable" and "Packet Too Big" messages containing any headers Unreachable" and "Packet Too Big" messages containing any headers
that match the associated flow state records. that match the associated flow state records.
3.3. Connection-oriented Filters 3.3. Connection-Oriented Filters
Most Internet applications use connection-oriented transport Most Internet applications use connection-oriented transport
protocols with orderly release semantics. These protocols include protocols with orderly release semantics. These protocols include
TCP, SCTP, DCCP, and potentially any future IETF standards-track TCP, SCTP, DCCP, and potentially any future IETF Standards-Track
transport protocols that use such semantics. Stateful packet filters transport protocols that use such semantics. Stateful packet filters
track the state of individual transport flows and prohibit the track the state of individual transport flows and prohibit the
forwarding of packets that do not match the state of an active flow 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 and do not conform to a rule for the automatic creation of such
state. state.
3.3.1. TCP Filters 3.3.1. TCP Filters
An interior endpoint initiates a TCP flow through a stateful packet An interior endpoint initiates a TCP flow through a stateful packet
filter by sending a SYN packet. The filter allocates (or reuses) a filter by sending a SYN packet. The filter allocates (or reuses) a
filter state record for the flow. The state record defines the filter state record for the flow. The state record defines the
interior and exterior IP addresses and ports used for forwarding all interior and exterior IP addresses and ports used for forwarding all
packets for that flow. packets for that flow.
Some peer-to-peer applications use an alternate method of connection Some peer-to-peer applications use an alternate method of connection
initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse initiation termed "simultaneous-open" ([RFC0793], Figure 8) to
stateful filters. In the simultaneous-open mode of operation, both traverse stateful filters. In the simultaneous-open mode of
peers send SYN packets for the same TCP flow. The SYN packets cross operation, both peers send SYN packets for the same TCP flow. The
in the network. Upon receiving the other end's SYN packet, each end SYN packets cross in the network. Upon receiving the other end's SYN
responds with a SYN-ACK packet, which also cross in the network. The packet, each end responds with a SYN-ACK packet, which also cross in
connection is established at each endpoint once the SYN-ACK packets the network. The connection is established at each endpoint once the
are received. SYN-ACK packets are received.
To provide stateful packet filtering service for TCP, it is necessary To provide stateful packet filtering service for TCP, it is necessary
for a filter to receive, process and forward all packets for a flow 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, that conform to valid transitions of the TCP state machine
[RFC0793]). ([RFC0793], Figure 6).
REC-31: All valid sequences of TCP packets (defined in [RFC0793]) REC-31: All valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound flows and explicitly permitted inbound MUST be forwarded for outbound flows and explicitly permitted inbound
flows. In particular, both the normal TCP 3-way handshake mode of flows. In particular, both the normal TCP 3-way handshake mode of
operation and the simultaneous-open modes of operation MUST be operation and the simultaneous-open mode of operation MUST be
supported. supported.
It is possible to reconstruct enough of the state of a TCP flow to 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 allow forwarding between an interior and exterior node, even when the
filter starts operating after TCP enters the established state. In filter starts operating after TCP enters the established state. In
this case, because the filter has not seen the TCP window-scale 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 option, it is not possible for the filter to enforce the TCP window
invariant by dropping out-of-window segments. invariant by dropping out-of-window segments.
REC-32: The TCP window invariant MUST NOT be enforced on flows for 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 which the filter did not detect whether the window-scale option (see
[RFC1323]) was sent in the 3-way handshake or simultaneous open. [RFC1323]) was sent in the 3-way handshake or simultaneous-open.
A stateful filter can allow an existing state record to be reused by A stateful filter can allow an existing state record to be reused by
an externally initiated flow if its security policy permits. Several an externally initiated flow if its security policy permits. Several
different policies are possible as described in [RFC4787] and different policies are possible, as described in [RFC4787] and
extended in [RFC5382]. extended in [RFC5382].
REC-33: If application transparency is most important, then a REC-33: If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent filter" stateful packet filter SHOULD have "endpoint-independent filtering"
behavior for TCP. If a more stringent filtering behavior is most behavior for TCP. If a more stringent filtering behavior is most
important, then a filter SHOULD have "address dependent filtering" important, then a filter SHOULD have "address-dependent filtering"
behavior. The filtering behavior MAY be an option configurable by behavior. The filtering behavior MAY be an option configurable by
the network administrator, and it MAY be independent of the filtering the network administrator, and it MAY be independent of the filtering
behavior for UDP and other protocols. Filtering behavior SHOULD be behavior for UDP and other protocols. Filtering behavior SHOULD be
endpoint independent by DEFAULT in gateways intended for provisioning endpoint independent by DEFAULT in gateways intended for provisioning
without service-provider management. without service-provider management.
If an inbound SYN packet is filtered, either because a corresponding If an inbound SYN packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error silently, or to signal an error to the sender. Signaling an error
through ICMPv6 messages allows the sender to detect that the SYN did through ICMPv6 messages allows the sender to detect that the SYN did
not reach the intended destination. Discarding the packet, on the not reach the intended destination. Discarding the packet, on the
other hand, allows applications to perform simultaneous-open more other hand, allows applications to perform simultaneous-open more
reliably. A more detailed discussion of this issue can be found in 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 [RFC5382], but the basic outcome of it is that filters need to wait
on signaling errors until simultaneous-open will not be impaired. on signaling errors until simultaneous-open will not be impaired.
REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6 REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively prohibited) "Destination Unreachable" error code 1 (Communication with
to any unsolicited inbound SYN packet after waiting at least 6 destination administratively prohibited) to any unsolicited inbound
seconds without first forwarding the associated outbound SYN or SYN/ SYN packet after waiting at least 6 seconds without first forwarding
ACK from the interior peer. the associated outbound SYN or SYN/ACK from the interior peer.
A TCP filter maintains state associated with in-progress connections A TCP filter maintains state associated with in-progress connections
and established flows. Because of this, a filter is susceptible to a and established flows. Because of this, a filter is susceptible to a
resource-exhaustion attack whereby an attacker (or virus) on the resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long needs to abandon unused state records after a sufficiently long
period of idleness. period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially flow state records for crashed endpoints, abandon preferentially flow state records for crashed endpoints,
followed by closed flows and partially-open flows. A gateway can 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- 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 alive packet on behalf of the other endpoint and receiving a TCP RST
packet in response. If the gateway cannot determine whether the packet in response. If the gateway cannot determine whether the
endpoint is active, then the associated state record needs to be endpoint is active, then the associated state record needs to be
retained until the TCP flow has been idle for some time. Note: an retained until the TCP flow has been idle for some time.
established TCP flow can stay idle (but live) indefinitely; hence,
there is no fixed value for an idle-timeout that accommodates all Note: An established TCP flow can stay idle (but live)
applications. However, a large idle-timeout motivated by indefinitely; hence, there is no fixed value for an idle-timeout
recommendations in [RFC1122] and [RFC4294] can reduce the chances of that accommodates all applications. However, a large idle-timeout
abandoning a live flow. 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 TCP flows can stay in the established phase indefinitely without
exchanging packets. Some end-hosts can be configured to send keep- exchanging packets. Some end-hosts can be configured to send keep-
alive packets on such idle flows; by default, such packets are sent alive packets on such idle flows; by default, such packets are sent
every two hours, if enabled [RFC1122]. Consequently, a filter that every two hours, if enabled [RFC1122]. Consequently, a filter that
waits for slightly over two hours can detect idle flows with keep- waits for slightly over two hours can detect idle flows with keep-
alive packets being sent at the default rate. TCP flows in the alive packets being sent at the default rate. TCP flows in the
partially-open or closing phases, on the other hand, can stay idle 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 for at most four minutes while waiting for in-flight packets to be
delivered [RFC1122]. delivered [RFC1122].
The "established flow idle-timeout" for a stateful packet filter is The "established flow idle-timeout" for a stateful packet filter is
defined as the minimum time a TCP flow in the established phase must defined as the minimum time a TCP flow in the established phase must
remain idle before the filter considers the associated state record a remain idle before the filter considers the associated state record a
candidate for collection. The "transitory flow idle-timeout" for a candidate for collection. The "transitory flow idle-timeout" for a
filter is defined as the minimum time a TCP flow in the partially- filter is defined as the minimum time a TCP flow in the partially
open or closing phases must remain idle before the filter considers open or closing phases must remain idle before the filter considers
the associated state record a candidate for collection. TCP flows in the associated state record a candidate for collection. TCP flows in
the TIME_WAIT state are not affected by the "transitory flow idle- the TIME-WAIT state are not affected by the "transitory flow idle-
timeout" parameter. timeout" parameter.
REC-35: If a gateway cannot determine whether the endpoints of a TCP 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 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 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 flow idle-timeout" MUST NOT be less than two hours four minutes, as
discussed in [RFC5382]. The value of the "transitory flow idle- discussed in [RFC5382]. The value of the "transitory flow idle-
timeout" MUST NOT be less than four minutes. The value of the idle- timeout" MUST NOT be less than four minutes. The value of the idle-
timeouts MAY be configurable by the network administrator. timeouts MAY be configurable by the network administrator.
Behavior for handing RST packets, or TCP flows in the TIME_WAIT state 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 is left unspecified. A gateway MAY hold state for a flow in the
TIME_WAIT state to accommodate retransmissions of the last ACK. TIME-WAIT state to accommodate retransmissions of the last ACK.
However, since the TIME_WAIT state is commonly encountered by However, since the TIME-WAIT state is commonly encountered by
interior endpoints properly closing the TCP flow, holding state for a interior endpoints properly closing the TCP flow, holding state for a
closed flow can limit the throughput of flows through a gateway with closed flow can limit the throughput of flows through a gateway with
limited resources. [RFC1337] discusses hazards associated with limited resources. [RFC1337] discusses hazards associated with
TIME_WAIT assassination. TIME-WAIT assassination.
The handling of non-SYN packets for which there is no active state The handling of non-SYN packets for which there is no active state
record is left unspecified. Such packets can be received if the record is left unspecified. Such packets can be received if the
gateway abandons a live flow, or abandons a flow in the TIME_WAIT gateway abandons a live flow, or abandons a flow in the TIME-WAIT
state before the four minute TIME_WAIT period expires. The decision state before the four-minute TIME-WAIT period expires. The decision
either to discard or to respond with an ICMPv6 "Destination either to discard or to respond with an ICMPv6 "Destination
Unreachable" error code 1 (administratively prohibited) is left up to Unreachable" error code 1 (Communication with destination
the implementation. administratively prohibited) is left up to the implementation.
Behavior for notifying endpoints when abandoning live flows is left Behavior for notifying endpoints when abandoning live flows is left
unspecified. When a gateway abandons a live flow, for example due to 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 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 on behalf of the other. Sending a RST notification allows
endpoint applications to recover more quickly, however, notifying endpoint applications to recover more quickly; however, notifying
endpoints might not always be possible if, for example, state records endpoints might not always be possible if, for example, state records
are lost due to power interruption. are lost due to power interruption.
Several TCP mechanisms depend on the reception of ICMPv6 error Several TCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of TCP segments. One such messages triggered by the transmission of TCP segments. One such
mechanism is path MTU discovery, which is required for correct mechanism is path MTU discovery, which is required for correct
operation of TCP. operation of TCP.
REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6 REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages containing "Destination Unreachable" and "Packet Too Big" messages containing
skipping to change at page 17, line 13 skipping to change at page 17, line 29
state record for a TCP flow. state record for a TCP flow.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows
can be terminated at multiple network addresses, IPv6 simple security can be terminated at multiple network addresses, IPv6 simple security
functions cannot achieve full transparency for SCTP applications. In functions cannot achieve full transparency for SCTP applications. In
multipath traversal scenarios, full transparency requires multipath traversal scenarios, full transparency requires
coordination between all the packet filter processes in the various coordination between all the packet filter processes in the various
paths between the endpoint network addresses. Such coordination is paths between the endpoint network addresses. Such coordination is
not "simple" and it is, therefore, beyond the scope of this not "simple", and it is, therefore, beyond the scope of this
recommendation. recommendation.
However, some SCTP applications are capable of tolerating the However, some SCTP applications are capable of tolerating the
inherent unipath restriction of IPv6 simple security, even in inherent unipath restriction of IPv6 simple security, even in
multipath traversal scenarios. They expect similar connection- multipath traversal scenarios. They expect connection-oriented
oriented filtering behaviors as for TCP, but at the level of SCTP filtering behaviors similar to those for TCP, but at the level of
associations, not stream connections. This section describes SCTP associations, not stream connections. This section describes
specific recommendations for SCTP filtering for such traversal specific recommendations for SCTP filtering for such traversal
scenarios. scenarios.
An interior endpoint initiates SCTP associations through a stateful An interior endpoint initiates SCTP associations through a stateful
packet filter by sending a packet comprising a single INIT chunk. packet filter by sending a packet comprising a single INIT chunk.
The filter allocates (or reuses) a filter state record for the The filter allocates (or reuses) a filter state record for the
association. The state record defines the interior and exterior IP association. The state record defines the interior and exterior IP
addresses and the observed verification tag used for forwarding addresses and the observed verification tag used for forwarding
packets in that association. packets in that association.
Peer-to-peer applications use an alternate method of association Some peer-to-peer SCTP applications use an alternate method of
initiation termed simultaneous-open to traverse stateful filters. In association initiation, termed "simultaneous-open", to traverse
the simultaneous-open mode of operation, both peers send INIT chunks stateful filters. In the simultaneous-open mode of operation, both
at the same time to establish an association. Upon receiving the peers send INIT chunks at the same time to establish an association.
other end's INIT chunk, each end responds with an INIT-ACK packet, Upon receiving the other end's INIT chunk, each end responds with an
which is expected to traverse the same path in reverse. Because only INIT-ACK packet, which is expected to traverse the same path in
one SCTP association may exist between any two network addresses, one reverse. Because only one SCTP association may exist between any two
of the peers in simultaneous-open mode of operation will send an network addresses, one of the peers in the simultaneous-open mode of
ERROR or ABORT chunk along with the INIT-ACK chunk. The association operation will send an ERROR or ABORT chunk along with the INIT-ACK
is established at each endpoint once an INIT-ACK chunks is received chunk. The association is established at each endpoint once an
at one end without an ERROR or ABORT chunk. INIT-ACK chunk without an ERROR or ABORT chunk is received at one
end.
To provide stateful packet filtering service for SCTP, it is To provide stateful packet filtering service for SCTP, it is
necessary for a filter to receive, process and forward all packets necessary for a filter to receive, process, and forward all packets
for an association that conform to valid transitions of the SCTP for an association that conform to valid transitions of the SCTP
state machine (Fig. 3, [RFC4960]). state machine ([RFC4960], Figure 3).
REC-38: All valid sequences of SCTP packets (defined in [RFC4960]) REC-38: All valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly permitted MUST be forwarded for outbound associations and explicitly permitted
inbound associations. In particular, both the normal SCTP inbound associations. In particular, both the normal SCTP
association establishment and simultaneous-open modes of operation association establishment and the simultaneous-open mode of operation
MUST be supported. MUST be supported.
If an inbound INIT packet is filtered, either because a corresponding If an inbound INIT packet is filtered, either because a corresponding
state record does not exist or because of the filter's normal state record does not exist or because of the filter's normal
behavior, a filter has two basic choices: to discard the packet behavior, a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error silently, or to signal an error to the sender. Signaling an error
through ICMPv6 messages allows the sender to detect that the INIT through ICMPv6 messages allows the sender to detect that the INIT
packet did not reach the intended destination. Discarding the packet did not reach the intended destination. Discarding the
packet, on the other hand, allows applications to perform packet, on the other hand, allows applications to perform
simultaneous-open more reliably. Delays in signaling errors can simultaneous-open more reliably. Delays in signaling errors can
prevent the impairment of simultaneous-open mode of operation. prevent the impairment of the simultaneous-open mode of operation.
REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6 REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively prohibited), "Destination Unreachable" error code 1 (Communication with
to any unsolicited inbound INIT packet after waiting at least 6 destination administratively prohibited), to any unsolicited inbound
seconds without first forwarding the associated outbound INIT from INIT packet after waiting at least 6 seconds without first forwarding
the interior peer. the associated outbound INIT from the interior peer.
An SCTP filter maintains state associated with in-progress and An SCTP filter maintains state associated with in-progress and
established associations. Because of this, a filter is susceptible established associations. Because of this, a filter is susceptible
to a resource-exhaustion attack whereby an attacker (or virus) on the to a resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To defend against such attacks, a filter creating state records. To defend against such attacks, a filter
needs to abandon unused state records after a sufficiently long needs to abandon unused state records after a sufficiently long
period of idleness. period of idleness.
A common method used for TCP filters in IPv4/NAT gateways is to A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by abandon preferentially sessions for crashed endpoints, followed by
closed associations and partially opened associations. A similar closed associations and partially opened associations. A similar
method is an option for SCTP filters in IPv6 gateways. A gateway can method is an option for SCTP filters in IPv6 gateways. A gateway can
check if an endpoint for an association has crashed by sending check if an endpoint for an association has crashed by sending
HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the
gateway cannot determine whether the endpoint is active, then the gateway cannot determine whether the endpoint is active, then the
associated state records needs to be retained until the SCTP associated state record needs to be retained until the SCTP
association has been idle for some time. Note: an established SCTP association has been idle for some time.
association can stay idle (but live) indefinitely, hence there is no
fixed value of an idle-timeout that accommodates all applications. Note: An established SCTP association can stay idle (but live)
However, a large idle-timeout motivated by [RFC4294] can reduce the indefinitely; hence, there is no fixed value of an idle-timeout
chances of abandoning a live association. 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 SCTP associations can stay in the ESTABLISHED state indefinitely
without exchanging packets. Some end-hosts can be configured to send without exchanging packets. Some end-hosts can be configured to send
HEARTBEAT chunks on such idle associations, but [RFC4960] does not HEARTBEAT chunks on such idle associations, but [RFC4960] does not
specify (or even suggest) a default time interval. A filter that specify (or even suggest) a default time interval. A filter that
waits for slightly over two hours can detect idle associations with waits for slightly over two hours can detect idle associations with
HEARTBEAT packets being sent at the same rate as most hosts use for HEARTBEAT packets being sent at the same rate as most hosts use for
TCP keep-alive, which is a reasonably similar system for this TCP keep-alive, which is a reasonably similar system for this
purpose. SCTP associations in the partially-open or closing states, purpose. SCTP associations in the partially open or closing states,
on the other hand, can stay idle for at most four minutes while on the other hand, can stay idle for at most four minutes while
waiting for in-flight packets to be delivered (assuming the suggested waiting for in-flight packets to be delivered (assuming the suggested
SCTP protocol parameter values in Section 15 of [RFC4960]). SCTP protocol parameter values in Section 15 of [RFC4960]).
The "established association idle-timeout" for a stateful packet The "established association idle-timeout" for a stateful packet
filter is defined as the minimum time an SCTP association in the filter is defined as the minimum time an SCTP association in the
established phase must remain idle before the filter considers the established phase must remain idle before the filter considers the
corresponding state record a candidate for collection. The corresponding state record a candidate for collection. The
"transitory association idle-timeout" for a filter is defined as the "transitory association idle-timeout" for a filter is defined as the
minimum time an SCTP association in the partially-open or closing minimum time an SCTP association in the partially open or closing
phases must remain idle before the filter considers the corresponding phases must remain idle before the filter considers the corresponding
state record a candidate for collection. state record a candidate for collection.
REC-40: If a gateway cannot determine whether the endpoints of an REC-40: If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state record if 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 it has been idle for some time. In such cases, the value of the
"established association idle-timeout" MUST NOT be less than two "established association idle-timeout" MUST NOT be less than
hours four minutes. The value of the "transitory association idle- two hours four minutes. The value of the "transitory association
timeout" MUST NOT be less than four minutes. The value of the idle- idle-timeout" MUST NOT be less than four minutes. The value of the
timeouts MAY be configurable by the network administrator. idle-timeouts MAY be configurable by the network administrator.
Behavior for handling ERROR and ABORT packets is left unspecified. A Behavior for handling ERROR and ABORT packets is left unspecified. A
gateway MAY hold state for an association after its closing phases gateway MAY hold state for an association after its closing phases
have completed to accommodate retransmissions of its final SHUTDOWN have completed to accommodate retransmissions of its final SHUTDOWN
ACK packets. However, holding state for a closed association can ACK packets. However, holding state for a closed association can
limit the throughput of associations traversing a gateway with limit the throughput of associations traversing a gateway with
limited resources. The discussion in [RFC1337] regarding the hazards limited resources. The discussion in [RFC1337] regarding the hazards
of TIME_WAIT assassination are relevant. of TIME-WAIT assassination is relevant.
The handling of inbound non-INIT packets for which there is no active The handling of inbound non-INIT packets for which there is no active
state record is left unspecified. Such packets can be received if state record is left unspecified. Such packets can be received if
the gateway abandons a live flow, or abandons an association in the the gateway abandons a live flow, or abandons an association in the
closing states before the transitory association idle-timeout closing states before the transitory association idle-timeout
expires. The decision either to discard or to respond with an ICMPv6 expires. The decision either to discard or to respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively prohibited) "Destination Unreachable" error code 1 (Communication with
is left to the implementation. destination administratively prohibited) is left to the
implementation.
Behavior for notifying endpoints when abandoning live associations is Behavior for notifying endpoints when abandoning live associations is
left unspecified. When a gateway abandons a live association, for left unspecified. When a gateway abandons a live association, for
example due to a timeout expiring, the filter MAY send an ABORT example due to a timeout expiring, the filter MAY send an ABORT
packet to each endpoint on behalf of the other. Sending an ABORT packet to each endpoint on behalf of the other. Sending an ABORT
notification allows endpoint applications to recover more quickly, notification allows endpoint applications to recover more quickly;
however, notifying endpoints might not always be possible if, for however, notifying endpoints might not always be possible if, for
example, state records are lost due to power interruption. example, state records are lost due to power interruption.
Several SCTP mechanisms depend on the reception of ICMPv6 error Several SCTP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of SCTP packets. messages triggered by the transmission of SCTP packets.
REC-41: If a gateway forwards an SCTP association, it MUST also REC-41: If a gateway forwards an SCTP association, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing SCTP headers that match the association state messages containing SCTP headers that match the association state
record. record.
REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for an SCTP association. state record for an SCTP association.
3.3.3. DCCP Filters 3.3.3. DCCP Filters
The connection semantics described in Datagram Congestion Control The connection semantics described in the "Datagram Congestion
Protocol (DCCP) [RFC4340] are very similar to those of TCP. An Control Protocol (DCCP)" [RFC4340] are very similar to those of TCP.
interior endpoint initiates a DCCP flow through a stateful packet An interior endpoint initiates a DCCP flow through a stateful packet
filter by sending a DCCP-Request packet. Simultaneous open is not filter by sending a DCCP-Request packet. Simultaneous-open is not
defined for DCCP. defined for DCCP.
In order to provide stateful packet filtering service for DCCP, it is In order to provide stateful packet filtering service for DCCP, it is
necessary for a filter to receive, process and forward all packets necessary for a filter to receive, process, and forward all packets
for a flow that conform to valid transitions of the DCCP state for a flow that conform to valid transitions of the DCCP state
machine (Section 8, [RFC4340]). machine ([RFC4340], Section 8).
REC-43: All valid sequences of DCCP packets (defined in [RFC4340]) REC-43: All valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all flows to exterior servers and those flows MUST be forwarded for all flows to exterior servers, and for any
to interior servers with explicitly permitted service codes. flows to interior servers that have explicitly permitted service
codes.
It is possible to reconstruct enough of the state of a DCCP flow to 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 allow forwarding between an interior and exterior node, even when the
filter starts operating after DCCP enters the OPEN state. Also, a filter starts operating after DCCP enters the OPEN state. Also, a
filter can allow an existing state record to be reused by an filter can allow an existing state record to be reused by an
externally initiated flow if its security policy permits. As with externally initiated flow if its security policy permits. As with
TCP, several different policies are possible, with a good discussion TCP, several different policies are possible, with a good discussion
of the issue involved presented in [RFC4787] and extended in of the issue involved presented in [RFC4787] and extended in
[RFC5382]. [RFC5382].
If an inbound DCCP-Request packet is filtered, either because a If an inbound DCCP-Request packet is filtered, either because a
corresponding state record does not already exist for it or because corresponding state record does not already exist for it or because
of the filter's normal behavior of refusing flows not explicitly of the filter's normal behavior of refusing flows not explicitly
permitted, then a filter has two basic choices: to discard the packet permitted, then a filter has two basic choices: to discard the packet
silently, or to signal an error to the sender. Signaling an error silently, or to signal an error to the sender. Signaling an error
through ICMPv6 messages allows the sender to detect that the DCCP- through ICMPv6 messages allows the sender to detect that the
Request did not reach the intended destination. Discarding the DCCP-Request did not reach the intended destination. Discarding the
packet, on the other hand, only delays the failure to connect and packet, on the other hand, only delays the failure to connect and
provides no measurable security. provides no measurable security.
A DCCP filter maintains state associated with in-progress connections A DCCP filter maintains state associated with in-progress connections
and established flows. Because of this, a filter is susceptible to a and established flows. Because of this, a filter is susceptible to a
resource-exhaustion attack whereby an attacker (or virus) on the resource-exhaustion attack whereby an attacker (or virus) on the
interior attempts to cause the filter to exhaust its capacity for interior attempts to cause the filter to exhaust its capacity for
creating state records. To prevent such an attack, a filter needs to creating state records. To prevent such an attack, a filter needs to
abandon unused state records after a sufficiently long period of abandon unused state records after a sufficiently long period of
idleness. idleness.
A common method used for TCP filters in IPv4/NAT gateways is to A common method used for TCP filters in IPv4/NAT gateways is to
abandon preferentially sessions for crashed endpoints, followed by abandon preferentially sessions for crashed endpoints, followed by
closed TCP flows and partially-open flows. No such method exists for closed TCP flows and partially open flows. No such method exists for
DCCP, and flows can stay in the OPEN phase indefinitely without DCCP, and flows can stay in the OPEN phase indefinitely without
exchanging packets. Hence, there is no fixed value for an idle- exchanging packets. Hence, there is no fixed value for an idle-
timeout that accommodates all applications. However, a large idle- timeout that accommodates all applications. However, a large idle-
timeout motivated by [RFC4294] can reduce the chances of abandoning a timeout motivated by recommendations in [RFC4294] can reduce the
live flow. chances of abandoning a live flow.
DCCP flows in the partially-open or closing phases can stay idle for 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 at most eight minutes while waiting for in-flight packets to be
delivered. delivered.
The "open flow idle-timeout" for a stateful packet filter is defined 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 as the minimum time a DCCP flow in the open state must remain idle
before the filter considers the associated state record a candidate before the filter considers the associated state record a candidate
for collection. The "transitory flow idle-timeout" for a filter is for collection. The "transitory flow idle-timeout" for a filter is
defined as the minimum time a DCCP flow in the partially-open or defined as the minimum time a DCCP flow in the partially open or
closing phases must remain idle before the filter considers the closing phases must remain idle before the filter considers the
associated state record a candidate for collection. DCCP flows in associated state record a candidate for collection. DCCP flows in
the TIMEWAIT state are not affected by the "transitory flow idle- the TIMEWAIT state are not affected by the "transitory flow idle-
timeout" parameter. timeout" parameter.
REC-44: A gateway MAY abandon a DCCP state record if it has been idle 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 for some time. In such cases, the value of the "open flow idle-
idle-timeout" MUST NOT be less than two hours four minutes. The timeout" MUST NOT be less than two hours four minutes. The value of
value of the "transitory flow idle-timeout" MUST NOT be less than the "transitory flow idle-timeout" MUST NOT be less than eight
eight minutes. The value of the idle-timeouts MAY be configurable by minutes. The value of the idle-timeouts MAY be configurable by the
the network administrator. network administrator.
Behavior for handing DCCP-Reset packets, or flows in the TIMEWAIT Behavior for handling DCCP-Reset packets or flows in the TIMEWAIT
state is left unspecified. A gateway MAY hold state for a flow in state is left unspecified. A gateway MAY hold state for a flow in
TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset. the TIMEWAIT state to accommodate retransmissions of the last
However, since the TIMEWAIT state is commonly encountered by interior DCCP-Reset. However, since the TIMEWAIT state is commonly
endpoints properly closing the DCCP flow, holding state for a closed encountered by interior endpoints properly closing the DCCP flow,
flow can limit the throughput of flows through a gateway with limited holding state for a closed flow can limit the throughput of flows
resources. [RFC1337] discusses hazards associated with TIME_WAIT through a gateway with limited resources. [RFC1337] discusses
assassination in TCP, and similar hazards exists for DCCP. 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 The handling of non-SYN packets for which there is no active state
record is left unspecified. Such packets can be received if the record is left unspecified. Such packets can be received if the
gateway abandons a live flow, or abandons a flow in the TIMEWAIT gateway abandons a live flow, or abandons a flow in the TIMEWAIT
state before the four minute 2MSL period expires. The decision state before the four-minute 2MSL period (two times the maximum
either to discard or to respond with an ICMPv6 "Destination segment lifetime [RFC4340]) expires. The decision either to discard
Unreachable" error code 1 (administratively prohibited) is left up to or to respond with an ICMPv6 "Destination Unreachable" error code 1
the implementation. (Communication with destination administratively prohibited) is left
up to the implementation.
Behavior for notifying endpoints when abandoning live flows is left Behavior for notifying endpoints when abandoning live flows is left
unspecified. When a gateway abandons a live flow, for example due to 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 a timeout expiring, the filter MAY send a DCCP-Reset packet to each
endpoint on behalf of the other. Sending a DCCP-Reset notification endpoint on behalf of the other. Sending a DCCP-Reset notification
allows endpoint applications to recover more quickly, however, allows endpoint applications to recover more quickly; however,
notifying endpoints might not always be possible if, for example, notifying endpoints might not always be possible if, for example,
state records are lost due to power interruption. state records are lost due to power interruption.
Several DCCP mechanisms depend on the reception of ICMPv6 error Several DCCP mechanisms depend on the reception of ICMPv6 error
messages triggered by the transmission of DCCP packets. One such messages triggered by the transmission of DCCP packets. One such
mechanism is path MTU discovery, which is required for correct mechanism is path MTU discovery, which is required for correct
operation. operation.
REC-45: If an Internet gateway forwards a DCCP flow, it MUST also REC-45: If an Internet gateway forwards a DCCP flow, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing DCCP headers that match the flow state record. messages containing DCCP headers that match the flow state record.
REC-46: Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-46: Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a DCCP flow. state record for a DCCP flow.
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
While IPv6 simple security is applicable to residential networks with While IPv6 simple security is applicable to residential networks with
only one Internet service provider at a time, the use of Level 3 only one Internet service provider at a time, the use of the Level 3
Multihoming Shim Protocol for IPv6 (SHIM6) [RFC5533] is necessary for Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] is necessary for
communications with some multihomed exterior destinations. No communications with some multihomed exterior destinations. No
special recommendations are made in this document for processing the special recommendations are made in this document for processing the
SHIM6 message format (protocol 140) beyond the recommendations in Shim6 message format (protocol 140) beyond the recommendations in
Section 3.2.2. The content of the SHIM6 payload extension header may Section 3.2.2. The content of the Shim6 payload extension header may
be ignored. be ignored.
REC-47: Valid sequences of packets bearing SHIM6 payload extension REC-47: Valid sequences of packets bearing Shim6 payload extension
headers in their outer IP extension header chains MUST be forwarded headers in their outer IP extension header chains MUST be forwarded
for all outbound and explicitly permitted flows. The content of the for all outbound and explicitly permitted flows. The content of the
SHIM6 payload extension header MAY be ignored for the purpose of Shim6 payload extension header MAY be ignored for the purpose of
state tracking. state tracking.
3.4. Passive Listeners 3.4. Passive Listeners
Some applications expect to solicit traffic from exterior nodes Some applications expect to solicit traffic from exterior nodes
without advance knowledge of the exterior addresses of their peers. without advance knowledge of the exterior addresses of their peers.
This requirement is met by IPv4/NAT gateways typically by the use of 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 either the NAT Port Mapping Protocol [NAT-PMP] or the Universal Plug
connected by gateways without such services, applications must use and Play Internet Gateway Device [UPnP-IGD] standardized device
techniques like Session Traversal Utilities for NAT (STUN) [RFC5389] control protocol. On IPv4/NAT networks connected by gateways without
to obtain and maintain connectivity, despite the translation and such services, applications must use techniques like Session
filtering effects of NAT. 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 While NAT for IPv6 is unlikely to be used in most residential
gateways, the filtering effect of the simple security functions gateways, the simple security functions recommended by this document,
recommended by this document are derived from those in widespread use and their filtering effects, are derived from comparable functions
on the IPv4 Internet, and a similar barrier to communication at already in widespread use on the IPv4 Internet. A similar barrier to
passive listeners is a natural outcome of its deployment. To avoid communication at passive listeners is a natural outcome of the
the need for IPv6 applications to use techniques like STUN for deployment of NAT for IPv6. To avoid the need for IPv6 applications
opening and maintaining dynamic filter state, something similar to to use techniques like STUN for opening and maintaining dynamic
NAT-PMP and UPnP-IGD but without actually supporting NAT could be filter state, something similar to NAT-PMP and UPnP-IGD, but without
deployed. Alas, no consensus has yet emerged in the Internet actually supporting NAT, could be deployed. Alas, no consensus has
engineering community as to what is most appropriate for residential yet emerged in the Internet engineering community as to what is most
IPv6 usage scenarios. appropriate for residential IPv6 usage scenarios.
One proposal that has been offered as an Internet Draft is the One proposal that has been offered is the Application Listener
Application Listener Discovery Protocol [I-D.woodyatt-ald]. It Discovery Protocol [WOODYATT-ALD] document. It remains to be seen
remains to be seen whether the Internet Gateway Device profile of the whether the Internet Gateway Device profile of the Universal Plug and
Universal Plug And Play protocol will be extended for IPv6. Other Play protocol will be extended for IPv6. Other proposals of note
proposals of note include the Middlebox Communication Protocol include the Middlebox Communication Protocol [RFC5189] and the Next
[RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until Steps in Signaling framework [RFC4080]. Until a consensus emerges
a consensus emerges around a specific method, the following around a specific method, the following recommendations are the best
recommendations are the best guidance available. guidance available.
REC-48: Internet gateways with IPv6 simple security capabilities REC-48: Internet gateways with IPv6 simple security capabilities
SHOULD implement a protocol to permit applications to solicit inbound SHOULD implement a protocol to permit applications to solicit inbound
traffic without advance knowledge of the addresses of exterior nodes traffic without advance knowledge of the addresses of exterior nodes
with which they expect to communicate. with which they expect to communicate.
REC-49: Internet gateways with IPv6 simple security capabilities MUST REC-49: Internet gateways with IPv6 simple security capabilities MUST
provide an easily selected configuration option that permits a provide an easily selected configuration option that permits a
"transparent mode" of operation that forwards all unsolicited flows "transparent mode" of operation that forwards all unsolicited flows
regardless of forwarding direction, i.e. not to use the IPv6 simple regardless of forwarding direction, i.e., not to use the IPv6 simple
security capabilities of the gateway. The transparent mode of security capabilities of the gateway. The transparent mode of
operation MAY be the default configuration. operation MAY be the default configuration.
In general, "transparent mode" will enable more flexibility and In general, "transparent mode" will enable more flexibility and
reliability for applications which require devices to be contacted reliability for applications that require devices to be contacted
inside the home directly, particularly in absence of a protocol as inside the home directly, particularly in the absence of a protocol
described in REC-48. Operating in transparent mode may come at the as described in REC-48. Operating in transparent mode may come at
expense of security if there are IPv6 nodes in the home that do not the expense of security if there are IPv6 nodes in the home that do
have their own host-based firewall capability and require a firewall not have their own host-based firewall capability and require a
in the gateway in order not to be compromised. firewall in the gateway in order not to be compromised.
3.5. Management Applications 3.5. Management Applications
Subscriber managed residential gateways are unlikely ever to be Subscriber-managed residential gateways are unlikely ever to be
completely zero-configuration, but their administrators will very completely zero-configuration, but their administrators will very
often possess no particular expertise in Internet engineering. In often possess no particular expertise in Internet engineering. In
general, the specification of management interfaces for residential general, the specification of management interfaces for residential
gateways is out of scope for this document, but security of gateways is out of scope for this document, but the security of
subscriber managed gateways merit special attention here. subscriber-managed gateways merits special attention here.
REC-50: By DEFAULT, subscriber managed residential gateways MUST NOT REC-50: By DEFAULT, subscriber-managed residential gateways MUST NOT
offer management application services to the exterior network. offer management application services to the exterior network.
4. Summary of Recommendations 4. Summary of Recommendations
This section collects all of the recommendations made in this This section collects all of the recommendations made in this
document into a convenient list. document into a convenient list.
REC-1 Packets bearing in their outer IPv6 headers multicast source REC-1 Packets bearing multicast source addresses in their outer
addresses MUST NOT be forwarded or transmitted on any IPv6 headers MUST NOT be forwarded or transmitted on any
interface. interface.
REC-2 Packets which bear in their outer IPv6 headers multicast REC-2 Packets bearing multicast destination addresses in their
destination addresses of equal or narrower scope (see IPv6 outer IPv6 headers of equal or narrower scope (see "IPv6
Scoped Address Architecture [RFC4007]) than the configured Scoped Address Architecture" [RFC4007]) than the configured
scope boundary level of the gateway MUST NOT be forwarded in scope boundary level of the gateway MUST NOT be forwarded in
any direction. The DEFAULT scope boundary level SHOULD be any direction. The DEFAULT scope boundary level SHOULD be
organization-local scope, and it SHOULD be configurable by organization-local scope, and it SHOULD be configurable by
the network administrator. the network administrator.
REC-3 Packets bearing source and/or destination addresses forbidden REC-3 Packets bearing source and/or destination addresses forbidden
to appear in the outer headers of packets transmitted over to appear in the outer headers of packets transmitted over
the public Internet MUST NOT be forwarded. In particular, the public Internet MUST NOT be forwarded. In particular,
site-local addresses are deprecated by [RFC3879], and site-local addresses are deprecated by [RFC3879], and
[RFC5156] explicitly forbids the use of addresses with IPv4- [RFC5156] explicitly forbids the use of address blocks of
Mapped, IPv4-Compatible, Documentation and ORCHID prefixes. 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 REC-4 Packets bearing deprecated extension headers prior to their
first upper-layer-protocol header SHOULD NOT be forwarded or first upper-layer-protocol header SHOULD NOT be forwarded or
transmitted on any interface. In particular, all packets transmitted on any interface. In particular, all packets
with routing extension header type 0 [RFC2460] preceding the with routing extension header type 0 [RFC2460] preceding the
first upper-layer-protocol header MUST NOT be forwarded. first upper-layer-protocol header MUST NOT be forwarded. See
(See [RFC5095] for additional background.) [RFC5095] for additional background.
REC-5 Outbound packets MUST NOT be forwarded if the source address REC-5 Outbound packets MUST NOT be forwarded if the source address
in their outer IPv6 header does not have a unicast prefix in their outer IPv6 header does not have a unicast prefix
assigned for use by globally reachable nodes on the interior configured for use by globally reachable nodes on the
network. interior network.
REC-6 Inbound packets MUST NOT be forwarded if the source address REC-6 Inbound packets MUST NOT be forwarded if the source address
in their outer IPv6 header has a global unicast prefix in their outer IPv6 header has a global unicast prefix
assigned for use by globally reachable nodes on the interior assigned for use by globally reachable nodes on the interior
network. network.
REC-7 By DEFAULT, packets with unique local source and/or REC-7 By DEFAULT, packets with unique local source and/or
destination addresses [RFC4193] SHOULD NOT be forwarded to or destination addresses [RFC4193] SHOULD NOT be forwarded to or
from the exterior network. from the exterior network.
REC-8 By DEFAULT, inbound DNS queries received on exterior REC-8 By DEFAULT, inbound DNS queries received on exterior
interfaces MUST NOT be processed by any integrated DNS interfaces MUST NOT be processed by any integrated DNS
resolving server. resolving server.
REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on
exterior interfaces MUST NOT be processed by any integrated exterior interfaces MUST NOT be processed by any integrated
DHCPv6 server or relay agent. DHCPv6 server or relay agent.
REC-10 IPv6 gateways MUST forward ICMPv6 "Destination Unreachable" REC-10 IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
and "Packet Too Big" messages containing IP headers that Unreachable" and "Packet Too Big" messages containing IP
match generic upper-layer transport state records. headers that do not match generic upper-layer transport state
records.
REC-11 If application transparency is most important, then a REC-11 If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent stateful packet filter SHOULD have "endpoint-independent
filter" behavior for generic upper-layer transport protocols. filtering" behavior for generic upper-layer transport
If a more stringent filtering behavior is most important, protocols. If a more stringent filtering behavior is most
then a filter SHOULD have "address dependent filtering" important, then a filter SHOULD have "address-dependent
behavior. The filtering behavior MAY be an option filtering" behavior. The filtering behavior MAY be an option
configurable by the network administrator, and it MAY be configurable by the network administrator, and it MAY be
independent of the filtering behavior for other protocols. independent of the filtering behavior for other protocols.
Filtering behavior SHOULD be endpoint independent by DEFAULT Filtering behavior SHOULD be endpoint independent by DEFAULT
in gateways intended for provisioning without service- in gateways intended for provisioning without service-
provider management. provider management.
REC-12 Filter state records for generic upper-layer transport REC-12 Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer protocols MUST NOT be deleted or recycled until an idle timer
not less than two minutes has expired without having not less than two minutes has expired without having
forwarded a packet matching the state in some configurable forwarded a packet matching the state in some configurable
skipping to change at page 26, line 6 skipping to change at page 26, line 48
to update their firmware securely, for the installation of to update their firmware securely, for the installation of
security patches and other manufacturer-recommended changes. security patches and other manufacturer-recommended changes.
REC-14 A state record for a UDP flow where both source and REC-14 A state record for a UDP flow where both source and
destination ports are outside the well-known port range destination ports are outside the well-known port range
(ports 0-1023) MUST NOT expire in less than two minutes of (ports 0-1023) MUST NOT expire in less than two minutes of
idle time. The value of the UDP state record idle timer MAY idle time. The value of the UDP state record idle timer MAY
be configurable. The DEFAULT is five minutes. be configurable. The DEFAULT is five minutes.
REC-15 A state record for a UDP flow where one or both of the source 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 and destination ports are in the well-known port range
0-1023) MAY expire after a period of idle time shorter than (ports 0-1023) MAY expire after a period of idle time shorter
two minutes to facilitate the operation of the IANA- than two minutes to facilitate the operation of the IANA-
registered service assigned to the port in question. registered service assigned to the port in question.
REC-16 A state record for a UDP flow MUST be refreshed when a packet 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 is forwarded from the interior to the exterior, and it MAY be
refreshed when a packet is forwarded in the reverse refreshed when a packet is forwarded in the reverse
direction. direction.
REC-17 If application transparency is most important, then a REC-17 If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent stateful packet filter SHOULD have "endpoint-independent
filter" behavior for UDP. If a more stringent filtering filtering" behavior for UDP. If a more stringent filtering
behavior is most important, then a filter SHOULD have behavior is most important, then a filter SHOULD have
"address dependent filtering" behavior. The filtering "address-dependent filtering" behavior. The filtering
behavior MAY be an option configurable by the network behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering administrator, and it MAY be independent of the filtering
behavior for TCP and other protocols. Filtering behavior behavior for TCP and other protocols. Filtering behavior
SHOULD be endpoint independent by DEFAULT in gateways SHOULD be endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider intended for provisioning without service-provider
management. management.
REC-18 If a gateway forwards a UDP flow, it MUST also forward ICMPv6 REC-18 If a gateway forwards a UDP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing UDP headers that match the flow state record. containing UDP headers that match the flow state record.
REC-19 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-19 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP flow. state record for a UDP flow.
REC-20 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as REC-20 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
UDP flows, except that the upper-layer transport protocol UDP flows, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore identifier for UDP-Lite is not the same as UDP; therefore,
UDP packets MUST NOT match UDP-Lite state records, and vice UDP packets MUST NOT match UDP-Lite state records, and vice
versa. versa.
REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate prohibit the forwarding of packets, to and from legitimate
node addresses, with destination extension headers of type node addresses, with destination extension headers of type
"Authenticated Header (AH)" [RFC4302] in their outer IP "Authentication Header (AH)" [RFC4302] in their outer IP
extension header chain. extension header chain.
REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate prohibit the forwarding of packets, to and from legitimate
node addresses, with an upper layer protocol of type node addresses, with an upper-layer protocol of type
"Encapsulating Security Payload (ESP)" [RFC4303] in their "Encapsulating Security Payload (ESP)" [RFC4303] in their
outer IP extension header chain. outer IP extension header chain.
REC-23 If a gateway forwards an ESP flow, it MUST also forward (in REC-23 If a gateway forwards an ESP flow, it MUST also forward (in
the reverse direction) ICMPv6 "Destination Unreachable" and the reverse direction) ICMPv6 "Destination Unreachable" and
"Packet Too Big" messages containing ESP headers that match "Packet Too Big" messages containing ESP headers that match
the flow state record. the flow state record.
REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of any UDP packets, to and from prohibit the forwarding of any UDP packets, to and from
legitimate node addresses, with a destination port of 500, legitimate node addresses, with a destination port of 500,
i.e. the port reserved by IANA for the Internet Key Exchange i.e., the port reserved by IANA for the Internet Key Exchange
Protocol [RFC5996]. (IKE) Protocol [RFC5996].
REC-25 In all operating modes, IPv6 gateways SHOULD use filter state REC-25 In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] records for Encapsulating Security Payload (ESP) [RFC4303]
that are indexable by a 3-tuple comprising the interior node that are indexable by a 3-tuple comprising the interior node
address, the exterior node address and the ESP protocol address, the exterior node address, and the ESP protocol
identifier. In particular, the IPv4/NAT method of indexing identifier. In particular, the IPv4/NAT method of indexing
state records also by security parameters index (SPI) SHOULD state records also by security parameters index (SPI) SHOULD
NOT be used. Likewise, any mechanism that depends on NOT be used. Likewise, any mechanism that depends on
detection of Internet Key Exchange (IKE) [RFC5996] detection of Internet Key Exchange (IKE) [RFC5996]
initiations SHOULD NOT be used. initiations SHOULD NOT be used.
REC-26 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-26 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate prohibit the forwarding of packets, to and from legitimate
node addresses, with destination extension headers of type node addresses, with destination extension headers of type
"Host Identity Protocol (HIP)" [RFC5201] in their outer IP "Host Identity Protocol (HIP)" [RFC5201] in their outer IP
skipping to change at page 28, line 14 skipping to change at page 29, line 8
REC-30 If a gateway forwards a Mobility Header [RFC3775] flow, then REC-30 If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward (in the reverse direction) ICMPv6 it MUST also forward (in the reverse direction) ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing any headers that match the associated flow state containing any headers that match the associated flow state
records. records.
REC-31 All valid sequences of TCP packets (defined in [RFC0793]) REC-31 All valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound flows and explicitly permitted MUST be forwarded for outbound flows and explicitly permitted
inbound flows. In particular, both the normal TCP 3-way inbound flows. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes handshake mode of operation and the simultaneous-open mode of
of operation MUST be supported. operation MUST be supported.
REC-32 The TCP window invariant MUST NOT be enforced on flows for REC-32 The TCP window invariant MUST NOT be enforced on flows for
which the filter did not detect whether the window-scale which the filter did not detect whether the window-scale
option (see [RFC1323]) was sent in the 3-way handshake or option (see [RFC1323]) was sent in the 3-way handshake or
simultaneous open. simultaneous-open.
REC-33 If application transparency is most important, then a REC-33 If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent stateful packet filter SHOULD have "endpoint-independent
filter" behavior for TCP. If a more stringent filtering filtering" behavior for TCP. If a more stringent filtering
behavior is most important, then a filter SHOULD have behavior is most important, then a filter SHOULD have
"address dependent filtering" behavior. The filtering "address-dependent filtering" behavior. The filtering
behavior MAY be an option configurable by the network behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering administrator, and it MAY be independent of the filtering
behavior for UDP and other protocols. Filtering behavior behavior for UDP and other protocols. Filtering behavior
SHOULD be endpoint independent by DEFAULT in gateways SHOULD be endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider intended for provisioning without service-provider
management. management.
REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively "Destination Unreachable" error code 1 (Communication with
prohibited) to any unsolicited inbound SYN packet after destination administratively prohibited), to any unsolicited
waiting at least 6 seconds without first forwarding the inbound SYN packet after waiting at least 6 seconds without
associated outbound SYN or SYN/ACK from the interior peer. 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 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 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 has been idle for some time. In such cases, the value of the
"established flow idle-timeout" MUST NOT be less than two "established flow idle-timeout" MUST NOT be less than
hours four minutes, as discussed in [RFC5382]. The value of two hours four minutes, as discussed in [RFC5382]. The value
the "transitory flow idle-timeout" MUST NOT be less than four of the "transitory flow idle-timeout" MUST NOT be less than
minutes. The value of the idle-timeouts MAY be configurable four minutes. The value of the idle-timeouts MAY be
by the network administrator. configurable by the network administrator.
REC-36 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 REC-36 If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing TCP headers that match the flow state record. containing TCP headers that match the flow state record.
REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP flow. state record for a TCP flow.
REC-38 All valid sequences of SCTP packets (defined in [RFC4960]) REC-38 All valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly MUST be forwarded for outbound associations and explicitly
permitted inbound associations. In particular, both the permitted inbound associations. In particular, both the
normal SCTP association establishment and simultaneous-open normal SCTP association establishment and the simultaneous-
modes of operation MUST be supported. open mode of operation MUST be supported.
REC-39 By DEFAULT, a gateway MUST respond with an ICMPv6 REC-39 By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively "Destination Unreachable" error code 1 (Communication with
prohibited) to any unsolicited inbound INIT packet after destination administratively prohibited) to any unsolicited
waiting at least 6 seconds without first forwarding the inbound INIT packet after waiting at least 6 seconds without
associated outbound INIT from the interior peer. first forwarding the associated outbound INIT from the
interior peer.
REC-40 If a gateway cannot determine whether the endpoints of an REC-40 If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state SCTP association are active, then it MAY abandon the state
record if it has been idle for some time. In such cases, the record if it has been idle for some time. In such cases, the
value of the "established association idle-timeout" MUST NOT value of the "established association idle-timeout" MUST NOT
be less than two hours four minutes. The value of the be less than two hours four minutes. The value of the
"transitory association idle-timeout" MUST NOT be less than "transitory association idle-timeout" MUST NOT be less than
four minutes. The value of the idle-timeouts MAY be four minutes. The value of the idle-timeouts MAY be
configurable by the network administrator. configurable by the network administrator.
REC-41 If a gateway forwards an SCTP association, it MUST also REC-41 If a gateway forwards an SCTP association, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing SCTP headers that match the association messages containing SCTP headers that match the association
state record. state record.
REC-42 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-42 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for an SCTP association. state record for an SCTP association.
REC-43 All valid sequences of DCCP packets (defined in [RFC4340]) REC-43 All valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all flows to exterior servers and those MUST be forwarded for all flows to exterior servers, and for
flows to interior servers with explicitly permitted service any flows to interior servers with explicitly permitted
codes. service codes.
REC-44 A gateway MAY abandon a DCCP state record if it has been idle REC-44 A gateway MAY abandon a DCCP state record if it has been
for some time. In such cases, the value of the "established idle for some time. In such cases, the value of the "open
flow idle-timeout" MUST NOT be less than two hours four flow idle-timeout" MUST NOT be less than two hours
minutes. The value of the "transitory flow idle-timeout" four minutes. The value of the "transitory flow idle-
MUST NOT be less than eight minutes. The value of the idle- timeout" MUST NOT be less than eight minutes. The value of
timeouts MAY be configurable by the network administrator. the idle-timeouts MAY be configurable by the network
administrator.
REC-45 If a gateway forwards a DCCP flow, it MUST also forward REC-45 If an Internet gateway forwards a DCCP flow, it MUST also
ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing DCCP headers that match the flow state messages containing DCCP headers that match the flow state
record. record.
REC-46 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-46 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a DCCP flow. state record for a DCCP flow.
REC-47 Valid sequences of packets bearing SHIM6 payload extension REC-47 Valid sequences of packets bearing Shim6 payload extension
headers in their outer IP extension header chains MUST be headers in their outer IP extension header chains MUST be
forwarded for all outbound and explicitly permitted flows. forwarded for all outbound and explicitly permitted flows.
The content of the SHIM6 payload extension header MAY be The content of the Shim6 payload extension header MAY be
ignored for the purpose of state tracking. ignored for the purpose of state tracking.
REC-48 Gateways SHOULD implement a protocol to permit applications REC-48 Internet gateways with IPv6 simple security capabilities
to solicit inbound traffic without advance knowledge of the SHOULD implement a protocol to permit applications to solicit
addresses of exterior nodes with which they expect to inbound traffic without advance knowledge of the addresses of
communicate. exterior nodes with which they expect to communicate.
REC-49 Gateways MUST provide an easily selected configuration option REC-49 Internet gateways with IPv6 simple security capabilities MUST
that permits a "transparent mode" of operation that forwards provide an easily selected configuration option that permits
all unsolicited flows regardless of forwarding direction, a "transparent mode" of operation that forwards all
i.e. to disable the IPv6 simple security capabilities of the 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 gateway. The transparent mode of operation MAY be the
default configuration. default configuration.
REC-50 By DEFAULT, subscriber managed residential gateways MUST NOT REC-50 By DEFAULT, subscriber-managed residential gateways MUST NOT
offer management application services to the exterior offer management application services to the exterior
network. network.
5. Contributors 5. Contributors
Comments and criticisms during the development of this document were Comments and criticisms during the development of this document were
received from the following IETF participants: received from the following IETF participants:
+-------------------+----------------------------+ +-------------------+----------------------------+
| Jari Arkko | Ran Atkinson | | Jari Arkko | Ran Atkinson |
| Fred Baker | Norbert Bollow | | Fred Baker | Norbert Bollow |
| Cameron Byrne | Brian Carpenter | | Cameron Byrne | Brian Carpenter |
| Remi Despres | Arnaud Ebalard | | Remi Despres | Arnaud Ebalard |
| Fabrice Fontaine | Jun-ichiro "itojun" Hagino | | Fabrice Fontaine | Jun-ichiro "itojun" Hagino |
| Thomas Herbst | Christian Huitema | | Thomas Herbst | Christian Huitema |
| Joel Jaeggli | Cullen Jennings | | Joel Jaeggli | Cullen Jennings |
| Suresh Krishnan | Erik Kline | | Suresh Krishnan | Erik Kline |
| Julien Laganier | Kurt Erik Lindqvist | | Julien Laganier | Kurt Erik Lindqvist |
| Boucadair Mohamed | Keith Moore | | Mohamed Boucadair | Keith Moore |
| Robert Moskowitz | Teemu Savolainen | | Robert Moskowitz | Teemu Savolainen |
| Hemant Singh | Yaron Sheffer | | Hemant Singh | Yaron Sheffer |
| Mark Townsley | Iljitsch van Beijnum | | Mark Townsley | Iljitsch van Beijnum |
| Magnus Westerlund | Dan Wing | | Magnus Westerlund | Dan Wing |
+-------------------+----------------------------+ +-------------------+----------------------------+
The editor thanks them all for their contributions. The editor thanks them all for their contributions.
It must be noted that a substantial portion of the text describing It must be noted that a substantial portion of the text describing
the detailed requirements for TCP and UDP filtering is derived or the detailed requirements for TCP and UDP filtering is derived or
transposed from [RFC4787] and [RFC5382]. The editors of those transposed from [RFC4787] and [RFC5382]. The editors of those
documents, Francois Audet and Saikat Guha, also deserve substantial documents, Francois Audet and Saikat Guha, also deserve substantial
credit for the form of the present document. credit for the form of the present document.
6. IANA Considerations 6. Security Considerations
This memo includes no request to IANA.
7. Security Considerations
The IPv6 stateful filtering behavior described in this document is The IPv6 stateful filtering behavior described in this document is
intended to be similar in function to the filtering behavior of intended to be similar in function to the filtering behavior of
commonly use IPv4/NAT gateways, which have been widely sold as a commonly used IPv4/NAT gateways, which have been widely sold as a
security tool for residential and small-office/home-office networks. security tool for residential and small-office/home-office networks.
As noted in the security considerations section of [RFC2993], the As noted in the Security Considerations section of [RFC2993], the
true impact of these tools may be a reduction in security. It may be true impact of these tools may be a reduction in security. It may be
generally assumed that the impacts discussed in that document related generally assumed that the impacts discussed in that document related
to filtering (and not translation) are to be expected with the simple to filtering (and not translation) are to be expected with the simple
IPv6 security mechanisms described here. IPv6 security mechanisms described here.
In particular, it is worth noting that stateful filters create the In particular, it is worth noting that stateful filters create the
illusion of a security barrier, but without the managed intent of a illusion of a security barrier, but without the managed intent of a
firewall. Appropriate security mechanisms implemented in the end firewall. Appropriate security mechanisms implemented in the end
nodes, in conjunction with the [RFC4864] local network protection nodes, in conjunction with the [RFC4864] local network protection
methods, function without reliance on network layer hacks and methods, function without reliance on network layer hacks and
skipping to change at page 31, line 49 skipping to change at page 32, line 45
The security functions described in this document may be considered The security functions described in this document may be considered
redundant in the event that all IPv6 hosts using a particular gateway redundant in the event that all IPv6 hosts using a particular gateway
have their own IPv6 host firewall capabilities enabled. At the time have their own IPv6 host firewall capabilities enabled. At the time
of this writing, the vast majority of commercially available of this writing, the vast majority of commercially available
operating systems with support for IPv6 include IPv6 host firewall operating systems with support for IPv6 include IPv6 host firewall
capability. capability.
Also worth noting explicitly, a practical side-effect of the Also worth noting explicitly, a practical side-effect of the
recommendations in Section 3.2.4, to allow inbound IPsec and IKE recommendations in Section 3.2.4, to allow inbound IPsec and IKE
flows from exterior to interior, is to facilitate more transparent flows from exterior to interior, is to facilitate more transparent
communication by the use of Better-Than-Nothing-Security: An communication by the use of an unauthenticated mode of IPsec, as
Unauthenticated Mode of IPsec [RFC5386], and this may be a departure described in "Better-Than-Nothing-Security: An Unauthenticated Mode
from expectations of transparency set by traditional IPv4/NAT of IPsec" [RFC5386], and this may be a departure from expectations of
residential gateways. transparency set by traditional IPv4/NAT residential gateways.
Finally, residential gateways that implement simple security Finally, residential gateways that implement simple security
functions are a bastion between the interior and the exterior, and functions are a bastion between the interior and the exterior, and
therefore are a target of denial of service attacks against the therefore are a target of denial-of-service attacks against the
interior network itself by processes designed to consume the interior network itself by processes designed to consume the
resources of the gateway, e.g. a ping or SYN flood. Gateways should resources of the gateway, e.g., a ping or SYN flood. Gateways should
employ the same sorts of protection techniques as application servers employ the same sorts of protection techniques as application servers
on the Internet. on the Internet.
IETF makes no statement, expressed or implied, as to whether using The IETF makes no statement, expressed or implied, as to whether
the capabilities described in this document ultimately improve using the capabilities described in this document ultimately improves
security for any individual users or for the Internet community as a security for any individual users or for the Internet community as a
whole. whole.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
April 2008. April 2008.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T.
"Host Identity Protocol", RFC 5201, April 2008. Henderson, "Host Identity Protocol", RFC 5201,
April 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
8.2. Informative References 7.2. Informative References
[I-D.cheshire-nat-pmp] [NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Mapping Protocol (NAT-PMP)", Work in Progress,
draft-cheshire-nat-pmp-03 (work in progress), April 2008. April 2008.
[I-D.woodyatt-ald] [RFC1122] Braden, R., "Requirements for Internet Hosts -
Woodyatt, J., "Application Listener Discovery (ALD) for Communication Layers", STD 3, RFC 1122, October 1989.
IPv6", draft-woodyatt-ald-03 (work in progress),
July 2008.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
Communication Layers", STD 3, RFC 1122, October 1989. RFC 1337, May 1992.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
RFC 1337, May 1992. and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
E. Lear, "Address Allocation for Private Internets", Discovery for IP version 6", RFC 1981, August 1996.
BCP 5, RFC 1918, February 1996.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP
Address Spoofing", BCP 38, RFC 2827, May 2000. Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Networks", BCP 84, RFC 3704, March 2004. Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van
Bosch, "Next Steps in Signaling (NSIS): Framework", den Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005. RFC 4080, June 2005.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006. April 2006.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864, E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007. May 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communication (MIDCOM) Protocol Semantics", RFC 5189, Communication (MIDCOM) Protocol Semantics", RFC 5189,
March 2008. March 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP",
RFC 5382, October 2008. BCP 142, RFC 5382, October 2008.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386, Security: An Unauthenticated Mode of IPsec", RFC 5386,
November 2008. November 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[UPnP-IGD] [UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway
UPnP Forum, "Universal Plug and Play Internet Gateway Device Standardized Device Control Protocol",
Device Standardized Gateway Device Protocol", September 2010, <http://upnp.org/specs/gw/igd2/>.
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 Author's Address
james woodyatt (editor) James Woodyatt (editor)
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
US US
Email: jhw@apple.com EMail: jhw@apple.com
 End of changes. 206 change blocks. 
519 lines changed or deleted 546 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/