ALTO                                                           S. Kiesel
Internet-Draft                                                 K. Krause
Intended status: Experimental                    University of Stuttgart
Expires: November 17, 2013                                M. Stiemerling
                                                         NEC Europe Ltd.
                                                            May 16, 2013


               Third-Party ALTO Server Discovery (3pdisc)
                       draft-kist-alto-3pdisc-03

Abstract

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource.  ALTO is realized by a client-server protocol.  Before an
   ALTO client can ask for guidance it needs to discover one or more
   ALTO servers that can provide suitable guidance.

   This document specifies a procedure for third-party ALTO server
   discovery, which can be used if the ALTO client is not co-located
   with the actual resource consumer, but instead embedded in a third
   party such as a peer-to-peer tracker.

   Technically, the algorithm specified in this document takes one
   IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or
   "ALTO:https") as parameters.  It performs several DNS lookups (for
   PTR, SOA, and U-NAPTR resource records) and returns one or more
   URI(s) of information resources related to that IP address.





















Kiesel, et al.          Expires November 17, 2013               [Page 1]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


Terminology and Requirements Language

   This document makes use of the ALTO terminology defined in RFC 5693
   [RFC5693].

   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].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on November 17, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.











Kiesel, et al.          Expires November 17, 2013               [Page 2]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Third-party ALTO Server Discovery Procedure Specification  . .  5
     2.1.  Interface  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Basic Principle  . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Overall Procedure  . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Specification of Tasks and Conditional Branches  . . . . .  7
       2.4.1.  T1/B1: PTR Lookup on IP Address  . . . . . . . . . . .  7
       2.4.2.  T2/B2: U-NAPTR Lookup on yielded PTR value(s)  . . . .  7
       2.4.3.  B3/T3/B4: Acquire SOA Record for Reverse Zone  . . . .  8
       2.4.4.  T4/B5: U-NAPTR Lookup on SOA-MNAME . . . . . . . . . .  9
       2.4.5.  T5: Sort the Results by Order and Preference . . . . .  9
   3.  Implementation, Deployment, and Operational Considerations . . 10
     3.1.  Considerations for ALTO Clients  . . . . . . . . . . . . . 10
       3.1.1.  Resource Consumer Initiated Discovery  . . . . . . . . 10
       3.1.2.  IPv4/v6 Dual Stack, Multihoming, NAT, and Host
               Mobility . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Deployment Considerations for Network Operators  . . . . . 11
       3.2.1.  PTR-based vs. SOA-based discovery  . . . . . . . . . . 11
       3.2.2.  Separation of Interests  . . . . . . . . . . . . . . . 11
     3.3.  Impact on DNS  . . . . . . . . . . . . . . . . . . . . . . 12
       3.3.1.  Usage with DNS Hidden Master Servers . . . . . . . . . 12
       3.3.2.  Load on the DNS  . . . . . . . . . . . . . . . . . . . 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Contributors List and Acknowledgments . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18




















Kiesel, et al.          Expires November 17, 2013               [Page 3]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


1.  Introduction

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource [RFC5693].  ALTO is realized by a client-server protocol;
   see requirement AR-1 in [RFC6708].  Before an ALTO client can ask for
   guidance it needs to discover one or more ALTO servers that can
   provide suitable guidance.  For applications that use a centralized
   resource directory, such as tracker-based P2P applications, the
   efficiency of ALTO is significantly improved if the ALTO client is
   embedded in said resource directory instead of the resource consumer
   (see Section 4.1 of [I-D.ietf-alto-deployments]).  The ALTO client
   embedded into the resource directory asks for guidance on behalf of
   the resource consumers.  To that end, it needs to discover ALTO
   servers that can give guidance suitable for these resource consumers,
   respectively.  This is called third-party party ALTO server
   discovery.

   This document specifies a procedure for third-party ALTO server
   discovery.  In other words, this document tries to meet requirement
   AR-33 in [RFC6708].

   The ALTO protocol specification [I-D.ietf-alto-protocol] is based on
   HTTP and expects the discovery procedure to yield the HTTP(S) URI of
   an ALTO server's information resource directory.  Therefore, this
   document specifies an algorithm that takes a resource consumer's IP
   address as argument, performs several DNS lookups (for PTR, SOA, and
   U-NAPTR [RFC4848] resource records), and produces URIs of ALTO
   servers that are able to give reasonable ALTO guidance to a resource
   consumer willing to communicate using this IP address.

   To some extent, AR-32, i.e., resource consumer initiated ALTO server
   discovery, can be seen as a special case of third-party ALTO server
   discovery.  However, the considerations in Section 3.1.1 apply.  Note
   that a less versatile yet simpler approach for resource consumer
   initiated ALTO server discovery is specified in
   [I-D.ietf-alto-server-discovery].

   A more detailed discussion of various options where to place the
   functional entities comprising the overall ALTO architecture can be
   found in [I-D.ietf-alto-deployments].

   Comments and discussions about this memo should be directed to the
   ALTO working group: alto@ietf.org.






