--- 1/draft-ietf-tsvwg-behave-requirements-update-05.txt 2016-01-18 08:15:10.050795456 -0800 +++ 2/draft-ietf-tsvwg-behave-requirements-update-06.txt 2016-01-18 08:15:10.086796315 -0800 @@ -1,25 +1,25 @@ TSVWG R. Penno Internet-Draft Cisco Updates: 4787, 5382, 5508 (if approved) S. Perreault Intended status: Best Current Practice Jive Communications -Expires: May 7, 2016 M. Boucadair - France Telecom +Expires: July 21, 2016 M. Boucadair, Ed. + Orange S. Sivakumar Cisco K. Naito NTT - November 4, 2015 + January 18, 2016 Network Address Translation (NAT) Behavioral Requirements Updates - draft-ietf-tsvwg-behave-requirements-update-05 + draft-ietf-tsvwg-behave-requirements-update-06 Abstract This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAT44. This document updates RFC4787, RFC5382 and RFC5508. Status of This Memo @@ -30,25 +30,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -114,21 +114,21 @@ Carrier-Grade NAT (CGN) related requirements are defined in [RFC6888]. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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]. In this document, the term "NAT" refers to both "Basic NAT" and "Network Address/Port Translator (NAPT)" (see Section 3 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 addresses alone, whereas translation in NAPT is extended to include IP address and Transport identifier (such as TCP/UDP port or ICMP query ID) (refer to Section 2 of [RFC3022]). @@ -330,25 +330,23 @@ Clarification: This document clarifies that even when a NAT has an inbound refresh behavior set to 'TRUE', such packets SHOULD NOT refresh the mapping. Otherwise a simple attack of a packet every 2 minutes can keep the mapping indefinitely. Update: This behavior SHOULD apply also for TCP. 7.1. Outbound Mapping Refresh and Error Packets - Update: In the case of NAT outbound refresh behavior there are - certain types of packets that should not refresh the mapping even - if their direction is outbound. For example, if the mapping is - kept alive by ICMP Errors or TCP RST outbound packets sent as - response to inbound packets, these SHOULD NOT refresh the mapping. + Update: In the case of NAT outbound refresh behavior, ICMP Errors or + TCP RST outbound packets, sent as response to inbound packets, + SHOULD NOT refresh the mapping. 8. Port Parity Update: A NAT MAY disable port parity preservation for all dynamic mappings. Nevertheless, A NAT SHOULD support means to explicitly request to preserve port parity (e.g., [I-D.ietf-pcp-port-set]). Note: According to [RFC6887], dynamic mappings are said to be dynamic in the sense that they are created on demand, either implicitly or explicitly: @@ -536,22 +534,22 @@ . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . Acknowledgements Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars - Eggert, Gorry Fairhurst, and Brandon Williams for their review and - discussion. + Eggert, Gorry Fairhurst, Brandon Williams, and David Black for their + review and discussion. Contributors The following individual contributed text to the document: Sarat Kamiset, Insieme Networks, United States Authors' Addresses Reinaldo Penno @@ -560,22 +558,22 @@ San Jose, California 95134 USA Email: repenno@cisco.com Simon Perreault Jive Communications Canada Email: sperreault@jive.com - Mohamed Boucadair - France Telecom + Mohamed Boucadair (editor) + Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Senthil Sivakumar Cisco Systems, Inc. United States Email: ssenthil@cisco.com