Internet DRAFT - draft-chen-pcp-discovery-llmnr

draft-chen-pcp-discovery-llmnr






Internet Engineering Task Force                                  G. Chen
Internet-Draft                                                   H. Deng
Intended status: Informational                                  J. Zhang
Expires: May 3, 2012                                        China Mobile
                                                        October 31, 2011


 Link-Local Multicast Name Resolution (LLMNR) Deployment Consideration
                        for PCP Server Discovery
                   draft-chen-pcp-discovery-llmnr-01

Abstract

   The memo has recommended to deploy Link-Local Multicast Name
   Resolution (LLMNR) in PCP scenarioes.  Depending on that, it could
   not only avoid adherence to DNS during PCP server name resolving, but
   also company with PCP FQDN DHCP options extention to accomplish PCP
   server discovery.  In order to fit LLMNR into PCP network, particular
   LLMNR deployment guide and relevant configurations are considerated
   along with PCP elements installation.

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 May 3, 2012.

Copyright Notice

   Copyright (c) 2011 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



Chen, et al.               Expires May 3, 2012                  [Page 1]

Internet-Draft               discovery-llmnr                October 2011


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



































Chen, et al.               Expires May 3, 2012                  [Page 2]

Internet-Draft               discovery-llmnr                October 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  LLMNR Feasibility Analysis  . . . . . . . . . . . . . . . . . . 4
   3.  LLMNR Deployment Consideration  . . . . . . . . . . . . . . . . 5
     3.1.  LLMNR Deployment Framework  . . . . . . . . . . . . . . . . 5
     3.2.  LLMNR Usage Model . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  DHCP Consideration  . . . . . . . . . . . . . . . . . . . . 6
     3.4.  Namespace Configuratin Consideration  . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7






































Chen, et al.               Expires May 3, 2012                  [Page 3]

Internet-Draft               discovery-llmnr                October 2011


1.  Introduction

   Pinhole Control Protocol (PCP)[PCP] has proposed amechanism to
   control how incoming packets are forwarded by upstream NAT devices.
   Therein, PCP server discovery is trageted to be resolved.  It
   recommended two approaches.  One is DHCP based solution.  Another is
   to assign a fixed IPv4 and a fixed IPv6 to locate PCP server.  To
   meet demands, PCP DHCP Options is trying to extend the DHCP as one of
   the mechanisms to discover a PCP Server.  For flexibility reasons,
   this document defines both IP address and FQDN Options.  Service
   provider could chooce either of them for their convenience.  This
   memo takes Link-Local Multicast Name Resolution (LLMNR) into account
   as condidate solution to discovery PCP server.  Alternatively, it
   could be complemented DHCP FQDN option to achieve the goal of
   discovering PCP server.

   In the draft-wing-softwire-port-control-protocol-02, several
   mechanisms for discovering the PCP Server were analyzed.  NAPTR is as
   candidate to be noted as where there would be a hurdle for updating
   the zone configuration.  Especially, any change of the engineering
   policies occurred, like introducing new CGN device, load-based
   dimensioning.  Such flexibility issues make adherence to DNS is not
   encouraged.  And, more flexibility means are expected to be promoted.
   LLMNR[RFC4795] could be taken as an advantageous part to improve such
   flexibility.

   The document is structured as follows.  Section 2 analyzes the
   applicability of LLMNR in PCP circumstance.  Section 3 elaborates the
   overall LLMNR deployment consideration and relevant LLMNR
   configurations, including LLMNR usage, namespace configuration and
   conflict resolution.  Section 5 is further securities consideration.


2.  LLMNR Feasibility Analysis

   In order to allow PCP applications to learn their external IP
   address, PCP server should be able to interact with controlled NAT
   located on the packet egress path.  This element might be the same as
   the device embedding the controlled NAT.  Thereby, the position of
   PCP server might locate on the local link with PCP client.  This
   deployment features would perfectly match region of LLMNR
   operation.In addition, LLMNR is desirable to consider expand multi-
   cast scope beyond link-local depending on the specific deployment
   experiences and service demands.  Such scalabilities could allow
   LLMNR fit into PCP deployment scope.

   Propagation of LLMNR packets is considereds sufficient to enable PCP
   discovery, where there are the PCP functionalites integrated with



Chen, et al.               Expires May 3, 2012                  [Page 4]