Kiesel, et al.          Expires November 17, 2013               [Page 4]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


2.  Third-party ALTO Server Discovery Procedure Specification

2.1.  Interface

   The algorithm specified in this document takes one IP address and a
   U-NAPTR Service Parameter (i.e., "ALTO:http" or "ALTO:https") as
   parameters.  It performs several DNS lookups (for U-NAPTR and SOA
   resource records) and returns one or more URI(s) of information
   resources related to that IP address.

2.2.  Basic Principle

   The algorithm sequentially tries two different lookup strategies.
   First, a "reverse DNS lookup" (i.e., PTR lookup in subdomains of in-
   addr.arpa. or ip6.arpa., respectively) is is performed on the IP
   address, in order to find the host name(s) associated with it.  An
   ALTO-specific U-NAPTR lookup on this/these name(s) is used to find
   ALTO server URIs.  If either lookup in the first step fails, the SOA
   record for the reverse zone is acquired.  The master name server
   (MNAME) is extracted from the SOA and used for a further ALTO-
   specific U-NAPTR lookup.

   The goal is to allow deployment scenarios that require fine-grained
   discovery on a per-IP basis, as well as large-scale scenarios where
   discovery is to be enabled for a large number of IP addresses with a
   small number of additional DNS resource records.

























Kiesel, et al.          Expires November 17, 2013               [Page 5]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


2.3.  Overall Procedure

   This figure gives an overview on the third-party discovery procedure.
   All tasks (T) and conditional branches (B) are specified below.


                 (-------------------------------------)
                 ( START 3pdisc with parameters        )
                 ( IP address IP, Service Parameter SP )
                 (------------------+------------------)
                                    V
                 +- T1 -------------+------------------+
                 | R:=<IP>.in-addr.arpa./<IP>.ip6.arpa.|
                 | X:=lookup(PTR,R)                    |
                 +------------------+------------------+
                                    V
                       / B1 --------+------------\
                 /----< One or more PTR(s) in X   >----\
                 | yes \-------------------------/ no  |
                 |                                     V
   +- T2 --------|-------------+    /----------------->+
   |             V             |    |                  V
   | /-> FOREACH Y:=PTR in X   |    |     /- B3 -------+------------\
   | |  +--------+-----------+ |    |    < AuthSect with SOA RR in X >
   | |  |lookup(U-NAPTR,Y,SP)| |    |     \--+---------+------------/
   | |  |add results to Z    | |    |    yes |         V no
   | |  +--------+-----------+ |    |        |  +- T3 -+-------------+
   | \-----------+             |    |        |  | X:=lookup(SOA,R)   |
   +-------------|-------------+    |        |  +------+-------------+
                 V                  |        |         V
    /- B2 -------+------------\     |        |   /- B4 +------------\ no
   < One or more results in Z  >----/        |  <Lookup OK, SOA in X >-\
    \------------+------------/ no           |   \-----+------------/  |
                 |                           \-------->V yes           |
                 | yes                   +- T4 --------+-------------+ |
                 |                       | Y:=extract MNAME from X   | |
                 V                       | Z:=lookup(U-NAPTR,Y,SP)   | |
                 +<-----------------\    +-------------+-------------+ |
                 V                  |                  V               |
   +- T5 --------+-------------+    |     /- B5 -------+------------\  |
   | sort Z acc. to order,pref |    \----< One or more results in Z  > |
   +-------------+-------------+      yes \------------+------------/  |
                 V                                  no V<--------------/
   (-------------+-------------)         (-------------+-------------)
   ( END 3pdisc with result Z  )         ( 3pdisc FAILED, no result  )
   (---------------------------)         (---------------------------)





