draft-ietf-v6ops-cpe-simple-security-07.txt   draft-ietf-v6ops-cpe-simple-security-08.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Informational July 27, 2009 Intended status: Informational October 19, 2009
Expires: January 28, 2010 Expires: April 22, 2010
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-07 draft-ietf-v6ops-cpe-simple-security-08
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 January 28, 2010. This Internet-Draft will expire on April 22, 2010.
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 23 skipping to change at page 2, line 23
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 7 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 7
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 7 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 7
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 8 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 8
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 9 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 9
3.2.1. Internet Control and Management . . . . . . . . . . . 9 3.2.1. Internet Control and Management . . . . . . . . . . . 9
3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 9 3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 9
3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. 6to4 Tunnels . . . . . . . . . . . . . . . . . . . . . 11 3.2.4. 6to4 Tunnels . . . . . . . . . . . . . . . . . . . . . 11
3.2.5. Teredo-specific Filters . . . . . . . . . . . . . . . 11 3.2.5. Teredo-specific Filters . . . . . . . . . . . . . . . 11
3.2.6. IPsec and Internet Key Exchange (IKE) . . . . . . . . 12 3.2.6. IPsec and Internet Key Exchange (IKE) . . . . . . . . 12
3.2.7. Other Virtual Private Network Protocols . . . . . . . 12 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 12
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 13
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 19
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 22 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 21
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 22 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 23
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . 32 draft-ietf-v6ops-cpe-simple-security-01 . . . . . . . . . 32
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 . . . . . . . . . 33 draft-ietf-v6ops-cpe-simple-security-02 . . . . . . . . . 32
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 . . . . . . . . . 33 draft-ietf-v6ops-cpe-simple-security-03 . . . . . . . . . 33
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 . . . . . . . . . 34 draft-ietf-v6ops-cpe-simple-security-04 . . . . . . . . . 33
A.5. draft-ietf-v6ops-cpe-simple-security-04 to A.5. draft-ietf-v6ops-cpe-simple-security-04 to
draft-ietf-v6ops-cpe-simple-security-05 . . . . . . . . . 34 draft-ietf-v6ops-cpe-simple-security-05 . . . . . . . . . 34
A.6. draft-ietf-v6ops-cpe-simple-security-05 to A.6. draft-ietf-v6ops-cpe-simple-security-05 to
draft-ietf-v6ops-cpe-simple-security-06 . . . . . . . . . 35 draft-ietf-v6ops-cpe-simple-security-06 . . . . . . . . . 35
A.7. draft-ietf-v6ops-cpe-simple-security-06 to A.7. draft-ietf-v6ops-cpe-simple-security-06 to
draft-ietf-v6ops-cpe-simple-security-07 . . . . . . . . . 36 draft-ietf-v6ops-cpe-simple-security-07 . . . . . . . . . 35
A.8. draft-ietf-v6ops-cpe-simple-security-07 to
draft-ietf-v6ops-cpe-simple-security-08 . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
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 capabilities is to improve settings. The principle goal of these capabilities 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 8, line 19 skipping to change at page 8, line 19
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 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 which bear in their outer IPv6 headers multicast source REC-1: Packets which bear in their outer IPv6 headers multicast
addresses MUST NOT be forwarded or transmitted on any interface. source addresses MUST NOT be forwarded or transmitted on any
interface.
R2: Packets which bear in their outer IPv6 headers multicast REC-2: Packets which bear in their outer IPv6 headers multicast
destination addresses of equal or narrower scope (see section 2.7 of destination addresses of equal or narrower scope (see section 2.7 of
IP Version 6 Addressing Architecture [RFC4291]) than the configured IP Version 6 Addressing Architecture [RFC4291]) than the configured
scope boundary level of the gateway MUST NOT be forwarded in any scope boundary level of the gateway MUST NOT be forwarded in any
direction. The DEFAULT scope boundary level SHOULD be organization- direction. The DEFAULT scope boundary level SHOULD be organization-
local scope, and it SHOULD be configurable by the network local scope, and it SHOULD be configurable by the network
admininistrator. admininistrator.
R3: Packets bearing source and/or destination addresses forbidden to REC-3: Packets bearing source and/or destination addresses forbidden
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 addresses with IPv4-Mapped, IPv4-Compatible, Documentation and
ORCHID prefixes. ORCHID prefixes.
R4: Packets bearing deprecated extension headers prior to their first REC-4: Packets bearing deprecated extension headers prior to their
upper-layer-protocol header SHOULD NOT be forwarded or transmitted on first upper-layer-protocol header SHOULD NOT be forwarded or
any interface. In particular, all packets with routing extension transmitted on any interface. In particular, all packets with
header type 0 [RFC2460] preceding the first upper-layer-protocol routing extension header type 0 [RFC2460] preceding the first upper-
header MUST NOT be forwarded. (See [RFC5095] for additional layer-protocol header MUST NOT be forwarded. (See [RFC5095] for
background.) additional background.)
R5: Outbound packets MUST NOT be forwarded if the source address in REC-5: Outbound packets MUST NOT be forwarded if the source address
their outer IPv6 header does not have a unicast prefix configured for in their outer IPv6 header does not have a unicast prefix configured
use by globally reachable nodes on the interior network. for use by globally reachable nodes on the interior network.
R6: Inbound packets MUST NOT be forwarded if the source address in REC-6: Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for use 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.
R7: By DEFAULT, packets with unique local source and/or destination REC-7: By DEFAULT, packets with unique local source and/or
addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior destination addresses [RFC4193] SHOULD NOT be forwarded to or from
network. the exterior network.
R8: By DEFAULT, inbound non-recursive DNS queries received on REC-8: 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.
R9: Inbound DHCP discovery packets received on exterior interfaces REC-9: 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 9, line 47 skipping to change at page 9, line 47
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 no
special requirements to inspect the transport headers. 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.
R10: Filter state records for generic upper-layer transport protocols REC-10: Filter state records for generic upper-layer transport
MUST BE indexable by a 3-tuple comprising the interior node address, protocols MUST BE indexable by a 3-tuple comprising the interior node
the exterior node address and the upper-layer transport protocol address, the exterior node address and the upper-layer transport
identifier. protocol identifier.
R11: Filter state records for generic upper-layer transport protocols REC-11: Filter state records for generic upper-layer transport
MUST NOT be deleted or recycled until an idle timer not less than two protocols MUST NOT be deleted or recycled until an idle timer not
minutes has expired without having forwarded a packet matching the less than two minutes has expired without having forwarded a packet
state in some configurable amount of time. By DEFAULT, the idle matching the state in some configurable amount of time. By DEFAULT,
timer for such state records is five minutes. the idle timer for such state records is five minutes.
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 exchange through a stateful An interior endpoint initiates a UDP exchange through a stateful
packet filter by sending a packet to an exterior address. The filter packet 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
exchange. The state record defines the interior and exterior IP exchange. The state record defines the interior and exterior IP
addresses and ports used between all packets in the exchange. addresses and ports used between all packets in the exchange.
State records for UDP exchanges remain active while they are in use State records for UDP exchanges remain active while they are in use
and only abandoned after an idle period of some time. and only abandoned after an idle period of some time.
R12: A state record for a UDP exchange where both interior and REC-12: A state record for a UDP exchange where both interior and
exterior ports are outside the well-known port range (ports 0-1023) exterior ports are outside the well-known port range (ports 0-1023)
MUST NOT expire in less than two minutes of idle time. The value of MUST NOT expire in less than two minutes of idle time. The value of
the UDP state record idle timer MAY be configurable. The DEFAULT is the UDP state record idle timer MAY be configurable. The DEFAULT is
five minutes. five minutes.
R13: A state record for a UDP exchange where one or both of the REC-13: A state record for a UDP exchange where one or both of the
interior and exterior ports are in the well-known port range (ports interior and exterior ports are in the well-known port range (ports
0-1023) MAY expire after a period of idle time shorter than two 0-1023) MAY expire after a period of idle time shorter than two
minutes to facilitate the operation of the IANA-registered service minutes to facilitate the operation of the IANA-registered service
assigned to the port in question. assigned to 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.
R14: A state record for a UDP exchange MUST be refreshed when a REC-14: A state record for a UDP exchange MUST be refreshed when a
packet is forwarded from the interior to the exterior, and it MAY be packet 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.5 of [RFC4787], the connection-free
semantics of UDP pose a difficulty for packet filters in trying to semantics of UDP pose a difficulty for packet filters in trying to
recognize which packets comprise an application flow and which are recognize which packets comprise an application flow and which are
unsolicited. Various strategies have been used in IPv4/NAT gateways unsolicited. Various strategies have been used in IPv4/NAT gateways
with differing effects. with differing effects.
R15: If application transparency is most important, then a stateful REC-15: If application transparency is most important, then a
packet filter SHOULD have "Endpoint independent filter" behavior for stateful packet filter SHOULD have "Endpoint independent filter"
UDP. If a more stringent filtering behavior is most important, then behavior for UDP. If a more stringent filtering behavior is most
a filter SHOULD have "Address dependent filtering" behavior. The important, then a filter SHOULD have "Address dependent filtering"
filtering behavior MAY be an option configurable by the network behavior. The filtering behavior MAY be an option configurable by
administrator, and it MAY be independent of the filtering behavior the network administrator, and it MAY be independent of the filtering
for TCP and other protocols. Filtering behavior SHOULD by endpoint behavior for TCP and other protocols. Filtering behavior SHOULD by
independent by DEFAULT in gateways intended for provisioning without endpoint independent by DEFAULT in gateways intended for provisioning
service-provider management. without service-provider management.
Applications mechanisms may depend on the reception of ICMP error Applications mechanisms may depend on the reception of ICMP 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.
R16: If a gateway forwards a UDP exchange, it MUST also forward ICMP REC-16: If a gateway forwards a UDP exchange, it MUST also forward
Destination Unreachable messages containing UDP headers that match ICMP Destination Unreachable messages containing UDP headers that
the exchange state record. match the exchange state record.
R17: Receipt of any sort of ICMP message MUST NOT terminate the state REC-17: Receipt of any sort of ICMP message MUST NOT terminate the
record for a UDP exchange. state record for a UDP exchange.
R18: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way REC-18: UDP-Lite exchanges [RFC3828] SHOULD be handled in the same
as UDP exchanges, except that the upper-layer transport protocol way 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.4. 6to4 Tunnels 3.2.4. 6to4 Tunnels
Typical dual-stack IPv4/IPv6 residential gateways use private IPv4 Typical dual-stack IPv4/IPv6 residential gateways use private IPv4
address ranges and network address/port translation on a single IPv4 address ranges and network address/port translation on a single IPv4
address assigned by the service provider. The use of private address assigned by the service provider. The use of private
addresses prevents interior hosts from using 6to4 [RFC3068] tunnels. addresses prevents interior hosts from using 6to4 [RFC3068] tunnels.
3.2.5. Teredo-specific Filters 3.2.5. 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.
R19: Where a globally routed IPv6 prefix is advertised on an interior REC-19: Where a globally routed IPv6 prefix is advertised on an
interface and IPv4 Internet service is provided with NAT [RFC4787], interior interface and IPv4 Internet service is provided with NAT
the Teredo qualification procedure (see section 5.2.1 and 5.2.2 of [RFC4787], the Teredo qualification procedure (see section 5.2.1 and
[RFC4380]) for clients in the interior SHOULD be prohibited by the 5.2.2 of [RFC4380]) for clients in the interior SHOULD be prohibited
IPv4/NAT stateful filter. This SHOULD be done by blocking outbound by the IPv4/NAT stateful filter. This SHOULD be done by blocking
UDP initiations to port 3544, the port reserved by IANA for Teredo outbound UDP initiations to port 3544, the port reserved by IANA for
servers. Teredo servers.
3.2.6. IPsec and Internet Key Exchange (IKE) 3.2.6. 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.
R20: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT
the forwarding of packets, to and from legitimate node addresses, prohibit the forwarding of packets, to and from legitimate node
with destination extension headers of type "Authenticated Header addresses, with destination extension headers of type "Authenticated
(AH)" [RFC4302] in their outer IP extension header chain. Header (AH)" [RFC4302] in their outer IP extension header chain.
R21: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT
the forwarding of packets, to and from legitimate node addresses, prohibit the forwarding of packets, to and from legitimate node
with an upper layer protocol of type "Encapsulating Security Payload addresses, with an upper layer protocol of type "Encapsulating
(ESP)" [RFC4303] in their outer IP extension header chain. Security Payload (ESP)" [RFC4303] in their outer IP extension header
chain.
R22: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT
the forwarding of any UDP packets, to and from legitimate node prohibit the forwarding of any UDP packets, to and from legitimate
addresses, with a destination port of 500, i.e. the port reserved by node addresses, with a destination port of 500, i.e. the port
IANA for the Internet Key Exchange Protocol [RFC4306]. reserved by IANA for the Internet Key Exchange Protocol [RFC4306].
R23: In all operating modes, IPv6 gateways SHOULD use filter state REC-23: 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
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)
[RFC4306] initiations SHOULD NOT be used. [RFC4306] initiations SHOULD NOT be used.
3.2.7. Other Virtual Private Network Protocols
Residential IPv6 gateways are not expected to prohibit the use of
virtual private networks in residential usage scenarios.
R24: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding, to and from legitimate node addresses, with upper
layer protocol of type IP version 6, and SHOULD NOT prohibit the
forwarding of other tunneled networking protocols commonly used for
virtual private networking, e.g. IP version 4, Generic Routing
Encapsulation, etcetera.
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
the Transport Control Protocol (TCP) [RFC0793], the Stream Control the Transport Control Protocol (TCP) [RFC0793], the Stream Control
Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion
Control Protocol (DCCP) [RFC4340], and potentially any future IETF Control Protocol (DCCP) [RFC4340], and potentially any future IETF
standards-track transport protocols that use such semantics. standards-track transport protocols that use such semantics.
Stateful packet filters track the state of individual transport Stateful packet filters track the state of individual transport
connections and prohibit the forwarding of packets that do not match connections and prohibit the forwarding of packets that do not match
skipping to change at page 13, line 40 skipping to change at page 13, line 27
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
connection that conform to valid transitions of the TCP state machine connection that conform to valid transitions of the TCP state machine
(Fig. 6, [RFC0793]). (Fig. 6, [RFC0793]).
R25: All valid sequences of TCP packets (defined in [RFC0793]) MUST REC-24: All valid sequences of TCP packets (defined in [RFC0793])
be forwarded for outbound connections and explicitly permitted MUST be forwarded for outbound connections and explicitly permitted
inbound connections. In particular, both the normal TCP 3-way inbound connections. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes of handshake mode of operation and the simultaneous-open modes of
operation MUST be supported. operation MUST be supported.
It is possible to reconstruct enough of the state of a TCP connection It is possible to reconstruct enough of the state of a TCP connection
to allow forwarding between an interior and exterior node even when to allow forwarding between an interior and exterior node even when
the filter starts operating after TCP enters the established state. the filter starts operating after TCP enters the established state.
In this case, because the filter has not seen the TCP window-scale In this case, because the filter has not seen the TCP window-scale
option, it is not possible for the filter to enforce the TCP window 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.
R26: The TCP window invariant MUST NOT be enforced on connections for REC-25: The TCP window invariant MUST NOT be enforced on connections
which the filter did not detect whether the window-scale option (see for which the filter did not detect whether the window-scale option
[RFC1323]) was sent in the 3-way handshake or simultaneous open. (see [RFC1323]) was sent in the 3-way handshake or simultaneous open.
A stateful filter can allow an existing state record to be reused by A stateful filter can allow an existing state record to be reused by
an externally initiated connection if its security policy permits. an externally initiated connection if its security policy permits.
Several different policies are possible as described in "Network Several different policies are possible as described in "Network
Address Translation (NAT) Behavioral Requirements for Unicast UDP Address Translation (NAT) Behavioral Requirements for Unicast UDP
[RFC4787] and extended in "NAT Behavioral Requirements for TCP" [RFC4787] and extended in "NAT Behavioral Requirements for TCP"
[RFC5382]. [RFC5382].
R27: If application transparency is most important, then a stateful REC-26: If application transparency is most important, then a
packet filter SHOULD have "Endpoint independent filter" behavior for stateful packet filter SHOULD have "Endpoint independent filter"
TCP. If a more stringent filtering behavior is most important, then behavior for TCP. If a more stringent filtering behavior is most
a filter SHOULD have "Address dependent filtering" behavior. The important, then a filter SHOULD have "Address dependent filtering"
filtering behavior MAY be an option configurable by the network behavior. The filtering behavior MAY be an option configurable by
administrator, and it MAY be independent of the filtering behavior the network administrator, and it MAY be independent of the filtering
for UDP and other protocols. Filtering behavior SHOULD by endpoint behavior for UDP and other protocols. Filtering behavior SHOULD by
independent by DEFAULT in gateways intended for provisioning without endpoint independent by DEFAULT in gateways intended for provisioning
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 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.
R28: By DEFAULT, a gateway MUST respond with an ICMP Destination REC-27: By DEFAULT, a gateway MUST respond with an ICMP Destination
Unreachable error (administratively prohibited) to any unsolicited Unreachable error (administratively prohibited) to any unsolicited
inbound SYN packet after waiting at least 6 seconds without first inbound SYN packet after waiting at least 6 seconds without first
forwarding the associated outbound SYN or SYN/ACK from the interior forwarding the associated outbound SYN or SYN/ACK from the interior
peer. peer.
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
skipping to change at page 15, line 36 skipping to change at page 15, line 23
The "established connection idle-timeout" for a stateful packet The "established connection idle-timeout" for a stateful packet
filter is defined as the minimum time a TCP connection in the filter is defined as the minimum time a TCP connection in the
established phase must remain idle before the filter considers the established phase must remain idle before the filter considers the
associated state record a candidate for collection. The "transitory associated state record a candidate for collection. The "transitory
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.
R29: If a gateway cannot determine whether the endpoints of a TCP REC-28: 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, as discussed in [RFC5382]. The value of the four minutes, as discussed in [RFC5382]. The value of the
"transitory connection idle-timeout" MUST NOT be less than four "transitory connection idle-timeout" MUST NOT be less than four
minutes. The value of the idle-timeouts MAY be configurable by the minutes. The value of the idle-timeouts MAY be configurable by the
network administrator. 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
skipping to change at page 16, line 26 skipping to change at page 16, line 13
example due to a timeout expiring, the filter MAY send a TCP RST example due to a timeout expiring, the filter MAY send a TCP RST
packet to each endpoint on behalf of the other. Sending a RST packet to each endpoint on behalf of the other. Sending a RST
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 TCP mechanisms depend on the reception of ICMP error messages Several TCP mechanisms depend on the reception of ICMP error messages
triggered by the transmission of TCP segments. One such mechanism is triggered by the transmission of TCP segments. One such mechanism is
path MTU discovery, which is required for correct operation of TCP. path MTU discovery, which is required for correct operation of TCP.
R30: If a gateway forwards a TCP connection, it MUST also forward REC-29: 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.
R31: Receipt of any sort of ICMP message MUST NOT terminate the state REC-30: Receipt of any sort of ICMP message MUST NOT terminate the
record for a TCP connection. state record for a TCP connection.
3.3.2. SCTP Filters 3.3.2. SCTP Filters
Because Stream Control Transmission Protocol (SCTP) [RFC4960] Because Stream Control Transmission Protocol (SCTP) [RFC4960]
connections can be terminated at multiple network addresses, IPv6 connections can be terminated at multiple network addresses, IPv6
simple security functions cannot achieve full transparency for SCTP simple security functions cannot achieve full transparency for SCTP
applications. In multipath traversal scenarios, full transparency applications. In multipath traversal scenarios, full transparency
requires coordination between all the packet filter processes in the requires coordination between all the packet filter processes in the
various paths between the endpoint network addresses. Such various paths between the endpoint network addresses. Such
coordination is not "simple" and it is, therefore, beyond the scope coordination is not "simple" and it is, therefore, beyond the scope
skipping to change at page 17, line 29 skipping to change at page 17, line 15
of the peers in simultaneous-open mode of operation will send an of the peers in simultaneous-open mode of operation will send an
ERROR or ABORT chunk along with the INIT-ACK chunk. The association ERROR or ABORT chunk along with the INIT-ACK chunk. The association
is established at each endpoint once an INIT-ACK chunks is is established at each endpoint once an INIT-ACK chunks is
receivedA at one end without an ERROR or ABORT chunk. receivedA at one end without an ERROR or ABORT chunk.
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 (Fig. 3, [RFC4960]).
R32: All valid sequences of SCTP packets (defined in [RFC4960]) MUST REC-31: All valid sequences of SCTP packets (defined in [RFC4960])
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 simultaneous-open modes 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 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.
R33: By DEFAULT, a gateway MUST respond with an ICMP Destination REC-32: By DEFAULT, a gateway MUST respond with an ICMP Destination
Unreachable error (administratively prohibited) to any unsolicited Unreachable error (administratively prohibited) to any unsolicited
inbound INIT packet after waiting at least 6 seconds without first inbound INIT packet after waiting at least 6 seconds without first
forwarding the associated outbound INIT from the interior peer. forwarding 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
skipping to change at page 18, line 44 skipping to change at page 18, line 31
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.
R34: If a gateway cannot determine whether the endpoints of an SCTP REC-33: If a gateway cannot determine whether the endpoints of an
association are active, then it MAY abandon the state record if it SCTP association are active, then it MAY abandon the state record if
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 two
hours four minutes. The value of the "transitory association idle- hours four minutes. The value of the "transitory association 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 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
skipping to change at page 19, line 32 skipping to change at page 19, line 18
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 ICMP error Several SCTP mechanisms depend on the reception of ICMP error
messages triggered by the transmission of SCTP packets. messages triggered by the transmission of SCTP packets.
R35: If a gateway forwards an SCTP association, it MUST also forward REC-34: If a gateway forwards an SCTP association, it MUST also
ICMP Destination Unreachable messages containing SCTP headers that forward ICMP Destination Unreachable messages containing SCTP headers
match the association state record. that match the association state record.
R36: Receipt of any sort of ICMP message MUST NOT terminate the state REC-35: Receipt of any sort of ICMP message MUST NOT terminate the
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 Datagram Congestion Control
Protocol (DCCP) [RFC4340] are very similar to those of TCP. An Protocol (DCCP) [RFC4340] are very similar to those of TCP. An
interior endpoint initiates a DCCP connection through a stateful interior endpoint initiates a DCCP connection through a stateful
packet filter by sending a DCCP-Request packet. Simultaneous open is packet filter by sending a DCCP-Request packet. Simultaneous open is
not defined for DCCP. not 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 connection that conform to valid transitions of the DCCP state for a connection that conform to valid transitions of the DCCP state
machine (Section 8, [RFC4340]). machine (Section 8, [RFC4340]).
R37: All valid sequences of DCCP packets (defined in [RFC4340]) MUST REC-36: All valid sequences of DCCP packets (defined in [RFC4340])
be forwarded for all connections to exterior servers and those MUST 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.
It is possible to reconstruct enough of the state of a DCCP It is possible to reconstruct enough of the state of a DCCP
connection to allow forwarding between an interior and exterior node connection to allow forwarding between an interior and exterior node
even when the filter starts operating after DCCP enters the OPEN even when the filter starts operating after DCCP enters the OPEN
state. Also, a filter can allow an existing state record to be state. Also, a filter can allow an existing state record to be
reused by an externally initiated connection if its security policy reused by an externally initiated connection if its security policy
permits. As with TCP, several different policies are possible, with permits. As with TCP, several different policies are possible, with
a good discussion of the issue involved presented in Network Address a good discussion of the issue involved presented in Network Address
skipping to change at page 21, line 11 skipping to change at page 20, line 46
The "open connection idle-timeout" for a stateful packet filter is The "open connection idle-timeout" for a stateful packet filter is
defined as the minimum time a DCCP connection in the open state must defined as the minimum time a DCCP connection in the open state 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 connection idle-timeout" candidate for collection. The "transitory connection idle-timeout"
for a filter is defined as the minimum time a DCCP connection in the for a filter is defined as the minimum time a DCCP connection in the
partially-open or closing phases must remain idle before the filter partially-open or closing phases must remain idle before the filter
considers the associated state record a candidate for collection. considers the associated state record a candidate for collection.
DCCP connections in the TIMEWAIT state are not affected by the DCCP connections in the TIMEWAIT state are not affected by the
"transitory connection idle-timeout" parameter. "transitory connection idle-timeout" parameter.
R38: A gateway MAY abandon a DCCP state record if it has been idle REC-37: 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" MUST minutes. The value of the "transitory connection idle-timeout" MUST
NOT be less than eight minutes. The value of the idle-timeouts MAY NOT be less than eight minutes. The value of the idle-timeouts MAY
be configurable by the network administrator. be configurable by the network administrator.
Behavior for handing DCCP-Reset packets, or connections in the Behavior for handing DCCP-Reset packets, or connections in the
TIMEWAIT state is left unspecified. A gateway MAY hold state for a TIMEWAIT state is left unspecified. A gateway MAY hold state for a
connection in TIMEWAIT state to accommodate retransmissions of the connection in TIMEWAIT state to accommodate retransmissions of the
last DCCP-Reset. However, since the TIMEWAIT state is commonly last DCCP-Reset. However, since the TIMEWAIT state is commonly
skipping to change at page 21, line 49 skipping to change at page 21, line 36
packet to each endpoint on behalf of the other. Sending a DCCP-Reset packet to each endpoint on behalf of the other. Sending a DCCP-Reset
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 DCCP mechanisms depend on the reception of ICMP error Several DCCP mechanisms depend on the reception of ICMP 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.
R39: If a gateway forwards a DCCP connection, it MUST also forward REC-38: 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.
R40: Receipt of any sort of ICMP message MUST NOT terminate the state REC-39: Receipt of any sort of ICMP message MUST NOT terminate the
record for a DCCP connection. state record for a DCCP connection.
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6)
IPv6 simple security is applicable to residential networks with only IPv6 simple security is applicable to residential networks with only
one default router, i.e. a single residential gateway to exactly one one default router, i.e. a single residential gateway to exactly one
Internet service provider. The use of Level 3 Multihoming Shim Internet service provider. The use of Level 3 Multihoming Shim
Protocol for IPv6 (SHIM6) [I-D.ietf-shim6-proto] as a site multi- Protocol for IPv6 (SHIM6) [RFC5533] as a site multi-homing solution
homing solution is not generally compatible with IPv6 simple is not generally compatible with IPv6 simple security.
security.
Residential gateways that are capable of site multi-homing Residential gateways that are capable of site multi-homing
simultaneously on more than one exterior network link SHOULD simultaneously on more than one exterior network link SHOULD
reference addresses in SHIM6 headers when comparing and creating reference addresses in SHIM6 headers when comparing and creating
filter state corresponding to interior endpoint hosts. filter state corresponding to interior endpoint hosts.
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 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]. On IPv4/NAT networks
connected by gateways without such services, applications must use
technique like Session Traversal Utilities for NAT (STUN) [RFC5389]
to obtain and maintain connectivity, despite the translation and
filtering effects of NAT.
While NAT for IPv6 is unlikely to be used in most residential
gateways, the filtering effect of the simple security functions
recommended by this document are derived from those in widespread use
on the IPv4 Internet, and a similar barrier to communication at
passive listeners is a natural outcome of its deployment. To avoid
the need for IPv6 applications to use techniques like STUN for
opening and maintaining dynamic filter state, something similar to
NAT-PMP and UPnP-IGD but without actually supporting NAT needs to be
deployed.
Alas, no consensus has yet emerged in the Internet engineering
community as to what is most appropriate for residential IPv6 usage
scenarios.
One proposal that has been offered as an Internet Draft is the 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
[RFC5189] and the Next Steps in Signaling framework [RFC4080]. No [RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until
consensus has yet emerged in the Internet engineering community as to a consensus emerges around a specific method, the following
which proposal is most appropriate for residential IPv6 usage recommendations are the best guidance available.
scenarios.
R41: Gateways SHOULD implement a protocol to permit applications to REC-40: Gateways SHOULD implement a protocol to permit applications
solicit inbound traffic without advance knowledge of the addresses of to solicit inbound traffic without advance knowledge of the addresses
exterior nodes with which they expect to communicate. If of exterior nodes with which they expect to communicate.
implemented, this protocol MUST have a specification that meets the
requirements of [RFC3979], [RFC4879] and [RFC5378].
R42: Gateways MUST provide an easily selected configuration option REC-41: Gateways MUST provide an easily selected configuration option
that permits operation in a mode that forwards all unsolicited flows that permits operation in a mode that forwards all unsolicited flows
regardless of forwarding direction. regardless of forwarding direction.
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 REC-1 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 which bear in their outer IPv6 headers multicast REC-2 Packets which bear in their outer IPv6 headers multicast
destination addresses of equal or narrower scope (see section 2.7 destination addresses of equal or narrower scope (see section 2.7
of IP Version 6 Addressing Architecture [RFC4291]) than the of IP Version 6 Addressing Architecture [RFC4291]) than the
configured scope boundary level of the gateway MUST NOT be configured scope boundary level of the gateway MUST NOT be
forwarded in any direction. The DEFAULT scope boundary level forwarded in any direction. The DEFAULT scope boundary level
SHOULD be organization-local scope, and it SHOULD be configurable SHOULD be organization-local scope, and it SHOULD be configurable
by the network admininistrator. by the network admininistrator.
R3 Packets bearing source and/or destination addresses forbidden to REC-3 Packets bearing source and/or destination addresses forbidden
appear in the outer headers of packets transmitted over the public to appear in the outer headers of packets transmitted over the
Internet MUST NOT be forwarded. In particular, site-local public Internet MUST NOT be forwarded. In particular, site-local
addresses are deprecated by [RFC3879], and [RFC5156] explicitly addresses are deprecated by [RFC3879], and [RFC5156] explicitly
forbids the use of addresses with IPv4-Mapped, IPv4-Compatible, forbids the use of addresses with IPv4-Mapped, IPv4-Compatible,
Documentation and ORCHID prefixes. Documentation and ORCHID prefixes.
R4 Packets bearing deprecated extension headers prior to their first REC-4 Packets bearing deprecated extension headers prior to their
upper-layer-protocol header SHOULD NOT be forwarded or transmitted first upper-layer-protocol header SHOULD NOT be forwarded or
on any interface. In particular, all packets with routing transmitted on any interface. In particular, all packets with
extension header type 0 [RFC2460] preceding the first upper-layer- routing extension header type 0 [RFC2460] preceding the first
protocol header MUST NOT be forwarded. (See [RFC5095] for upper-layer-protocol header MUST NOT be forwarded. (See [RFC5095]
additional background.) for additional background.)
R5 Outbound packets MUST NOT be forwarded if the source address in REC-5 Outbound packets MUST NOT be forwarded if the source address
their outer IPv6 header does not have a unicast prefix assigned in 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.
R6 Inbound packets MUST NOT be forwarded if the source address in REC-6 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.
R7 By DEFAULT, packets with unique local source and/or destination REC-7 By DEFAULT, packets with unique local source and/or
addresses [RFC4193] SHOULD NOT be forwarded to or from the destination addresses [RFC4193] SHOULD NOT be forwarded to or from
exterior network. the exterior network.
R8 By DEFAULT, inbound non-recursive DNS queries received on exterior REC-8 By DEFAULT, inbound non-recursive DNS queries received on
interfaces MUST NOT be processed by any integrated DNS proxy exterior interfaces MUST NOT be processed by any integrated DNS
resolving server. proxy resolving server.
R9 Inbound DHCP discovery packets received on exterior interfaces REC-9 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.
R10 Filter state records for generic upper-layer transport protocols REC-10 Filter state records for generic upper-layer transport
MUST BE indexable by a 3-tuple comprising the interior node protocols MUST BE indexable by a 3-tuple comprising the interior
address, the exterior node address and the upper-layer transport node address, the exterior node address and the upper-layer
protocol identifier. transport protocol identifier.
R11 Filter state records for generic upper-layer transport protocols REC-11 Filter state records for generic upper-layer transport
MUST NOT be deleted or recycled until an idle timer not less than protocols MUST NOT be deleted or recycled until an idle timer not
two minutes has expired without having forwarded a packet matching less than two minutes has expired without having forwarded a
the state in some configurable amount of time. By DEFAULT, the packet matching the state in some configurable amount of time. By
idle timer for such state records is five minutes. DEFAULT, the idle timer for such state records is five minutes.
R12 A state record for a UDP exchange where both interior and REC-12 A state record for a UDP exchange where both interior and
exterior ports are outside the well-known port range (ports exterior ports are outside the well-known port range (ports
0-1023) MUST NOT expire in less than two minutes of idle time. 0-1023) MUST NOT expire in less than two minutes of idle time.
The value of the UDP state record idle timer MAY be configurable. The value of the UDP state record idle timer MAY be configurable.
The DEFAULT is five minutes. The DEFAULT is five minutes.
R13 A state record for a UDP exchange where one or both of the REC-13 A state record for a UDP exchange where one or both of the
interior and exterior ports are in the well-known port range interior and exterior ports are in the well-known port range
(ports 0-1023) MAY expire after a period of idle time shorter than (ports 0-1023) MAY expire after a period of idle time shorter than
two minutes to facilitate the operation of the IANA-registered two minutes to facilitate the operation of the IANA-registered
service assigned to the port in question. service assigned to the port in question.
R14 A state record for a UDP exchange MUST be refreshed when a REC-14 A state record for a UDP exchange MUST be refreshed when a
packet is forwarded from the interior to the exterior, and it MAY packet is forwarded from the interior to the exterior, and it MAY
be refreshed when a packet is forwarded in the reverse direction. be refreshed when a packet is forwarded in the reverse direction.
R15 If application transparency is most important, then a stateful REC-15 If application transparency is most important, then a
packet filter SHOULD have "Endpoint independent filter" behavior stateful packet filter SHOULD have "Endpoint independent filter"
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 the network administrator, and it MAY be independent of the
filtering behavior for TCP and other protocols. Filtering filtering behavior for TCP and other protocols. Filtering
behavior SHOULD by endpoint independent by DEFAULT in gateways behavior SHOULD by endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider management. intended for provisioning without service-provider management.
R16 If a gateway forwards a UDP exchange, it MUST also forward ICMP REC-16 If a gateway forwards a UDP exchange, it MUST also forward
Destination Unreachable messages containing UDP headers that match ICMP Destination Unreachable messages containing UDP headers that
the exchange state record. match the exchange state record.
R17 Receipt of any sort of ICMP message MUST NOT terminate the state REC-17 Receipt of any sort of ICMP message MUST NOT terminate the
record for a UDP exchange. state record for a UDP exchange.
R18 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same way REC-18 UDP-Lite exchanges [RFC3828] SHOULD be handled in the same
as UDP exchanges, except that the upper-layer transport protocol way as UDP exchanges, except that the upper-layer transport
identifier for UDP-Lite is not the same as UDP, and therefore UDP protocol identifier for UDP-Lite is not the same as UDP, and
packets MUST NOT match UDP-Lite state records, and vice versa. therefore UDP packets MUST NOT match UDP-Lite state records, and
vice versa.
R19 Where a globally routed IPv6 prefix is advertised on an interior REC-19 Where a globally routed IPv6 prefix is advertised on an
interface and IPv4 Internet service is provided with NAT interior interface and IPv4 Internet service is provided with NAT
[RFC4787], the Teredo qualification procedure (see section 5.2.1 [RFC4787], the Teredo qualification procedure (see section 5.2.1
and 5.2.2 of [RFC4380]) for clients in the interior MUST be and 5.2.2 of [RFC4380]) for clients in the interior MUST be
prohibited by the IPv4/NAT stateful filter. This SHOULD be done prohibited by the IPv4/NAT stateful filter. This SHOULD be done
by blocking outbound UDP initiations to port 3544, the port by blocking outbound UDP initiations to port 3544, the port
reserved by IANA for Teredo servers. reserved by IANA for Teredo servers.
R20 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit REC-20 In their DEFAULT operating mode, IPv6 gateways MUST NOT
the forwarding of packets, to and from legitimate node addresses, prohibit the forwarding of packets, to and from legitimate node
with destination extension headers of type "Authenticated Header addresses, with destination extension headers of type
(AH)" [RFC4302] in their outer IP extension header chain. "Authenticated Header (AH)" [RFC4302] in their outer IP extension
header chain.
R21 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding of packets, to and from legitimate node addresses,
with an upper layer protocol of type "Encapsulating Security
Payload (ESP)" [RFC4303] in their outer IP extension header chain.
R22 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT
the forwarding of any UDP packets, to and from legitimate node prohibit the forwarding of packets, to and from legitimate node
addresses, with a destination port of 500, i.e. the port reserved addresses, with an upper layer protocol of type "Encapsulating
by IANA for the Internet Key Exchange Protocol [RFC4306]. Security Payload (ESP)" [RFC4303] in their outer IP extension
header chain.
R23 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT
the forwarding, to and from legitimate node addresses, with upper prohibit the forwarding of any UDP packets, to and from legitimate
layer protocol of type IP version 6, and SHOULD NOT prohibit the node addresses, with a destination port of 500, i.e. the port
forwarding of other tunneled networking protocols commonly used reserved by IANA for the Internet Key Exchange Protocol [RFC4306].
for virtual private networking, e.g. IP version 4, Generic
Routing Encapsulation, etcetera.
R24 In all operating modes, IPv6 gateways SHOULD use filter state REC-23 In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] that records for Encapsulating Security Payload (ESP) [RFC4303] that
are indexable by a 3-tuple comprising the interior node address, are indexable by a 3-tuple comprising the interior node address,
the exterior node address and the ESP protocol identifier. In the 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
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)
[RFC4306] initiations SHOULD NOT be used. [RFC4306] initiations SHOULD NOT be used.
R25 All valid sequences of TCP packets (defined in [RFC0793]) MUST REC-24 All valid sequences of TCP packets (defined in [RFC0793])
be forwarded for outbound connections and explicitly permitted MUST be forwarded for outbound connections and explicitly
inbound connections. In particular, both the normal TCP 3-way permitted inbound connections. In particular, both the normal TCP
handshake mode of operation and the simultaneous-open modes of 3-way handshake mode of operation and the simultaneous-open modes
operation MUST be supported. of operation MUST be supported.
R26 The TCP window invariant MUST NOT be enforced on connections for REC-25 The TCP window invariant MUST NOT be enforced on connections
which the filter did not detect whether the window-scale option for which the filter did not detect whether the window-scale
(see [RFC1323]) was sent in the 3-way handshake or simultaneous option (see [RFC1323]) was sent in the 3-way handshake or
open. simultaneous open.
R27 If application transparency is most important, then a stateful REC-26 If application transparency is most important, then a
packet filter SHOULD have "Endpoint independent filter" behavior stateful packet filter SHOULD have "Endpoint independent filter"
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 the network administrator, and it MAY be independent of the
filtering behavior for UDP and other protocols. Filtering filtering behavior for UDP and other protocols. Filtering
behavior SHOULD by endpoint independent by DEFAULT in gateways behavior SHOULD by endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider management. intended for provisioning without service-provider management.
R28 By DEFAULT, a gateway MUST respond with an ICMP Destination REC-27 By DEFAULT, a gateway MUST respond with an ICMP Destination
Unreachable error (administratively prohibited) to any unsolicited Unreachable error (administratively prohibited) to any unsolicited
inbound SYN packet after waiting at least 6 seconds without first inbound SYN packet after waiting at least 6 seconds without first
forwarding the associated outbound SYN or SYN/ACK from the forwarding the associated outbound SYN or SYN/ACK from the
interior peer. interior peer.
R29 If a gateway cannot determine whether the endpoints of a TCP REC-28 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, as discussed in [RFC5382]. The value of the hours four minutes, as discussed in [RFC5382]. The value of the
"transitory connection idle-timeout" MUST NOT be less than four "transitory connection idle-timeout" MUST NOT be less than four
minutes. The value of the idle-timeouts MAY be configurable by minutes. The value of the idle-timeouts MAY be configurable by
the network administrator. the network administrator.
R30 If a gateway forwards a TCP connection, it MUST also forward REC-29 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.
R31 Receipt of any sort of ICMP message MUST NOT terminate the state REC-30 Receipt of any sort of ICMP message MUST NOT terminate the
record for a TCP connection. state record for a TCP connection.
R32 All valid sequences of SCTP packets (defined in [RFC4960]) MUST REC-31 All valid sequences of SCTP packets (defined in [RFC4960])
be forwarded for outbound associations and explicitly permitted MUST be forwarded for outbound associations and explicitly
inbound associations. In particular, both the normal SCTP permitted inbound associations. In particular, both the normal
association establishment and simultaneous-open modes of operation SCTP association establishment and simultaneous-open modes of
MUST be supported. operation MUST be supported.
R33 By DEFAULT, a gateway MUST respond with an ICMP Destination REC-32 By DEFAULT, a gateway MUST respond with an ICMP Destination
Unreachable error (administratively prohibited) to any unsolicited Unreachable error (administratively prohibited) to any unsolicited
inbound INIT packet after waiting at least 6 seconds without first inbound INIT packet after waiting at least 6 seconds without first
forwarding the associated outbound INIT from the interior peer. forwarding the associated outbound INIT from the interior peer.
R34 If a gateway cannot determine whether the endpoints of an SCTP REC-33 If a gateway cannot determine whether the endpoints of an
association are active, then it MAY abandon the state record if it SCTP association are active, then it MAY abandon the state record
has been idle for some time. In such cases, the value of the if it has been idle for some time. In such cases, the value of
"established association idle-timeout" MUST NOT be less than two the "established association idle-timeout" MUST NOT be less than
hours four minutes. The value of the "transitory association two 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.
R35 If a gateway forwards an SCTP association, it MUST also forward REC-34 If a gateway forwards an SCTP association, it MUST also
ICMP Destination Unreachable messages containing SCTP headers that forward ICMP Destination Unreachable messages containing SCTP
match the association state record. headers that match the association state record.
R36 Receipt of any sort of ICMP message MUST NOT terminate the state REC-35 Receipt of any sort of ICMP message MUST NOT terminate the
record for an SCTP association. state record for an SCTP association.
R37 All valid sequences of DCCP packets (defined in [RFC4340]) MUST REC-36 All valid sequences of DCCP packets (defined in [RFC4340])
be forwarded for all connections to exterior servers and those MUST be forwarded for all connections to exterior servers and
connections to interior servers with explicitly permitted service those connections to interior servers with explicitly permitted
codes. service codes.
R38 A gateway MAY abandon a DCCP state record if it has been idle REC-37 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.
R39 If a gateway forwards a DCCP connection, it MUST also forward REC-38 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.
R40 Receipt of any sort of ICMP message MUST NOT terminate the state REC-39 Receipt of any sort of ICMP message MUST NOT terminate the
record for a DCCP connection. state record for a DCCP connection.
R41 Gateways SHOULD implement a protocol to permit applications to REC-40 Gateways SHOULD implement a protocol to permit applications
solicit inbound traffic without advance knowledge of the addresses to solicit inbound traffic without advance knowledge of the
of exterior nodes with which they expect to communicate. If addresses of exterior nodes with which they expect to communicate.
implemented, this protocol MUST have a specification that meets
the requirements of [RFC3979], [RFC4879] and [RFC5378].
R42 Gateways MUST provide an easily selected configuration option REC-41 Gateways MUST provide an easily selected configuration option
that permits operation in a mode that forwards all unsolicited that permits operation in a mode that forwards all unsolicited
flows regardless of forwarding direction. flows regardless of forwarding direction.
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
skipping to change at page 30, line 24 skipping to change at page 30, line 18
[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.
[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.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, 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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[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)",
skipping to change at page 31, line 5 skipping to change at page 30, line 44
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.
[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
Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884, "Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007. April 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.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
8.2. Informative References 8.2. Informative References
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008. draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.ietf-shim6-proto]
Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work
in progress), February 2009.
[I-D.woodyatt-ald] [I-D.woodyatt-ald]
Woodyatt, J., "Application Listener Discovery (ALD) for Woodyatt, J., "Application Listener Discovery (ALD) for
IPv6", draft-woodyatt-ald-03 (work in progress), IPv6", draft-woodyatt-ald-03 (work in progress),
July 2008. July 2008.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[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.
skipping to change at page 32, line 33 skipping to change at page 32, line 13
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", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[UPnP-IGD] [UPnP-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>.
Appendix A. Change Log Appendix A. Change Log
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 draft-ietf-v6ops-cpe-simple-security-01
skipping to change at page 33, line 15 skipping to change at page 32, line 48
o SCTP is now [RFC4960]. o SCTP is now [RFC4960].
o Moved some references to informative. o Moved some references to informative.
o Corrected the reference for o Corrected the reference for
draft-hoagland-v6ops-teredosecconcerns. draft-hoagland-v6ops-teredosecconcerns.
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 draft-ietf-v6ops-cpe-simple-security-02
o Inserted R20, i.e. do not enforce TCP window invariant unless the o Inserted REC-20, i.e. do not enforce TCP window invariant unless
TCP window-scale is known for the state. the TCP window-scale is known for the state.
o Filled out Section 4. o Filled out Section 4.
o Added reference to [RFC1323]. o Added reference to [RFC1323].
o Updated the reference for draft-hoagland-v6ops-teredosecconcerns. o Updated the reference for draft-hoagland-v6ops-teredosecconcerns.
o Expanded list of contributers and commenters. o Expanded list of contributers and commenters.
o Mention that UDP-Lite should be handled just like UDP. o Mention that UDP-Lite should be handled just like UDP.
skipping to change at page 34, line 12 skipping to change at page 33, line 43
o Added recommendations for SCTP and DCCP. o Added recommendations for SCTP and DCCP.
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 draft-ietf-v6ops-cpe-simple-security-04
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 RFC 4879. (Removed in -08).
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 A.5. draft-ietf-v6ops-cpe-simple-security-04 to
draft-ietf-v6ops-cpe-simple-security-05 draft-ietf-v6ops-cpe-simple-security-05
o Changed category from BCP to Informational. o Changed category from BCP to Informational.
o Change text in section 3 to read "activate new states as a side o Change text in section 3 to read "activate new states as a side
effect of forwarding outbound flow initiations" to improve effect of forwarding outbound flow initiations" to improve
clarity. clarity.
o Qualified an informative insertion by inserting the phrase "on o Qualified an informative insertion by inserting the phrase "on
such networks" appropriately and relaxed the MUST to a SHOULD in such networks" appropriately and relaxed the MUST to a SHOULD in
the text about impeding Teredo. the text about impeding Teredo.
o Changed MUST to SHOULD in R18 about impeding Teredo. o Changed MUST to SHOULD in REC-18 about impeding Teredo.
o Replace "that" with "than" in R2. o Replace "that" with "than" in REC-2.
o Removed an unnecessary and incorrect paragraph about IPv6/NAT from o Removed an unnecessary and incorrect paragraph about IPv6/NAT from
the overview. the overview.
o Changed the first MUST NOT to a SHOULD NOT in R3. o Changed the first MUST NOT to a SHOULD NOT in REC-3.
o Renumbered the recommendations in section 3.1 to increase o Renumbered the recommendations in section 3.1 to increase
monotonically and match the same recommendations in the summary. monotonically and match the same recommendations in the summary.
o Rewrote R6, R27 and R32 for clarity. o Rewrote REC-6, REC-27 and REC-32 for clarity.
o Added normative reference to [RFC4193]. o Added normative reference to [RFC4193].
o Removed R8 from the summary, which did not appear in section 3.1, o Removed REC-8 from the summary, which did not appear in section
and was redundant with R27. 3.1, and was redundant with REC-27.
o Added a reference to [RFC5382] in R28. o Added a reference to [RFC5382] in REC-28.
o Inserted R32 into the summary, which had been skipped. o Inserted REC-32 into the summary, which had been skipped.
o Removed "alongside an IPv4 private address" and inserted "globally o Removed "alongside an IPv4 private address" and inserted "globally
routed" before the first use of the word "prefix" in R18. routed" before the first use of the word "prefix" in REC-18.
o Qualify an assertion with "some" in the informative section about o Qualify an assertion with "some" in the informative section about
TCP filters. TCP filters.
o Updated obsolete references to RFC 3989 and RFC 4748. o Updated obsolete references to RFC 3989 and RFC 4748.
A.6. draft-ietf-v6ops-cpe-simple-security-05 to A.6. draft-ietf-v6ops-cpe-simple-security-05 to
draft-ietf-v6ops-cpe-simple-security-06 draft-ietf-v6ops-cpe-simple-security-06
o Corrected some typographical spelling errors. o Corrected some typographical spelling errors.
o Added more names to the contributors section and attempted to o Added more names to the contributors section and attempted to
provide better attribution for the editors of previous RFCs. provide better attribution for the editors of previous RFCs.
o Add normative reference to [RFC5095]. o Add normative reference to [RFC5095].
o Editorial improvement to Section 2.3. o Editorial improvement to Section 2.3.
o Added DEFAULT recommendation for R14 and R26 to use Endpoint- o Added DEFAULT recommendation for REC-14 and REC-26 to use
independent filtering in gateways intended for provisioning Endpoint-independent filtering in gateways intended for
without service-provider management. provisioning without service-provider management.
o Added informative reference to [RFC4949]. o Added informative reference to [RFC4949].
o Added normative references for ICMP6 [RFC4884] and [RFC4890]. o Added normative references for ICMP6 [RFC4884] and [RFC4890].
o Added normative references to [RFC3879] and [RFC5156] and inserted o Added normative references to [RFC3879] and [RFC5156] and inserted
new R3 to forbid forwarding packets for addresses forbidden on the new REC-3 to forbid forwarding packets for addresses forbidden on
public Internet. the public Internet.
o Removed erroneous recommendation about SCTP INIT from summary o Removed erroneous recommendation about SCTP INIT from summary
list, which had already been removed from the detailed section in list, which had already been removed from the detailed section in
an earlier revision. an earlier revision.
o Added a section describing the irrelevance of 6to4 and an o Added a section describing the irrelevance of 6to4 and an
informative reference to [RFC3068]. informative reference to [RFC3068].
o Added normative reference to [RFC4291], and word-smithed R2 to add o Added normative reference to [RFC4291], and word-smithed REC-2 to
a brief discussion about multicast scope boundaries. add a brief discussion about multicast scope boundaries.
o Added a section and an information reference for SHIM6 explaining o Added a section and an information reference for SHIM6 explaining
why it's incompatible with IPv6 simple security. why it's incompatible with IPv6 simple security.
A.7. draft-ietf-v6ops-cpe-simple-security-06 to A.7. draft-ietf-v6ops-cpe-simple-security-06 to
draft-ietf-v6ops-cpe-simple-security-07 draft-ietf-v6ops-cpe-simple-security-07
o Improve the language describing directionality of traffic flows. o Improve the language describing directionality of traffic flows.
o Explicitly recommend a less restrictive configuration option. o Explicitly recommend a less restrictive configuration option.
o Don't use Latin-1 characters not present in 7-bit ASCII. o Don't use Latin-1 characters not present in 7-bit ASCII.
A.8. draft-ietf-v6ops-cpe-simple-security-07 to
draft-ietf-v6ops-cpe-simple-security-08
o Use REC- instead of R for prefixing recommendations.
o Remove second sentence of REC-41, dropping the somewhat squirrely
language about documentation standards.
o Remove section 3.2.7 Other Virtual Private Network Protocols,
including REC-24.
o Improve section 3.4, Passive Listeners, with a reference to
[RFC5389] and further explanation of motivation for
recommendations.
o Correct order of recommendations in summary section.
o Update reference to [RFC5533].
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. 114 change blocks. 
289 lines changed or deleted 301 lines changed or added

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