Internet-Draft               discovery-llmnr                October 2011


   current CP (Customer Premises) router model offered to customers.  In
   that case, more fine-grained changes of the engineering policies
   could be handled by LLMNR better than DNS, since dynamic updates in
   DNS aren't supported widely.

   In draft-bpw-pcp-dhcp-00, DHCPv4/v6 would consider carrying FQDN
   option to locate PCP server, there is obviously a need to consider a
   sort of name resolving service to support.  LLMNR could avoid
   adhenrence to DNS considering several flexibilties issues.

   LLMNR could increase the searching effiency of PCP server.  The
   response for PCP discovery request could be transmitted to the
   originator locally, otherwire it might have to flow through the
   distance network to reach authoritative DNS server.


3.  LLMNR Deployment Consideration

   LLMNR could fit into the PCP network with minimum modifications on
   PCP element.  LLMNR would install on the PC, laptop and co-locate
   with PCP client.  Currently, LLMNR has already implemented in Windows
   operation system.  It could accelerate the depolyement process.  This
   section will go into relevant details.

3.1.  LLMNR Deployment Framework

   LLMNR is recommended as sencondary name resolution mechanism to be
   utilized in some particular situation.  It is not targeting to
   substitute the existing DNS system.  Therefore, both LLMNR and DNS
   would be placed in PCP network.  It is up to Service Providers to
   determine which way to resolve PCP server naming depending on the
   specific network situations.

   In the case of adapting LLMNR, DNS server do not need to restore PCP
   server related RR.  The PCP server discovery will be performed in
   local network, where there are PCP client and server located.

3.2.  LLMNR Usage Model

   LLMNR usage should be customized to make it more suitable for PCP
   situation.  The following statements should be taken into account
   once LLMNR has been deployed in PCP network.

   o  LLMNR operation scope.  RFC4795 originally recommended to send
      LLMNR queries to 224.0.0.252 over IPv4 and FF02:0:0:0:0:0:1:3 over
      IPv6.  However, it encouraged to expand operation scope based on
      accumulated experiences. for the PCP case, it needs to figure out
      the appropriate multicast scope to satisfy PCP accomodation. for



Chen, et al.               Expires May 3, 2012                  [Page 5]

Internet-Draft               discovery-llmnr                October 2011


      the scenarios where multicast is not enabled, LLMNR could use
      unicast queries and responses to perform PCP server discovery. for
      example, it could use sender queries for a PTR RR of a fully
      formed IP address within the "in-addr.arpa" or "ip6.arpa" zones.

   o  LLMNR enabler.  LLMNR is enable on a per-interface basis.  It
      could be configured manually or automatically.  Along with PCP
      DHCP options extention, it might consider adding LLMNR enable
      option to assist DHCP FQDN manner.

   o  LLMNR PCP namespace configuration.  LLMNR responders may self-
      allocate a name within the single-label namespace to represent PCP
      server name.  Since single-label names allow to not be unique,
      Service Provider could self-define the particular name for
      indicating their PCP server.

   o  Conflict detection.  LLMNR defined thorough conflict defense
      procedures to prevent LLMNR response from confusion.  These
      processes should take place in PCP scenarioes.  The further
      consideration need to be identified for resolving specific PCP
      problems.

3.3.  DHCP Consideration

   LLMNR is a peer-to-peer name resolution protocol.  There was LLMNR
   Enable DHCP extention work described in LLMNR Enable [LLMNREnable],
   can be used to explicitly enable or disable use of LLMNR on an
   interface.  The further consideration need to be identified for PCP
   specific cases.

3.4.  Namespace Configuratin Consideration

   LLMNR sender SHOULD send LLMNR queries only for single-label names.
   A specific PCP namespace configuration need to be further identified.


4.  IANA Considerations

   This memo includes no request to IANA.


5.  Security Considerations

   The memo would follow LLMNR security consideration.  The further
   consideration need to be identified for PCP specific cases.






Chen, et al.               Expires May 3, 2012                  [Page 6]

Internet-Draft               discovery-llmnr                October 2011


6.  Normative References

   [LLMNREnable]
              Guttman, E., "DHCP LLMNR Enable Option", April 2002.

   [PCP]      Wing, D., "Pinhole Control Protocol (PCP)",
              draft-ietf-pcp-base-16.txt (work in progress),
              October 2011.

   [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local
              Multicast Name Resolution (LLMNR)", RFC 4795,
              January 2007.


Authors' Addresses

   Gang Chen
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: chengang@chinamobile.com


   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.
   Beijing  100053
   P.R.China

   Phone: +86-13910750201
   Email: denghui02@gmail.com


   Junbin Zhang
   China Mobile
   Jinyuan Building
   Jiangxi
   P.R.China

   Phone:
   Email: zhangjunbin@jx.chinamobile.com







Chen, et al.               Expires May 3, 2012                  [Page 7]