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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2013-02-11
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
ALTO                                                           S. Kiesel
Internet-Draft                                                 K. Krause
Intended status: Experimental                    University of Stuttgart
Expires: August 15, 2013                                  M. Stiemerling
                                                         NEC Europe Ltd.
                                                       February 11, 2013

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

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.

   This algorithm takes a resource consumer's IP address as argument,
   performs several DNS lookups (for PTR, SOA, and U-NAPTR 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.

   Starting with draft-kist-alto-3pdisc-02 the algorithm has
   significantly changed compared to previous versions of this document,
   including draft-kiesel-alto-3pdisc-* and
   draft-ietf-alto-server-discovery-*.  The new algorithm does not try
   "DNS tree climbing" and it does not neccessarily rely on PTR records,
   i.e., it can also produce results if no PTR records are populated in
   the DNS, for example when IPv6 privacy exensions are in use.

Kiesel, et al.           Expires August 15, 2013                [Page 1]
Internet-Draft      Third-Party ALTO Server Discovery      February 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 August 15, 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 August 15, 2013                [Page 2]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Third-Party ALTO Server Discovery Procedure Overview . . . . .  5
     2.1.  Variant 1  . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Variant 2  . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Third-party ALTO Server Discovery Procedure Specification  . .  8
   4.  Deployment Considerations and Operational Considerations . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Contributors List and Acknowledgments . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Kiesel, et al.           Expires August 15, 2013                [Page 3]
Internet-Draft      Third-Party ALTO Server Discovery      February 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 resouce 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.  For that matter, an ALTO client embedded in a ressouce
   consumer would have to figure out its own "public" IP address (e.g.,
   using STUN [RFC5389]), and then perform the procedures described in
   this document.  However, note that a less flexible 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
   funcional 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 August 15, 2013                [Page 4]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

2.  Third-Party ALTO Server Discovery Procedure Overview

   There are currently two different algorithms for ALTO third-party
   server discovery, which only differ slightly in respect to handling
   of the MNAME.  The following two figures give an overview on these
   algorithms.  For a detailed specification of the U-NAPTR lookups, see
   Step 2 in [I-D.ietf-alto-server-discovery].

   NOTE: only one of these algorithms will eventually be specified as
   the official ALTO thirt-party discovery algorithm.  An analysis of
   their advantages and drawbacks, respecively, and a decision is for
   further study.

Kiesel, et al.           Expires August 15, 2013                [Page 5]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

2.1.  Variant 1

             IPv4 address                            IPv6 address
                   |                                       |
                   V                                       V
         Rev=d.c.b.a.in-addr.arpa.            Rev=f.e ... 1.0.ip6.arpa.
                               |               |
                               \-------+-------/
                                       V
                           PTR query on Rev,
                           answer is called Ans-PTR
            one or more PTR(s) |               | NXDOMAIN or
              found in Ans-PTR |               | other error
                               V               |
                  NAPTR lookup(s)              |
                  on these PTR(s)              |
       one or more |           | NXDOMAIN or   |
    usable results |           | other error   |
                   |           |               |
                   |           \-------+-------/
                   |                   V
                   |  Auth.Section with SOA present in Ans-PTR?
                   |       Yes |               | No
                   |           |               V
                   |           |     Explicit SOA query on Rev
                   |           |    OK |                   | Error
                   |           \-------+                   |
                   |                   V                   |
                   |  NAPTR lookup on MNAME (Responsible   |
                   |  Name Server) extracted from SOA      |
                   |        OK |               | NXDOMAIN  |
                   |           |               | or other  |
                   |           |               | error     |
                   +-----------/               \-----------+
                   V                                       V
    One or more URIs as ALTO third                   Algorithm failed,
    party server discovery result                    no result yielded

    Note: for a detailed specification of the NAPTR lookups see
    Step 2 (Section 3.2) of draft-ietf-alto-server-discovery-07.txt

Kiesel, et al.           Expires August 15, 2013                [Page 6]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

2.2.  Variant 2

             IPv4 address                            IPv6 address
                   |                                       |
                   V                                       V
         Rev=d.c.b.a.in-addr.arpa.            Rev=f.e ... 1.0.ip6.arpa.
                               |               |
                               \-------+-------/
                                       V
                           PTR query on Rev,
                           answer is called Ans-PTR
            one or more PTR(s) |               | NXDOMAIN or
              found in Ans-PTR |               | other error
                               V               |
                  NAPTR lookup(s)              |
                  on these PTR(s)              |
       one or more |           | NXDOMAIN or   |
    usable results |           | other error   |
                   |           |               |
                   |           \-------+-------/
                   |                   V
                   |  Auth.Section with SOA present in Ans-PTR?
                   |       Yes |               | No
                   |           |               V
                   |           |     Explicit SOA query on Rev
                   |           |    OK |                   | Error
                   |           \-------+                   |
                   |                   V                   |
                   |  Take MNAME (Responsible Name Server) |
                   |  from SOA, remove first component     |
                   |  up to and including first dot        |
                   |                   |                   |
                   |                   V                   |
                   |    NAPTR lookup on shortened MNAME    |
                   |        OK |               | NXDOMAIN  |
                   |           |               | or other  |
                   |           |               | error     |
                   +-----------/               \-----------+
                   V                                       V
    One or more URIs as ALTO third                   Algorithm failed,
    party server discovery result                    no result yielded

Kiesel, et al.           Expires August 15, 2013                [Page 7]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

3.  Third-party ALTO Server Discovery Procedure Specification

   TBD.

   The third-party ALTO server discovery procedure is performed in two
   steps:

   1.  A DNS domain name is yieleded, by means of a DNS PTR lookup on
       the resouce consumer's IP address (or the "public" IP address of
       the outermost NAT in front of the resource consumer).  This IP
       address is the source address of application protocol messages
       arriving at the resource directory.  If no PTR can be found, a
       SOA lookup is performed instead, and the MNAME (Responsible Name
       Server) entry is extracted from it.

       The two proposed algorithms differ slightly: Variant 2 chops off
       the first compinent from the MNAME, i.e., nameserver.domain.tld
       becomes domain.tld before the U-NAPTR lookup is performed.

   2.  This DNS domain name is used for an U-NAPTR lookup yielding the
       URI.  Further DNS lookups may be neccessary to determine the ALTO
       server's IP address(es).

   Note: Step 2 is identical to Step 2 specified in
   [I-D.ietf-alto-server-discovery], which already specifies two
   alternatives for its Step 1.  Therefore, it is possible to merge both
   documents to one specification with three alternatives for Step 1 and
   a common Step 2.

