Internet DRAFT - draft-yan-mext-dnsmip
draft-yan-mext-dnsmip
MEXT Working Group Zhiwei Yan
Internet Draft CNNIC
Expires: March 2012 Jong-Hyouk Lee
INRIA
October 24, 2011
DNS update for MIPv6
draft-yan-mext-dnsmip-00.txt
Abstract
In order to update the DNS (Domain Name System)[1] resource records
(RRs) for the node when its name or address changes, the DDNS
(Dynamic DNS) protocol[2] has been standardized as an extension of
basic DNS protocol. Then the security DDNS scheme[3] was proposed to
enhance the security of DDNS. Based on these two protocols, the DNS
update can be used in many scenarios, for example in the DHCP
(Dynamic Host Configuration Protocol)[4] deployed environment.
Based on these specifications, this document defines the extension
in MIPv6 (Mobile IPv6)[5] to achieve DNS update for the named MN
(Mobile Node). Specifically speaking, the FQND Option defined in the
RFC4704[6] is included in the MIPv6 BU (Binding Update) signaling
message. Then the PTR RR or AAAA and PTR RRs may be updated by the
HA (Home Agent) when the HoA (Home Address) or name of MN changes.
Requirements Language
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].
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".
Yan et al. Expires March,2012 [Page 1]
Internet-Draft DNS update for MIPv6 October 2011
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 March, 2012.
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 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.
Table of Contents
1. Introduction ................................................ 2
2. Extensions of MIPv6 ......................................... 3
2.1. Operation of MN......................................... 3
2.2. Operation of HA......................................... 4
3. DNS update .................................................. 4
4. DNS RR TTL .................................................. 4
5. Security Considerations...................................... 4
6. References .................................................. 5
Authors' Addresses ............................................. 5
Acknowledgment ................................................. 5
1. Introduction
Based on DNS, peer entities can find each other through the FQDN-to-
IP address mapping querying. In this way, the communication can be
established from an easily remembered name other than the
meaningless IP address. This is the basic feature of Internet.
In order to support the session connectivity in the mobile Internet,
the MIPv6 protocol was proposed in which two addresses are used to
Yan et al. Expires March,2012 [Page 2]
Internet-Draft DNS update for MIPv6 October 2011
split the identifier and locator of one MN. As the identifier, the
HoA can be registered in the DNS as the AAAA record of the MN. In
this way, the CN (Corresponding Node) can always find it and the DNS
is relatively stable.
However, the related DNS records still must be updated in order to
maintain the MN reachability when its HoA or name changes. As stated
in RFC 6275, when the home network prefix changes, the HA should
notify the new prefix to the MN. In this way, the MN can configure
the new available HoA accordingly. Although the HoA change is not so
frequent compared with the CoA of the MN, it will significantly
increase with the growing number of the mobile internet user in the
near future. In order to guarantee the security and efficiency of
DNS update for the MN, this document extends the basic MIPv6
protocol. In order to make use of the standardized protocols and
minimize the modification of the mature protocols, we only add a
one-bit flag in BU message to notify the HA about the inclusion of
FQDN information, which is carried in the RFC 4704 defined FQDN
Option.
2. Extensions of MIPv6
In order to support the FQDN Option, a one-bit flag named D is added
in mobility header of the BU message as shown in Fig.1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|D| Reserved | ......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.1. Extension of BU message
When the D flag is set to 1, the RFC 4704 defined FQDN Option is
included in the BU message as a new option or mobility header.
Besides, that means the DNS information may be changed and the
related DNS update is needed. When the D flag is set 0, no FQDN
Option is carried and it means the AAAA or PTR records of MN needs
no update.
The processing of FQDN Option conforms to the related specifications
in RFC 4704.
2.1. Operation of MN
For the named MN in foreign network, we recommend that the HoA is
registered in the DNS as a relatively stable identifier. However,
Yan et al. Expires March,2012 [Page 3]
Internet-Draft DNS update for MIPv6 October 2011
once the HoA changes due to MIPv6 administration policy or home
network renumbering, the MN must resend the BU message for the
binding update. In this case, the D flag should be set to 1 and the
FQDN information of MN should be included in the BU message. In
other case, the BU message with D=0 and no FQDN Option is sent for
the traditional binding refreshment or CoA update.
For the named MN in home network, it only owns HoA as the usable
address. When the DNS update is needed in this case, the MN still
sends the BU message to HA carrying D=1 and FQDN Option for
operational consistency. However, the Lifetime filed should be set
to zero and with no CoA information accordingly to manifest that
this BU is not for binding establishment.
2.2. Operation of HA
When the HA receives a BU with D=1, it should extract out the FQDN
Option and process it according to the flags in FQDN Option and
management policy of MIPv6. Otherwise, the HA does nothing if D=0 or
the BU has no D flag.
3. DNS update
The HA operates as the DHCP server for the DNS update as specified
in the subsection 6.1 in RFC 4704.
4. DNS RR TTL
Even the HoA as an identifier is more stable than the CoA, it may be
still dynamic in the mobile environment. Then the MN and HA which
perform the DNS update should attempt to avoid the staling of DNS RRs.
The operation recommendation can be referred to section 7 in RFC 4704.
5. Security Considerations
The Security Dynamic DNS should be supported whatever the DNS update
is executed by HA or MN. Whether the FQDN-to-IP address mapping
should be updated by MN firstly depends on whether the MN has enough
security material for the security DNS update. However, the MIPv6
deployment policy may also require that all the DNS updates be
performed by the HA for the efficiency and security considerations.
Besides, the HA can identify and trust the accessed MN based on the
authentication schemes in MIPv6 (e.g., Diameter or RADIUS), then the
confident DNS update can be executed by the HA or the HA can
authority the FQDN-to-IP address mapping update to the MN.
Yan et al. Expires March,2012 [Page 4]
Internet-Draft DNS update for MIPv6 October 2011
6. References
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE) ", RFC 2136,
April 1997.
[3] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[5] Charles E. Perkins, David B. Johnson and Jari Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
[6] B. Volz, "The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option",
RFC 4704, October 2006.
Authors' Addresses
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Email: yanzhiwei@cnnic.cn
Jong-Hyouk Lee
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France
Email: jong-hyouk.lee@inria.fr
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yan et al. Expires March,2012 [Page 5]
