idnits 2.17.1 draft-xia-netlmm-lma-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 29, 2009) is 5476 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MN1' is mentioned on line 94, but not defined == Missing Reference: 'MN2' is mentioned on line 94, but not defined == Missing Reference: 'MN3' is mentioned on line 94, but not defined == Unused Reference: 'RFC3736' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mip6-bootstrapping-integrated-dhc' is defined on line 274, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-17 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Expires: October 31, 2009 Huawei USA 5 April 29, 2009 7 Local Mobile Anchor Discovery Using DHCP 8 draft-xia-netlmm-lma-discovery-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 31, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This draft defines a DHCP-based scheme to enable dynamic discovery of 47 a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. Existing Dynamic 48 Host Configuration Protocol (DHCP) options are used allowing a Mobile 49 Access Gateway (MAG) to request the LMA's IP address, Fully Qualified 50 Domain Name (FQDN), or home network prefix via the DHCP response. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Message Sequence . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. DHCPv6 Relay Agent . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Relay agent configuration . . . . . . . . . . . . . . . . . 5 59 4.2. Transmission of DHCPv6 messages . . . . . . . . . . . . . . 6 60 4.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative references . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 [I-D.giaretta-netlmm-mip-interactions] describes possible scenarios 72 which require an interaction between PMIPv6 and MIPv6. In a similar 73 scenario depicted in Figure 1 , some mobile nodes use Mobile IPv6 to 74 manage their movements while others rely on a network-based mobility 75 solution provided by the network. There is a common mobility anchor 76 that acts as Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA, 77 depending on the type of the node. 79 +---------+ +--------+ 80 |LMA1/HA1 | |LMA2/HA2| 81 +---------+ +--------+ 82 //\\ \\ 83 +----//--\\-------------\\------+ 84 ( // \\ \\ ) 85 ( // \\ \\ ) 86 +-//--------\\-------------\\---+ 87 // \\ \\ 88 // \\ \\ 89 // \\ \\ 90 +----+ +----+ +--------+ 91 |MAG1| |AR2 | |MAG3/AR3| 92 +----+ +----+ +--------+ 93 | | | 94 [MN1] [MN2] [MN3] 96 Figure 1: Hybrid deployment with MIPv6 and PMIPv6 98 Before a MAG or a MN can engage in mobility management signaling with 99 the mobility anchor (LMA or HA), it SHOULD either know the IP address 100 of the mobility anchor via pre-configuration, or dynamically discover 101 it. 103 [I-D.ietf-mip6-hiopt] defines DHCPv6 options which are used for 104 acquiring the mobile anchor(HA) information from a DHCPv6 server in 105 MIPv6, while this document describes a procedure that the MAG 106 retrieves the information from the same server using the DHCP options 107 in Proxy MIPv6. 109 We note that LMA discovery can be done by some other means such as 110 AAA. MAG could be provided with LMA address by AAA server during 111 access authentication of the mobile node. LMA can also be discovered 112 by lower layer means such as from the identity of the mobile node. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 The terminology in this document is based on the definitions in 121 [RFC5213]. 123 3. Message Sequence 125 Figure 2 shows the message sequence for dynamic LMA discovery using 126 DHCPv6. The following details apply. 128 +-----+ +------+ +------+ +------+ 129 | | |NAS/ | | | | | 130 | MN/ | |MAG/ | | DHCP | | AAA | 131 |User | |DHCP | |Server| |Server| 132 | | |client| | | | | 133 +-----+ +------+ +------+ +------+ 134 | | | | 135 | 1 | 1 | | 136 |<------------>|<---------------------->| Access Authentication 137 | | | | 138 | | 2 | | 139 | |------------>| | Information Request 140 | | | | 141 | | 3 | | 142 | |<------------| | Information Reply 143 | | | | 145 Figure 2: Dynamic LMA Using DHCP 147 1. The mobile node executes the network access authentication 148 procedure (e.g., IEEE802.1X or IKEv2 SA establishment followed by 149 EAP authentication) and it interacts with the NAS/MAG. The NAS/ 150 MAG interacts with the AAA server to authenticate the mobile 151 node. In the process of authorizing the mobile node, the AAA 152 server verifies in the AAA profile that the mobile node is 153 allowed to use the Proxy Mobile IPv6 service. The AAA server 154 possibly assigns a LMA and returns this information to the NAS 155 through Diameter [I-D.korhonen-dime-pmip6] or RADIUS 156 [I-D.xia-netlmm-radius], thus, it is not necessary to continue 157 with step 2 and 3. Otherwise, the NAS/MAG continues the 158 following DHCP exchanges to inquire the home network information. 159 2. The NAS/MAG as a DHCP client sends a DHCPv6 Information Request 160 message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers 161 multicast address. In this message, the NAS/MAG SHALL include 162 Home Network Identifier Option [I-D.ietf-mip6-hiopt] in the 163 OPTION_ORO, and a Home Network Identifier Option with id-type set 164 to 0. When the Sub-opt-code of the sub-option is set to 1 in the 165 request, the Home Network Parameter field MUST contain an 166 identifier to specify the home network requested by the mobile 167 node. This field MUST be set in the form of a FQDN [RFC1035], 168 encoded as specified in Section 8 of [RFC3315]. If the mobile 169 node has a NAI, the FQDN can be constructed by concatenating a 170 fixed string with the realm part of the NAI. This sub-option in 171 the request SHOULD be copied into the Home Network Information 172 option returned in the reply. The NAS/MAG SHALL also include the 173 OPTION_CLIENTID to identify itself to the DHCP server. The DHCP 174 Unique Identifier(DUID) can be generated based on the mobile 175 node's link layer address or other information. How to create 176 DUID is beyond the scope of this document. 177 3. The DHCP server identifies the client by looking at the DUID for 178 the client in the OPTION_CLIENTID. The DHCP server also 179 determines that the MAG is requesting home network information by 180 looking at the Home Network Identifier Option (id-type 0). The 181 DHCP server retrieves the allocated IP (v6 and v4) address of the 182 HA, i.e. LMA, FQDN of the HA, i.e. LMA, and home network 183 prefix, and includes them in the Home Network Information Option 184 [I-D.ietf-mip6-hiopt] in the Information Reply Message that it 185 sends to the DHCP client. 187 4. DHCPv6 Relay Agent 189 A DHPCv6 relay agent function [RFC3315] SHOULD be used when NAS/MAG 190 and the DHCP server are not connected directly. In this 191 configuration, the relay agent function is co-located in the NAS/MAG 192 with the DHCPv6 client function. Rather than using multicast to send 193 DHCPv6 messages to the DHCPv6 server, the DHCPv6 client in the NAS/ 194 MAG hands any outbound DHCPv6 messages to the co- located relay 195 agent. Responses from the DHCPv6 server are delivered to the relay 196 agent function in the NAS/MAG, which extracts the encapsulated 197 message and delivers it to the DHCPv6 client in the NAS/MAG. 199 4.1. Relay agent configuration 201 The use of the relay agent function in the NAS/MAG allows the NAS/MAG 202 to unicast DHCPv6 messages to the DHCPv6 server. The relay agent 203 must be configured with the address of the DHCPv6 server or another 204 DHCPv6 relay agent that will forward message on to a DHCPv6 server. 206 4.2. Transmission of DHCPv6 messages 208 In this configuration, when the DHCPv6 client in the NAS/MAG sends a 209 message, it hands the message to the DHCPv6 relay agent in the NAS/ 210 MAG. The relay agent encapsulates the message from the client in a 211 Relay-forward message and sends the resulting DHCPv6 message to the 212 DHCP server. The relay agent sets the fields in the Relay-forward 213 message as follows: 215 msg-type RELAY-FORW 216 hop-count 1 217 link-address A non-link-local address from the upstream or loopback 218 interface. 219 peer-address A non-link-local address from the upstream or loopback 220 interface. 221 options MUST include a "Relay Message option" in which OPTION_ORO 222 is included. 224 4.3. Receipt of DHCPv6 messages 226 In this configuration, messages from the DHCPv6 server will be 227 returned to the DHCPv6 relay agent, with the message for the DHCPv6 228 client encapsulated in the Relay Message option [RFC3315] in a Relay- 229 reply message. The relay agent function extracts the message for the 230 client from the Relay Message option and hands the message to the 231 DHCPv6 client in the NAS/MAG. 233 5. Security Considerations 235 This document describes the use of DHCPv6 for LMA discovery in Proxy 236 Mobile IPv6 networks. It does not introduce any additional security 237 concerns beyond those described in the "Security Considerations" 238 section of the DHCPv6 base specification [RFC3315]. 240 6. IANA considerations 242 None. 244 7. Acknowledgements 246 The authors are thankful to Sri Gundavelli for his comments that have 247 led to some improvements in this draft. 249 8. References 251 8.1. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 257 and M. Carney, "Dynamic Host Configuration Protocol for 258 IPv6 (DHCPv6)", RFC 3315, July 2003. 260 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 261 (DHCP) Service for IPv6", RFC 3736, April 2004. 263 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 264 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 266 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 267 in IPv6", RFC 3775, June 2004. 269 [RFC1035] Mockapetris, P., "Domain names - implementation and 270 specification", STD 13, RFC 1035, November 1987. 272 8.2. Informative references 274 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 275 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 276 Integrated Scenario", 277 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 278 progress), April 2008. 280 [I-D.ietf-mip6-hiopt] 281 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 282 Options for Home Information Discovery in MIPv6", 283 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 285 [I-D.xia-netlmm-radius] 286 Xia, F., Sarikaya, B., Korhonen, J., Gundavelli, S., and 287 D. Damic, "RADIUS Support for Proxy Mobile IPv6", 288 draft-xia-netlmm-radius-04 (work in progress), April 2009. 290 [I-D.korhonen-dime-pmip6] 291 Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K., 292 and U. Meyer, "Diameter Proxy Mobile IPv6: Support For 293 Mobile Access Gateway and Local Mobility Anchor to 294 Diameter Server Interaction", draft-korhonen-dime-pmip6-04 295 (work in progress), September 2008. 297 [I-D.giaretta-netlmm-mip-interactions] 298 Giaretta, G., "Interactions between PMIPv6 and MIPv6: 299 scenarios and related issues", 300 draft-giaretta-netlmm-mip-interactions-02 (work in 301 progress), November 2007. 303 Authors' Addresses 305 Frank Xia 306 Huawei USA 307 1700 Alma Dr. Suite 500 308 Plano, TX 75075 310 Phone: +1 972-509-5599 311 Email: xiayangsong@huawei.com 313 Behcet Sarikaya 314 Huawei USA 315 1700 Alma Dr. Suite 500 316 Plano, TX 75075 318 Phone: +1 972-509-5599 319 Email: sarikaya@ieee.org