Kiesel, et al.           Expires August 15, 2013                [Page 8]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

4.  Deployment Considerations and Operational Considerations

   Individual PTR records per IP address 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.  If
   an operator considers this procedure too cumbersome, or if IPv6
   privacy extensions is to be used without dynamic DNS updates, setting
   up SOA records in the in-addr.arpa. or ip6.arpa. subdomains plus
   setting up corresponding ALTO U-NAPTR records will also give
   reasonable, yet less fine-grained results.

   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)
   and/or redirect the client to another ALTO server using mechanisms of
   the ALTO protocol (see Sect. 6.7 of [I-D.ietf-alto-protocol]).

   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 may do redirections if desired or required by
   policies.

Kiesel, et al.           Expires August 15, 2013                [Page 9]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

5.  Security Considerations

   TBD.  See also [I-D.ietf-alto-server-discovery].

Kiesel, et al.           Expires August 15, 2013               [Page 10]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

6.  IANA Considerations

   None.

Kiesel, et al.           Expires August 15, 2013               [Page 11]
Internet-Draft      Third-Party ALTO Server Discovery      February 2013

7.  References

7.1.  Normative References

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

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

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

   [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 August 15, 2013               [Page 12]
Internet-Draft      Third-Party ALTO Server Discovery      February 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 August 15, 2013               [Page 13]
Internet-Draft      Third-Party ALTO Server Discovery      February 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 August 15, 2013               [Page 14]