One document matched: draft-woodyatt-spnatpmp-appl-01.txt
Differences from draft-woodyatt-spnatpmp-appl-00.txt
Behavior Engineering for Hindrance j. woodyatt
Avoidance Apple
Internet-Draft November 19, 2008
Intended status: Informational
Expires: May 23, 2009
Applicability of NAT-PMP with Service Provider Deployments of Network
Address Translation
draft-woodyatt-spnatpmp-appl-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 23, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
In an effort to conserve global scope IPv4 address allocations,
service providers are deploying network address/port translators in
their interior routing domain and assigning private addresses to
residential and small office subscriber sites. This document
discusses the applicability of NAT-PMP is such networks to support
application requiring dynamic TCP and UDP port forwarding.
woodyatt Expires May 23, 2009 [Page 1]
Internet-Draft NAT-PMP for Service Providers November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 4
3.1. Response Code . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Relay Service . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. The Simple Case . . . . . . . . . . . . . . . . . . . . 5
3.2.2. The NAT444 Case . . . . . . . . . . . . . . . . . . . . 5
4. UNSAF Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . 8
B.1. Change -00 to -01 . . . . . . . . . . . . . . . . . . . . . 8
B.2. Starting Point . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
woodyatt Expires May 23, 2009 [Page 2]
Internet-Draft NAT-PMP for Service Providers November 2008
1. Introduction
Some service providers are finding it necessary to conserve their
global scope IPv4 address allocations by assigning private addresses
[RFC1918] to subscribers and deploying network address and port
translating (NAPT) routers in their interior routing domains. In
doing so, providers may give up the option of relying on legal
(contractual) restrictions alone to prohibit subscribers from
operating servers or using peer-to-peer (P2P) functions. A natural
side effect of using NAPT and private subscriber routing realms is to
introduce a technical obstacle to A) the use of P2P communication
with peers on the public Internet, and B) the advertisement and
availability of servers to clients on the public Internet.
Those providers wishing to offer more than "client connectivity only,
without public addresses" service (as defined in Terminology for
Describing Internet Connectivity [RFC4084]) are invited to consider
deploying the Network Address Translator Port Mapping Protocol
[I-D.cheshire-nat-pmp] in conjuction with their NAPT gateways in
order to provide a dynamic port forwarding service and mitigate
against the loss of application transparency caused by the placement
of subscribers in private routing realms.
This document discusses the applicability of NAT-PMP in such
deployments and identifies the specific clarifications necessary to
improve the existing draft of the protocol to improve its
suitability.
1.1. Special Language
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 RFC 2119 [RFC2119].
2. Overview
The motivating usage scenario that drove the development of the NAT-
PMP protocol was the case where a residential subscriber deploys NAPT
in their CPE gateway as a method to provide Internet service to a
home network of devices using a single service provider access point,
and as a kind of "firewall" to protect their local network from
unsolicited exterior traffic.
In that usage scenario, the NAT-PMP service is in the same
administrative domain as the residential gateway and the other nodes
in the subscriber's network. When the protocol was first specified,
the normal expectation was that subscribers are generally assigned
woodyatt Expires May 23, 2009 [Page 3]
Internet-Draft NAT-PMP for Service Providers November 2008
public addresses and most service providers offer either "full
Internet connectivity" or "firewalled Internet connectivity"
[RFC4084]. However, by virtue of its minimal and simple design, NAT-
PMP is easily adapted for use with service provider NAPT gateways.
In general, the aspects of NAT-PMP that need revision for the
scenario at hand are those having to do with the division of the
clients from the administrative domain of the NAPT gateway. To that
end, the protocol should be extended by adding a result code for
mapping requests to indicate that the per-subscriber resource limit
would be exceeded. Additionally, a definition is required for a so-
called NAT-PMP "relay" service, which mediates between the clients in
the CPE routing realm and the service provider NAPT gateway. Also,
some consideration in the server must be given to admission control
and denial of service attack.
3. Detailed Recommendations
This section enumerates the specific recommendations specific changes
to the NAT-PMP specification [I-D.cheshire-nat-pmp] to adapt for use
with service provider NAPT gateways.
3.1. Response Code
A new response code should be defined.
6 - Per-subscriber resource limit would be exceeded.
Some discussion is warranted.
The NAT-PMP specification currently defines response code 2 as "Not
Authorized/Refused," but this code is inappropriate because it
indicates that the NAPT gateway is not allowing any mapping requests
from the current user to succeed as a matter of policy. (The server
is expected to answer requests to determine the exterior address.)
The NAT-PMP specification also currently defines response code 4 as
"Out of resources (cannot create any more mappings at this time)" but
this code is also inappropriate because it indicates that the hard
limit of the whole NAPT gateway would be exceeded. This limit is not
the same as a per-subscriber limit, and the distinction is important
for traffic engineering purposes.
3.2. Relay Service
Subscribers with routers at their demarcation point will need a relay
for NAT-PMP from the provider's NAPT gateway to the dynamic port-
woodyatt Expires May 23, 2009 [Page 4]
Internet-Draft NAT-PMP for Service Providers November 2008
forwarding protocol(s) in use on the subscriber's network, e.g. UPnP
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
is left unspecified.
A NAT-PMP relay service acts in all respects as a NAT-PMP server from
the perspective of its downstream clients. However, from the
perspective of the upstream service, there are two important
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)
the case where the relay is not controlling its own NAPT, as in the
DS-Lite architecture [I-D.durand-softwire-dual-stack-lite].
3.2.1. The Simple Case
In the simple case, the NAT-PMP clients in the subscriber realm
initiate port mapping requests to a relay on the subscriber's gateway
router, which forwards them to the service provider NAPT gateway.
The subscriber router does not also have a NAPT function, so the
relay doesn't have to translate requests.
The only minor complications for the relay are that the public
address of the service provider NAPT gateway must be propagated to
the subscriber NAT-PMP clients in the relay announcements and the
responses to the exterior address requests, and the relay must
synchronize the start of its epoch to the upstream service.
Synchronizing the start of the epoch is straightforward. So long as
the upstream server is sending a monotonically increasing value for
its start of the epoch, the relay simply copies the counter into its
own counter, which it uses when sending announcements to subscriber
clients.
A simple NAT-PMP relay, i.e. one without a NAPT function attached,
need not attempt to cache the state of the upstream NAT-PMP server.
All requests can be forwarded directly, and the expense and
difficulty of maintaining a cache is unnecessary.
3.2.2. The NAT444 Case
In the NAT444 case, the NAT-PMP clients in the subscriber realm
initiate port mapping requests that involve a distributed transaction
on both the subscriber NAPT gateway and the service provider NAPT
gateway.
As in the simple case, the NAT-PMP relay in the NAT444 case needs to
synchronize the start of the epoch with the service provider NAT-PMP
server. It also needs to propagate the exterior public address from
woodyatt Expires May 23, 2009 [Page 5]
Internet-Draft NAT-PMP for Service Providers November 2008
the NAT-PMP server to the subscriber clients. However, it also must
recursively forward NAT-PMP requests from subscribers to the server
by translating ports from realm to realm.
A brief word about how to do that. When the NAT-PMP relay receives a
locally satisfiable request, then it inserts the redirection mapping
into its NAPT ruleset and forwards the request to the server with the
interior port replaced by the locally assigned exterior port, i.e.
the one allocated in the service provider address realm. Likewise,
when the NAT-PMP relay receives a response from its server, the relay
translates the interior port from the service provider realm to the
subscriber realm and forwards the response to the client. If the
response code from the server is non-zero, then the corresponding
port mapping needs to be removed from the NAPT ruleset in order to
abort the distributed transaction.
The technical matters revolving around handling renewals and drops
are straightforward variations as in the insertion case.
4. UNSAF Considerations
In addition to all the UNSAF considerations [RFC3424] described in
[I-D.cheshire-nat-pmp], the idea of a NAT-PMP relay poses its own
special UNSAF issues with respect to hairpins.
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
woodyatt Expires May 23, 2009 [Page 6]
Internet-Draft NAT-PMP for Service Providers November 2008
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
This document has no IANA actions.
6. Security Considerations
[EDITOR: See [RFC3552] for guidelines to writing this section.
Preliminary note: concerns about authorization of subscriber clients
and relays to use the NAT-PMP service at the service provider address
realm boundary might arise. These should be resisted, but if they
cannot be dismissed, then it would seem that IPsec w/ IKE would be
the appropriate cryptographic protocol for that purpose.]
7. Contributors
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
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
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
woodyatt Expires May 23, 2009 [Page 7]
Internet-Draft NAT-PMP for Service Providers November 2008
(work in progress), November 2008.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
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
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4084] Klensin, J., "Terminology for Describing Internet
Connectivity", BCP 104, RFC 4084, May 2005.
Appendix A. Open Issues
o [EDITOR: Insert open issues here.]
Appendix B. Change Log
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.
Author's Address
james woodyatt
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
US
Email: jhw@apple.com
woodyatt Expires May 23, 2009 [Page 8]
Internet-Draft NAT-PMP for Service Providers November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
woodyatt Expires May 23, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 03:28:28 |