draft-ietf-tsvwg-behave-requirements-update-05.txt   draft-ietf-tsvwg-behave-requirements-update-06.txt 
TSVWG R. Penno TSVWG R. Penno
Internet-Draft Cisco Internet-Draft Cisco
Updates: 4787, 5382, 5508 (if approved) S. Perreault Updates: 4787, 5382, 5508 (if approved) S. Perreault
Intended status: Best Current Practice Jive Communications Intended status: Best Current Practice Jive Communications
Expires: May 7, 2016 M. Boucadair Expires: July 21, 2016 M. Boucadair, Ed.
France Telecom Orange
S. Sivakumar S. Sivakumar
Cisco Cisco
K. Naito K. Naito
NTT NTT
November 4, 2015 January 18, 2016
Network Address Translation (NAT) Behavioral Requirements Updates Network Address Translation (NAT) Behavioral Requirements Updates
draft-ietf-tsvwg-behave-requirements-update-05 draft-ietf-tsvwg-behave-requirements-update-06
Abstract Abstract
This document clarifies and updates several requirements of RFC4787, This document clarifies and updates several requirements of RFC4787,
RFC5382 and RFC5508 based on operational and development experience. RFC5382 and RFC5508 based on operational and development experience.
The focus of this document is NAT44. The focus of this document is NAT44.
This document updates RFC4787, RFC5382 and RFC5508. This document updates RFC4787, RFC5382 and RFC5508.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 May 7, 2016. This Internet-Draft will expire on July 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 32 skipping to change at page 3, line 32
Carrier-Grade NAT (CGN) related requirements are defined in Carrier-Grade NAT (CGN) related requirements are defined in
[RFC6888]. [RFC6888].
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar withe terminology defined in: The reader is assumed to be familiar with the terminology defined in:
[RFC2663],[RFC4787],[RFC5382], and [RFC5508]. [RFC2663],[RFC4787],[RFC5382], and [RFC5508].
In this document, the term "NAT" refers to both "Basic NAT" and In this document, the term "NAT" refers to both "Basic NAT" and
"Network Address/Port Translator (NAPT)" (see Section 3 of "Network Address/Port Translator (NAPT)" (see Section 3 of
[RFC4787]). As a reminder, Basic NAT and NAPT are two variations of [RFC4787]). As a reminder, Basic NAT and NAPT are two variations of
traditional NAT, in that translation in Basic NAT is limited to IP traditional NAT, in that translation in Basic NAT is limited to IP
addresses alone, whereas translation in NAPT is extended to include addresses alone, whereas translation in NAPT is extended to include
IP address and Transport identifier (such as TCP/UDP port or ICMP IP address and Transport identifier (such as TCP/UDP port or ICMP
query ID) (refer to Section 2 of [RFC3022]). query ID) (refer to Section 2 of [RFC3022]).
skipping to change at page 8, line 7 skipping to change at page 8, line 7
Clarification: This document clarifies that even when a NAT has an Clarification: This document clarifies that even when a NAT has an
inbound refresh behavior set to 'TRUE', such packets SHOULD NOT inbound refresh behavior set to 'TRUE', such packets SHOULD NOT
refresh the mapping. Otherwise a simple attack of a packet every refresh the mapping. Otherwise a simple attack of a packet every
2 minutes can keep the mapping indefinitely. 2 minutes can keep the mapping indefinitely.
Update: This behavior SHOULD apply also for TCP. Update: This behavior SHOULD apply also for TCP.
7.1. Outbound Mapping Refresh and Error Packets 7.1. Outbound Mapping Refresh and Error Packets
Update: In the case of NAT outbound refresh behavior there are Update: In the case of NAT outbound refresh behavior, ICMP Errors or
certain types of packets that should not refresh the mapping even TCP RST outbound packets, sent as response to inbound packets,
if their direction is outbound. For example, if the mapping is SHOULD NOT refresh the mapping.
kept alive by ICMP Errors or TCP RST outbound packets sent as
response to inbound packets, these SHOULD NOT refresh the mapping.
8. Port Parity 8. Port Parity
Update: A NAT MAY disable port parity preservation for all dynamic Update: A NAT MAY disable port parity preservation for all dynamic
mappings. Nevertheless, A NAT SHOULD support means to explicitly mappings. Nevertheless, A NAT SHOULD support means to explicitly
request to preserve port parity (e.g., [I-D.ietf-pcp-port-set]). request to preserve port parity (e.g., [I-D.ietf-pcp-port-set]).
Note: According to [RFC6887], dynamic mappings are said to be Note: According to [RFC6887], dynamic mappings are said to be
dynamic in the sense that they are created on demand, either dynamic in the sense that they are created on demand, either
implicitly or explicitly: implicitly or explicitly:
skipping to change at page 12, line 23 skipping to change at page 12, line 23
<http://www.rfc-editor.org/info/rfc6887>. <http://www.rfc-editor.org/info/rfc6887>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <http://www.rfc-editor.org/info/rfc6888>. April 2013, <http://www.rfc-editor.org/info/rfc6888>.
Acknowledgements Acknowledgements
Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars
Eggert, Gorry Fairhurst, and Brandon Williams for their review and Eggert, Gorry Fairhurst, Brandon Williams, and David Black for their
discussion. review and discussion.
Contributors Contributors
The following individual contributed text to the document: The following individual contributed text to the document:
Sarat Kamiset, Insieme Networks, United States Sarat Kamiset, Insieme Networks, United States
Authors' Addresses Authors' Addresses
Reinaldo Penno Reinaldo Penno
skipping to change at page 13, line 4 skipping to change at page 13, line 4
San Jose, California 95134 San Jose, California 95134
USA USA
Email: repenno@cisco.com Email: repenno@cisco.com
Simon Perreault Simon Perreault
Jive Communications Jive Communications
Canada Canada
Email: sperreault@jive.com Email: sperreault@jive.com
Mohamed Boucadair Mohamed Boucadair (editor)
France Telecom Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Senthil Sivakumar Senthil Sivakumar
Cisco Systems, Inc. Cisco Systems, Inc.
United States United States
Email: ssenthil@cisco.com Email: ssenthil@cisco.com
 End of changes. 9 change blocks. 
16 lines changed or deleted 14 lines changed or added

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