Kiesel, et al.          Expires November 17, 2013               [Page 6]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


2.4.  Specification of Tasks and Conditional Branches

2.4.1.  T1/B1: PTR Lookup on IP Address

   Task T1 performs a PTR lookup in order to get the host name(s)
   associated with the IP address that was given as a parameter to the
   3pdisc algorithm.

   To that end, a domain name is prepared for the PTR lookup and stored
   in variable "R" for later re-use, too.  For IPv4, this domain name is
   rooted in the in the special domain "IN-ADDR.ARPA."  [RFC1035] and
   for IPv6 the special domain "IP6.ARPA."  [RFC3596] is used.  The
   yielded PTR records are stored in variable "X".

   Example PTR records for IPv4 and IPv6 could be (Note: a line break
   was added in the IPv6 example):

   3.100.51.198.in-addr.arpa.  IN PTR dsl-198-51-100-3.isp.example.net.

   0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.
   2.ip6.arpa.  IN PTR  somehost.isp.example.net.



   Note that more than one PTR record could be found for a given IP
   address.

   Conditional Branch B1 checks whether at least one PTR record could be
   retrieved.  If so, the algorithm continues with T2.  If no PTR record
   could be retrieved we continue with B3.

2.4.2.  T2/B2: U-NAPTR Lookup on yielded PTR value(s)

   Task T2 uses a loop to iterate over all names in X and do a U-NAPTR
   [RFC4848] lookup.  For every name yielded in the previous task, the
   procedure uses a U-NAPTR lookup with the "ALTO" Application Service
   Tag and either the "http" or the "https" Application Protocol Tag to
   obtain one or more URIs (indicating protocol, host and possibly path
   elements) for the ALTO server's Information Resource Directory.  In
   this document, only the HTTP and HTTPS URI schemes are defined, as
   the ALTO protocol specification defines the access over both
   protocols, but no other [I-D.ietf-alto-protocol].  Note that the
   result can be any valid HTTP(S) URI.  The yielded NAPTR records are
   stored in array variable "Z".

   The following two U-NAPTR resource records can be used for mapping
   "somehost.isp.example.net." to the HTTPS URI
   https://altoserver.isp.example.net/secure/directory or the HTTP URI



Kiesel, et al.          Expires November 17, 2013               [Page 7]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


   http://altoserver.isp.example.net/directory, with the former being
   preferred.

   somehost.isp.example.net.

   IN NAPTR 100  10   "u"    "ALTO:https"
        "!.*!https://altoserver.isp.example.net/secure/directory!"  ""

   IN NAPTR 200  10   "u"    "ALTO:http"
        "!.*!http://altoserver.isp.example.net/directory!"  ""

   The response to a PTR query in Task T1 could contain multiple names,
   each causing a subsequent DNS lookup in this task.  To prevent heavy
   DNS loads, discovery clients performing these queries MUST be
   implemented such that the number of DNS queries issued (i.e., loop
   cycles) is finite, though it MAY be configurable by an administrator.
   As an example, Section 5.5 of [RFC4408] chose a limit of 10 for its
   implementation of a similar algorithm.

   Conditional Branch B2 checks whether at least one NAPTR record could
   be retrieved.  If so, the algorithm continues with T5.  If no NAPTR
   record could be retrieved we continue with B3.

   Note: The U-NAPTR lookup in Task T2 is identical to Step 2 specified
   in [I-D.ietf-alto-server-discovery], which specifies with "manual
   input" and "DHCP" two alternatives for acquiring the name to be
   looked up.  Therefore, it is possible to merge both documents into a
   common ALTO server discovery framework.

