source: draft-cheshire-pcp-anycast/draft-ietf-pcp-anycast.xml @ 355

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pcp-anycast-02" ipr="trust200902">
  <front>
    <title abbrev="PCP Anycast Address">PCP Anycast Address</title>

    <author fullname="Sebastian Kiesel" initials="S." surname="Kiesel">
      <organization abbrev="University of Stuttgart">University of Stuttgart
      Information Center</organization>

      <address>
        <postal>
          <street>Networks and Communication Systems Department</street>
          <street>Allmandring 30</street>

          <city>Stuttgart</city>

          <code>70550</code>

          <country>Germany</country>
        </postal>

        <email>ietf-pcp@skiesel.de</email>
      </address>
    </author>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <city>San Jose</city>

          <region>CA</region>

          <code/>

          <country>US</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>repenno@cisco.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
      <organization abbrev="Apple">Apple Inc.</organization>

      <address>
        <postal>
          <street>1 Infinite Loop</street>

          <city>Cupertino</city>

          <region>California</region>

          <code>95014</code>

          <country>USA</country>
        </postal>

        <phone>+1 408 974 3207</phone>

        <email>cheshire@apple.com</email>
      </address>
    </author>


    <date year="2014"/>

    <workgroup>PCP working group</workgroup>

    <abstract>
      <t>The Port Control Protocol (PCP) Anycast Address enables PCP clients to
      transmit signaling messages to their closest on-path NAT, Firewall, or other
      middlebox, without having to learn the IP address of that middlebox via
      some external channel.  This document establishes one well-known
      IPv4 address and one well-known IPv6 address to be used as
      PCP Anycast Address.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">

      <t>The Port Control Protocol (PCP) <xref target="RFC6887"/> 
      provides a mechanism to control how
      incoming packets are forwarded by upstream devices such as Network
      Address Translator IPv6/IPv4 (NAT64), Network Address Translator
      IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a mechanism to
      reduce application keep alive traffic.</t>

      <t>The PCP document <xref target="RFC6887"/> 
      specifies the message formats used, but the address to which a client
      sends its request is either assumed to be the default router (which is
      appropriate in a typical single-link residential network) or has to be
      configured otherwise via some external mechanism, such as DHCP.
      The properties and drawbacks of various mechanisms are discussed in
      <xref target="appendix-alternatives"/>.</t>

      <t>This document follows a different approach: it establishes a
      well-known anycast address for the PCP Server.
      PCP clients are expected to send requests to this
      address during the PCP Server discovery process. A PCP Server configured
      with the anycast address could optionally redirect or return a list of
      unicast PCP Servers to the client. For a more extensive discussion
      on anycasting see <xref target="appendix_anycast_discussion"/>.</t>

      <t>The benefit of using an anycast address is simplicity and
      reliability. In an example deployment scenario: <list style="numbers">
          <t>A network administrator installs a PCP-capable NAT.</t>

          <t>An end user (who may be the same person) runs a PCP-enabled
          application. This application can implement PCP with purely
          user-level code -- no operating system support is required.</t>

          <t>This PCP-enabled application sends its PCP request to the PCP
          anycast address. This packet travels through the network like any
          other, without any special support from DNS, DHCP, other routers, or
          anything else, until it reaches the PCP-capable NAT, which receives
          it, handles it, and sends back a reply.</t>
        </list> Using the PCP anycast address, the only two things that need
      to be deployed in the network are the two things that actually use PCP:
      The PCP-capable NAT, and the PCP-enabled application. Nothing else in
      the network needs to be changed or upgraded, and nothing needs to be
      configured, including the PCP client.</t>

    </section>



    <section anchor="spec"
             title="PCP Server Discovery based on well-known IP Address">
      <section title="PCP Discovery Client behavior">
        <t>PCP Clients that need to discover PCP servers SHOULD first send a
        PCP request to the configured PCP server or to the default router,
        as described in Section 8.1 of <xref target="RFC6887"/>.  However,
        differing from Section 8.1.1 of <xref target="RFC6887"/>, MRC
        (Maximum Retransmission Count) is set to 4.  Trying the configured
        PCP server or the default router first is important because in the
        case of cascaded PCP Servers, all of them need to be discovered in
        order of hop distance from the client. </t>
        
        <t>If contacting the configured PCP server or the default router
        does not succeed with this first approach, the PCP client 
        re-initializes RT based on IRT, and
        it resets MRC to its "normal" value (0 unless a different value is
        requested by the application), as described in Section 8.1.1 of
        <xref target="RFC6887"/>.
        Then, the PCP client repeatedly transmits a message to the
        configured PCP server or the default router, waits RT, transmits a
        message to the anycast address, waits RT, recalculates RT as specified
        in Section 8.1.1 of <xref target="RFC6887"/>, and starts again
        with a retransmission to the configured PCP server or the default
        router. This procedure continues until a reply is received or
        or the PCP client is no longer interested in the PCP transaction
        or the message exchange is considered to have failed according to
        MRC/MRD.</t>
       
        <t>The PCP client SHOULD select the PCP anycast address to be of the
        same IP address family as its requested PCP mapping, i.e., the
        address family of the Requested Internal IP Address.</t>
        
      </section>

      <section title="PCP Discovery Server behavior">
        <t>A PCP Server can be configured to listen on the anycast address for
        incoming PCP requests.</t>

        <t>PCP responses are sent from that same IANA-assigned address (see
        Page 5 of <xref target="RFC1546"/>).</t>
      </section>
    </section>

    <section title="Deployment Considerations">
        <t>There are known limitations when there is more than one
        PCP server and asymmetric routing, or similar scenarios.
        Mechanisms to deal with those situations, such as state 
        synchronization between PCP servers, are beyond
        the scope of this document.</t>

        <t>For general recommendations regarding operation of
        anycast services see <xref target="RFC4786"/>.</t>

    </section>

    <section title="IANA Considerations">
      <section title="Registration of IPv4 Special Purpose Address">
        <t>IANA is requested to register a single IPv4 address in the IANA
        IPv4 Special Purpose Address Registry <xref target="RFC5736"/>.</t>

        <t><xref target="RFC5736"/> itemizes some information to be recorded
        for all designations: <list style="hanging">
            <t>1. The designated address prefix.</t>

            <t>Prefix: TBD by IANA. Prefix length: /32</t>

            <t>2. The RFC that called for the IANA address designation.</t>

            <t>This document.</t>

            <t>3. The date the designation was made.</t>

            <t>TBD.</t>

            <t>4. The date the use designation is to be terminated (if
            specified as a limited-use designation).</t>

            <t>Unlimited. No termination date.</t>

            <t>5. The nature of the purpose of the designated address (e.g.,
            unicast experiment or protocol service anycast).</t>

            <t>protocol service anycast.</t>

            <t>6. For experimental unicast applications and otherwise as
            appropriate, the registry will also identify the entity and
            related contact details to whom the address designation has been
            made.</t>

            <t>N/A.</t>

            <t>7. The registry will also note, for each designation, the
            intended routing scope of the address, indicating whether the
            address is intended to be routable only in scoped, local, or
            private contexts, or whether the address prefix is intended to be
            routed globally.</t>

            <t>Typically used within a network operator's network domain, but
            in principle globally routable.</t>

            <t>8. The date in the IANA registry is the date of the IANA
            action, i.e., the day IANA records the allocation.</t>

            <t>TBD.</t>
          </list></t>
      </section>

      <section title="Registration of IPv6 Special Purpose Address">
        <t>IANA is requested to register a single IPv6 address in the IANA
        IPv6 Special Purpose Address Block <xref target="RFC4773"/>.</t>

        <t><xref target="RFC4773"/> itemizes some information to be recorded
        for all designations: <list style="hanging">
            <t>1. The designated address prefix.</t>

            <t>Prefix: TBD by IANA. Prefix length: /128</t>

            <t>2. The RFC that called for the IANA address designation.</t>

            <t>This document.</t>

            <t>3. The date the designation was made.</t>

            <t>TBD.</t>

            <t>4. The date the use designation is to be terminated (if
            specified as a limited-use designation).</t>

            <t>Unlimited. No termination date.</t>

            <t>5. The nature of the purpose of the designated address (e.g.,
            unicast experiment or protocol service anycast).</t>

            <t>protocol service anycast.</t>

            <t>6. For experimental unicast applications and otherwise as
            appropriate, the registry will also identify the entity and
            related contact details to whom the address designation has been
            made.</t>

            <t>N/A.</t>

            <t>7. The registry will also note, for each designation, the
            intended routing scope of the address, indicating whether the
            address is intended to be routable only in scoped, local, or
            private contexts, or whether the address prefix is intended to be
            routed globally.</t>

            <t>Typically used within a network operator's network domain, but
            in principle globally routable.</t>

            <t>8. The date in the IANA registry is the date of the IANA
            action, i.e., the day IANA records the allocation.</t>

            <t>TBD.</t>
          </list></t>
      </section>

    </section>

    <section anchor="security" title="Security Considerations">
      <t>In a network without any border gateway, NAT or firewall that is
      aware of the PCP anycast address, outgoing PCP requests could leak out
      onto the external Internet, possibly revealing information about
      internal devices.</t>

      <t>Using an IANA-assigned well-known PCP anycast address enables border
      gateways to block such outgoing packets. In the default-free zone,
      routers should be configured to drop such packets. Such configuration
      can occur naturally via BGP messages advertising that no route exists to
      said address.</t>

      <t>Sensitive clients that do not wish to leak information about their
      presesence can set an IP TTL on their PCP requests that limits how far
      they can travel into the public Internet.</t>
    </section>
  </middle>

  <back>
    <?rfc needLines="6" ?>

    <references title="Normative References">
      <?rfc include="reference.RFC.1546"?>

      <!-- <?rfc include="reference.RFC.2119"?> -->

      <?rfc include="reference.RFC.3958"?>

      <?rfc include="reference.RFC.4773"?>

      <?rfc include="reference.RFC.5736"?>

      <?rfc include="reference.RFC.6887"?>

    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4786"?>
      <?rfc include="reference.I-D.chen-pcp-mobile-deployment"?>
      <?rfc include="reference.I-D.ietf-pcp-dhcp"?>

      <?rfc include="reference.I-D.ietf-dhc-container-opt"?>

      <reference anchor="DhcpRequestParams"
                 target="http://msdn.microsoft.com/en-us/library/windows/desktop/aa363298%28v=vs.85%29.aspx">
        <front>
          <title>OpenFlow Switch Specification</title>

          <author fullname="OpenFlow" surname="OpenFlow">
            <organization>OpenFlow</organization>
          </author>

          <date month="February" year="2011"/>
        </front>
      </reference>

      <reference anchor="DNSDisc">
        <front>
          <title>Analysis of DNS Server Discovery Mechanisms for IPv6</title>

          <author fullname="Jun-ichiro Hagino" initials="J" surname="Hagino">
            <organization/>
          </author>

          <author fullname="Dave Thaler" initials="D" surname="Thaler">
            <organization/>
          </author>

          <date day="27" month="November" year="2001"/>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-ipngwg-dns-discovery-01"/>

        <format target="http://tools.ietf.org/id/draft-ietf-ipngwg-dns-discovery-01.txt"
                type="TXT"/>
      </reference>
    </references>



    <section anchor="appendix-alternatives" title="Discussion of other PCP Discovery methods">
      <t>Several algorithms have been specified that allows PCP Client to
      discover the PCP Servers on a network . However, each of this approaches
      has technical or operational issues that will hinder the fast deployment
      of PCP.</t>

      <section anchor="default_router" title="Default Router">
        <t>The PCP specification allows one mode of operation in which the
        PCP client sends its requests to the default router. This approach
        is appropriate in a typical single-link residential network but
        has limitations in more complex network topologies.</t>

        <t>If PCP server does not reside in first hop router, whether because
        subscriber has a existing home router or in the case of Wireless
        Networks (3G, LTE) <xref target="I-D.chen-pcp-mobile-deployment"/>,
        trying to send a request to default router will not work.</t>
      </section>

      <section anchor="dhcp_option" title="DHCP PCP Options">
        <t>One general drawback of relying on external configuration mechanisms,
        such as DHCP <xref target="I-D.ietf-pcp-dhcp"/>, is that it creates
        an external dependency on another piece of network infrastructure which
        must be configured with the right address for PCP to work. In some
        environments the staff managing the DHCP servers may not be the same
        staff managing the NAT gateways, and in any case, constantly keeping the
        DHCP server address information up to date as NAT gateways are added,
        removed, or reconfigured, is burdensome.</t>

        <t>Another drawback of relying on DHCP for configuration is that at
        least one significant target deployment environments for PCP -- namely
        3GPP for mobile telephones -- does not use DHCP.</t>
        <t>There are two problems with DHCP Options: DHCP Server on Home
        Gateways (HGW) and Operating Systems DHCP clients</t>

        <t>Currently what the HGW does with the options it receives from the
        ISP is not standardized in any general way. As a matter of practice,
        the HGW is most likely to use its own customer-LAN-facing IP address
        for the DNS server address. As for other options, it's free to offer
        the same values to the client, offer no value at all, or offer its own
        IP address if that makes sense, as it does (sort of) for DNS.</t>

        <t>In scenarios where PCP Server resides on ISP network and is
        intended to work with arbitrary home gateways that don't know they are
        being used in a PCP context, that won't work, because there's no
        reason to think that the HGW will even request the option from the
        DHCP server, much less offer the value it gets from the server on the
        customer-facing LAN. There is work on the DHC WG to overcome some of
        these limitations <xref target="I-D.ietf-dhc-container-opt"/> but in
        terms of deployment it also needs HGW to be upgraded.</t>

        <t>The problems with Operating Systems is that even if DHCP PCP Option
        were made available to customer-facing LAN, host stack DHCP
        enhancements are required to process or request new DHCP PCP option.
        One exception is Windows <xref target="DhcpRequestParams"/></t>

        <t>Finally, in the case of IPv6 there are networks where there is
        DHCPv6 infrastructure at all or some hosts do not have a DHCPv6
        client.</t>
      </section>


      <section anchor="user_input" title="User Input">
        <t>A regular subscriber can not be expected to input IP address of PCP
        Server or network domain name. Moreover, user can be at a Wi-Fi
        hotspot, Hotel or related. Therefore relying on user input is not
        reliable.</t>
      </section>

      <section anchor="dns_based" title="Domain Name System Based ">
        <t>There are three separate category of problems with NAPTR <xref
        target="RFC3958"/> <list style="numbers">
            <t>End Points: It relies on PCP client determining the domain name
            and supporting certain DNS queries</t>

            <t>DNS Servers: DNS server need to be provisioned with the
            necessary records</t>

            <t>CPEs: CPEs might interfere with DNS queries and the DHCP domain
            name option conveyed by ISP that could be used to bootstrap NAPTR
            might not be relayed to home network.</t>
          </list></t>
      </section>

      <section anchor="port_based" title="Addressing only based on Destination Port">
        <t>One design option that was considered for Apple's NAT gateways was to
        have the NAT gateway simply handle and respond to all packets addressed
        to UDP port 5351, regardless of the destination address in the packet.
        Since the device is a NAT gateway, it already examines every packet in
        order to rewrite port numbers, so also detecting packets addressed to
        UDP port 5351 is not a significant additional burden. Also, since this
        device is a NAT gateway which rewrites port numbers, any attempt by a
        client to talk *though* this first NAT gateway to create mappings in
        some second upstream NAT gateway is futile and pointless. Any mappings
        created in the second NAT gateway are useful to the client only if there
        are also corresponding mappings created in the first NAT gateway.
        Consequently, there is no case where it is useful for PCP requests to
        pass transparently through the first PCP-aware NAT gateway on their way
        to the second PCP-aware NAT gateway. In all cases, for useful
        connectivity to be established, the PCP request must be handled by the
        first NAT gateway, and then the first NAT gateway generates a
        corresponding new upstream request to establish a mapping in the second
        NAT gateway. (This process can be repeated recursively for as many times
        as necessary for the depth of nesting of NAT gateways; this is
        transparent to the client device.)</t>
      </section>
    </section>

    <section anchor="appendix_anycast_discussion"
             title="Discussion of IP Anycast Address usage for PCP">
      <section title="Motivation">
        <t>The two issues identified in <xref target="port_based"/>
        result in the following related observations: the
        PCP client may not *know* what destination address to use in its PCP
        request packets; the PCP server doesn't *care* what destination address
        is in the PCP request packets.</t>

        <t>Given that the devices neither need to know nor care what destination
        address goes in the packet, all we need to do is pick one and use it.
        It's little more than a placeholder in the IP header. Any globally
        routable unicast address will do. Since this address is one that
        automatically routes its packet to the closest on-path device that
        implements the desired functionality, it is an anycast address.</t>
      </section>
      <section title="Scenarios">
        <t>In the simple case where the first-hop router is also the NAT gateway
        (as is common in a typical single-link residential network), sending to
        the PCP anycast address is equivalent to sending to the client's default
        router, as specified in <xref target="RFC6887">the PCP base
        document</xref>.</t>

        <t>In the case of a larger corporate network, where there may be several
        internal routed subnets and one or more border NAT gateway(s) connecting
        to the rest of the Internet, sending to the PCP anycast address has the
        interesting property that it magically finds the right border NAT
        gateway for that client. Since we posit that other network
        infrastructure does not need (and should not have) any special knowledge
        of PCP (or its anycast address) this means that to other non-NAT
        routers, the PCP anycast address will look like any other unicast
        destination address on the public Internet, and consequently the packet
        will be forwarded as for any other packet destined to the public
        Internet, until it reaches a NAT or firewall device that is aware of the
        PCP anycast address. This will result in the packet naturally arriving
        the NAT gateway that handles this client's outbound traffic destined to
        the public Internet, which is exactly the NAT gateway that the client
        wishes to communicate with when managing its port mappings.</t>
      </section>

      <section anchor="history" title="Historical Objections to Anycast">
        <t>In March 2001 a draft document entitled <xref
        target="DNSDisc">"Analysis of DNS Server Discovery Mechanisms for
        IPv6"</xref> proposed using anycast to discover DNS servers, a proposal
        that was subsequently abandoned in later revisions of that draft
        document.</t>
   
        <t>There are legitimate reasons why using anycast to discover DNS
        servers is not compelling, mainly because it requires explicit
        configuration of routing tables to direct those anycast packets to the
        desired DNS server. However, DNS server discovery is very different to
        NAT gateway discovery. A DNS server is something a client explicitly
        talks to, via IP address. The DNS server may be literally anywhere on
        the Internet. Various reasons make anycast an uncompelling technique for
        DNS server discovery: <list style="symbols">
            <t>DNS is a pure application-layer protocol, running over UDP.</t>
   
            <t>On an operating system without appropriate support for
            configuring anycast addresses, a DNS server would have to use
            something like Berkeley Packet Filter (BPF) to snoop on received
            packets to intercept DNS requests, which is inelegant and
            inefficient.</t>
   
            <t>Without appropriate routing changes elsewhere in the network,
            there's no reason to assume that packets sent to that anycast
            address would even make it to the desired DNS server machine. This
            places an addition configuration burden on the network
            administrators, to install appropriate routing table entries to
            direct packets to the desired DNS server machine.</t>
          </list></t>
   
        <t>In contrast, a NAT gateway is something a client's packets stumble
        across as they try to leave the local network and head out onto the
        public Internet. The NAT gateway has to be on the path those packets
        naturally take or it can't perform its NAT functions. As a result, the
        objections to using anycast for DNS server discovery do not apply to
        PCP: <list style="symbols">
            <t>No routing changes are needed (or desired) elsewhere in the local
            network, because the whole *point* of using anycast is that we want
            the client's PCP request packet to take the same forwarding path
            through the network as a TCP SYN to any other remote destination
            address, because we want the *same* NAT gateway that would have made
            a mapping in response to receiving an outbound TCP SYN packet from
            the client to be the the one that makes a mapping in response to
            receiving a PCP request packet from the client.</t>
   
            <t>A NAT engine is already snooping on (and rewriting) every packet
            it forwards. As part of that snooping it could trivially look for
            packets addressed to the PCP UDP port and process them locally (just
            like the local processing it already does when it sees an outbound
            TCP SYN packet).</t>
          </list></t>
      </section>
    </section>

  </back>
</rfc>