idnits 2.17.1 draft-arita-netext-pnemo-00.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 == Line 143 has weird spacing: '...s using the M...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 12, 2010) is 4938 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-3963' is mentioned on line 75, but not defined == Missing Reference: 'RFC-3775' is mentioned on line 76, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC-5213' is mentioned on line 86, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 115, but not defined == Unused Reference: 'RFC2119' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 575, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Tetsuya Arita 3 Fumio Teraoka 4 Keio univ. 5 Expires April 2011 October 12, 2010 7 Proxy Network Mobility Protocol 8 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April, 2011. 35 Copyright Notice 37 Copyright (c) 2010 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 Abstract 52 Proxy Mobile IPv6 (PMIPv6) provides the Internet connectivity to 53 Mobile Node in a PMIPv6 domain. Current PMIPv6 specification supports 54 only Host Mobility. In order to support a network mobility, this 55 document defines Proxy Mobility Protocol that provides and maintains 56 the connectivity for the Mobile Network Node (MNN) in the mobile 57 network (nemo). This document discusses the deployment consideration 58 of PNEMO and proposes the possible solution accordingly. 60 Table of Contents 62 1. Introduction ....................................................3 63 2. Conventions and Terminology .....................................4 64 3. Proxy Network Mobility Protocol .................................4 65 3.1 Protocol Overview ............................................4 66 3.2 Nested Network ...............................................7 67 4. Local Mobility Anchor Operation ................................10 68 5. Mobile Access Gateway Operation ................................11 69 6. Mobile Router Operation ........................................13 70 7. References .....................................................14 71 7.1. Normative References .......................................14 73 1. Introduction 75 Network Mobility Basic Support (NEMO BS) [RFC-3963] was proposed to 76 support network mobility. Similar to Mobile IPv6 (MIPv6) [RFC-3775], 77 the Home Agent (HA) and the Mobile Router (MR) are important entities 78 in NEMO BS. The HA maintains the prefix of the mobile network (nemo) 79 and forwards packets to and from the nemo. The MR establishes a bi- 80 directional tunnel to the HA. However, NEMO BS has several problems. 81 If the nemo is nested, the header overhead increases because of 82 multiple tunnels. If the wireless link between the MR and the access 83 router (AR) is unstable after handover, the signaling messages such 84 as Binding Update (BU) might be lost. 86 Proxy Mobile IPv6 (PMIPv6) [RFC-5213] provides mobility to the Mobile 87 Node (MN) in the PMIPv6 domain. To achieve mobility in the PMIPv6 88 domain, the Local Mobility Anchor (LMA) and the Mobile Access Gateway 89 (MAG) are installed. The LMA serves as the HA in MIPv6. It manages 90 the binding between the LMA and the MAG to which the MN is attached. 91 The MAG sends the signaling messages to MN's LMA on behalf of the MN. 92 It establishes a bi-directional tunnel to the LMA. In PMIPv6, the 93 signaling messages are exchanged in the wired network. Even if the 94 wireless link between the MN and the MAG is unstable after handover, 95 the signaling messages between the MAG and the LMA are rarely lost. 97 This document defines a protocol called PNEMO that provides network- 98 based localized mobility to a mobile network. In PNEMO, the signaling 99 messages are exchanged between the MAG and the LMA, i.e., the MR does 100 not participate in the signaling procedure. PNEMO is an extension of 101 PMIPv6. The MR sends and receives the packets for the Visited Mobile 102 Node (VMN) and the Local Fixed Node (LFN). It also informs the state 103 of the nemo to the LMA and the MAG. As the LMA and the MAG manage the 104 location information of the VMN and the nested network, they can 105 forward the packets to the VMN and the nested network in the nemo. 107 The MR has the NEMO State Table, which manages the location 108 information of the VMN and the nested network in its lower subnet. 110 2. Conventions and Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC-2119]. 116 3. Proxy Network Mobility Protocol 118 3.1. Protocol Overview 120 This document defines the specification of a network-based mobility 121 management protocol for a mobile network (nemo), called Proxy Network 122 Mobility Protocol (PNEMO). It is an extension of Proxy Mobile IPv6. 124 The LMA and the MAG will keep track of nemo's movements, initiate the 125 mobility signaling, and set up the required routing state. 127 The entities in the NETLMM infrastructure are the LMA, the MAG and 128 the MR. The LMA is responsible for maintaining the reachability state 129 of the MR and the VMN. it allocates the prefixes for mobile nodes to 130 configure their address. The MR is allocated the Home Network Prefix 131 (HNP) and the Mobile Network Prefix (MNP). The VMN is allocated the 132 HNP. The LMA is the topological anchor point for these prefixes. The 133 MAG is the entity that performs the mobility management on behalf of 134 the MR and the VMN. It emulates the Home Link of the MR and the VMN. 135 It is responsible for detecting nemo's movements to and from the 136 access link and for initiating binding registrations to the LMA of 137 the MR's or the VMN's. The MAG itself manages its binding information 138 of the nemo. When the MAG receives packets destined to the nodes in 139 the nemo, it forwards the packets to the corresponding MR. A nemo 140 consists of a MR, VMNs and LFNs. The MR is the default router of the 141 nemo and the entity that manages the nested network. In the nested 142 nemo, the MR informs the configuration change in the nemo to the MAG. 143 The LFN in the nemo configures its address using the MNP advertised 144 by the MR. 146 +-----+ 147 | LMA | 148 +-----+ 149 |<--LMAA 150 Tunnel-->// 151 +-------//---+ 152 ( // )<-- IPv6 Network 153 ( // ) 154 +----//------+ 155 | 156 |<-Proxy-CoA 157 +-----+ ____MR-HNP 158 | MAG | / 159 +-----+-----{ MR } 160 | | 161 VMN-HNP-->| |<--LFN-MNP 162 { VMN } { LFN } 164 Figure 1. Architecture of PNEMO 166 The architecture of PNEMO is shown in Figure 1. In this figure, a VMN 167 and a nemo composed of a MR and a LFN are attached to a MAG. 169 Figure 2 shows the signaling flow when a nemo enters a PMIPv6 domain. 170 When the MR is attached to a PMIPv6 domain, the MAG detects MR's 171 attachment and acquires MR's identifier. It determines whether the MR 172 is authorized for the network-based mobility management service. 173 After the MR is authorized for the network-based mobility service, 174 the MAG sends the Proxy Binding Update (PBU) message to MR's LMA to 175 register the current location of the MR. 177 When the LMA accepts the PBU message, it creates the Binding Cache 178 Entry for the MR and sets up its endpoint of the bi-directional 179 tunnel to the MAG. Then the LMA sends the Proxy Binding 180 Acknowledgement (PBA) message including the HNP and the MNP to the 181 MAG that the MR attaches to. 183 When the MAG receives the PBA message, it sets up its endpoint of the 184 bi-directional tunnel to the LMA and also sets up the forwarding 185 state for nemo's traffic. To emulate the Home Link of the MR, the MAG 186 configures certain link local addresses. Then, it sends the Router 187 Advertisement (RA) message to the MR. 189 The MR configures its address using the HNP advertised by the MAG and 190 it advertise the RA message including the MNP to the nemo. 192 If there is a LFN in the nemo, the LFN configures its address using 193 the MNP. The LMA and the MAG have proper routing states for handling 194 the traffic sent to and from the nemo using the address from its MNP. 196 +-----+ +----+ +-----+ +-----+ 197 | LFN | | MR | | MAG | | LMA | 198 +-----+ +----+ +-----+ +-----+ 199 | | | | 200 | Attached | | 201 | | | | 202 | | Detect Attachment event | 203 | | (Acquire MR-ID/ Profile) | 204 | |-- Rtr Sol ----->| | 205 | | |-- PBU ------------>| 206 | | | Accept PBU 207 | | | (Allocate HNP/MNP, 208 | | | Setup BCE/Tunnel) 209 | | |<------------ PBA --| 210 | | Accept PBA | 211 | | (Setup Tunnel and Routing) | 212 | | | | 213 | | |== Bi-Dir Tunnel ===| 214 | |<----- Rtr Adv --| | 215 | | (HNP,MNP) | | 216 | IP Address | | 217 | Configuration | | 218 | | | | 219 |<- Rtr Adv --| | | 220 | (MNP) | | | 221 IP Address | | | 222 Configuration | | | 223 | | | | 225 Figure 2. Mobile Router Attachment - Signaling Call Flow 227 Figure 3 shows the signaling flow for nemo's handoff. The MR moves 228 from the previously attached MAG (p-MAG) to the newly attached MAG 229 (n-MAG). When the MR changes its point of attachment to the Internet, 230 the p-MAG can detect MR's detachment from the access link. The p-MAG 231 sends a De-registration request message to MR's LMA and deletes the 232 binding and routing state for the MR. On receiving the request 233 message, the LMA accepts the request and deletes the binding for the 234 MR if the LMA does not receive the PBU from the n-MAG within the 235 timeout. 237 When the MR is attached to the new link, the n-MAG detects MR's 238 attachment. Then, the n-MAG sends the PBU message to MR's LMA to 239 update the binding state. After the signaling procedure, the n-MAG 240 sends the RA message to advertise the HNP and the MNP to the MR. The 241 MR does not detect the changes with respect to the layer-3 attachment 242 of this interface. 244 On receiving the RA message from the n-MAG, the MR sends the RA 245 message with the MNP to the nemo. The LFN receives the RA message and 246 configures its address if it does not have its address. 248 In Figure 3, the RS message and the RA message are exchanged between 249 the MR and the n-MAG. Because the MR has already set its address and 250 the default router, the MR does not need the RA message. 252 +-----+ +----+ +-----+ +-----+ 253 | LFN | | MR | |p-MAG| | LMA | 254 +-----+ +----+ +-----+ +-----+ 255 | | |== Bi-Dir Tunnel ===| 256 | Detached | | 257 | | Detect Detachment event | 258 | | | | 259 | | | | 260 | | | 261 | | +-----+ | 262 | | |n-MAG| | 263 | | +-----+ | 264 | Attached | | 265 | | Detect Attachment event | 266 | | | | 267 | |--(Rtr Sol)----->| | 268 | | |-- PBU ------------>| 269 | | | | 270 | | |<------------ PBA --| 271 | |<-----(Rtr Adv)--| | 272 |<- Rtr Adv --| (HNP,MNP) |== Bi-Dir Tunnel ===| 273 | (MNP) | | | 274 | | | | 276 Figure 3. Mobile Network Handoff - Signaling Flow 278 3.2 Nested network 280 Figure 4 shows an example of a nested nemo. Figure 5 shows the 281 signaling flow when a nemo is nested. When another MR (MR2) or a VMN 282 is attached to the MR (MR1) which is connected to the MAG, MR1 283 detects MR2's or VMN's attachment. Then MR1 sends the Nested Binding 284 Update (NBU) message including MR2's or VMN's identifier to the MAG. 286 After the MAG receives the NBU message, it determines whether MR2 or 287 the VMN are authorized for the network-based mobility management 288 service. 290 +-----+ 291 | LMA | 292 +-----+ 293 | 294 // 295 // 296 | 297 +-----+ 298 | MAG | 299 +-----+ 300 | 301 +-----+ 302 | MR1 | 303 +-----+ 304 _______|_______ 305 | | 306 +-----+ | 307 | MR2 | {VMN} 308 +-----+ 309 | 310 +-----+ 311 | MR3 | 312 +-----+ 314 Figure 4. the nested Mobile Network of PNEMO 316 +-----+ +----+ +-----+ +-----+ 317 | VMN | | MR1| | MAG | | LMA | 318 +-----+ +----+ +-----+ +-----+ 319 | | |== Bi-Dir Tunnel ===| 320 Attach Event | | | 321 | Detect Attach event | | 322 | | | | 323 |- Rtr Sol -->| | | 324 | |-- NBU --------->| | 325 | | |-- PBU ------------>| 326 | | | Create BCE 327 | | |<------------ PBA --| 328 | |<--------- NBA --| | 329 |<- Rtr Adv --| | | 330 | | | | 332 Figure 5. Nested Network Attachment - Signaling Flow 334 Then the MAG sends the PBU message to the LMA to update its binding 335 state. When the LMA receives the PBU message, the LMA registers MR1's 336 identifier into MR2's or VMN's upper-router field in the BCE and 337 updates the tunnel identifier field in the BCE. After the LMA sets up 338 the BCE, the LMA sends the PBA message to the MAG. On receiving the 339 PBA message, the MAG registers MR'1 identifier as the upper-router 340 identifier in the Binding Update List Entry (BULE) that the MAG 341 manages to maintain the binding state of a nemo. After that the MAG 342 sets up the routing table to the nested nemo. MR1 receives the Nested 343 Binding Acknowledgement (NBA) message that the MAG sends to MR1 and 344 updates the NEMO State Table. MR1 has the mobility information of the 345 mobile nodes attached to MR1 in the NEMO State Table. 347 When MR3 or a VMN attaches to MR2, a recursive procedure is needed to 348 update upper router's NEMO State Table, the BULE, and the BCE. MR2 349 sends the NBU message to its upper router (MR1). MR1 receives the NBU 350 message and creates the NEMO State Table related to MR3 or the VMN. 351 Then MR1 sends the Proxy Nested Binding Update (PNBU) message to the 352 MAG. After the LMA and the MAG finish their process, MR1 receives the 353 Proxy Nested Binding Acknowledgement (PNBA) message. Then MR1 updates 354 its NEMO State Table and sets up the routing table. MR1 sends the NBA 355 message to MR2. MR2 updates its NEMO State Table after receiving the 356 NBA message. 358 Figure 6 shows the handoff procedure when a nemo is nested. Even if a 359 nemo is nested, the handoff procedure is the same as the non-nested 360 case. The LMA and the MAG also update the entries for the nodes in 361 the nested nemo. When the LMA and the MAG receive the signaling 362 message such as the PBU, they check all entries in its binding table. 364 If an identifier in the upper router field equals to the Mobile Node 365 Identifier option in the signaling message, the LMA and the MAG find 366 that this entry must be updated. 368 +-----+ +-----+ +-----+ +-----+ 369 | VMN | | MR2 | | MR1 | | MAG | 370 +-----+ +-----+ +-----+ +-----+ 371 | | | | 372 Attach Event | | | 373 | Detect Attach event | | 374 | | | | 375 |- Rtr Sol -->| | | 376 | |-- NBU --------->| | 377 | | |-- PNBU ----------->| 378 | | | |- PBU -> 379 | | | | 380 | | |<----------- PNBA --| 381 | |<--------- NBA --| | 382 |<- Rtr Adv --| | | 383 | | | | 385 Figure 6. Nested Mobile Network - Signaling Flow 387 4. Local Mobility Anchor Operation 389 In order to manage the binding states of the MR and the VMN, some new 390 functions MUST be added to the LMA. 392 The LMA MUST have the function that allocates and manages the MNP. In 393 order to forward the packets to LFN's address configured using the 394 MNP, the LMA MUST intercept the packets destined to the MNP. 396 To update the BCEs for the MR and the VMN in the nested nemo, the 397 format of the PBU and the PBA messages MUST be extended. The PBU and 398 the PBA message MUST have the Mobile Network Prefix option. This 399 option informs the LMA and the MAG of the prefixes that are allocated 400 to the nemo. The PBU and the PBA messages MUST also have the Upper 401 Mobile Router option. This option informs the LAM and the MAG of the 402 identifier of the upper MR to which the VMN and the MR are attached. 403 The upper MR MUST be the MR that is attached to the MAG directly. 405 The format of the BCE in the LMA MUST be extended to manage the MNP 406 and the upper MR's identifier. The BCE has the R flag field in order 407 to indicate whether or not this BCE is created for a MR or a single 408 node. For a MR, this flag is set to value 1 and is set to value 0 for 409 a single node. The BCE in the LMA also has the Mobile Network Prefix 410 field to manage the MNP. Besides, the BCE in the LMA has the Upper 411 Mobile Router field. In the nested nemo scenario, if the LMA receives 412 the signaling messages such as the PBU including the MR's identifier, 413 the LMA updates the BCE for MR's identifier and the BCE whose upper 414 router field equals to the MR's identifier. The LMA can manage the 415 mobility of the nested nemo. 417 5. Mobile Access Gateway Operation 419 In order to manage the binding states of the MR and the VMN, some new 420 functions MUST be added to the MAG. 422 The format of the BULE MUST be extended to manage the mobility of the 423 nemo and the nested nemo. The Mobile Network Prefix field, the Upper 424 Mobile Router field and the R flag must be added to the BULE in the 425 MAG. If the R flag in the BULE is set to value 1, the entry is for a 426 MR. If this R flag in the BULE is set to value 0, the entry is for a 427 single node. The identifier of the Upper Mobile Router Identifier 428 option in the signaling message from the MR is stored into the upper 429 mobile router field. 431 In order to manage the mobility of the nested nemo, PNEMO defines the 432 following new signaling messages, the Nested Binding Update (NBU), 433 the Netsted Binding Acknowledgement (NBA), the Proxy Nested Binding 434 Update (PNBU) and the Proxy Nested Binding Acknowledgement (PNBA). 436 Figure 7. shows the formats of the new signaling messages. The NBU 437 and the NBA have the P flag and some Mobility options. If the P flag 438 is set to value 1, this signaling message is called the PNBU or the 439 PNBA. The NBU and the PNBU have the Mobile Node Identifier option, 440 the Home Network Prefix option, the Mobile Network Prefix option and 441 the Upper Mobile Router Identifier option as the Mobility Options. 442 The NBA and the PNBA have the Mobile Node Identifier option, the Home 443 Network Prefix option, the Mobile Network Prefix option as the 444 Mobility Options and the P flag. 446 Nested Binding Update Massage 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Sequence # | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |P| Reserved | Lifetime | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | | 456 . . 457 . Mobility options . 458 . . 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Nested Binding Acknowledgement Message 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Status |P| Reserved | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Sequence # | Lifetime | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | 473 . . 474 . Mobility options . 475 . . 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 7. A Format of New Signaling Messages 480 +-----+ 481 | LMA | 482 +-----+ 483 | 484 +-----+ 485 | MAG | 486 +-----+ 487 | 488 +-----+ 489 +------| MR1 |--------+ 490 | +-----+ | 491 | | | 492 | +-----+ | 493 | +--| MR2 |----+ | 494 | | +-----+ | | 495 | | | | | 496 | | +-----+ | | 497 | |+-| MR3 |--+ | | 498 | || +-----+ | | | 499 | |+----------+ | | 500 | +-------------+ | 501 +---------------------+ 503 Figure 8. An Example of a Nested NEMO 505 Figure 8 shows an example of a nested nemo. When the MAG receives the 506 NBU message from MR1 after MR2 is attached to MR1, the MAG creates an 507 entry for MR2 in the BULE. The MAG registers the identifier of MR2 in 508 the Mobile Node Identifier option with the Mobile Node Identifier 509 field in this entry and registers the identifier and the link local 510 address of MR1 with the Upper Mobile Router field and the Linklocal 511 Address field in this entry, respectively. After authentication, the 512 MAG sends the PBU message to its LMA. 514 If the MR3 is attached to MR2, the MAG receives the PNBU message from 515 MR1. As the MAG receives the NBU message, it sets up the binding 516 states. Then the MAG sends the PBU message to its LMA. The LMA sends 517 the PBA message containing the HNP and the MNP to allocate them to 518 the nested nemo. After the MAG receives the PBA message, it updates 519 entries for MR2 and MR3. Then the MAG sends the NBA or the PNBA 520 message to MR1. 522 6. Mobile Router Operation 524 Each MR MUST have the NEMO State Table (NST) to manage the location 525 of the nested nemo. The NST has the Mobile Node Identifier field, the 526 Home Network Prefix field, the Mobile Network Prefix field, the 527 Mobile Node Linklocal Address field and the Upper Mobile Router 528 field. 530 The Mobile Node Identifier field has the identifier of the nested MR 531 (e.g., MR2) attached to the MR (e.g., MR1). The Home Network Prefix 532 field and the Mobile Network Prefix field have the prefixes that are 533 allocated to the nested nemo. The link local address in the Mobile 534 Node Linklocal Address field is the next hop node's link local 535 address to the HNP and MNP. MR's identifier in the Upper Mobile 536 Router field is the next hop node's identifier to the destination. 538 The signaling flow of the nested nemo is shown below. In Figure 8, 539 MR1 is connected to the MAG and MR2 is connected to MR1. When MR3 is 540 attached to MR2, MR3 sends the Router Solicitation (RS) message to 541 MR2. 543 MR2 detects MR3's attachment and creates the NST for MR3. MR2 sends 544 the NBU message whose Mobile Node identifier option is set to the 545 identifier of MR3 and whose Upper Mobile Router option is set the 546 identifier of MR2 to MR1. 548 After MR1 receives the NBU message, MR1 creates an entry for MR3 in 549 the NST. Its Mobile Node Identifier field is set to the identifier of 550 MR3 and its Upper Mobile Router field is set to the identifier of 551 MR2. Then MR1 sends the PNBU message containing MR1's identifier in 552 its Upper Mobile Router option to the MAG. 554 After the MAG updates its BULE and the LMA updates its BCE, the MAG 555 sends the PNBA message to MR1. When MR1 receives the PNBA message, it 556 sets a lifetime in its NST. Then MR1 sends the NBA message to MR2. 558 MR2 updates its NST and extracts the HNP and the MNP from the NBA 559 message. Then the MR2 sends the Router Advertisement (RA) message to 560 advertise the HNP and the MNP to MR3. 562 MR3 configures its address using the HNP and sends the RA message 563 with the MNP to its network. 565 7. References 567 7.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC3775] D. Johnson, "Mobility Support in IPv6", RFC 3775, June 572 2004. 573 [RFC3963] V. Devarapalli, "Network Mobility (NEMO) Basic Support 574 Protocol", RFC 3963, January 2005. 575 [RFC5213] S. Gundavelli, Ed. "Proxy Mobile IPv6", RFC 5213, August 576 2008. 578 Authors' Addresses 580 Tetsuya Arita 581 Graduate School of Science and Technology, KEIO University 582 3-14-1 Hiyoshi, Kohoku-ku 583 Yokohama, Kanagawa 223-8522 584 Japan 586 Phone: +81-45-566-1425 587 EMail: cream@tera.ics.keio.ac.jp 588 URI: http://www.tera.ics.keio.ac.jp/ 590 Fumio Teraoka 591 Faculty of Science and Technology, KEIO University 592 3-14-1 Hiyoshi, Kohoku-ku 593 Yokohama, Kanagawa 223-8522 594 Japan 596 Phone: +81-45-566-1425 597 EMail: tera@ics.keio.ac.jp 598 URI: http://www.tera.ics.keio.ac.jp/