2.4.3.  B3/T3/B4: Acquire SOA Record for Reverse Zone

   The task of B3/T3/B4 is to acquire the SOA record for the "reverse
   zone", i.e., the zone in the in-addr.arpa. or ip6.arpa. domain that
   contains the IP address in question.

   A sample SOA record could be:

   100.51.198.in-addr.arpa
   IN  SOA dns1.isp.example.net.   hostmaster.isp.example.net. (
                                 1         ; Serial
                            604800         ; Refresh
                             86400         ; Retry
                           2419200         ; Expire
                            604800 )       ; Negative Cache TTL

   Conditional Branch B3 checks whether the SOA record was present in
   the authority section of X, i.e., the reply in Task T1.  If not, an
   explicit lookup is done in Task T3.  If Conditional Branch B4



Kiesel, et al.          Expires November 17, 2013               [Page 8]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


   determines that this explicit lookup failed, the discovery procedure
   is aborted without a result; otherwise we continue with T4.

2.4.4.  T4/B5: U-NAPTR Lookup on SOA-MNAME

   Now that the SOA record is available, Task T4 first extracts the
   MNAME field, i.e., the responsible master name server from the SOA
   record.  An example MNAME could be:

       dns1.isp.example.net.

   Then, a U-NAPTR lookup as the one in Task T2 is performed on this
   MNAME and the result is stored in array variable "Z".

   If Conditional Branch B4 determines that this explicit lookup failed,
   the discovery procedure is aborted without a result; otherwise we
   continue with T5.

2.4.5.  T5: Sort the Results by Order and Preference

   Task T5 sorts the NAPTR records that have been retrieved and stored
   in array variable "Z" according to their order and preference fields,
   see [RFC4848] and [RFC3403].  This sorted array is the final result
   of the third-party discovery procedure.



























Kiesel, et al.          Expires November 17, 2013               [Page 9]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


3.  Implementation, Deployment, and Operational Considerations

3.1.  Considerations for ALTO Clients

3.1.1.  Resource Consumer Initiated Discovery

   To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource
   consumer initiated ALTO server discovery, can be seen as a special
   case of third-party ALTO server discovery.  To that end, an ALTO
   client embedded in a ressouce consumer would have to figure out its
   own "public" IP address and perform the procedures described in this
   document on that address.  However, due to the widespread deployment
   of Network Address Translators (NAT), additional protocols and
   mechanisms such as STUN [RFC5389] would be needed and considerations
   for UNSAF [RFC3424] apply.  Therefore, using the procedures specified
   in this document for resource consumer based ALTO server discovery is
   generally NOT RECOMMENDED.  Note that a less versatile yet simpler
   approach for resource consumer initiated ALTO server discovery is
   specified in [I-D.ietf-alto-server-discovery].

3.1.2.  IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility

   The algortihm specified in this document can discover ALTO server
   URIs for a given IP address.  The intention is, that a third party
   (e.g., a resource directory) that receives query messages from a
   resource consumer can use the source address in these messages to
   discover suitable ALTO servers for this specific resource consumer.

   However, resource consumers (as defined in Section 2 of [RFC5693])
   may reside on hosts with more than one IP address, e.g., due to
   IPv4/v6 dual stack operation and/or multihoming.  IP packets sent
   with different source addresses may be subject to different routing
   policies and path costs.  In some deployment scenarios, it may even
   be required to ask different sets of ALTO servers for guidance.
   Furthermore, source addresses in IP packets may be modified en-route
   by Network Address Translators (NAT).

   If a resource consumer queries a resource directory for candidate
   resource providers, the locally selected (and possibly en-route
   translated) source address of the query message - as observed by the
   resource directory - will become the basis for the ALTO server
   discovery and the subsequent optimization of the resource directory's
   reply.  If, however, the resource consumer then selects different
   source addresses to contact returned resource providers, the desired
   better-than-random "ALTO effect" may not occur.

   Therefore, a dual stack or multihomed resource consumer SHOULD either
   always use the same address for contacting the resource directory and



