One document matched: draft-woodyatt-spnatpmp-appl-01.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3424.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4084.xml">
<!ENTITY I-D.cheshire-nat-pmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-nat-pmp.xml">
<!ENTITY I-D.durand-softwire-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.durand-softwire-dual-stack-lite.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most
    I-Ds might want to use.  (Here they are set differently than their defaults
    in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<!-- We the people, in order to form a more perfect standard... -->
<rfc category="info" docName="draft-woodyatt-spnatpmp-appl-01" ipr="full3978">
  <!-- EDITOR: category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ########################### FRONT MATTER ########################### -->
  <front>
    <title abbrev="NAT-PMP for Service Providers">
		Applicability of NAT-PMP with Service Provider Deployments of
		Network Address Translation
	</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <author fullname="james woodyatt" initials="j.h" surname="woodyatt">
      <organization abbrev='Apple'>Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino</city>
          <region>CA</region>
          <code>95014</code>
          <country>US</country>
        </postal>
        <email>jhw@apple.com</email>
      </address>
    </author>

    <!-- EDITOR: Other authors go here... -->

    <!-- EDITOR: Always make sure the year is correct here. -->
    <date year="2008" />

    <!-- If the month and year are both specified and are the current ones,
		xml2rfc will fill in the current day for you. If only the current year
		is specified, xml2rfc will fill in the current day and month for you.
		If the year is not the current one, it is necessary to specify at least
		a month (xml2rfc assumes day="1" if not specified for the purpose of
		calculating the expiry date).  With drafts it is normally sufficient to 
		specify just the year. -->

    <!-- EDITOR: Meta-data Declarations -->
    <area>Operations and Management</area>
    <workgroup>Behavior Engineering for Hindrance Avoidance</workgroup>
    <keyword>NAT-PMP</keyword>
    <keyword>NAT</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <!-- ########################### MIDDLE MATTER ########################## -->
  <middle>
    <section anchor='intro' title="Introduction">
      <t>Some service providers are finding it necessary to conserve their global scope IPv4 address allocations by assigning <xref target='RFC1918'>private addresses</xref> 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.</t>
      
      <t>Those providers wishing to offer more than "client connectivity only, without public addresses" service (as defined in <xref target='RFC4084'>Terminology for Describing Internet Connectivity</xref>) are invited to consider deploying the <xref target='I-D.cheshire-nat-pmp'>Network Address Translator Port Mapping Protocol</xref> 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.</t>
      
      <t>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.</t>
      	  
      <section anchor='req-lang' title="Special Language">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>
	
	<section anchor='overview' title="Overview">
	  <t>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.</t>
	  
	  <t>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 public addresses and most service providers offer either "full Internet connectivity" or "firewalled Internet connectivity" <xref target="RFC4084"/>.  However, by virtue of its minimal and simple design, NAT-PMP is easily adapted for use with service provider NAPT gateways.</t>
	  
	  <t>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.</t>
	</section>
	 
	<section anchor="summary" title="Detailed Recommendations">
	  <t>This section enumerates the specific recommendations specific changes to the NAT-PMP specification <xref target='I-D.cheshire-nat-pmp'/> to adapt for use with service provider NAPT gateways.</t>
	  
	  <section anchor="response-code" title="Response Code">
	  	<t>A new response code should be defined.</t>
	  	
	  	<t>6 - Per-subscriber resource limit would be exceeded.</t>
	  	
	  	<t>Some discussion is warranted.</t>
	  	
	  	<t>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.)</t>
	  	
	  	<t>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.</t>
	  </section>
	  
	  <section anchor="relay" title="Relay Service">
	  	<t>Subscribers with routers at their demarcation point will need a relay for NAT-PMP from the provider's NAPT gateway to the dynamic port-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.</t>
	  	
		<t>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 <xref target='I-D.durand-softwire-dual-stack-lite'>the DS-Lite architecture</xref>.</t>
		
		<section anchor="relay-simple" title="The Simple Case">
		  <t>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.</t>
		  
		  <t>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.</t>
		  
		  <t>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.</t>
		  
		  <t>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.</t>
		</section>
		
		<section anchor="relay-nat444" title="The NAT444 Case">
		  <t>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.</t>
		  
		  <t>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 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.</t>
		  
		  <t>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.</t>
		  
		  <t>The technical matters revolving around handling renewals and drops are straightforward variations as in the insertion case.</t>
		</section>
	  </section>
	</section>

    <section anchor="unsaf" title="UNSAF Considerations">
      <t>In addition to all the <xref target='RFC3424'>UNSAF considerations</xref> described in <xref target='I-D.cheshire-nat-pmp'/>, the idea of a NAT-PMP relay poses its own special UNSAF issues with respect to hairpins.</t>
      
      <t>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.</t>
      
      <t>In the simple NAT-PMP relay case, i.e. the one proposed for <xref target='I-D.durand-softwire-dual-stack-lite'>the DS-Lite architecture</xref>, 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.</t>
      
      <t>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.</t>
      
      <t>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.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
        <!-- EDITOR: this entity is defined at the top, and only used here. -->
      <t>This document has no IANA actions.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <!-- EDITOR: this entity is defined at the top, and only used here. -->
      <t>[EDITOR: See <xref target="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.]</t>
    </section>

    <section anchor="contrib" title="Contributors">
	  <t>Comments and criticisms during the development of this document were
	  received from the following IETF participants:</t>
	  
	  <t><list>
		<t>Stuart Cheshire</t>
	  </list></t>
	</section>
  </middle>

  <!-- ############################ BACK MATTER ########################### -->
  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation
		libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629;
		here (as shown)
     2. simply use a PI "less than character"?rfc
		include="reference.RFC.2119.xml"?> here
        (for I-Ds:
			include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included
	 files in the same directory as the including file. You can also define the
	 XML_LIBRARY environment variable with a value containing a set of
	 directories to search.  These can be either in the local filing system or
	 remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!-- Here we use entities that we defined at the beginning. -->
      &RFC2119; <!-- All drafts reference RFC 2119 in their boilerplate. -->

      <!-- Here we include reference elements internally. -->
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      &RFC1918; <!-- Private addresses -->
      &RFC3424; <!-- UNSAF considerations. -->
      &RFC3552; <!-- Guidelines for security sections in RFC text. -->
      &RFC4084; <!-- Terminology for describing Internet connectivity. -->
	  &I-D.cheshire-nat-pmp; <!-- NAT-PMP specification. --->
	  &I-D.durand-softwire-dual-stack-lite; <!-- Dual-stack lite -->

      <!-- Here we include reference elements internally. -->
    </references>

    <!-- Open Issues -->
	<section anchor='issues' title="Open Issues">
	  <t><list style='symbols'>
	     <t>[EDITOR: Insert open issues here.]</t>
	  </list></t>
	</section>

    <!-- Change Log -->
	<section anchor='changelog' title="Change Log">
	  <section title='Change -00 to -01'>
	    <t><list style='symbols'>
		  <t>Added UNSAF considerations section.</t>
		</list></t>
	    <t><list style='symbols'>
		  <t>Moved the contributors section to the end of the middle element.</t>
		</list></t>
	  </section>
	  
	  <section title='Starting Point'>
	    <t><list style='symbols'>
		  <t>Initial revision.</t>
		</list></t>
	  </section>
	</section>
  </back>
</rfc>