idnits 2.17.1 draft-petrescu-netext-pmip-nemo-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 11, 2012) is 4301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-netext-pd-pmip-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT A. Petrescu 3 Internet-Draft M. Boc 4 Intended status: Informational C. Janneteau 5 Expires: January 12, 2013 CEA 6 July 11, 2012 8 Network Mobility with Proxy Mobile IPv6 9 draft-petrescu-netext-pmip-nemo-01.txt 11 Abstract 13 The Proxy Mobile IPv6 protocol supports Mobile Hosts moving 14 independently, but not Mobile Routers in charge of moving networks. 16 This draft addresses this problem. The goal is to allow 17 bidirectional communication between a Local Fixed Node (in the moving 18 network) and a Correspondent Node (situated arbitrarily somewhere in 19 the Internet). First, a mechanism of "prefix division" is presented, 20 whereby the Home Network Prefix typically assigned by PMIPv6 to a MH 21 is used by MR to form Mobile Network sub-Prefix(es); they are used by 22 LFNs within the moving network to form addresses; this avoids changes 23 in the PMIPv6 protocol specification. A second mechanism proposes 24 enhancements to the use of the DHCPv6 Prefix Delegation protocol 25 entities informing the PMIPv6 entities about the allocated MNP; this 26 is achieved by equaling MNID and DUID. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 12, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Concentrated Description . . . . . . . . . . . . . . . . . . . 4 61 2.1. HNP Division . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. DHCPv6-PD and PMIPv6 Enhancements . . . . . . . . . . . . 7 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 65 5. Normative References . . . . . . . . . . . . . . . . . . . . . 13 66 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 69 1. Requirements notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Concentrated Description 77 The term Mobile Router has several meanings. One of the agreed 78 meanings at IETF, documented in terminology RFCs, is that of an 79 entity implementing the Mobile IPv6 protocol with NEMOv6 extensions, 80 and accomodating changes in its Care-of Address, maintaining a stable 81 Home Address with the help of a Home Agent, and in charge of LFNs in 82 a moving network whose addresses do not change. Another meaning is 83 that of a router which moves around and does not necessarily change 84 its IP address. In the context of this draft we consider this latter 85 meaning. We ignore whether or not the MR runs Mobile IPv6. 87 The work presented in this draft is developped in the context of 88 Proxy Mobile IPv6 [RFC5213]. With respect to prefix division, 89 similar methods have been alluded to in the context of DHCPv6 Prefix 90 Delegation by [I-D.krishnan-intarea-pd-epc] (with a slide 91 presentation in the DHC WG at IETF77) and of OSPFv3 by 92 draft-arkko-homenet-prefix-assignment-01. 94 Mechanisms for supporting Mobile Routers with PMIPv6 and DHCPv6 are 95 presented in [I-D.ietf-netext-pd-pmip] and preceding individual 96 drafts. 98 The methods presented in this draft are different from most if not 99 all existing documented methods to accomodate moving networks with 100 PMIPv6. In particular, the HNP Division offers several MNPs for use 101 by LFNs, does not modify PMIPv6, does not require the use of 102 DHCPv6-PD but has an inconveninent in that it may not accommodate 103 Ethernet LFNs with SLAAC. The DHCPv6-PD and PMIPv6 enhancements 104 offer MNPs potentially completely different than HNP, may use 105 Ethernet LFNs with SLAAC, modify MAG, LMA, DHCP Relay and potentially 106 DHCP Server. 108 Moreover, the PMIPv6 and DHCPv6 enhancements presented in this draft 109 rely on the use of MNID being equal to the DUID, a feature absent 110 from existing proposals. Also, with this mechanism the entity 111 performing the allocation of an MNP is the DHCPv6 Server (and not the 112 LMA). 114 2.1. HNP Division 116 The mechanism "HNP Division" divides the Home Network Prefix into two 117 or more Mobile Network Prefixes (MNPs). 119 It is assumed that in a domain running PMIPv6 the LMA assigns a Home 120 Network Prefix (HNP) to the Mobile Host. If we consider this Mobile 121 Host to be a Mobile Router, in charge of a set of Local Fixed Nodes 122 (LFNs) in a moving network, it is necessary to use a Mobile Network 123 Prefix (MNP) within the moving network. Simply using HNP to form 124 addresses for LFNs, without modifying MR behaviour with respect to 125 its routing table, is not sufficient. 127 The topology illustrated in the next figure depicts a domain where 128 PMIPv6 is run, and a Mobile Router in charge of a set of LFNs forming 129 a moving network. 131 ---- 132 | CN | 133 ---- 134 | 135 Internet 136 | 137 ---- 138 | LMA| 139 ---- 140 | 141 Operator Network 142 / \ 143 / \ 144 ---- ---- 145 |MAG1| |MAG2| 146 ---- ---- 147 | HNP 148 ---- 149 | MR | ---> handover 150 ---- 151 ---- ---- ---- | 152 |LFN2| |LFN3| |LFN5|| 153 ---- ---- ---- |MNP1 or MNP2 154 | | | | 155 -------------------+ 157 For a HNP with prefix length 64, two or more MNPs are generated, each 158 having a prefix length longer than 64. For brevity and without 159 losing generality, we present a detailed division example for a 160 fictitious addressing system whose "IP" addresses are of a maximum 161 length of 5 bits (instead of 128 bits of IPv6). 163 A0 11000/5 164 A2 11010/5 To be used by LFN2 165 A3 11011/5 To be used by LFN3 166 +--------> MNP1 1101/4 167 | 168 | 169 HNP 11000/2 +--------> A1 11001/5 To be used on egress of MR 170 | 171 | 172 +--------> MNP2 111/3 173 A4 11100/5 174 A5 11101/5 To be used by LFN5 175 A6 11110/5 To be used by LFN6 176 A7 11111/5 178 In this example, the HNP/2 11000 is assigned by LMA to MR. The MR 179 divides this into MNP1 1101/4 and MNP2 111/3, and an address A1 180 11001/5. The MNP1 and MNP2 are used to help LFNs within the moving 181 network to configure full /5 addresses. This may be achieved either 182 with DHCPv6 (MR or a DHCPv6 Server send these addresses) or with 183 stateless address auto-configuration (MR or a Router send Router 184 Advertisements containing MNP1 and/or MNP2). 186 In most PMIPv6 implementations for MHs, the MAG contains a routing 187 table entry with respect to the allocated HNP. Depending on the 188 nature of the link between MAG and MR, this entry has two different 189 forms: [HNP, vif, *] in case of point-to-point links (typically used 190 in cellular systems) and [HNP, eth, *] (typically used in WiFi 191 hotspot shared links). The vif is a virtual interface, e.g. "ppp0", 192 whereas eth is a real interface, e.g. "eth0". 194 In the case of point-to-point links, it is not necessary to add any 195 additional behaviour for MR to work (LFN to be reachable from CN). 196 It is sufficient for MR to perform HNP division as described above. 198 On the contrary, in the case of shared links, it is necessary to 199 perform an operation of Neighbor Discovery proxying on the Mobile 200 Router. When MAG receives a packet from CN addressed to LFN, it 201 would solicit the MAC address of LFN on the MAG-MR link (even though 202 LFN is not present on that link). For this reason, the MR must 203 pretend it owns the IP address of LFN and respond to that 204 solicitation with its own MAC address. 206 The HNP division mechanism requires that the MNP be part of the HNP 207 (e.g. MNP must have the leftmost n bits the same as the prefix 208 length of HNP), and its length be longer. In case of an HNP/64 and 209 the use of Ethernet for LFNs, only the DHCPv6 protocol can be used by 210 LFNs, and not SLAAC, because stateless address auto-configuration is 211 not possible for MNPs whose prefix length is longer than 64, the 212 Interface ID being of length precisely 64 for Ethernet. 214 2.2. DHCPv6-PD and PMIPv6 Enhancements 216 A second mechanism considers the use of MNP completely different than 217 HNP (may differ on the leftmost bit), hence the use of SLAAC with 218 Ethernet LFNs and HNP/64 is possible, but whereby the PMIPv6 protocol 219 implementation must be modified; this mechanism involves also the use 220 of the DHCPv6 Prefix Delegation protocol. 222 For this mechanism, we consider the following PMIP topology augmented 223 with DHCP entities: 225 ---- 226 | CN | 227 ---- 228 | 229 Internet 230 | 231 ---- 232 | LMA| 233 ---- 234 ----- | 235 | DSe |------ Operator Network 236 ----- / \ 237 / \ 238 ---- ---- 239 |MAG1| |MAG2| 240 |DRe1| |DRe2| 241 ---- ---- 242 | HNP 243 ---- 244 | MR | ---> handover 245 ---- 246 ---- ---- ---- | 247 |LFN2| |LFN3| |LFN5|| 248 ---- ---- ---- |MNP1 or MNP2 249 | | | | 250 -------------------+ 252 The DSe entity is a DHCPv6 Server. Each MAG also runs a DRe which is 253 a DHCPv6 Relay. 255 It is necessary to modify the DRe, LMA and MAG behaviour. Depending 256 on deployment, it may be preferable to modify or to not modify the 257 DHCPv6 Server as well. In case it is not acceptable to modify the 258 DSe the following protocol is proposed: 260 LFN MR MAG DSe LMA CN 261 | RA defr | | | | | 262 |<--------| DHCPReq | | | | 263 | |-------->| | | | 264 | | | RelFwd | | | 265 | | |------->| | | 266 | | |DUID=MNID | | 267 | | | | | | 268 | | | RelRep | | | 269 | | |<-------| | | 270 | | | MNP | | | 271 | | | | | | 272 | | | PBU MNID, MNP | | 273 | | |--------|------>| | 274 | | | PBA MNID, MNP | | 275 | | |<-------|-------| | 276 | | DHCPRep | | | | 277 | RA MNP |<--------| | | | 278 |<--------| | | | | 279 | | | | | | 280 |<--------|---------|========|=======|------->| app data 281 | | | | | | 283 In case it is not acceptabe to modify the DSe the following protocol 284 is proposed: 286 LFN MR MAG DSe LMA CN 287 | RA defr | | | | | 288 |<--------| DHCPReq | | | | 289 | |-------->| | | | 290 | | | RelFwd | | | 291 | | |------->| | | 292 | | |DUID=MNID | | 293 | | | | | | 294 | | | | D2PU | | 295 | | | |------>| | 296 | | | | MNID | | 297 | | | | MNP | | 298 | | | | | | 299 | | | | D2PA | | 300 | | | |<----- | | 301 | | | | MNID | | 302 | | | RelRep | MNP | | 303 | | |<-------| | | 304 | | | | | | 305 | | | PBU MNID, MNP | | 306 | | |--------|------>| | 307 | | | | | | 308 | | | PBA MNID, MNP | | 309 | | |<-------|-------| | 310 | | DHCPRep | | | | 311 | RA MNP |<--------| | | | 312 |<--------| | | | | 313 | | | | | | 314 |<------------------=========|========------->| app data 315 | | | | | | 317 D2PU and D2PA are new message formats, to be further defined. 319 The structure of the PBU message is enhanced with respect to the 320 original. Its structure is presented in the following figure: 322 Proxy Binding Update Message (existing + Q) 323 0 1 2 3 324 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Sequence # | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |A|H|L|K|M|R|P|Q| Reserved | Lifetime | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Mobile Node Identifier Option (existing) 332 0 1 2 3 333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Option Type | Option Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Subtype | Identifier ... 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Mobile Network Prefix (MNP) Option (NEW) 341 0 1 2 3 342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type | Length | Reserved | Prefix Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 + + 348 | | 349 + Mobile Network Prefix (MNP) + 350 | | 351 + + 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 'R' flag in PBU: it must be reset. 357 'Q' flag in PBU: it must be set. It signifies this PBU is sent for 358 an MNP (and not for an HNP). 360 Type field in the MNP Option: a new type TBA. 362 Length field in the MNP Option: the length of the MNP as was assigned 363 by DHCP. 365 3. Security Considerations 367 DHCPv6 and PMIPv6 have security options that should be used in this 368 contect as well. 370 Security risks exist in the process of MR performing proxy Neighbor 371 Discovery on behalf of LFN, if done without explicit authorization 372 provided by LFN. 374 Security risks exist when performing D2PU and D2PA. 376 4. Acknowledgements 378 The mechanisms described in this draft were inspired by several 379 discussions on the NETEXT and intarea email lists. Contributors of 380 these discussions are acknowledged here. 382 In the process of filing for patent applications the lawyers provided 383 comments which led to better descriptions. 385 Administratively, this work has been performed in the framework of 386 CELTIC project CP7-011 MEVICO. The authors would like to acknowledge 387 the contributions of their colleagues, although the views expressed 388 are those of the authors and do not necessarily represent the 389 project. 391 5. Normative References 393 [I-D.ietf-netext-pd-pmip] 394 Zhou, X., Korhonen, J., Williams, C., and S. Gundavelli, 395 "Prefix Delegation for Proxy Mobile IPv6", 396 draft-ietf-netext-pd-pmip-01 (work in progress), 397 October 2011. 399 [I-D.krishnan-intarea-pd-epc] 400 Krishnan, S., Garneij, F., Korhonen, J., and T. 401 Savolainen, "Prefix Delegation in Evolved Packet Core 402 networks", draft-krishnan-intarea-pd-epc-00 (work in 403 progress), February 2010. 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 409 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 411 Appendix A. ChangeLog 413 The changes are listed in reverse chronological order, most recent 414 changes appearing at the top of the list. 416 From nil to draft-petrescu-nextex-pmip-nemo-00.txt: 418 o The -00 version is mostly a placeholder containing the essence of 419 the mechanisms. 421 From draft-petrescu-netext-pmip-nemo-00 to -01: 423 o Updated the address of authors. 425 o Aspects described in the draft are now implemented. 427 Authors' Addresses 429 Alexandru Petrescu 430 CEA, LIST 431 Communicating Systems Laboratory, Point Courrier 173 432 Palaiseau, F-91120 433 France 435 Phone: +33 169089223 436 Email: alexandru.petrescu@cea.fr 438 Michael Mathias Boc 439 CEA, LIST 440 Communicating Systems Laboratory, Point Courrier 173 441 Palaiseau, F-91120 442 France 444 Phone: +33 (0) 169083976 445 Email: michael.boc@cea.fr 447 Christophe Janneteau 448 CEA, LIST 449 Communicating Systems Laboratory, Point Courrier 173 450 Palaiseau, F-91120 451 France 453 Phone: +33 (0) 169089182 454 Email: christophe.janneteau@cea.fr