Kiesel, et al.          Expires November 17, 2013              [Page 10]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


   the resource providers, i.e., overriding the operating system's
   automatic source IP address selection, or use resource consumer based
   ALTO server discovery [I-D.ietf-alto-server-discovery] to discover
   suitable ALTO servers for every local address and then locally
   perform ALTO-influenced resource consumer selection and source
   address selection.  Similarly, resource consumers on mobile hosts
   SHOULD query the resource directory again after a change of IP
   address, in order to get a list of candidate resource providers that
   is optimized for the new IP address.

3.2.  Deployment Considerations for Network Operators

3.2.1.  PTR-based vs. SOA-based discovery

   As already outlined in Section 2.2, the third-party discovery
   procedure sequentially tries two different lookup strategies, thus
   giving network operators the choice of two different deployment
   options:

   o  Individual PTR records in the in-addr.arpa or ip6.arpa domains and
      corresponding individual ALTO U-NAPTR records for these names
      allow very fine-grained discovery of ALTO "entry point" URIs on a
      per-IP-address basis.  DNS operators that already maintain reverse
      zones (e.g., for PTR records) should prefer this option, possibly
      using DNS server implementation-specific methods for mass
      deployment (e.g., BIND9's $GENERATE statement).

   o  If a DNS operator considers the first option too cumbersome, or if
      IPv6 privacy extensions is to be used without dynamic PTR updates,
      setting up SOA records in the in-addr.arpa. or ip6.arpa.
      subdomains plus setting up corresponding ALTO-specific U-NAPTR
      records will also give reasonable, yet less fine-grained results.

3.2.2.  Separation of Interests

   We assume that if two organizations share parts of their DNS
   infrastructure, i.e., have a common SOA record in their in-addr.arpa.
   or ip6.arpa. subdomain(s), they will also be able to operate a common
   ALTO server, which still may do redirections if desired or required
   by policies.

   Note that the ALTO server discovery procedure is supposed to produce
   only a first URI of an ALTO server that can give reasonable guidance
   to the client.  An ALTO server can still return different results
   based on the client's address (or other identifying properties) or
   redirect the client to another ALTO server using mechanisms of the
   ALTO protocol (see Sect. 6.7 of [I-D.ietf-alto-protocol]).




Kiesel, et al.          Expires November 17, 2013              [Page 11]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


3.3.  Impact on DNS

3.3.1.  Usage with DNS Hidden Master Servers

   In some deployment scenarios, the Master DNS server for a in-
   addr.arpa. or ip6.arpa. subdomain, as indicated in the respective SOA
   record, may not be reachable due to traffic restrictions ("hidden
   master").  This does not cause any problems with the algorithm
   described here, as the MNAME is only used for further DNS lookups;
   but it is never attempted to contact this server directly.

3.3.2.  Load on the DNS

   The procedure described in this document features only one loop that
   contains a DNS lookup (within task T2).  This loop iterates over the
   PTR records yielded in task T1, which are associated with the input
   IP addres.  In the worst-case scenario the total number of DNS
   lookups is 3+N, with N the number of PTR records, usually 0 or 1.
   DNS operators should avoid adding excessive numbers of PTR records
   for one IP address to the DNS, as this could - amongst other risks -
   increase the load on the DNS caused by this procedure.






























Kiesel, et al.          Expires November 17, 2013              [Page 12]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


4.  Security Considerations

   A classification of the main security concerns related to ALTO can be
   found in the ALTO requirements document [RFC6708].

   Using the procedure described in this document, any third party can
   discover a set of ALTO servers that can give ALTO guidance to a given
   IP address.  However, this is generally not considered a security or
   privacy concern.

   Forged DNS replies (e.g., due to a compromised name server or due to
   DNS message interception and modification) may cause the discovery
   algorithm to fail or produce undesirable results:

      First, the third-party discovery procedure might not be able to
      discover an ALTO server, even if a suitable ALTO server exists.
      In that case, ALTO guidance will not be used.  The resulting
      application performance and traffic distribution will subsequently
      correspond to a deployment scenario without ALTO guidance.

      Second, the discovery procedure may discover a sub-optimal or
      wrong ALTO server.  Such an ALTO server may either not be able to
      provide information for a given resource consumer, thus rendering
      the ALTO service useless.  Alternatively, the ALTO server may
      provide suboptimal or forged information.  In the latter case,
      attackers could try to use ALTO to affect the traffic distribution
      or the performance of applications.  Users may then observe
      performance problems, and network operators could detect traffic
      anormalities.  A potential counter-measure is to disable the use
      of the ALTO service if such anormalities are detected.

   The application of DNS security (DNSSEC) [RFC4033] provides a means
   to limit attacks that rely on forging DNS messages.  Security
   considerations specific to U-NAPTR are described in more detail in
   [RFC4848].
















Kiesel, et al.          Expires November 17, 2013              [Page 13]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


5.  IANA Considerations

   This document does not require any IANA action.

   This document specifies an algorithm that uses U-NAPTR lookups
   [RFC4848] with the Application Service Tag "ALTO" and the Application
   Protocol Tags "http" and "https".  These tags have already been
   registered with IANA.  In particular, for the registration of the
   Application Service Tag "ALTO", see [I-D.ietf-alto-server-discovery].










































Kiesel, et al.          Expires November 17, 2013              [Page 14]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


6.  References

6.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, April 2007.

6.2.  Informative References

   [I-D.ietf-alto-deployments]
              Stiemerling, M. and S. Kiesel, "ALTO Deployment
              Considerations", draft-ietf-alto-deployments-03 (work in
              progress), November 2011.

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
              draft-ietf-alto-protocol-13 (work in progress),
              September 2012.

   [I-D.ietf-alto-server-discovery]
              Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
              S. Yongchao, "ALTO Server Discovery",
              draft-ietf-alto-server-discovery-04 (work in progress),
              July 2012.

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.




Kiesel, et al.          Expires November 17, 2013              [Page 15]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


   [RFC4408]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
              for Authorizing Use of Domains in E-Mail, Version 1",
              RFC 4408, April 2006.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.

   [RFC6708]  Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", RFC 6708, September 2012.




































Kiesel, et al.          Expires November 17, 2013              [Page 16]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


Appendix A.  Contributors List and Acknowledgments

   The initial version of this document was co-authored by Marco Tomsu
   <marco.tomsu@alcatel-lucent.com>.

   Hannes Tschofenig provided the initial input to the U-NAPTR solution
   part.  Hannes and Martin Thomson provided excellent feedback and
   input to the server discovery.

   This memo borrows some text from [I-D.ietf-alto-server-discovery], as
   the 3pdisc was historically part of that memo.  Special thanks to
   Michael Scharf and Nico Schwan.

   Martin Stiemerling is partially supported by the CHANGE project
   (http://www.change-project.eu), a research project supported by the
   European Commission under its 7th Framework Program (contract no.
   257422).  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the CHANGE project or the European Commission.































Kiesel, et al.          Expires November 17, 2013              [Page 17]


Internet-Draft      Third-Party ALTO Server Discovery           May 2013


Authors' Addresses

   Sebastian Kiesel
   University of Stuttgart Information Center
   Allmandring 30
   Stuttgart  70550
   Germany

   Email: ietf-alto@skiesel.de
   URI:   http://www.rus.uni-stuttgart.de/nks/


   Kilian Krause
   University of Stuttgart Information Center
   Allmandring 30
   Stuttgart  70550
   Germany

   Email: schreibt@normalerweise.net
   URI:   http://www.rus.uni-stuttgart.de/nks/


   Martin Stiemerling
   NEC Laboratories Europe
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342 113
   Email: martin.stiemerling@neclab.eu
   URI:   http://ietf.stiemerling.org




















Kiesel, et al.          Expires November 17, 2013              [Page 18]