Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: January 14, 2010 Huawei USA July 13, 2009 Local Mobile Anchor Discovery Using DNS by Service Name draft-sarikaya-netlmm-lma-dnsdiscovery-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Sarikaya & Xia Expires January 14, 2010 [Page 1] Internet-Draft LMA Discovery July 2009 Abstract This draft defines a Domain Name System (DNS)-based scheme to enable dynamic discovery of a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. DNS Service Resource Record option is used allowing a Mobile Access Gateway (MAG) to request the LMA's Fully Qualified Domain Name (FQDN) and possibly IP address via the DNS response. IPv4 case is also covered. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. LMA Discovery by DNS Service Name . . . . . . . . . . . . . . 4 3.1. Transmission of DNS Queries . . . . . . . . . . . . . . . 5 3.2. Receiving Answers to DNS Queries . . . . . . . . . . . . . 5 3.3. Example Processing at MAG . . . . . . . . . . . . . . . . 6 4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Sarikaya & Xia Expires January 14, 2010 [Page 2] Internet-Draft LMA Discovery July 2009 1. Introduction [I-D.giaretta-netlmm-mip-interactions] describes possible scenarios which require an interaction between PMIPv6 and MIPv6. In a similar scenario depicted in Figure 1, some mobile nodes use Mobile IPv6 to manage their movements while others rely on a network-based mobility solution provided by the network. There is a common mobility anchor that acts as Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA, depending on the type of the node. +---------+ +--------+ |LMA1/HA1 | | LMA2 | +---------+ +--------+ //\\ \\ +----//--\\-------------\\------+ ( // \\ \\ ) ( // \\ \\ ) +-//--------\\-------------\\---+ // \\ \\ // \\ \\ // \\ \\ +----+ +----+ +--------+ |MAG1| |AR2 | |MAG3/AR3| +----+ +----+ +--------+ | | | [MN1] [MN2] [MN3] Figure 1: Hybrid deployment with MIPv6 and PMIPv6 Before a MAG or a MN can engage in mobility management signaling with the mobility anchor (LMA or HA), it SHOULD either know the IP address of the mobility anchor via pre-configuration, or dynamically discover it. Proxy Mobile IPv6 can be offered as a service in an operator domain. Domain name system contains mechanisms for the clients (Mobile Access Gateways in lieue of Mobile Nodes) to query the names of the local mobility anchors that provide Proxy Mobile IPv6 service and get back the names. Service resource records (SRV RR) defined in [RFC2782] enable the servers like local mobility anchors to publish information about their services in the DNS database in terms of SRV RRs. Some local mobility anchors may be designated as primary servers and others as backup servers. Sarikaya & Xia Expires January 14, 2010 [Page 3] Internet-Draft LMA Discovery July 2009 2. Terminology 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 [RFC2119]. The terminology in this document is based on the definitions in [RFC5213]. 3. LMA Discovery by DNS Service Name Figure 2 shows the message sequence for dynamic LMA discovery using DNS. The following details apply. +-----+ +------+ +------+ +------+ | | |NAS/ | | | | | | MN/ | |MAG/ | | DNS | | AAA | |User | |DNS | |Server| |Server| | | |client| | | | | +-----+ +------+ +------+ +------+ | | | | | 1 | 1 | | |<------------>|<---------------------->| Access Authentication | | | | | | 2 | | | |------------>| | DNS Query | | | | | | 3 | | | |<------------| | DNS Query Reply | | | | Figure 2: Dynamic LMA Discovery Using DNS The mobile node executes the network access authentication procedure (e.g., IEEE802.1X or IKEv2 SA establishment followed by EAP authentication) and it interacts with the NAS/MAG. The NAS/MAG interacts with the AAA server to authenticate the mobile node. In the process of authorizing the mobile node, the AAA server verifies in the AAA profile that the mobile node is allowed to use the Proxy Mobile IPv6 service. The AAA server possibly assigns a LMA address and returns this information to the NAS through Diameter [I-D.korhonen-dime-pmip6] or RADIUS [I-D.xia-netlmm-radius], thus, it is not necessary to continue with steps 2 and 3. If AAA server returns the fully qualified domain name (FQDN) of LMA to the NAS then Sarikaya & Xia Expires January 14, 2010 [Page 4] Internet-Draft LMA Discovery July 2009 MAG queries the DNS infrastructure in order to resolve the FQDN to the LMA [I-D.korhonen-netlmm-lma-discovery]. Otherwise, the MAG continues the following DNS exchanges to do a DNS lookup by service name. The MAG as DNS client sends a DNS query to retrieve SRV RRs for Proxy Mobile IPv6 service using IPv6 protocol for a specific domain (Step 2 in Figure 2). Once MAG receives in the DNS Query Reply all SRV RRs containing information about multiple local mobility anchors it is up to the MAG to select one local mobility anchor (Step 3 in Figure 2). After selecting the local mobility anchor, MAG proceeds with registering the mobile node with this server as described in [RFC5213]. The format of the SRV RR is: _Service._Proto.Name TTL Class SRV Priority Weight Port Target MAG MUST use the service name "pmip6" and the protocol name "ipv6". The protocol name "ipv4" MAY be used as discussed in Section 4. SRV RR's DNS type code is 33. Name is the domain that this RR refers to. 3.1. Transmission of DNS Queries LMA discovery by DNS service name is based on the clients, e.g. MAGs retrieving the servers', e.g. local mobility anchors service resource records (SRV RRs) from the DNS infrastructure. If SRV RRs are not available in the domain this technique should not be used. In sending the DNS query, MAG MUST extract the domain name from the Mobile Node Identifier (MN-Identifier) [RFC5213] such as Network Access Identifier (NAI) [RFC4282]. If NAI is not available MAG MUST use its own domain name. The resulting QNAME takes the form of "_pmip6_ipv6.example.com". In most cases an SRV RR with QNAME=_pmip6._ipv6.example.com, QCLASS=IN and QTYPE=SRV would be sufficient. 3.2. Receiving Answers to DNS Queries If more than one local mobility anchor are available in the SRV RR mobility access gateway is responsible for selecting one local mobility anchor. The choice could be based on the preference and weight values in SRV RRs received. [RFC2782] presents domain administrator advices the preference and weight values which could be followed. The answer to the DNS query contains one or more fully qualified domain names (FQDN) of one or more local mobility anchors. In that case mobility access gateway MUST resolve the IP addresses in a Sarikaya & Xia Expires January 14, 2010 [Page 5] Internet-Draft LMA Discovery July 2009 separate DNS query. However this is undesirable as it requires an additional DNS query round trip. DNS servers are RECOMMENDED to return IP addresses in AAAA records also in the SRV reply. Caching local mobility anchor addresses in mobility access gateways may also save DNS round trips. If the policy indicates that the mobile nodes in the same domain be served by the same local mobility anchor, mobility access gateway may immediately start registration procedures with that local mobility anchor after the mobile node's access authentication terminates successfully. 3.3. Example Processing at MAG Mobility access gateway makes a DNS SRV RR query for the mobile node whose MN-ID is 123456789. DNS reply contains the following FQDNs: lma-central.example.com lma-east.example.com lma-dfw.example.com lma-nyc.example.com lma-sfbay.example.com lma-west.example.com Assume that the preference and weight values of all SRV RRs are the same. Mobility access gateway MAY choose one randomly based on MN-ID. One such random choice could be made by calculating MN-ID modulus the number of local mobility anchor FDQNs returned. In the case of the above example, this yields: MN-ID mod number of SRV RRs = 123456789 mod 6 = 3 Therefore mobility access gateway assigns lma-dfw.example.com to this MN, makes another DNS query to get this local mobility anchor's address. 4. IPv4 Support Local mobility anchors may have IPv4 addresses called IPv4 Local Mobility Anchor Address (IPv4-LMAA) [I-D.ietf-netlmm-pmip6-ipv4-support]. Mobility access gateways need Sarikaya & Xia Expires January 14, 2010 [Page 6] Internet-Draft LMA Discovery July 2009 to discover IPv4-LMAA in two cases: the mobile node is an IPv4 node or the transport between mobility access gateway and local mobility anchor is IPv4. In [RFC4472] the use of separate service names or the same name for IPv4 and IPv6 users is discussed. [RFC4472] recommends using the same name, e.g. pmip6.example.com to indicate that Proxy Mobile IPv6 service is available to both IPv6 and IPv4 hosts. In this specification we also define "pmip6" service for "ipv4" protocol. Mobile access gateway MUST use QNAME=_pmip6._ipv4.example.com in SRV RR to receive IPv4 address of the local mobility anchors that serve IPv4 hosts or when the transport network is IPv4. DNS servers send replies to SRV RRs with pmip6 service and ipv4 protocol names as described in Section 3.2. If only FQDNs are received then mobility access gateway makes another query to retrieve both A and AAAA address records associated with the local mobility anchors. If address records are also included, DNS servers are RECOMMENDED to return IP addresses in AAAA and A records also in the SRV reply. DNS servers may also send replies to SRV RRs with pmipv6 service for any protocol name (ipv6 or ipv4) with dual-stack local mobility anchor FQDNs. DNS servers may also add AAAA and A address records of such local mobility anchors in the same reply. 5. Security Considerations This document introduces a new service name for LMA discovery in Proxy Mobile IPv6 networks. [RFC2782] requires that security considerations regarding this new service name be included. A host in Proxy Mobile IPv6 network referenced as a server in SRV RRs can be subject to denial of service attacks. In this specification, SRV RRs are used by mobile access gateways and mobile access gateways are considered trustable in the same PMIPv6 domain. Denial of service attacks can be a real issue if the mobile nodes in PMIPv6 domain use SRV RRs to obtain local mobility anchor addresses and then propagate this address to the attackers. This issue is similar to the denial of service attacts on the home agents and considerations presented in [RFC5026] apply here as well. Sarikaya & Xia Expires January 14, 2010 [Page 7] Internet-Draft LMA Discovery July 2009 6. IANA considerations This document defines a new service name called pimp6 available on protocols of ipv6 and ipv4. 7. Acknowledgements The authors are grateful to Julien Laganier for Section 3.3 contents. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13 (work in progress), June 2009. 8.2. Informative references [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Sarikaya & Xia Expires January 14, 2010 [Page 8] Internet-Draft LMA Discovery July 2009 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), April 2008. [I-D.xia-netlmm-radius] Xia, F., Sarikaya, B., Korhonen, J., Gundavelli, S., and D. Damic, "RADIUS Support for Proxy Mobile IPv6", draft-xia-netlmm-radius-04 (work in progress), April 2009. [I-D.korhonen-dime-pmip6] Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K., and U. Meyer, "Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local Mobility Anchor to Diameter Server Interaction", draft-korhonen-dime-pmip6-04 (work in progress), September 2008. [I-D.giaretta-netlmm-mip-interactions] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. [I-D.korhonen-netlmm-lma-discovery] Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy Mobile IPv6", draft-korhonen-netlmm-lma-discovery-01 (work in progress), February 2009. Sarikaya & Xia Expires January 14, 2010 [Page 9] Internet-Draft LMA Discovery July 2009 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Sarikaya & Xia Expires January 14, 2010 [Page 10]