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]
