draft-ietf-v6ops-cpe-simple-security-04.txt   draft-ietf-v6ops-cpe-simple-security-05.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: BCP March 23, 2009 Intended status: Informational April 17, 2009
Expires: September 24, 2009 Expires: October 19, 2009
Recommended Simple Security Capabilities in Customer Premises Equipment Recommended Simple Security Capabilities in Customer Premises Equipment
for Providing Residential IPv6 Internet Service for Providing Residential IPv6 Internet Service
draft-ietf-v6ops-cpe-simple-security-04 draft-ietf-v6ops-cpe-simple-security-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 24, 2009. This Internet-Draft will expire on October 19, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . 7 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 7
3.2.1. Upper-layer Transport Protocols . . . . . . . . . . . 8 3.2.1. Upper-layer Transport Protocols . . . . . . . . . . . 8
3.2.2. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. UDP Filters . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. Teredo-specific Filters . . . . . . . . . . . . . . . 10 3.2.3. Teredo-specific Filters . . . . . . . . . . . . . . . 10
3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 10
3.2.5. Other Virtual Private Network Protocols . . . . . . . 11 3.2.5. Other Virtual Private Network Protocols . . . . . . . 11
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 11 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 11
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 15 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 14
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 18 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 17
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 20 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 20
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 21 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 20
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
A.1. draft-ietf-v6ops-cpe-simple-security-00 to A.1. draft-ietf-v6ops-cpe-simple-security-00 to
draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 29 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 29
A.2. draft-ietf-v6ops-cpe-simple-security-01 to A.2. draft-ietf-v6ops-cpe-simple-security-01 to
draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 30 draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 29
A.3. draft-ietf-v6ops-cpe-simple-security-02 to A.3. draft-ietf-v6ops-cpe-simple-security-02 to
draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 30 draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 30
A.4. draft-ietf-v6ops-cpe-simple-security-03 to A.4. draft-ietf-v6ops-cpe-simple-security-03 to
draft-ietf-v6ops-cpe-simple-security-04 . . . . . . . . . 31 draft-ietf-v6ops-cpe-simple-security-04 . . . . . . . . . 30
A.5. draft-ietf-v6ops-cpe-simple-security-04 to
draft-ietf-v6ops-cpe-simple-security-05 . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
In "Local Network Protection for IPv6" [RFC4864], IETF recommends In "Local Network Protection for IPv6" [RFC4864], IETF recommends
'simple security' capabilities for gateway devices that enable 'simple security' capabilities for gateway devices that enable
delivery of Internet services in residential and small office delivery of Internet services in residential and small office
settings. The principle goal of these capabilties is to improve settings. The principle goal of these capabilties is to improve
security of the IPv6 Internet without increasing the perceived security of the IPv6 Internet without increasing the perceived
complexity for users who just want to accomplish useful work. complexity for users who just want to accomplish useful work.
skipping to change at page 4, line 41 skipping to change at page 4, line 41
and small offices often used private IPv4 network address realms and small offices often used private IPv4 network address realms
[RFC1918] with Network Address Translation (NAT) functions deployed [RFC1918] with Network Address Translation (NAT) functions deployed
to present all the hosts on the interior network as a single host to to present all the hosts on the interior network as a single host to
the Internet service provider. The stateful packet filtering the Internet service provider. The stateful packet filtering
behavior of NAT set user expectations that persist today with behavior of NAT set user expectations that persist today with
residential IPv6 service. "Local Network Protection for IPv6" residential IPv6 service. "Local Network Protection for IPv6"
[RFC4864] recommends applying stateful packet filtering at [RFC4864] recommends applying stateful packet filtering at
residential IPv6 gateways that conforms to the user expectations residential IPv6 gateways that conforms to the user expectations
already in place. already in place.
It should be noted that NAT for IPv6 is both strictly forbidden by
the standards documents and strongly deprecated by Internet
operators. Only the perceived security benefits associated with
stateful packet filtering, which NAT requires as a side effect, are
thought relevant in the IPv6 residential usage scenario.
As the latest revision of this document is being drafted, As the latest revision of this document is being drafted,
conventional stateful packet filters are activated as a side effect conventional stateful packet filters activate new states as a side
of outbound flow initiations from interior network nodes. This effect of forwarding outbound flow initiations from interior network
requires applications to have advance knowledge of the addresses of nodes. This requires applications to have advance knowledge of the
exterior nodes with which they expect to communicate. Several addresses of exterior nodes with which they expect to communicate.
proposals are currently under consideration for allowing applications Several proposals are currently under consideration for allowing
to solicit inbound traffic from exterior nodes without advance applications to solicit inbound traffic from exterior nodes without
knowledge of their addresses. While consensus within the Internet advance knowledge of their addresses. While consensus within the
engineering community has emerged that such protocols are necessary Internet engineering community has emerged that such protocols are
to implement in residential IPv6 gateways, the best current practice necessary to implement in residential IPv6 gateways, the best current
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 Internet routers
[RFC4294], residential gateways are expected to have basic stateless [RFC4294], residential gateways are expected to have basic stateless
filters for prohibiting certains kinds of traffic with invalid filters for prohibiting certains kinds of traffic with invalid
headers, e.g. martian packets, spoofs, routing header type code zero, headers, e.g. martian packets, spoofs, routing header type code zero,
etc. etc.
Internet gateways that route multicast traffic are expected to Internet gateways that route multicast traffic are expected to
skipping to change at page 6, line 4 skipping to change at page 5, line 46
keep IPv6 flows subject to a consistent policy. If the security keep IPv6 flows subject to a consistent policy. If the security
functions of an IPv6 residential gateway can be bypassed through functions of an IPv6 residential gateway can be bypassed through
Teredo [RFC4380], then application developers will be encouraged to Teredo [RFC4380], then application developers will be encouraged to
use it even at nodes where native IPv6 service is available. This use it even at nodes where native IPv6 service is available. This
will have the effect of impeding the completion of the transition to will have the effect of impeding the completion of the transition to
native IPv6. native IPv6.
Residential IPv6 gateways are expected to continue operating as IPv4/ Residential IPv6 gateways are expected to continue operating as IPv4/
NAT gateways for the foreseeable future. To prevent Teredo from NAT gateways for the foreseeable future. To prevent Teredo from
acquiring a utility that it was never meant to have on networks where acquiring a utility that it was never meant to have on networks where
both IPv4/NAT and native IPv6 services are available, gateways MUST both IPv4/NAT and native IPv6 services are available, gateways on
impede Teredo tunnels by blocking clients from learning their mapped such networks SHOULD impede Teredo tunnels by blocking clients from
addresses and ports in the qualification procedure described in learning their mapped addresses and ports in the qualification
sections 5.2.1 and 5.2.2 of [RFC4380]. (Note: this is a necessary procedure described in sections 5.2.1 and 5.2.2 of [RFC4380]. (Note:
addition to the "automatic sunset" provision in section 5.5 of this is a necessary addition to the "automatic sunset" provision in
[RFC4380] because it's all too common that nested IPv4/NAT gateways section 5.5 of [RFC4380] because it's all too common that nested
are deployed unintentionally in residential settings and without IPv4/NAT gateways are deployed unintentionally in residential
consideration for Internet architectural implications.) settings and without consideration for Internet architectural
implications.)
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 transport layers like User Datagram Protocol stateful filtering of transport layers like User Datagram Protocol
(UDP) [RFC0768] (and Lightweight User Datagram Protocol (UDP-Lite) (UDP) [RFC0768] (and Lightweight User Datagram Protocol (UDP-Lite)
[RFC3828]), Transport Control Protocol (TCP) [RFC0793], the Stream [RFC3828]), Transport Control Protocol (TCP) [RFC0793], the Stream
Control Transmission Protocol (SCTP) [RFC4960], the Datagram Control Transmission Protocol (SCTP) [RFC4960], the Datagram
Congestion Control Protocol (DCCP) [RFC4340], and potentially any Congestion Control Protocol (DCCP) [RFC4340], and potentially any
standards-track transport protocols to be defined in the future. standards-track transport protocols to be defined in the future.
skipping to change at page 7, line 21 skipping to change at page 7, line 13
prefixes, and packets with deprecated extension headers. prefixes, and packets with deprecated extension headers.
Other stateless filters are recommended to guard against spoofing, to Other stateless filters are recommended to guard against spoofing, to
enforce multicast scope boundaries, and to isolate certain local enforce multicast scope boundaries, and to isolate certain local
network services from the public Internet. network services from the public Internet.
R1: Packets bearing in their outer IPv6 headers multicast source R1: Packets bearing in their outer IPv6 headers multicast source
addresses MUST NOT be forwarded or transmitted on any interface. addresses MUST NOT be forwarded or transmitted on any interface.
R2: Packets bearing in their outer IPv6 headers multicast destination R2: Packets bearing in their outer IPv6 headers multicast destination
addresses of equal or narrower scope that the configured scope addresses of equal or narrower scope than the configured scope
boundary level of the gateway MUST NOT be forwarded in any direction. boundary level of the gateway MUST NOT be forwarded in any direction.
The DEFAULT scope boundary level SHOULD be organization-local scope. The DEFAULT scope boundary level SHOULD be organization-local scope.
R3: Packets bearing deprecated extension headers prior to their first R3: Packets bearing deprecated extension headers prior to their first
upper-layer-protocol header MUST NOT be forwarded or transmitted on upper-layer-protocol header SHOULD NOT be forwarded or transmitted on
any interface. In particular, all packets with routing extension any interface. In particular, all packets with routing extension
header type 0 [RFC2460] preceding the first upper-layer-protocol header type 0 [RFC2460] preceding the first upper-layer-protocol
header MUST NOT be forwarded. header MUST NOT be forwarded.
R4: Outbound packets MUST NOT be forwarded if the source address in R4: Outbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header does not have a unicast prefix assigned for their outer IPv6 header does not have a unicast prefix configured for
use by globally reachable nodes on the interior network. use by globally reachable nodes on the interior network.
R4: Inbound packets MUST NOT be forwarded if the source address in R5: Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for use their outer IPv6 header has a global unicast prefix assigned for use
by globally reachable nodes on the interior network. by globally reachable nodes on the interior network.
R5: Packets MAY be discarded if the source and/or destination address R6: By DEFAULT, packets with unique local source and/or destination
in the outer IPv6 header is a unique local address. By DEFAULT, addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior
gateways SHOULD NOT forward packets across unique local address scope network.
boundaries.
R6: By DEFAULT, inbound non-recursive DNS queries received on R7: By DEFAULT, inbound non-recursive DNS queries received on
exterior interfaces MUST NOT be processed by any integrated DNS proxy exterior interfaces MUST NOT be processed by any integrated DNS proxy
resolving server. resolving server.
R7: Inbound DHCP discovery packets received on exterior interfaces R8: Inbound DHCP discovery packets received on exterior interfaces
MUST NOT be processed by any integrated DHCP server. MUST NOT be processed by any integrated DHCP server.
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 abandoned
when no further communication is detected after some period of time. when no further communication is detected after some period of time.
skipping to change at page 10, line 22 skipping to change at page 10, line 12
R17: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way R17: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way
as UDP exchanges, except that the upper-layer transport protocol as UDP exchanges, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore UDP identifier for UDP-Lite is not the same as UDP, and therefore UDP
packets MUST NOT match UDP-Lite state records, and vice versa. packets MUST NOT match UDP-Lite state records, and vice versa.
3.2.3. Teredo-specific Filters 3.2.3. Teredo-specific Filters
Transitional residential IPv6 gateways that also feature integrated Transitional residential IPv6 gateways that also feature integrated
IPv4/NAT gateways require special filtering for Teredo tunnels. IPv4/NAT gateways require special filtering for Teredo tunnels.
R18: Where an IPv6 prefix is advertised on an interior interface R18: Where a globally routed IPv6 prefix is advertised on an interior
alongside an IPv4 private address [RFC1918] and IPv4 Internet service interface and IPv4 Internet service is provided with NAT [RFC4787],
is provided with NAT [RFC4787], the Teredo qualification procedure the Teredo qualification procedure (see section 5.2.1 and 5.2.2 of
(see section 5.2.1 and 5.2.2 of [RFC4380]) for clients in the [RFC4380]) for clients in the interior SHOULD be prohibited by the
interior MUST be prohibited by the IPv4/NAT stateful filter. This IPv4/NAT stateful filter. This SHOULD be done by blocking outbound
SHOULD be done by blocking outbound UDP initiations to port 3544, the UDP initiations to port 3544, the port reserved by IANA for Teredo
port reserved by IANA for Teredo servers. servers.
3.2.4. IPsec and Internet Key Exchange (IKE) 3.2.4. IPsec and Internet Key Exchange (IKE)
Internet protocol security (IPsec) offers greater flexibility and Internet protocol security (IPsec) offers greater flexibility and
better overall security than the simple security of stateful packet better overall security than the simple security of stateful packet
filtering at network perimeters. Therefore, residential IPv6 filtering at network perimeters. Therefore, residential IPv6
gateways need not prohibit IPsec traffic flows. gateways need not prohibit IPsec traffic flows.
R19: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R19: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
skipping to change at page 11, line 45 skipping to change at page 11, line 38
the automatic creation of such state. the automatic creation of such state.
3.3.1. TCP Filters 3.3.1. TCP Filters
An interior endpoint initiates a TCP connection through a stateful An interior endpoint initiates a TCP connection through a stateful
packet filter by sending a SYN packet. The filter allocates (or packet filter by sending a SYN packet. The filter allocates (or
reuses) a filter state record for the connection. The state record reuses) a filter state record for the connection. The state record
defines the interior and exterior IP addresses and ports used for defines the interior and exterior IP addresses and ports used for
forwarding all packets for that connection. forwarding all packets for that connection.
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 (Fig. 8, [RFC0793]) to traverse
stateful filters. In the simultaneous-open mode of operation, both stateful filters. In the simultaneous-open mode of operation, both
peers send SYN packets for the same TCP connection. The SYN packets peers send SYN packets for the same TCP connection. The SYN packets
cross in the network. Upon receiving the other end's SYN packet, cross in the network. Upon receiving the other end's SYN packet,
each end responds with a SYN-ACK packet, which also cross in the each end responds with a SYN-ACK packet, which also cross in the
network. The connection is established at each endpoint once the network. The connection is established at each endpoint once the
SYN-ACK packets 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 for a filter to receive, process and forward all packets for a
skipping to change at page 13, line 6 skipping to change at page 12, line 46
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 ICMP messages allows the sender to detect that the SYN did through ICMP 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.
R27: A gateway MUST NOT signal an error for an unsolicited inbound R27: By DEFAULT, a gateway MUST respond with an ICMP Destination
SYN packet for at least 6 seconds after the packet is received. If Unreachable error (administratively prohibited) to any unsolicited
during this interval the gateway receives and forwards an outbound inbound SYN packet after waiting at least 6 seconds without first
SYN for the connection, then the gateway MUST discard the original forwarding the associated outbound SYN or SYN/ACK from the interior
unsolicited inbound SYN packet without signaling an error. peer.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of the
network administrator.
A TCP filter maintains state associated with in-progress and A TCP filter maintains state associated with in-progress and
established connections. Because of this, a filter is susceptible to established connections. Because of this, a filter is susceptible to
a resource-exhaustion attack whereby an attacker (or virus) on the 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
skipping to change at page 14, line 14 skipping to change at page 13, line 51
connection idle-timeout" for a filter is defined as the minimum time connection idle-timeout" for a filter is defined as the minimum time
a TCP connection in the partially-open or closing phases must remain a TCP connection in the partially-open or closing phases must remain
idle before the filter considers the associated state record a idle before the filter considers the associated state record a
candidate for collection. TCP connections in the TIME_WAIT state are candidate for collection. TCP connections in the TIME_WAIT state are
not affected by the "transitory connection idle-timeout" parameter. not affected by the "transitory connection idle-timeout" parameter.
R28: If a gateway cannot determine whether the endpoints of a TCP R28: If a gateway cannot determine whether the endpoints of a TCP
connection are active, then it MAY abandon the state record if it has connection are active, then it MAY abandon the state record if it has
been idle for some time. In such cases, the value of the been idle for some time. In such cases, the value of the
"established connection idle-timeout" MUST NOT be less than two hours "established connection idle-timeout" MUST NOT be less than two hours
four minutes. The value of the "transitory connection idle-timeout" four minutes, as discussed in [RFC5382]. The value of the
MUST NOT be less than four minutes. The value of the idle-timeouts "transitory connection idle-timeout" MUST NOT be less than four
MAY be configurable by the network administrator. minutes. The value of the idle-timeouts MAY be configurable by the
network administrator.
Behavior for handing RST packets, or connections in the TIME_WAIT Behavior for handing RST packets, or connections in the TIME_WAIT
state is left unspecified. A gateway MAY hold state for a connection state is left unspecified. A gateway MAY hold state for a connection
in TIME_WAIT state to accommodate retransmissions of the last ACK. in 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 connection, holding state interior endpoints properly closing the TCP connection, holding state
for a closed connection can limit the throughput of connections for a closed connection can limit the throughput of connections
through a gateway with limited resources. [RFC1337] discusses through a gateway with limited resources. [RFC1337] discusses
hazards associated with TIME_WAIT assassination. hazards associated with TIME_WAIT assassination.
skipping to change at page 16, line 17 skipping to change at page 16, line 6
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 ICMP messages allows the sender to detect that the INIT through ICMP 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 simultaneous-open mode of operation.
R32: A gateway MUST NOT signal an error for an unsolicited inbound R32: By DEFAULT, a gateway MUST respond with an ICMP Destination
INIT packet for at least 6 seconds after the packet is received. If Unreachable error (administratively prohibited) to any unsolicited
during this interval the gateway receives and forwards an outbound inbound INIT packet after waiting at least 6 seconds without first
INIT packet for the association, the the gateway MUST discard the forwarding the associated outbound INIT from the interior peer.
original unsolicited inbound INIT packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original INIT--
unless sending any response violates the security policy of the
network administrator.
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
skipping to change at page 20, line 46 skipping to change at page 20, line 30
Some applications expect to solicit traffic from exterior nodes Some applications expect to solicit traffic from exterior nodes
without any advance knowledge of the exterior address. This without any advance knowledge of the exterior address. This
requirement is met by IPv4/NAT gateways typically by the use of requirement is met by IPv4/NAT gateways typically by the use of
either [I-D.cheshire-nat-pmp] or [UPnP-IGD]. either [I-D.cheshire-nat-pmp] or [UPnP-IGD].
One proposal that has been offered as an Internet Draft is the One proposal that has been offered as an Internet Draft is the
Application Listener Discovery Protocol [I-D.woodyatt-ald]. It Application Listener Discovery Protocol [I-D.woodyatt-ald]. It
remains to be seen whether the Internet Gateway Device profile of the remains to be seen whether the Internet Gateway Device profile of the
Universal Plug And Play protocol will be extended for IPv6. Other Universal Plug And Play protocol will be extended for IPv6. Other
proposals of note include the Middlebox Communication Protocol proposals of note include the Middlebox Communication Protocol
[RFC3989] and the Next Steps in Signaling framework [RFC4080]. No [RFC5189] and the Next Steps in Signaling framework [RFC4080]. No
consensus has yet emerged in the Internet engineering community as to consensus has yet emerged in the Internet engineering community as to
which proposal is most appropriate for residential IPv6 usage which proposal is most appropriate for residential IPv6 usage
scenarios. scenarios.
R31: Gateways MUST implement a protocol to permit applications to R41: Gateways SHOULD implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses of solicit inbound traffic without advance knowledge of the addresses of
exterior nodes with which they expect to communicate. This protocol exterior nodes with which they expect to communicate. If
MUST have a specification that meets the requirements of [RFC5378], implemented, this protocol MUST have a specification that meets the
[RFC3979], [RFC4748] and [RFC4879]. requirements of [RFC3979], [RFC4879] and [RFC5378].
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.
R1 Packets bearing in their outer IPv6 headers multicast source R1 Packets bearing in their outer IPv6 headers multicast source
addresses MUST NOT be forwarded or transmitted on any interface. addresses MUST NOT be forwarded or transmitted on any interface.
R2 Packets bearing in their outer IPv6 headers multicast destination R2 Packets bearing in their outer IPv6 headers multicast destination
addresses of equal or narrower scope that the configured scope addresses of equal or narrower scope that the configured scope
boundary level of the gateway MUST NOT be forwarded in any boundary level of the gateway MUST NOT be forwarded in any
direction. The DEFAULT scope boundary level SHOULD be direction. The DEFAULT scope boundary level SHOULD be
organization-local scope. organization-local scope.
R3 Packets bearing deprecated extension headers prior to their first R3 Packets bearing deprecated extension headers prior to their first
upper-layer-protocol header MUST NOT be forwarded or transmitted upper-layer-protocol header SHOULD NOT be forwarded or transmitted
on any interface. In particular, all packets with routing on any interface. In particular, all packets with routing
extension header type 0 [RFC2460] preceding the first upper-layer- extension header type 0 [RFC2460] preceding the first upper-layer-
protocol header MUST NOT be forwarded. protocol header MUST NOT be forwarded.
R4 Outbound packets MUST NOT be forwarded if the source address in R4 Outbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header does not have a unicast prefix assigned their outer IPv6 header does not have a unicast prefix assigned
for use by globally reachable nodes on the interior network. for use by globally reachable nodes on the interior network.
R4 Inbound packets MUST NOT be forwarded if the source address in R5 Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for their outer IPv6 header has a global unicast prefix assigned for
use by globally reachable nodes on the interior network. use by globally reachable nodes on the interior network.
R5 Packets MAY be discarded if the source and/or destination address R6 By DEFAULT, packets with unique local source and/or destination
in the outer IPv6 header is a unique local address. By DEFAULT, addresses [RFC4193] SHOULD NOT be forwarded to or from the
gateways SHOULD NOT forward packets across unique local address exterior network.
scope boundaries.
R6 By DEFAULT, inbound non-recursive DNS queries received on exterior R7 By DEFAULT, inbound non-recursive DNS queries received on exterior
interfaces MUST NOT be processed by any integrated DNS proxy interfaces MUST NOT be processed by any integrated DNS proxy
resolving server. resolving server.
R7 Inbound DHCP discovery packets received on exterior interfaces R8 Inbound DHCP discovery packets received on exterior interfaces
MUST NOT be processed by any integrated DHCP server. MUST NOT be processed by any integrated DHCP server.
R8 Inbound packets not matching any existing filter state record for
a permitted transport flow MUST NOT be forwarded to the interior
network, and an ICMP Error message of type Administratively
Prohibited MUST be sent to the source address.
R9 Filter state records for generic upper-layer transport protocols R9 Filter state records for generic upper-layer transport protocols
MUST BE indexable by a 3-tuple comprising the interior node MUST BE indexable by a 3-tuple comprising the interior node
address, the exterior node address and the upper-layer transport address, the exterior node address and the upper-layer transport
protocol identifier. protocol identifier.
R10 Filter state records for generic upper-layer transport protocols R10 Filter state records for generic upper-layer transport protocols
MUST NOT be deleted or recycled until an idle timer not less than MUST NOT be deleted or recycled until an idle timer not less than
two minutes has expired without having forwarded a packet matching two minutes has expired without having forwarded a packet matching
the state in some configurable amount of time. By DEFAULT, the the state in some configurable amount of time. By DEFAULT, the
idle timer for such state records is five minutes. idle timer for such state records is five minutes.
skipping to change at page 23, line 10 skipping to change at page 22, line 35
the exchange state record. the exchange state record.
R16 Receipt of any sort of ICMP message MUST NOT terminate the state R16 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a UDP exchange. record for a UDP exchange.
R17 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way R17 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way
as UDP exchanges, except that the upper-layer transport protocol as UDP exchanges, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore UDP identifier for UDP-Lite is not the same as UDP, and therefore UDP
packets MUST NOT match UDP-Lite state records, and vice versa. packets MUST NOT match UDP-Lite state records, and vice versa.
R18 Where an IPv6 prefix is advertised on an interior interface R18 Where a globally routed IPv6 prefix is advertised on an interior
alongside an IPv4 private address [RFC1918] and IPv4 Internet interface and IPv4 Internet service is provided with NAT
service is provided with NAT [RFC4787], the Teredo qualification [RFC4787], the Teredo qualification procedure (see section 5.2.1
procedure (see section 5.2.1 and 5.2.2 of [RFC4380]) for clients and 5.2.2 of [RFC4380]) for clients in the interior MUST be
in the interior MUST be prohibited by the IPv4/NAT stateful prohibited by the IPv4/NAT stateful filter. This SHOULD be done
filter. This SHOULD be done by blocking outbound UDP initiations by blocking outbound UDP initiations to port 3544, the port
to port 3544, the port reserved by IANA for Teredo servers. reserved by IANA for Teredo servers.
R19 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R19 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
with destination extension headers of type "Authenticated Header with destination extension headers of type "Authenticated Header
(AH)" [RFC4302] in their outer IP extension header chain. (AH)" [RFC4302] in their outer IP extension header chain.
R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses, the forwarding of packets, to and from legitimate node addresses,
with an upper layer protocol of type "Encapsulating Security with an upper layer protocol of type "Encapsulating Security
Payload (ESP)" [RFC4303] in their outer IP extension header chain. Payload (ESP)" [RFC4303] in their outer IP extension header chain.
skipping to change at page 24, line 19 skipping to change at page 23, line 45
open. open.
R26 If application transparency is most important, then a stateful R26 If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior packet filter SHOULD have "Endpoint independent filter" behavior
for TCP. If a more stringent filtering behavior is most 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 the network administrator, and it MAY be independent of the
filtering behavior for UDP and other protocols. filtering behavior for UDP and other protocols.
R27 A gateway MUST NOT signal an error for an unsolicited inbound R27 By DEFAULT, a gateway MUST respond with an ICMP Destination
SYN packet for at least 6 seconds after the packet is received. Unreachable error (administratively prohibited) to any unsolicited
If during this interval the gateway receives and forwards an inbound SYN packet after waiting at least 6 seconds without first
outbound SYN for the connection, then the gateway MUST discard the forwarding the associated outbound SYN or SYN/ACK from the
original unsolicited inbound SYN packet without signaling an interior peer.
error. Otherwise, the gateway SHOULD send an ICMP Destination
Unreachable error, code 1 (administratively prohibited) for the
original SYN-- unless sending any response violates the security
policy of network administrator.
R28 If a gateway cannot determine whether the endpoints of a TCP R28 If a gateway cannot determine whether the endpoints of a TCP
connection are active, then it MAY abandon the state record if it connection 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 connection idle-timeout" MUST NOT be less than two "established connection idle-timeout" MUST NOT be less than two
hours four minutes. The value of the "transitory connection idle- hours four minutes, as discussed in [RFC5382]. The value of the
timeout" MUST NOT be less than four minutes. The value of the "transitory connection idle-timeout" MUST NOT be less than four
idle-timeouts MAY be configurable by the network administrator. minutes. The value of the idle-timeouts MAY be configurable by
the network administrator.
R29 If a gateway forwards a TCP connection, it MUST also forward R29 If a gateway forwards a TCP connection, it MUST also forward
ICMP Destination Unreachable messages containing TCP headers that ICMP Destination Unreachable messages containing TCP headers that
match the connection state record. match the connection state record.
R30 Receipt of any sort of ICMP message MUST NOT terminate the state R30 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a TCP connection. record for a TCP connection.
R31 Gateways MUST implement a protocol to permit applications to R31 All valid sequences of SCTP packets (defined in [RFC4960]) MUST
solicit inbound traffic without advance knowledge of the addresses
of exterior nodes with which they expect to communicate. This
protocol MUST have a specification that meets the requirements of
[RFC5378], [RFC3979], [RFC4879] and [RFC4748].
R33 All valid sequences of SCTP packets (defined in [RFC4960]) MUST
be forwarded for outbound associations and explicitly permitted 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 simultaneous-open modes of operation
MUST be supported. MUST be supported.
R34 A gateway MUST NOT signal an error for an unsolicited inbound R32 By DEFAULT, a gateway MUST respond with an ICMP Destination
Unreachable error (administratively prohibited) to any unsolicited
inbound INIT packet after waiting at least 6 seconds without first
forwarding the associated outbound INIT from the interior peer.
R33 A gateway MUST NOT signal an error for an unsolicited inbound
INIT packet for at least 6 seconds after the packet is received. INIT packet for at least 6 seconds after the packet is received.
If during this interval the gateway receives and forwards an If during this interval the gateway receives and forwards an
outbound INIT packet for the association, the the gateway MUST outbound INIT packet for the association, the the gateway MUST
discard the original unsolicited inbound INIT packet without discard the original unsolicited inbound INIT packet without
signaling an error. Otherwise, the gateway SHOULD send an ICMP signaling an error. Otherwise, the gateway SHOULD send an ICMP
Destination Unreachable error, code 1 (administratively Destination Unreachable error, code 1 (administratively
prohibited) for the original INIT-- unless sending any response prohibited) for the original INIT-- unless sending any response
violates the security policy of the network administrator. violates the security policy of the network administrator.
R33 If a gateway cannot determine whether the endpoints of an SCTP R34 If a gateway cannot determine whether the endpoints of an SCTP
association are active, then it MAY abandon the state record if it 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 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 two
hours four minutes. The value of the "transitory association hours four minutes. The value of the "transitory association
idle-timeout" MUST NOT be less than four minutes. The value of idle-timeout" MUST NOT be less than four minutes. The value of
the idle-timeouts MAY be configurable by the network the idle-timeouts MAY be configurable by the network
administrator. administrator.
R34 If a gateway forwards an SCTP association, it MUST also forward R35 If a gateway forwards an SCTP association, it MUST also forward
ICMP Destination Unreachable messages containing SCTP headers that ICMP Destination Unreachable messages containing SCTP headers that
match the association state record. match the association state record.
R35 Receipt of any sort of ICMP message MUST NOT terminate the state R36 Receipt of any sort of ICMP message MUST NOT terminate the state
record for an SCTP association. record for an SCTP association.
R36 All valid sequences of DCCP packets (defined in [RFC4340]) MUST R37 All valid sequences of DCCP packets (defined in [RFC4340]) MUST
be forwarded for all connections to exterior servers and those be forwarded for all connections to exterior servers and those
connections to interior servers with explicitly permitted service connections to interior servers with explicitly permitted service
codes. codes.
R37 A gateway MAY abandon a DCCP state record if it has been idle R38 A gateway MAY abandon a DCCP state record if it has been idle
for some time. In such cases, the value of the "established for some time. In such cases, the value of the "established
connection idle-timeout" MUST NOT be less than two hours four connection idle-timeout" MUST NOT be less than two hours four
minutes. The value of the "transitory connection idle-timeout" minutes. The value of the "transitory connection idle-timeout"
MUST NOT be less than eight minutes. The value of the idle- MUST NOT be less than eight minutes. The value of the idle-
timeouts MAY be configurable by the network administrator. timeouts MAY be configurable by the network administrator.
R38 If a gateway forwards a DCCP connection, it MUST also forward R39 If a gateway forwards a DCCP connection, it MUST also forward
ICMP Destination Unreachable messages containing DCCP headers that ICMP Destination Unreachable messages containing DCCP headers that
match the connection state record. match the connection state record.
R39 Receipt of any sort of ICMP message MUST NOT terminate the state R40 Receipt of any sort of ICMP message MUST NOT terminate the state
record for a DCCP connection. record for a DCCP connection.
R41 Gateways SHOULD implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses
of exterior nodes with which they expect to communicate. If
implemented, this protocol MUST have a specification that meets
the requirements of [RFC3979], [RFC4879] and [RFC5378].
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:
Fred Baker Fred Baker
Norbert Bollow Norbert Bollow
Brian Carpenter Brian Carpenter
skipping to change at page 26, line 40 skipping to change at page 26, line 21
Kurt Erik Lindqvist Kurt Erik Lindqvist
Iljitsch van Beijnum Iljitsch van Beijnum
Yaron Sheffer Yaron Sheffer
Dan Wing Dan Wing
Much of the text describing the detailed requirements for TCP and UDP Much of the text describing the detailed requirements for TCP and UDP
filtering is derived or transposed from [RFC5382] and [RFC4787], and filtering is derived or transposed from [RFC4787] and [RFC5382], and
some form of attribution here may therefore be appopriate. some form of attribution here may therefore be appopriate.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 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
skipping to change at page 28, line 10 skipping to change at page 27, line 39
[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.
[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.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005. Technology", BCP 79, RFC 3979, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, 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.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF
Trust", RFC 4748, October 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.
[RFC4879] Narten, T., "Clarification of the Third Party Disclosure [RFC4879] Narten, T., "Clarification of the Third Party Disclosure
Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
skipping to change at page 29, line 18 skipping to change at page 28, line 47
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992. RFC 1337, May 1992.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communications (MIDCOM) Protocol Semantics", RFC 3989,
February 2005.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", 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.
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communication (MIDCOM) Protocol Semantics", RFC 5189,
March 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [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", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway UPnP Forum, "Universal Plug and Play Internet Gateway
Device Standardized Gateway Device Protocol", Device Standardized Gateway Device Protocol",
September 2006, September 2006,
<http://www.upnp.org/standardizeddcps/igd.asp>. <http://www.upnp.org/standardizeddcps/igd.asp>.
skipping to change at page 31, line 18 skipping to change at page 30, line 47
o Removed references to draft-hoagland-v6ops-teredosecconcerns. o Removed references to draft-hoagland-v6ops-teredosecconcerns.
o Updated reference to [RFC5382]. o Updated reference to [RFC5382].
o Add reference to [RFC4879]. o Add reference to [RFC4879].
o Use SYSTEM resources for referencing Internet Drafts. o Use SYSTEM resources for referencing Internet Drafts.
o Updated IPR boilerplate. o Updated IPR boilerplate.
A.5. draft-ietf-v6ops-cpe-simple-security-04 to
draft-ietf-v6ops-cpe-simple-security-05
o Changed category from BCP to Informational.
o Change text in section 3 to read "activate new states as a side
effect of forwarding outbound flow initiations" to improve
clarity.
o Qualified an informative insertion by inserting the phrase "on
such networks" appropriately and relaxed the MUST to a SHOULD in
the text about impeding Teredo.
o Changed MUST to SHOULD in R18 about impeding Teredo.
o Replace "that" with "than" in R2.
o Removed an unnecessary and incorrect paragraph about IPv6/NAT from
the overview.
o Changed the first MUST NOT to a SHOULD NOT in R3.
o Renumbered the recommendations in section 3.1 to increase
monotonically and match the same recommendations in the summary.
o Rewrote R6, R27 and R32 for clarity.
o Added normative reference to [RFC4193].
o Removed R8 from the summary, which did not appear in section 3.1,
and was redundant with R27.
o Added a reference to [RFC5382] in R28.
o Inserted R32 into the summary, which had been skipped.
o Removed "alongside an IPv4 private address" and inserted "globally
routed" before the first use of the word "prefix" in R18.
o Qualify an assertion with "some" in the informative section about
TCP filters.
o Updated obsolete references to RFC 3989 and RFC 4748.
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. 51 change blocks. 
135 lines changed or deleted 163 lines changed or added

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