idnits 2.17.1 draft-zhou-netext-pd-pmip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 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 date (July 11, 2011) is 4670 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: 'RFC 3633' is mentioned on line 327, but not defined ** Obsolete undefined reference: RFC 3633 (Obsoleted by RFC 8415) == Missing Reference: 'RFC 2119' is mentioned on line 96, but not defined == Missing Reference: 'RFC 3775' is mentioned on line 98, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC 3963' is mentioned on line 297, but not defined == Missing Reference: 'RFC 5213' is mentioned on line 195, but not defined == Missing Reference: 'RFC 3753' is mentioned on line 102, but not defined == Missing Reference: 'RFC 3315' is mentioned on line 205, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Unused Reference: 'RFC2119' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 354, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 netext X. Zhou 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track J. Korhonen 5 Expires: January 12, 2012 Nokia Siemens Networks 6 C. Williams 7 Consultant 8 July 11, 2011 10 Prefix Delegation for Proxy Mobile IPv6 11 draft-zhou-netext-pd-pmip-01.txt 13 Abstract 15 This document explains how network mobility and DHCPv6-based Prefix 16 Delegation works with Proxy Mobile IPv6. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 12, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Convention & Terminology . . . . . . . . . . . . . . . . . . . 4 54 3. DHCPv6 Prefix Delegation for PMIPv6 . . . . . . . . . . . . . 5 55 3.1. Assumption . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Network Mobility Service . . . . . . . . . . . . . . . . . 5 57 3.3. Binding association with the delegated prefix . . . . . . 6 58 3.3.1. Mobile Router initiated prefix delegation in PMIPv6 . 6 59 3.3.2. Mobile Router refresh prefix delegation in PMIPv6 . . 7 60 3.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 7 61 3.4.1. Extension to Binding Update List Entry Data 62 Structure . . . . . . . . . . . . . . . . . . . . . . 7 63 3.4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . 8 64 3.4.3. Handover . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 9 66 3.5.1. Extension to Binding Cache Entry Data Structure . . . 9 67 3.5.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . 9 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6. Normative References . . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 DHCPv6 prefix delegation [RFC 3633] (DHCPv6PD) can be used to assign 76 mobile network prefix(es) to a Mobile Router as specified in DHCPv6 77 Prefix Delegation for NEMO [draft-ietf-mext-nemo-pd-07]. However, 78 there is a gap currently for this NEMO support in PMIPv6 79 architecture. If a mobile router (MR) is provided Proxy Mobile IPv6 80 Protocol as its mobility management when connecting the network and 81 use DHCPv6PD to obtain prefix(es) for the nodes in the mobile network 82 behind the MR, currently neither the Mobile Access Gateway (MAG) nor 83 the Local Mobility Anchor (LMA) can be able to identify the packet 84 including delegated prefix(es). When the MR (Requesting Router) uses 85 DHCPv6 PD to obtain the delegated prefix(es), these prefix(es) SHOULD 86 be associated with the PMIPv6 binding. Otherwise the packets 87 addressed to the delegated prefix will be discarded by the MAG or the 88 LMA. This document describes extension to PMIPv6 for supporting 89 prefix delegation. 91 2. Convention & Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC 2119]. 97 All the mobility related terms used in this document are to be 98 interpreted as defined in Mobile IPv6 [RFC 3775], Network Mobility 99 Basic Support protocol [RFC 3963], Proxy Mobile IPv6 specification 100 [RFC 5213], DHCPv6 Prefix Delegation for NEMO 101 [draft-ietf-mext-nemo-pd-07], DHCP Prefix Delegation [RFC3633] and 102 Mobility Related Terminology [RFC 3753]. This document does not 103 define any new terms. 105 3. DHCPv6 Prefix Delegation for PMIPv6 107 3.1. Assumption 109 This specification extends PMIPv6 to assign not only the home network 110 prefix but also the mobile network prefix for supporting network 111 mobility. It assumes that a MR is a regular IPv6 router without 112 extension for mobility managements. The MR sends the packets from 113 its mobile network to the MAG and the MAG delivers the packets to the 114 mobile network via the MR. 116 In order to use DHCPv6PD as mobile network prefix assignment 117 mechanism in mobile networks, this specification has following 118 assumptions. 120 o The Mobile Router MUST play the role of the Requesting Router. 122 o The Delegating Router can be located either at LMA or some other 123 device in the PMIPv6 domain. 125 o The MAG MUST play the role of DHCPv6 Relay Agent to intercept the 126 related DHCPv6 message from the Mobile Router. 128 o The Mobile Router (Requesting Router) MUST obtain the home network 129 prefix before initiating the DHCPv6 prefix delegation procedure. 131 o All the mobile network prefixes managed in the Delegating Router 132 MUST be reachable via local mobility anchor. 134 o The Mobile Router (Requesting Router) SHOULD support Prefix 135 Exclude Option for DHCPv6-based Prefix Delegation as described in 136 [draft-ietf-dhc-pd-exclude]. 138 3.2. Network Mobility Service 140 The network mobility service of a mobile router is managed by the 141 mobile node's policy profile defined in [RFC 5213]. During mobile 142 router initial attachment procedure, the mobile access gateway MUST 143 identify the mobile router and acquire the mobile router!_s policy 144 profile to determine whether the network mobility service is offered 145 to the mobile router. If the network mobility service needs to be 146 offered to the mobile node, the mobile access gateway MUST set the 147 Mobile Router Flag (R) when sending the Proxy Binding Update message 148 to the local mobility anchor. 150 3.3. Binding association with the delegated prefix 152 3.3.1. Mobile Router initiated prefix delegation in PMIPv6 154 +-------------------+ +------------------+ +--------+ +------------+ 155 | Mobile Router | | MAG | | LMA | | Delegating | 156 |(Requesting Router)| |(DHCP Relay Agent)| +--------+ | Router | 157 +-------------------+ +------------------+ | +------------+ 158 | | | | 159 | |---------------------| | 160 | | 1.PMIPv6 tunnel | | 161 | |---------------------| | 162 |--2.DHCPv6 SOLICIT-->| | | 163 | | | | 164 | |--------3.PBU------->| | 165 | | | | 166 | |<-------4.PBA--------| | 167 | | | | 168 | |---------5.DHCPv6 SOLICIT---------->| 169 | |<--------6.DHCPv6 ADVERTISE---------| 170 | | | | 171 |<-7.DHCPv6 ADVERTISE-| | | 172 | | | | 173 |--8.DHCPv6 REQUEST-->| | | 174 | |--9.DHCPv6 REQUEST----------------->| 175 | | | | 176 | |<-----10.DHCPv6 REPLAY--------------| 177 |<--11.DHCPv6 REPLY---| | | 178 | | | | 180 Figure 1: Prefix Delegation in PMIPv6 182 The steps of the procedure in Figure 1 are as following. 184 1. The PMIPv6 tunnel is set up between the MAG and LMA. The MAG 185 plays function of DHCPv6 relay agent between the MN and the DHCPv6 186 server and intercept all the DHCP related messages. 188 2. The mobile router which acts as a "Requesting Router" as 189 described in [RFC 3633] sends DHCPv6 SOLICIT massage including one or 190 more IA_PD option(s) to the MAG to acquire the delegated prefix(es). 192 3. Upon receiving DHCPv6 SOLICIT the MAG sends a Proxy Binding 193 Update message including a Mobile Network Prefix mobility option as 194 defined in Section 4.3 of [RFC 3963] to the LMA. All the 195 considerations from Section 5.3.1 of [RFC 5213] MUST be applied on 196 the encapsulated Proxy Binding Update message. 198 4. On reception of the Proxy Binding Update the LMA returns the 199 assigned prefix in the Mobile Network Prefix option carried by a 200 Proxy Binding Acknowledgment to the MAG. The assigned prefix is the 201 same one which will be assigned via DHCPv6PD in step 6 which MUST be 202 added the delegated prefix(es) in its binding cache which is extended 203 as in Section 3.5.1. 205 5. The DHCPv6 relay agent on the MAG as described in [RFC 3315] 206 relays the DHCPv6 SOLICIT message to the delegation router. NOTE: 207 Step 3 and Step 5 are processed in parallel. 209 6. The delegating router inserts one or more IA_PD option(s) 210 including the delegated prefix(es) and send it to the MAG (DHCPv6 211 relay agent) via the DHCPv6 ADVERTISE message. 213 7. The MAG relays the DHCPv6 ADVERTISE message to the MN. 215 8. The MN sends DHCPv6 REQUEST message with the IA_PD option(s) 216 received from previous message to the MAG (DHCPv6 relay agent). 218 9. The MAG relays the DHCPv6 REQUEST message to the delegating 219 router. 221 10. The delegating router responses the REQUEST to the MAG via 222 DHCPv6 REPLY message. 224 11. The MN receives one or more IA_PD prefix(es) in the DHCPv6 REPLY 225 message from the MAG. 227 3.3.2. Mobile Router refresh prefix delegation in PMIPv6 229 When the mobile router sends DHCPv6 Renew messages to extend the 230 lifetime of the delegated prefix, the messages are also intercepted 231 by the MAG and relayed to the delegating router. If the MAG finds 232 that the lifetime of the delegated prefix which is stored in the 233 IA_PD Prefix Option carried by the DHCPv6 reply message set to zero, 234 the MAG SHOULD triggers a Proxy Binding Update to remove the binding 235 for that mobile network prefix. 237 3.4. Mobile Access Gateway Operation 239 3.4.1. Extension to Binding Update List Entry Data Structure 241 In order to support this specification, the conceptual Binding Cache 242 entry data structure needs to be extended with a new prefix 243 information field as [RFC 3963] does. This prefix information field 244 is used to store the mobile network prefix information which is 245 assigned to the mobile router in the Proxy Binding Acknowledgement 246 during the procedure of Binding association with the delegated prefix 247 in section 3.2. 249 3.4.2. Forwarding 251 Forwarding packets sent to the mobile router!_s mobile network prefix 253 o On receiving a packet from the bi-directional tunnel established 254 with the mobile router!_s local mobility anchor, the mobile access 255 gateway MUST use the destination address of the inner packet to 256 forward it on the interface where the destination mobile network 257 prefix is hosted. 259 Forwarding packets sent by the mobile router 261 o On receiving a packet from a mobile router connected to its access 262 link, the mobile access gateway MUST ensure that there is an 263 established binding for that mobile router with its local mobility 264 anchor before tunneling the packet to the mobile router!_s local 265 mobility anchor. 267 All other considerations from 6.10.5 MUST be applied here also. 269 3.4.3. Handover 271 When the mobile router moves from the previously attached mobile 272 access gateway to the newly attached mobile access gateway, the newly 273 attached mobile access gateway MAY know the mobile network prefix 274 which is assigned during the previous attachment from some network 275 element, e.g. from the previous mobile access gateway. It is out of 276 scope of this specification that how the newly attached mobile access 277 gateway obtains the previously assigned mobile network prefix. After 278 handover to the new mobile access gateway, a Proxy Binding Update 279 message including the assigned mobile network prefix (if available) 280 MUST be sent from the new mobile access gateway to the local mobility 281 anchor. The local mobility anchor MUST check the mobile network 282 prefix in the Proxy Binding Update message and return the same 283 assigned mobile network prefix in the Proxy Binding Acknowledgement 284 message. If the previously assigned mobile network prefix is not 285 available in the new mobile access gateway, the new mobile access 286 gateway MUST contain the mobile network prefix set with 0 in the 287 Proxy Binding Update message. In this case, the local mobility 288 anchor MUST return the same previously assigned mobile network prefix 289 in Proxy Binding Acknowledgement. 291 3.5. Local Mobility Anchor Operation 293 3.5.1. Extension to Binding Cache Entry Data Structure 295 In order to support this specification, the conceptual Binding Cache 296 entry data structure needs to be extended with a new prefix 297 information field as [RFC 3963] does. This prefix information field 298 is used to store the mobile network prefix information which is 299 assigned to the mobile router in the Proxy Binding Acknowledgement 300 during the procedure of Binding association with the delegated prefix 301 in section 3.2. 303 3.5.2. Forwarding 305 Intercepting packets sent to the mobile router!_s mobile network 306 prefix 308 o When the local mobility anchor is serving to the mobile router, it 309 MUST be able to receive packets those are sent to the mobile 310 router!_s mobile network. In order to receive those packets, the 311 mobile access gateway MUST advertise a connected route into the 312 Routing Infrastructure for the mobile router!_s mobile network 313 prefix(es). 315 Forwarding packets to the mobile router 317 o On receiving a packet from a correspondent node with the 318 destination address matching the mobile router!_s mobile network 319 prefix(es) the local mobility anchor MUST forward the packet 320 through the bi-directional tunnel set up for that mobile router. 322 All other considerations from 5.6.2 MUST be applied here also. 324 4. Security Considerations 326 All security considerations from the base Proxy Mobile IPv6 [RFC 327 5213], DHCPv6 Prefix Delegation specification [RFC 3633] apply when 328 using the extensions defined in this document. 330 5. IANA Considerations 332 This document reuses the mobile network prefix option defined in [RFC 333 3963] in Proxy Mobile IPv6 to assign the mobile network prefix via 334 DHCPv6 for prefix delegation. It does not introduce any additional 335 IANA considerations. 337 6. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 343 and M. Carney, "Dynamic Host Configuration Protocol for 344 IPv6 (DHCPv6)", RFC 3315, July 2003. 346 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 347 Host Configuration Protocol (DHCP) version 6", RFC 3633, 348 December 2003. 350 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 351 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 352 RFC 3963, January 2005. 354 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 355 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 357 Authors' Addresses 359 Xingyue Zhou 360 ZTE Corporation 361 No.50 Software Avenue, Yuhuatai District 362 Nanjing 363 China 365 Phone: +86-25-8801-4634 366 Email: zhou.xingyue@zte.com.cn 368 Jouni Korhonen 369 Nokia Siemens Networks 370 Linnoitustie 6 371 Espoo FIN-02600 372 Finland 374 Email: jouni.nospam@gmail.com 376 Carl Williams 377 Consultant 378 San Jose, CA 379 USA 381 Email: carlw@mcsr-labs.org