draft-ietf-v6ops-cpe-simple-security-15.txt   draft-ietf-v6ops-cpe-simple-security-16.txt 
IPv6 Operations j. woodyatt, Ed. IPv6 Operations j. woodyatt, Ed.
Internet-Draft Apple Internet-Draft Apple
Intended status: Informational October 12, 2010 Intended status: Informational October 21, 2010
Expires: April 15, 2011 Expires: April 24, 2011
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-15 draft-ietf-v6ops-cpe-simple-security-16
Abstract Abstract
This document identifies a set of recommendations for the makers of This document identifies a set of recommendations for the makers of
devices describing how to provide for "simple security" capabilities devices describing how to provide for "simple security" capabilities
at the perimeter of local-area IPv6 networks in Internet-enabled at the perimeter of local-area IPv6 networks in Internet-enabled
homes and small offices. homes and small offices.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 15, 2011. This Internet-Draft will expire on April 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1.2. Use of Normative Keywords . . . . . . . . . . . . . . . . 3 1.2. Use of Normative Keywords . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5 2.1. Basic Sanitation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5 2.2. Internet Layer Protocols . . . . . . . . . . . . . . . . . 5
2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6 2.3. Transport Layer Protocols . . . . . . . . . . . . . . . . 6
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 6
3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6 3.1. Stateless Filters . . . . . . . . . . . . . . . . . . . . 6
3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8 3.2. Connection-free Filters . . . . . . . . . . . . . . . . . 8
3.2.1. Internet Control and Management . . . . . . . . . . . 8 3.2.1. Internet Control and Management . . . . . . . . . . . 8
3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8 3.2.2. Upper-layer Transport Protocols . . . . . . . . . . . 8
3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. UDP Filters . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 11 3.2.4. IPsec and Internet Key Exchange (IKE) . . . . . . . . 11
3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 12 3.2.5. Mobility Support in IPv6 . . . . . . . . . . . . . . . 12
3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 13 3.3. Connection-oriented Filters . . . . . . . . . . . . . . . 13
3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. TCP Filters . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 16 3.3.2. SCTP Filters . . . . . . . . . . . . . . . . . . . . . 17
3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 20 3.3.3. DCCP Filters . . . . . . . . . . . . . . . . . . . . . 20
3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 22 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) . . 22
3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22 3.4. Passive Listeners . . . . . . . . . . . . . . . . . . . . 22
3.5. Management Applications . . . . . . . . . . . . . . . . . 23 3.5. Management Applications . . . . . . . . . . . . . . . . . 23
4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 24 4. Summary of Recommendations . . . . . . . . . . . . . . . . . . 24
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Some IPv6 gateway devices that enable delivery of Internet services Some IPv6 gateway devices that enable delivery of Internet services
in residential and small office settings may be augmented with in residential and small office settings may be augmented with
'simple security' capabilities as described in "Local Network 'simple security' capabilities as described in "Local Network
Protection for IPv6" [RFC4864]. In general, these capabilities cause Protection for IPv6" [RFC4864]. In general, these capabilities cause
packets to be discarded in an attempt to make local networks and the packets to be discarded in an attempt to make local networks and the
Internet more secure. However, it is worth noting that some packets Internet more secure. However, it is worth noting that some packets
skipping to change at page 9, line 30 skipping to change at page 9, line 30
Filtering behavior SHOULD be endpoint independent by DEFAULT in Filtering behavior SHOULD be endpoint independent by DEFAULT in
gateways intended for provisioning without service-provider gateways intended for provisioning without service-provider
management. management.
REC-12: Filter state records for generic upper-layer transport REC-12: Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer not protocols MUST NOT be deleted or recycled until an idle timer not
less than two minutes has expired without having forwarded a packet less than two minutes has expired without having forwarded a packet
matching the state in some configurable amount of time. By DEFAULT, matching the state in some configurable amount of time. By DEFAULT,
the idle timer for such state records is five minutes. the idle timer for such state records is five minutes.
The Internet security community never is never completely at rest. The Internet security community is never completely at rest. New
New attack surfaces, and vulnerabilities in them, are typically attack surfaces, and vulnerabilities in them, are typically
discovered faster than they can be patched by normal equipment discovered faster than they can be patched by normal equipment
upgrade cycles. It's therefore important for vendors of residential upgrade cycles. It's therefore important for vendors of residential
gateway equipment to provide automatic softare updates to patch gateway equipment to provide automatic softare updates to patch
vulnerabilties as they are discovered. vulnerabilties as they are discovered.
REC-13: By DEFAULT, Internet gateways SHOULD, automatically download REC-13: Residential IPv6 gateways SHOULD provide a convenient means
and install software updates for extending IPv6 simple security for to update their firmware securely, for the installation of security
support of future standard upper layer transports and extension patches and other manufacturer-recommended changes.
headers.
Vendors can expect users and operators to have differing viewpoints
on the maintenance of patches, with some preferring automatic update
and some preferring manual procedures. Those preferring automatic
update may also prefer either to download from a vendor site or from
one managed by their network provider. To handle the disparity,
vendors are advised to provide both manual and automatic options. In
the automatic case, they would do well to facilitate pre-
configuration of the download URL and a means of validating the
software image such as a certificate.
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.
skipping to change at page 25, line 36 skipping to change at page 25, line 40
in gateways intended for provisioning without service- in gateways intended for provisioning without service-
provider management. provider management.
REC-12 Filter state records for generic upper-layer transport REC-12 Filter state records for generic upper-layer transport
protocols MUST NOT be deleted or recycled until an idle timer protocols MUST NOT be deleted or recycled until an idle timer
not less than two minutes has expired without having not less than two minutes has expired without having
forwarded a packet matching the state in some configurable forwarded a packet matching the state in some configurable
amount of time. By DEFAULT, the idle timer for such state amount of time. By DEFAULT, the idle timer for such state
records is five minutes. records is five minutes.
REC-13 A state record for a UDP flow where both source and REC-13 Residential IPv6 gateways SHOULD provide a convenient means
to update their firmware securely, for the installation of
security patches and other manufacturer-recommended changes.
REC-14 A state record for a UDP flow where both source and
destination ports are outside the well-known port range destination ports are outside the well-known port range
(ports 0-1023) MUST NOT expire in less than two minutes of (ports 0-1023) MUST NOT expire in less than two minutes of
idle time. The value of the UDP state record idle timer MAY idle time. The value of the UDP state record idle timer MAY
be configurable. The DEFAULT is five minutes. be configurable. The DEFAULT is five minutes.
REC-14 A state record for a UDP flow where one or both of the source REC-15 A state record for a UDP flow where one or both of the source
and destination ports are in the well-known port range (ports and destination ports are in the well-known port range (ports
0-1023) MAY expire after a period of idle time shorter than 0-1023) MAY expire after a period of idle time shorter than
two minutes to facilitate the operation of the IANA- two minutes to facilitate the operation of the IANA-
registered service assigned to the port in question. registered service assigned to the port in question.
REC-15 A state record for a UDP flow MUST be refreshed when a packet REC-16 A state record for a UDP flow MUST be refreshed when a packet
is forwarded from the interior to the exterior, and it MAY be is forwarded from the interior to the exterior, and it MAY be
refreshed when a packet is forwarded in the reverse refreshed when a packet is forwarded in the reverse
direction. direction.
REC-16 If application transparency is most important, then a REC-17 If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent stateful packet filter SHOULD have "endpoint independent
filter" behavior for UDP. If a more stringent filtering filter" behavior for UDP. If a more stringent filtering
behavior is most important, then a filter SHOULD have behavior is most important, then a filter SHOULD have
"address dependent filtering" behavior. The filtering "address dependent filtering" behavior. The filtering
behavior MAY be an option configurable by the network behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering administrator, and it MAY be independent of the filtering
behavior for TCP and other protocols. Filtering behavior behavior for TCP and other protocols. Filtering behavior
SHOULD be endpoint independent by DEFAULT in gateways SHOULD be endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider intended for provisioning without service-provider
management. management.
REC-17 If a gateway forwards a UDP flow, it MUST also forward ICMPv6 REC-18 If a gateway forwards a UDP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing UDP headers that match the flow state record. containing UDP headers that match the flow state record.
REC-18 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-19 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a UDP flow. state record for a UDP flow.
REC-19 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as REC-20 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as
UDP flows, except that the upper-layer transport protocol UDP flows, except that the upper-layer transport protocol
identifier for UDP-Lite is not the same as UDP, and therefore identifier for UDP-Lite is not the same as UDP, and therefore
UDP packets MUST NOT match UDP-Lite state records, and vice UDP packets MUST NOT match UDP-Lite state records, and vice
versa. versa.
REC-20 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate prohibit the forwarding of packets, to and from legitimate
node addresses, with destination extension headers of type node addresses, with destination extension headers of type
"Authenticated Header (AH)" [RFC4302] in their outer IP "Authenticated Header (AH)" [RFC4302] in their outer IP
extension header chain. extension header chain.
REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate prohibit the forwarding of packets, to and from legitimate
node addresses, with an upper layer protocol of type node addresses, with an upper layer protocol of type
"Encapsulating Security Payload (ESP)" [RFC4303] in their "Encapsulating Security Payload (ESP)" [RFC4303] in their
outer IP extension header chain. outer IP extension header chain.
REC-22 If a gateway forwards an ESP flow, it MUST also forward (in REC-23 If a gateway forwards an ESP flow, it MUST also forward (in
the reverse direction) ICMPv6 "Destination Unreachable" and the reverse direction) ICMPv6 "Destination Unreachable" and
"Packet Too Big" messages containing ESP headers that match "Packet Too Big" messages containing ESP headers that match
the flow state record. the flow state record.
REC-23 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of any UDP packets, to and from prohibit the forwarding of any UDP packets, to and from
legitimate node addresses, with a destination port of 500, legitimate node addresses, with a destination port of 500,
i.e. the port reserved by IANA for the Internet Key Exchange i.e. the port reserved by IANA for the Internet Key Exchange
Protocol [RFC5996]. Protocol [RFC5996].
REC-24 In all operating modes, IPv6 gateways SHOULD use filter state REC-25 In all operating modes, IPv6 gateways SHOULD use filter state
records for Encapsulating Security Payload (ESP) [RFC4303] records for Encapsulating Security Payload (ESP) [RFC4303]
that are indexable by a 3-tuple comprising the interior node that are indexable by a 3-tuple comprising the interior node
address, the exterior node address and the ESP protocol address, the exterior node address and the ESP protocol
identifier. In particular, the IPv4/NAT method of indexing identifier. In particular, the IPv4/NAT method of indexing
state records also by security parameters index (SPI) SHOULD state records also by security parameters index (SPI) SHOULD
NOT be used. Likewise, any mechanism that depends on NOT be used. Likewise, any mechanism that depends on
detection of Internet Key Exchange (IKE) [RFC5996] detection of Internet Key Exchange (IKE) [RFC5996]
initiations SHOULD NOT be used. initiations SHOULD NOT be used.
REC-25 In their DEFAULT operating mode, IPv6 gateways MUST NOT REC-26 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate prohibit the forwarding of packets, to and from legitimate
node addresses, with destination extension headers of type node addresses, with destination extension headers of type
"Host Identity Protocol (HIP)" [RFC5201] in their outer IP "Host Identity Protocol (HIP)" [RFC5201] in their outer IP
extension header chain. extension header chain.
REC-26 The state records for flows initiated by outbound packets REC-27 The state records for flows initiated by outbound packets
that bear a Home Address destination option [RFC3775] are that bear a Home Address destination option [RFC3775] are
distinguished by the addition of the home address of the flow distinguished by the addition of the home address of the flow
as well as the interior care-of address. IPv6 gateways MUST as well as the interior care-of address. IPv6 gateways MUST
NOT prohibit the forwarding of any inbound packets bearing NOT prohibit the forwarding of any inbound packets bearing
type 2 routing headers, which otherwise match a flow state type 2 routing headers, which otherwise match a flow state
record, and where A) the address in the destination field of record, and where A) the address in the destination field of
the IPv6 header matches the interior care-of address of the the IPv6 header matches the interior care-of address of the
flow, and B) the Home Address field in the Type 2 Routing flow, and B) the Home Address field in the Type 2 Routing
Header matches the home address of the flow. Header matches the home address of the flow.
REC-27 Valid sequences of Mobility Header [RFC3775] packets MUST be REC-28 Valid sequences of Mobility Header [RFC3775] packets MUST be
forwarded for all outbound and explicitly permitted inbound forwarded for all outbound and explicitly permitted inbound
Mobility Header flows. Mobility Header flows.
REC-28 If a gateway forwards a Mobility Header [RFC3775] flow, then REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward, in both directions, the IPv4 and IPv6 it MUST also forward, in both directions, the IPv4 and IPv6
packets that are encapsulated in IPv6 associated with the packets that are encapsulated in IPv6 associated with the
tunnel between the home agent and the correspondent node. tunnel between the home agent and the correspondent node.
REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then REC-30 If a gateway forwards a Mobility Header [RFC3775] flow, then
it MUST also forward (in the reverse direction) ICMPv6 it MUST also forward (in the reverse direction) ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing any headers that match the associated flow state containing any headers that match the associated flow state
records. records.
REC-30 All valid sequences of TCP packets (defined in [RFC0793]) REC-31 All valid sequences of TCP packets (defined in [RFC0793])
MUST be forwarded for outbound flows and explicitly permitted MUST be forwarded for outbound flows and explicitly permitted
inbound flows. In particular, both the normal TCP 3-way inbound flows. In particular, both the normal TCP 3-way
handshake mode of operation and the simultaneous-open modes handshake mode of operation and the simultaneous-open modes
of operation MUST be supported. of operation MUST be supported.
REC-31 The TCP window invariant MUST NOT be enforced on flows for REC-32 The TCP window invariant MUST NOT be enforced on flows for
which the filter did not detect whether the window-scale which the filter did not detect whether the window-scale
option (see [RFC1323]) was sent in the 3-way handshake or option (see [RFC1323]) was sent in the 3-way handshake or
simultaneous open. simultaneous open.
REC-32 If application transparency is most important, then a REC-33 If application transparency is most important, then a
stateful packet filter SHOULD have "endpoint independent stateful packet filter SHOULD have "endpoint independent
filter" behavior for TCP. If a more stringent filtering filter" behavior for TCP. If a more stringent filtering
behavior is most important, then a filter SHOULD have behavior is most important, then a filter SHOULD have
"address dependent filtering" behavior. The filtering "address dependent filtering" behavior. The filtering
behavior MAY be an option configurable by the network behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering administrator, and it MAY be independent of the filtering
behavior for UDP and other protocols. Filtering behavior behavior for UDP and other protocols. Filtering behavior
SHOULD be endpoint independent by DEFAULT in gateways SHOULD be endpoint independent by DEFAULT in gateways
intended for provisioning without service-provider intended for provisioning without service-provider
management. management.
REC-33 By DEFAULT, a gateway MUST respond with an ICMPv6 REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively "Destination Unreachable" error code 1 (administratively
prohibited) to any unsolicited inbound SYN packet after prohibited) to any unsolicited inbound SYN packet after
waiting at least 6 seconds without first forwarding the waiting at least 6 seconds without first forwarding the
associated outbound SYN or SYN/ACK from the interior peer. associated outbound SYN or SYN/ACK from the interior peer.
REC-34 If a gateway cannot determine whether the endpoints of a TCP REC-35 If a gateway cannot determine whether the endpoints of a TCP
flow are active, then it MAY abandon the state record if it flow are active, then it MAY abandon the state record if it
has been idle for some time. In such cases, the value of the has been idle for some time. In such cases, the value of the
"established flow idle-timeout" MUST NOT be less than two "established flow idle-timeout" MUST NOT be less than two
hours four minutes, as discussed in [RFC5382]. The value of hours four minutes, as discussed in [RFC5382]. The value of
the "transitory flow idle-timeout" MUST NOT be less than four the "transitory flow idle-timeout" MUST NOT be less than four
minutes. The value of the idle-timeouts MAY be configurable minutes. The value of the idle-timeouts MAY be configurable
by the network administrator. by the network administrator.
REC-35 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 REC-36 If a gateway forwards a TCP flow, it MUST also forward ICMPv6
"Destination Unreachable" and "Packet Too Big" messages "Destination Unreachable" and "Packet Too Big" messages
containing TCP headers that match the flow state record. containing TCP headers that match the flow state record.
REC-36 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a TCP flow. state record for a TCP flow.
REC-37 All valid sequences of SCTP packets (defined in [RFC4960]) REC-38 All valid sequences of SCTP packets (defined in [RFC4960])
MUST be forwarded for outbound associations and explicitly MUST be forwarded for outbound associations and explicitly
permitted inbound associations. In particular, both the permitted inbound associations. In particular, both the
normal SCTP association establishment and simultaneous-open normal SCTP association establishment and simultaneous-open
modes of operation MUST be supported. modes of operation MUST be supported.
REC-38 By DEFAULT, a gateway MUST respond with an ICMPv6 REC-39 By DEFAULT, a gateway MUST respond with an ICMPv6
"Destination Unreachable" error code 1 (administratively "Destination Unreachable" error code 1 (administratively
prohibited) to any unsolicited inbound INIT packet after prohibited) to any unsolicited inbound INIT packet after
waiting at least 6 seconds without first forwarding the waiting at least 6 seconds without first forwarding the
associated outbound INIT from the interior peer. associated outbound INIT from the interior peer.
REC-39 If a gateway cannot determine whether the endpoints of an REC-40 If a gateway cannot determine whether the endpoints of an
SCTP association are active, then it MAY abandon the state SCTP association are active, then it MAY abandon the state
record if it has been idle for some time. In such cases, the record if it has been idle for some time. In such cases, the
value of the "established association idle-timeout" MUST NOT value of the "established association idle-timeout" MUST NOT
be less than two hours four minutes. The value of the be less than two hours four minutes. The value of the
"transitory association idle-timeout" MUST NOT be less than "transitory association idle-timeout" MUST NOT be less than
four minutes. The value of the idle-timeouts MAY be four minutes. The value of the idle-timeouts MAY be
configurable by the network administrator. configurable by the network administrator.
REC-40 If a gateway forwards an SCTP association, it MUST also REC-41 If a gateway forwards an SCTP association, it MUST also
forward ICMPv6 "Destination Unreachable" and "Packet Too Big" forward ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing SCTP headers that match the association messages containing SCTP headers that match the association
state record. state record.
REC-41 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-42 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for an SCTP association. state record for an SCTP association.
REC-42 All valid sequences of DCCP packets (defined in [RFC4340]) REC-43 All valid sequences of DCCP packets (defined in [RFC4340])
MUST be forwarded for all flows to exterior servers and those MUST be forwarded for all flows to exterior servers and those
flows to interior servers with explicitly permitted service flows to interior servers with explicitly permitted service
codes. codes.
REC-43 A gateway MAY abandon a DCCP state record if it has been idle REC-44 A gateway MAY abandon a DCCP state record if it has been idle
for some time. In such cases, the value of the "established for some time. In such cases, the value of the "established
flow idle-timeout" MUST NOT be less than two hours four flow idle-timeout" MUST NOT be less than two hours four
minutes. The value of the "transitory flow idle-timeout" minutes. The value of the "transitory flow 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.
REC-44 If a gateway forwards a DCCP flow, it MUST also forward REC-45 If a gateway forwards a DCCP flow, it MUST also forward
ICMPv6 "Destination Unreachable" and "Packet Too Big" ICMPv6 "Destination Unreachable" and "Packet Too Big"
messages containing DCCP headers that match the flow state messages containing DCCP headers that match the flow state
record. record.
REC-45 Receipt of any sort of ICMPv6 message MUST NOT terminate the REC-46 Receipt of any sort of ICMPv6 message MUST NOT terminate the
state record for a DCCP flow. state record for a DCCP flow.
REC-46 Gateways SHOULD implement a protocol to permit applications REC-47 Valid sequences of packets bearing SHIM6 payload extension
headers in their outer IP extension header chains MUST be
forwarded for all outbound and explicitly permitted flows.
The content of the SHIM6 payload extension header MAY be
ignored for the purpose of state tracking.
REC-48 Gateways SHOULD implement a protocol to permit applications
to solicit inbound traffic without advance knowledge of the to solicit inbound traffic without advance knowledge of the
addresses of exterior nodes with which they expect to addresses of exterior nodes with which they expect to
communicate. communicate.
REC-47 Gateways MUST provide an easily selected configuration option REC-49 Gateways MUST provide an easily selected configuration option
that permits a "transparent mode" of operation that forwards that permits a "transparent mode" of operation that forwards
all unsolicited flows regardless of forwarding direction, all unsolicited flows regardless of forwarding direction,
i.e. to disable the IPv6 simple security capabilities of the i.e. to disable the IPv6 simple security capabilities of the
gateway. The transparent mode of operation MAY be the gateway. The transparent mode of operation MAY be the
default configuration. default configuration.
REC-48 By DEFAULT, subscriber managed residential gateways MUST NOT REC-50 By DEFAULT, subscriber managed residential gateways MUST NOT
offer management application services to the exterior offer management application services to the exterior
network. network.
5. Contributors 5. Contributors
Comments and criticisms during the development of this document were Comments and criticisms during the development of this document were
received from the following IETF participants: received from the following IETF participants:
+-------------------+----------------------------+ +-------------------+----------------------------+
| Jari Arkko | Ran Atkinson | | Jari Arkko | Ran Atkinson |
 End of changes. 45 change blocks. 
50 lines changed or deleted 69 lines changed or added

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