< draft-woodyatt-spnatpmp-appl-00.txt		draft-woodyatt-spnatpmp-appl-01.txt >
	Behavior Engineering for Hindrance j. woodyatt		Behavior Engineering for Hindrance j. woodyatt
	Avoidance Apple		Avoidance Apple
	Internet-Draft November 18, 2008		Internet-Draft November 19, 2008
	Intended status: Informational		Intended status: Informational
	Expires: May 22, 2009		Expires: May 23, 2009
	Applicability of NAT-PMP with Service Provider Deployments of Network		Applicability of NAT-PMP with Service Provider Deployments of Network
	Address Translation		Address Translation
	draft-woodyatt-spnatpmp-appl-00		draft-woodyatt-spnatpmp-appl-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 May 22, 2009.		This Internet-Draft will expire on May 23, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	In an effort to conserve global scope IPv4 address allocations,		In an effort to conserve global scope IPv4 address allocations,
	service providers are deploying network address/port translators in		service providers are deploying network address/port translators in
	their interior routing domain and assigning private addresses to		their interior routing domain and assigning private addresses to
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3		1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 4		3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 4
	3.1. Response Code . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Response Code . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Relay Service . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Relay Service . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2.1. The Simple Case . . . . . . . . . . . . . . . . . . . . 5		3.2.1. The Simple Case . . . . . . . . . . . . . . . . . . . . 5
	3.2.2. The NAT444 Case . . . . . . . . . . . . . . . . . . . . 5		3.2.2. The NAT444 Case . . . . . . . . . . . . . . . . . . . . 5
	4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. UNSAF Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . 7		Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 8
	B.1. Starting Point . . . . . . . . . . . . . . . . . . . . . . 7		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		B.1. Change -00 to -01 . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 8		B.2. Starting Point . . . . . . . . . . . . . . . . . . . . . . 8
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
			Intellectual Property and Copyright Statements . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Some service providers are finding it necessary to conserve their		Some service providers are finding it necessary to conserve their
	global scope IPv4 address allocations by assigning private addresses		global scope IPv4 address allocations by assigning private addresses
	[RFC1918] to subscribers and deploying network address and port		[RFC1918] to subscribers and deploying network address and port
	translating (NAPT) routers in their interior routing domains. In		translating (NAPT) routers in their interior routing domains. In
	doing so, providers may give up the option of relying on legal		doing so, providers may give up the option of relying on legal
	(contractual) restrictions alone to prohibit subscribers from		(contractual) restrictions alone to prohibit subscribers from
	operating servers or using peer-to-peer (P2P) functions. A natural		operating servers or using peer-to-peer (P2P) functions. A natural
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	IGD and/or NAT-PMP. The relay service for NAT-PMP to NAT-PMP is		IGD and/or NAT-PMP. The relay service for NAT-PMP to NAT-PMP is
	described here, and the corresponding relay for UPnP-IGD to NAT-PMP		described here, and the corresponding relay for UPnP-IGD to NAT-PMP
	is left unspecified.		is left unspecified.
	A NAT-PMP relay service acts in all respects as a NAT-PMP server from		A NAT-PMP relay service acts in all respects as a NAT-PMP server from
	the perspective of its downstream clients. However, from the		the perspective of its downstream clients. However, from the
	perspective of the upstream service, there are two important		perspective of the upstream service, there are two important
	subclasses of NAT-PMP relay to discuss: A) the case where the relay		subclasses of NAT-PMP relay to discuss: A) the case where the relay
	is controlling its own NAPT, as in the NAT444 architecture; and, B)		is controlling its own NAPT, as in the NAT444 architecture; and, B)
	the case where the relay is not controlling its own NAPT, as in the		the case where the relay is not controlling its own NAPT, as in the
	DS-Lite architecture.		DS-Lite architecture [I-D.durand-softwire-dual-stack-lite].
	3.2.1. The Simple Case		3.2.1. The Simple Case
	In the simple case, the NAT-PMP clients in the subscriber realm		In the simple case, the NAT-PMP clients in the subscriber realm
	initiate port mapping requests to a relay on the subscriber's gateway		initiate port mapping requests to a relay on the subscriber's gateway
	router, which forwards them to the service provider NAPT gateway.		router, which forwards them to the service provider NAPT gateway.
	The subscriber router does not also have a NAPT function, so the		The subscriber router does not also have a NAPT function, so the
	relay doesn't have to translate requests.		relay doesn't have to translate requests.
	The only minor complications for the relay are that the public		The only minor complications for the relay are that the public
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 23 ¶
	when the NAT-PMP relay receives a response from its server, the relay		when the NAT-PMP relay receives a response from its server, the relay
	translates the interior port from the service provider realm to the		translates the interior port from the service provider realm to the
	subscriber realm and forwards the response to the client. If the		subscriber realm and forwards the response to the client. If the
	response code from the server is non-zero, then the corresponding		response code from the server is non-zero, then the corresponding
	port mapping needs to be removed from the NAPT ruleset in order to		port mapping needs to be removed from the NAPT ruleset in order to
	abort the distributed transaction.		abort the distributed transaction.
	The technical matters revolving around handling renewals and drops		The technical matters revolving around handling renewals and drops
	are straightforward variations as in the insertion case.		are straightforward variations as in the insertion case.
	4. Contributors		4. UNSAF Considerations
	Comments and criticisms during the development of this document were		In addition to all the UNSAF considerations [RFC3424] described in
	received from the following IETF participants:		[I-D.cheshire-nat-pmp], the idea of a NAT-PMP relay poses its own
			special UNSAF issues with respect to hairpins.
	Stuart Cheshire		In general, NAT-PMP and UPnP IGD clients in subscriber address realms
			are unprepared to cope with the possibility of other address realms
			besides their own and the public address realm. Also, current
			deployments of UPnP IGD and NAT-PMP have the hairpins turning at the
			subscriber NAPT gateway. With a NAT-PMP relay, the hairpins are
			pushed up to the provider NAPT gateway, and this may result in a
			noticeable deterioration in performance of hairpinned throughput.
			In the simple NAT-PMP relay case, i.e. the one proposed for the DS-
			Lite architecture [I-D.durand-softwire-dual-stack-lite], there is no
			separate provider address realm, so the shortest path for all
			possible paths through the provider network, including hairpins,
			passes through the NAPT gateway.
			However, in the case of the NAT444 architecture, where the NAT-PMP
			relay is mapping ports between the subscriber realm and the provider
			realm, paths between subscribers within the same provider address
			realm are not used by NAT-PMP client applications because there is
			only one hairpin point, the provider NAPT gateway.
			This points to potentially thorny traffic engineering problem in the
			deployment of service provider NAPT gateways: the desire to simplify
			network operations by minimizing the number of provider address
			realms cuts against the desire to minimize the load on the provider
			NAPT gateways arising from hairpins. Also worth noting: this problem
			is not limited to just the NAT444 architecture; it's a problem for
			all service providers that move the public address realm boundary
			into their interior routing domain.
	5. IANA Considerations		5. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	6. Security Considerations		6. Security Considerations
	[EDITOR: See [RFC3552] for guidelines to writing this section.		[EDITOR: See [RFC3552] for guidelines to writing this section.
	Preliminary note: concerns about authorization of subscriber clients		Preliminary note: concerns about authorization of subscriber clients
	and relays to use the NAT-PMP service at the service provider address		and relays to use the NAT-PMP service at the service provider address
	realm boundary might arise. These should be resisted, but if they		realm boundary might arise. These should be resisted, but if they
	cannot be dismissed, then it would seem that IPsec w/ IKE would be		cannot be dismissed, then it would seem that IPsec w/ IKE would be
	the appropriate cryptographic protocol for that purpose.]		the appropriate cryptographic protocol for that purpose.]
	7. References		7. Contributors
	7.1. Normative References
			Comments and criticisms during the development of this document were
			received from the following IETF participants:
			Stuart Cheshire
			8. References
			8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.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.durand-softwire-dual-stack-lite]
			Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
			"Dual-stack lite broadband deployments post IPv4
			exhaustion", draft-durand-softwire-dual-stack-lite-01
			(work in progress), November 2008.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets",		E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
			[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
			Self-Address Fixing (UNSAF) Across Network Address
			Translation", RFC 3424, November 2002.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	July 2003.		July 2003.
	[RFC4084] Klensin, J., "Terminology for Describing Internet		[RFC4084] Klensin, J., "Terminology for Describing Internet
	Connectivity", BCP 104, RFC 4084, May 2005.		Connectivity", BCP 104, RFC 4084, May 2005.
	Appendix A. Open Issues		Appendix A. Open Issues
	o [EDITOR: Insert open issues here.]		o [EDITOR: Insert open issues here.]
	Appendix B. Change Log		Appendix B. Change Log
	B.1. Starting Point		B.1. Change -00 to -01
			o Added UNSAF considerations section.
			o Moved the contributors section to the end of the middle element.
			B.2. Starting Point
	o Initial revision.		o Initial revision.
	Author's Address		Author's Address
	james woodyatt		james woodyatt
	Apple Inc.		Apple Inc.
	1 Infinite Loop		1 Infinite Loop
	Cupertino, CA 95014		Cupertino, CA 95014
	US		US
End of changes. 14 change blocks.
	24 lines changed or deleted		78 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/