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/