Internet Engineering Task Force G. Chen Internet-Draft H. Deng Intended status: Informational China Mobile Expires: April 19, 2011 October 16, 2010 Link-Local Multicast Name Resolution (LLMNR) Deployment Consideration for PCP Server Discovery draft-chen-pcp-discovery-llmnr-00 Abstract The memo has recommended to deploy Link-Local Multicast Name Resolution (LLMNR) in PCP scenarios. Depending on that, it could not only avoid adherence to DNS during PCP server name resolving, but also company with PCP FQDN DHCP options extension to accomplish PCP server discovery. In order to fit LLMNR into PCP network, particular LLMNR deployment guides 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 April 19, 2011. Copyright Notice Copyright (c) 2010 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 Chen & Deng Expires April 19, 2011 [Page 1] Internet-Draft discovery-llmnr October 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. LLMNR Feasibility Analysis . . . . . . . . . . . . . . . . . . 3 3. LLMNR Deployment Consideration . . . . . . . . . . . . . . . . 4 3.1. LLMNR Deployment Framework . . . . . . . . . . . . . . . . 4 3.2. LLMNR Usage Model . . . . . . . . . . . . . . . . . . . . . 4 3.3. DHCP Consideration . . . . . . . . . . . . . . . . . . . . 5 3.4. Namespace Configuratin Consideration . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Chen & Deng Expires April 19, 2011 [Page 2] Internet-Draft discovery-llmnr October 2010 1. Introduction Pinhole Control Protocol (PCP)[PCP] has proposed a mechanism to control how incoming packets are forwarded by upstream NAT devices. Therein, PCP server discovery is targeted 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, draft-bpw-pcp-dhcp-00 [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 choose either of them for their convenience. This memo takes Link-Local Multicast Name Resolution (LLMNR) into account as candidate 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 considered sufficient to enable PCP discovery, where there are the PCP functionalities integrated with Chen & Deng Expires April 19, 2011 [Page 3] Internet-Draft discovery-llmnr October 2010 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 adherence to DNS considering several flexibilities issues. LLMNR could increase the searching efficiency of PCP server. The response for PCP discovery request could be transmitted to the originator locally, otherwise 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 deployment process. This section will go into relevant details. 3.1. LLMNR Deployment Framework LLMNR is recommended as secondary 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 & Deng Expires April 19, 2011 [Page 4] Internet-Draft discovery-llmnr October 2010 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 extension, 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 scenarios. 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 extension 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 Configuration 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 & Deng Expires April 19, 2011 [Page 5] Internet-Draft discovery-llmnr October 2010 6. Normative References [LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", April 2002. [PCP] Wing, D., "Pinhole Control Protocol (PCP)", draft-wing-softwire-port-control-protocol-02.txt (work in progress), July 2010. [PCP DHCP Options] Boucadair, M., "DHCP and DHCPv6 Options for Port Control Protocol (PCP)", draft-bpw-pcp-dhcp-00 (work in progress), October 2010. [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 Chen & Deng Expires April 19, 2011 [Page 6]