idnits 2.17.00 (12 Aug 2021) /tmp/idnits45992/draft-na-nemo-path-control-header-00.txt: -(138): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(238): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(375): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(407): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(669): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(683): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(684): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(685): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 9 instances of lines with non-ascii characters in the document. == 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 an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Scope Binding Updates)", draft-ernst-mobileip-v6-network-03' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) ** There are 461 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([2], [15], [16], [3], [4], [5], [7], [8], [9], [10], [11], [12], [13], [1], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2004) is 6610 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 section? '15' on line 758 looks like a reference -- Missing reference section? '14' on line 754 looks like a reference -- Missing reference section? '2' on line 715 looks like a reference -- Missing reference section? '4' on line 723 looks like a reference -- Missing reference section? '5' on line 728 looks like a reference -- Missing reference section? '1' on line 711 looks like a reference -- Missing reference section? '3' on line 718 looks like a reference -- Missing reference section? '7' on line 732 looks like a reference -- Missing reference section? '8' on line 735 looks like a reference -- Missing reference section? '9' on line 738 looks like a reference -- Missing reference section? '10' on line 741 looks like a reference -- Missing reference section? '11' on line 744 looks like a reference -- Missing reference section? '12' on line 747 looks like a reference -- Missing reference section? '13' on line 751 looks like a reference -- Missing reference section? '16' on line 762 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group Jongkeun Na 3 Internet Draft Seongho Cho 4 Expires: November 2004 Chongkwon Kim 5 Seoul National University 6 Sungjin Lee 7 Hyunjeong Kang 8 Changhoi Koo 9 Samsung Electronics 10 April 2004 12 Route Optimization Scheme based on Path Control Header 13 draft-na-nemo-path-control-header-00 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 In this memo, we propose a unified Route Optimization (RO) scheme 39 that can solve several types of RO problem by using Path Control 40 Header (PCH) Piggybacking. In our scheme, Home Agent (HA) does 41 piggyback the PCH on the packet which is reversely forwarded from 42 Mobile Router (MR). That enables any PCH-aware routing facility on 43 the route to make a RO tunnel with MR using the Care-of address of 44 MR contained in the PCH. By applying to some already known NEMO RO 45 problems, we show that our scheme can incrementally optimize the 46 routes via default HA-MR tunnel through the simple PCH 47 interpretation. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 53 this document are to be interpreted as described in RFC-2119. 55 Table of Contents 57 1. Introduction.................................................4 58 2. Terminology..................................................5 59 3. Basic Operations.............................................6 60 3.1 PCH Piggybacking by HA..................................6 61 3.2 Making a RO Tunnel......................................7 62 4. Route Optimization...........................................9 63 4.1 Route Optimization by CR................................9 64 4.2 Route Optimization over MR-to-MR.......................10 65 4.3 Nested Tunnels Optimization............................12 66 5. Extensions..................................................15 67 5.1 MIPv6 Extension........................................15 68 5.2 MR Extension...........................................18 69 5.3 HA Extension...........................................18 70 6. Security Considerations.....................................19 71 References......................................................20 72 Acknowledgments.................................................21 73 Authors' Addresses..............................................21 75 1. Introduction 77 NEMO Basic Support Solution[15] would suppose to support 78 transparent mobility to mobile network nodes(MNNs) in mobile 79 networks by using MR-HA bi-directional tunneling. However, 80 inherently due to the use of the bi-directional tunnel, there are 81 some types of route optimization problem [14] that need our 82 attention. Until now, one solution is proposed to solve only one 83 type of route optimization problem such as nested tunnel 84 optimization. 86 In this memo, we propose a route optimization scheme based on 87 PCH(Path Control Header) piggybacking by HA. The scheme is a 88 unified solution that can solve a several types of route 89 optimization problem with applying the same principle to the 90 routing facilities such as HA, MR and Correspondent Router(CR). 92 In the proposed scheme, HA does piggyback PCH on the packet which 93 is reversely forwarded from MR through bi-directional MR-HA tunnel. 94 PCH is a hop-by-hop option header so that it can be processed by 95 all of the routing facilities on the path that is from HA to CN. HA 96 forwards the packet with PCH to CN for the route optimization. CR 97 on the path makes a RO(Route Optimization) tunnel between MR and 98 itself using the information which is the CoA of MR that is 99 contained in PCH. 101 This memo describes how we can apply PCH based scheme on two 102 problem spaces listed in [14]. One is to CR based route 103 optimization in routing infrastructure and the other is to the 104 nested tunnels optimization for which many of solutions in NEMO 105 have been proposed. The basic operation and signaling will be 106 detailed in section 3 and 4. 108 Our proposed RO scheme, PCH piggybacking by HA, is a simple but 109 effective one in solving the problems of route optimization in 110 network mobility support. By taking the functional extension of 111 routing facilities such as HA, MR and CR, we can dynamically 112 incrementally optimize the routes over CN-HA-MR without the loss of 113 transparency to CN. 115 We expect that the basic concept of this scheme can be used to 116 support other mobility-related route optimizations as a unified 117 solution, not limited to network mobility. 119 2. Terminology 121 It is assumed that readers are familiar with NEMO terminology 122 described in [2][14], and the terms described in [4][5]. In 123 addition, we define a few of terms used in describing the operation 124 of our solution. 126 Path Control Header (PCH) 128 IPv6 hop-by-hop option header piggybacked on the reversely 129 forwarded packet by HA for the route optimization. This 130 header contains, as an option data, a form of array of IPv6 131 global addresses that are the addresses of Mobile Routers on 132 the nested path which means from TLMR to any nested MR in 133 nested mobile networks. 135 RO Tunnel (ROT) 137 Any tunnel that created by the scheme of route optimization 138 proposed by this document is referred to a "RO Tunnel”. 140 Nested RO Tunnel (NROT) 142 Any RO tunnel that do require the source routing using IPv6 143 Routing Header Type 0 (RH0). This kind of RO tunnel is only 144 used in optimizing the nested tunnels to guarantee the 145 correct routing over nested MRs. 147 Correspondent Router (CR) 149 Any router in the Internet that can play a role of a 150 correspondent agent for a set of correspondent nodes. It 151 maybe an access router serving the routing service to a set 152 of subnets or a border router located in AS-level or ISP- 153 level. 155 3. Basic Operations 157 3.1 PCH Piggybacking by HA 159 To route optimization, HA does piggyback PCH on the packet which is 160 reversely forwarded from MR through bi-directional MR-HA tunnel. 161 PCH is a hop-by-hop option header so that it can be processed by 162 all of the routing facilities on the path that is from HA to CN. 163 The mentioned routing facility means an entity which can play a 164 role of transparent correspondent agent. The router in the Internet 165 that implements such a function of transparent correspondent agent, 166 we call it a CR, provides the packet redirection service to the 167 nodes behind it by intercepting the packets sent from them and 168 redirecting to the RO tunnel. The RO tunnel between CR and MR can 169 be established when CR gets know the existence of HA by processing 170 the packet with PCH. 172 In fig.1, HA de-capsulates the encapsulated packet forwarded from 173 MR via MR-HA tunnel and then forwards the PCH piggybacked packet to 174 CN for the route optimization. Any existing CR on the path from HA 175 to CN can catch the path control information as examining PCH in 176 the packet. Therefore, the CR can initiate the procedure of making 177 RO tunnel between itself and MR using the CoA of MR which is 178 contained in PCH. After setting up RO tunnel, the packets of CN 179 will be redirected to RO tunnel at CR. 181 +----+ IP in IP 182 CN <--- Packet with PCH --- | HA |<==== Packet ==== MR 183 | +----+ 184 =[1|CoA of MR] 186 Fig.1 PCH piggybacking by HA 188 This scheme is simple and effective in respects of RO. It only 189 requires a little effort of HA to provide the RO tunnel between CR 190 and MR. HA does PCH piggybacking on the packet which taking a non- 191 optimized path of MR-HA tunnel. In here, we can say that CR maybe 192 an access router that providing the routing service for a few of 193 subnets or a border router that runs BGP routing protocol in one AS. 195 Fig.2 shows the structure of PCH. PCH has address information as an 196 option data. In here, the address information represents the list 197 of IPv6 addresses. The address contained in PCH indicates the CoA 198 of MR in MR-HA relationship. Through PCH, CR gets know the CoA of 199 MR so that CR can initiate the signaling for RO tunnel. 201 PCH(Path Control Header) : IPv6 Hop-by-Hop Options Header 202 Option Type : 00 0 XXXXX 203 00 - skip over this option and continue processing the header. 204 0 - Option Data does not change en-route 205 XXXXX = Path Control Option ID (to be assigned by IANA) 206 Option Data : 207 +-----------+------------+------------+---------+------------+ 208 | Length(n) | Address(1) | Address(2) | . . . . | Address(n) | 209 +-----------+------------+------------+---------+------------+ 211 Fig.2 Type and data format of PCH option 213 In fig.3 that shows the case of forming nested tunnels, PCH gets 214 contain two CoAs, each of MR1 and MR2. HA2 gets know the fact that 215 its MR2-HA2 tunnel is nested under outer MR1-HA1 tunnel after 216 taking a look at the packet with PCH1. The nested HA just adds the 217 CoA of its MR on the received PCH to make its PCH. In fig.3, HA2 218 does piggyback PCH which includes the CoA of MR1(the exit point of 219 the outer tunnel) and the CoA of MR2(the exit point of its tunnel). 220 In this case, one CR on the path between HA2 and CN will able to 221 make RO tunnel with MR2 by using the nested information carried in 222 PCH. 224 +---+ +---+ +---+ +---+ 225 CN <----|HA2|=========|HA1|////////|MR1|========|MR2|<----LFN 226 \ +---+ \ +---+ +---+ +---+ 227 \ PCH=[1|CoA of MR1] 228 PCH=[2|CoA of MR1, CoA of MR2] 230 Fig.3 Nested PCH piggybacking by HAs 232 3.2 Making a RO Tunnel 234 The CR can make a RO tunnel after getting the piggybacked PCH from 235 HA. The signaling to construct a RO tunnel between CR and MR is 236 done with 3-way handshake as in fig.4. The messages defined in here 237 are carried by Mobility Header(MIPv6). We define new message called 238 “BR(Binding Request)” to notify MR of the need of RO tunnel. 239 BU(Binding Update) and BA(Binding Acknowledgement) are same as 240 defined in MIPv6 and NEMO. Additionally, we define new mobility 241 option to carry a set of network prefixes. CR can use this option 242 to inform MR of the routing information of networks which are 243 reachable from RO tunnel. By referring those of routing information, 244 MR reversely forwards the packets to pre-established RO tunnel 245 because they are destined to the network that is reachable from RO 246 tunnel. 247 CR does the same thing for the prefix of mobile network that is 248 bound through BU from MR. CR intercepts the packets destined to the 249 prefix and redirects them to pre-established RO tunnel. 251 CR MR 252 | | 253 |----- Binding Request(BR) -------->| 254 | | 255 |<---- Binding Update(BU)-----------| 256 | | 257 |----- Binding Ack.(BA)------------>| 258 | | 259 |<======== RO tunnel ==============>| 260 | | 262 Fig.4 The signaling procedure for RO Tunnel 264 4. Route Optimization 266 4.1 Route Optimization by CR 268 HA1 269 | 270 ===*==== 271 |& 272 CR1(Border Router) 273 \ 274 +---------------------+ 275 | Internet |--CR2 ====|=== 276 +---------------|-----+ CN1 277 / AR(Access Router) 278 CN2 | 279 ======*=========== 280 MR1 281 | 282 LFN1 284 Fig.5 CR-based Route Optimization : Network Configuration 286 As in fig.5 and 6, CR1 and CR2 can simultaneously establish a RO 287 tunnel with MR through one PCH piggybacking by HA1. This is 288 possible because both are on the path that is from HA1 to CN1. In 289 that case, the packets sent from CNs in all of subnets attached to 290 CR2 are redirected to RO tunnel at CR2. CR1 can serve the packets 291 sent from any CNs(in here, CN2) that are scattered in the Internet. 292 The packets reached on CR1 indicate that there is no CR in the path 293 that is from CN2 to CR1, or CR but still not received PCH. The 294 packets from CN2 are redirected at CR1 and reversely the packets 295 from MR1 are forwarded via HA1. At next time, the CR on the CR1-CN2 296 path can make a RO tunnel by picking PCH up on the reversely 297 forwarded packets from HA1. As a result of PCH piggybacking by HA1, 298 we can serve the incremental route optimization to all of CNs. 300 CN1 CN2 CR2 CR1 HA1 MR1 LFN1 301 | | | | | | | 302 | | | | | Tunnel | | 303 |----------Packet------------------>|========|------->| 304 |<+++Packet(PCH)++|<+++++++|<+++++++|========|<-------| 305 | | | |------- BR ----->| | 306 | | | |<------ BU ------| | 307 | | | |------- BA------>| | 308 | | | |<== RO tunnel ==>| | 309 | | | | | | | 310 | | |----------- BR ---------->| | 311 | | |<---------- BU -----------| | 312 | | |----------- BA ---------->| | 313 | | |<======= RO tunnel ======>| | 314 | | | | | | | 315 |---------------->|==========================|------->| 316 |<----------------|==========================|<-------| 317 | | | | | | | 318 | |---------------->|=================|------->| 319 | |<+++++++++++++++++++++++++|========|<-------| 320 | | | | | | | 322 Fig.6 CR-based Route Optimization : Message Flow 324 4.2 Route Optimization over MR-to-MR 326 As in fig.7 and fig.8, we can get the RO tunnel over MR-to-MR by 327 using PCH piggybacking. MR per se interprets PCH piggybacked from 328 the HA of the other MR and initiates the signaling for RO tunnel 329 with the other MR. As a result of that, the nodes behind one MR can 330 directly communicate with the nodes behind the other MR without any 331 routing overhead. 333 LFN2 334 | 335 MR2 336 ===*==== 337 | 338 AR(Access Router) 339 \ 340 +---------------------+ 341 | Internet |--HA1 342 +---------------|-----+ 343 / AR(Access Router) 344 HA2 | 345 ======*=========== 346 MR1 347 | 348 LFN1 350 Fig.7 MR-to-MR Route Optimization : Network Configuration 352 LFN1 MR1 HA1 HA2 MR2 LFN2 353 | | | | | | 354 | | Tunnel | | Tunnel | | 355 |------->|========|+++++++>|========|+++++++>| 356 | | | | | | 357 | |<---------- BR -----------| | 358 | | | | | | 359 | |----------- BU ---------->| | 360 | | | | | | 361 | |<---------- BA -----------| | 362 | | | | | | 363 | |<======= RO Tunnel ======>| | 364 | | | | | | 365 |<-------|==========================|<-------| 366 | | | | | | 367 | | | | | | 369 Fig.8 MR-to-MR Route Optimization : Message Flow 371 4.3 Nested Tunnels Optimization 373 Fig.9 and 10 show the network configuration and message flow for 374 the nested tunnels optimization using PCH piggybacking. In nested 375 mobile networks, RO tunnel is called “Nested RO Tunnel(NROT)” 376 because we introduces the source routing concept in handling the 377 nested tunnel optimization. To the correct routing in the nested 378 network configuration, we take advantage of IPv6 Routing Header 379 Type 0(RH0) in NROT. 381 HA1 382 | 383 ===*==== 384 |& 385 AR(Access Router) 386 \ 387 +---------------------+ 388 HA2--| Internet |--CR====|=== 389 +---------------|-----+ CN 390 / AR(Access Router) 391 HA3 | 392 ======*=========== 393 MR1(TLMR) 394 | 395 ====*=============|=================*========== 396 MR2 LFN1 MR4 397 | | 398 =======*==== ================?==== 399 MR3 VMN 400 | 401 ====|=======|===== 402 LFN3 LMN 404 Fig.9 Nested Tunnels Optimization : Network Configuration 406 In fig.10, CR gets know the existence of nested tunnels through PCH 407 information (MR1’s CoA and MR2’s CoA, MR3’s CoA) and then initiate 408 the signaling for NROT to MR3 via nested tunnels. At this time, 409 Binding Request(BR) message contains Nested Routing Path Option(NRP 410 Option). NRP Option is used to inform MR3 of the nested path 411 information. If MR3 receives BR message having NRP option, MR3 also 412 gets know that it is nested. Therefore, the tunnel between CR and 413 MR3 becomes a NROT. 415 In NROT, the entry point of tunnel adds RH0 at encapsulation. 416 Reversely, the exit point of tunnel deletes RH0 at decapsulation. 418 For the packets tunneled from CR to MR3, the packet forwarding is 419 done with source routing of RH0 (MR1->MR2->MR3). For the packets 420 tunneled from MR3 to CR, the reverse source routing (MR2->MR1->CR) 421 occurs. Fig.11 and 12 shows the content of RH0 at the packet 422 delivery. 424 LFN3 MR3 MR2 MR1 HA1 HA2 HA3 CR CN 425 | | | | | | | | | 426 | | | |\\\\\\| | | | | 427 | | |//////|//////|//////| | | | 428 |----->|======|======|======|======|======|+++++>|++++>| 429 | | |//////|//////|//////| | | | 430 | | | |\\\\\\| | | | | 431 | | | | | | | | | 432 | |<----------------- BR -------------------| | 433 | |------------------ BU ------------------>| | 434 | |<----------------- BA -------------------| | 435 | | | | | | | | | 436 | |<========== Nested RO Tunnel ===========>| | 437 | | | | | | | | | 438 | |Source routing | | | | | 439 |<-----|<<====|<<====|<<=========================|<----| 440 | | | | | | | | | 441 |----->|====>>|====>>|=========================>>|---->| 442 | | | | | | | | | 444 Fig.10 Nested Tunnels Optimization : Message Flow 446 <--------------- outer IPv6 header ---------------> 447 +-------+-------++ -- ++----+---+--------+---------++-------- 448 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 449 CR :| CR |MR1-CoA|:oEXT:|type| 2 |MR2-CoA | MR3-CoA || iPACKET 450 | | |: :| 0 | | | || 451 +-------+-------++ -- ++----+---+--------+---------++-------- 453 <--------------- outer IPv6 header ---------------> 454 +-------+-------++ -- ++----+---+--------+---------++-------- 455 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 456 MR1:| CR |MR2-CoA|:oEXT:|type| 1 |MR1 | MR3-CoA || iPACKET 457 | | |: :| 0 | | | || 458 +-------+-------++ -- ++----+---+--------+---------++-------- 460 <--------------- outer IPv6 header ---------------> 461 +-------+-------++ -- ++----+---+--------+---------++-------- 462 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 463 MR2:| CR |MR3-CoA|:oEXT:|type| 0 |MR1 | MR2 || iPACKET 464 | | |: :| 0 | | | || 465 +-------+-------++ -- ++----+---+--------+---------++-------- 467 Fig.11 Forward Packet Delivery (CR->MR3) via NROT 469 <--------------- outer IPv6 header ---------------> 470 +-------+-------++ -- ++----+---+--------+---------++-------- 471 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 472 MR3: |MR3-CoA| MR2 |:oEXT:|type| 2 |MR1 | CR || iPACKET 473 | | |: :| 0 | | | || 474 +-------+-------++ -- ++----+---+--------+---------++-------- 476 <--------------- outer IPv6 header ---------------> 477 +-------+-------++ -- ++----+---+--------+---------++-------- 478 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 479 MR2: |MR2-CoA| MR1 |:oEXT:|type| 1 |MR3-CoA | CR || iPACKET 480 | | |: :| 0 | | | || 481 +-------+-------++ -- ++----+---+--------+---------++-------- 483 <--------------- outer IPv6 header ---------------> 484 +-------+-------++ -- ++----+---+--------+---------++-------- 485 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 486 MR1: |MR1-CoA| CR |:oEXT:|type| 0 |MR3-CoA | MR2-CoA || iPACKET 487 | | |: :| 0 | | | || 488 +-------+-------++ -- ++----+---+--------+---------++-------- 490 Fig.12 Reverse Packet Delivery (MR3->CR) via NROT 492 5. Extensions 494 The proposed scheme requires some extensions for existing MIPv6 and 495 NEMO Basic Support protocols. 497 5.1 MIPv6 Extension 499 The proposed scheme requires some extensions for existing MIPv6 500 protocol [1]. As you see in section 3.2, new mobility message, BR, 501 is required. And also, new two mobility options are needed. We 502 describe the purpose and usage of them in here. 504 Binding Request Message (BR Message): This message is used to 505 notify MR of the need of RO tunnel. If the sender of this 506 message detects the nested tunneling(i.e. PCH contains one more 507 addresses), it should put NRP(Nested Routing Path) Option into 508 this message to inform MR of its nested path information. 509 Otherwise, this message includes no special information except 510 for triggering the signaling of RO tunnel. 512 Nested Routing Path Option (NRP Option): The initiator of the 513 signaling of RO tunnel should add this mobility option in BR 514 message to set up the Nested RO Tunnel with nested MR. This 515 option contains the list of addresses that represents the tree 516 topology of nested MRs. That is used for MR to assign the source 517 routing path that is necessary to nested tunnels optimization. 519 Reachable Network Prefixes Option (RNP Option): This option is 520 used to let MR know about the network prefixes which are 521 reachable via RO tunnel. By using this information associated 522 with RO tunnel, MR can select the optimized path(i.e. RO tunnel) 523 for the out-going packets. This option should be contained in BA 524 message. 526 5.1.1 Binding Request Message (BR Message) 528 New BR Message is defined to notify MR of the need of RO tunnel. If 529 sender detects the nested mobility, it has to put NRP Option into 530 in this message to inform MR of its nested path information. The 531 format of this message is as follows: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Sequence # | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Reserved | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 . . 543 . Mobility options . 544 . . 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 TBD 550 5.1.2 Reachable Network Prefixes Option (RNP Option) 552 RNP Option is used to let MR know about the networks reachable via 553 the tunnel. By using this information associated with the tunnel 554 between CR and MR, MR can select the optimized path for the out- 555 going packets. This option should be contained either BR or BA 556 message for the route optimization in the reverse packet delivery. 557 The format of this option is as follows: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type = TBA | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 + + 566 | | 567 + a set of network prefixes + 568 | | 569 + + 570 | | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 TBD 575 5.1.3 Nested Routing Path Option (NRP Option) 577 CR adds new mobility option, NRP Option in BR message to set up the 578 Nested RO Tunnel with nested MR. The format of this option is as 579 follows: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type = TBA | Length=16*n | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | NP_Length=n | Reserved | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | 589 + + 590 | | 591 + Addr[1](=TLMR address) + 592 | | 593 + + 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | o | 597 | o | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | | 600 + + 601 | | 602 + Addr[n] + 603 | | 604 + + 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 NP_Length 610 8-bit unsigned integer that indicates the number of Addr[] 611 slots. 613 Addr[1..n] 615 Vector of IPv6 global addresses of MRs on the nested path, 616 numbered 1 to n. 618 NRP Option is only valid in a Binding Request message. The purpose 619 of this option is to inform MR that it can do optimize the nested 620 tunnels overhead. Using this information, MR can route packets to 621 CR via the MRs on the nested path by using type 0 RH optional 622 header. 624 5.2 MR Extension 626 For route optimization, MR MUST understand BR message sent from 627 routing facilities such as CR. According to MIPv6 Spec.[1], MR MUST 628 maintain Binding Update List(BU List). In managing BU List, the 629 following information MUST be maintained additionally to use RO 630 tunnel defined in this proposed solution. 632 RO Tunnel (ROT) flag: When it is set, it indicates that the 633 associated BU entry is for ROT tunnel. All of ROT tunnel should 634 contain a set of network prefixes that is carried from RNP 635 Option. 637 Nested RO Tunnel (NROT) flag: When it is set, it indicates that 638 the associated BU entry is for NROT tunnel. In this case, the BU 639 entry should contain the nested path information carried from 640 NRP Option. 642 Nested Path Information (NPI) Vector: The address vector 643 information is transferred in NRP Option. This information is 644 only valid when NROT flag is set. 646 Network Prefixes (NP) Vector: The address vector information 647 transferred in RNP Option. This information is only valid when 648 either ROT flag or NROT flag is set. 650 The successful establishment of RO tunnel allows the ready of RO- 651 enabled tunnel interface that would be associated with the 652 correspondent entry of BU List. That tunnel interface should be 653 setup to add IPv6 RH0(Routing Header Type 0) optional header at the 654 encapsulation of tunneled packets if the NROT flag is set. 656 Lastly, MR should maintain the RO tunnels in its own context. In 657 other words, MR can tear down less necessary RO tunnels according 658 to its own criterion such as Least Recently Used(LRU) in case of 659 the resource shortage. 661 5.3 HA Extension 663 For route optimization, HA should maintain the state of PCH 664 piggybacking for per traffic flow. The traffic flow can be 665 classified by the destination address of the packets. HA does 666 piggyback PCH on one packet per the traffic flow. The piggybacking 667 state should be managed by soft-state. The piggybacking state of 668 per traffic flow becomes set when the first packet is piggybacked 669 and reset when the state timer is expired. HA doesn’t need to 670 piggyback PCH on the packets belong the traffic flow while the 671 correspondent state is set. The overhead of managing the 672 piggybacking state can be minimized by the careful implementation. 674 According to MIPv6 Spec.[1], HA MUST maintain Binding Cache(BC). 675 Like MR extension. Additionally, HA manages the following 676 information in associated BC entry for route optimization. 678 Route Optimization (RO) flag: When it is set, it indicates that 679 the associated BU entry is RO enabled. RO may be enabled or 680 disabled by administrative means. 682 Piggybacking State Table (PST): An entry of this table 683 represents a record that contains (“flow-id” = destination 684 address, “time-info” = UTC time). It indicates that the first 685 packet belong the traffic flow(=”flow-id”) was piggybacked with 686 PCH at time(=”time-info”). 688 For the packets forwarded via RO enabled tunnel from MR, HA 689 decapsulates them, and checks the need of PCH piggybacking. If an 690 entry that contains the destination address of the packet exists in 691 PST, PCH is not piggybacked to the packet at forwarding. Otherwise, 692 HA creates new entry in PST for that traffic flow and piggybacks 693 PCH on the packet at forwarding. We can use one global timer to 694 delete the records which were long sustained in PST. 696 6. Security Considerations 698 TBD 700 In particular, considering security concerns is very important in 701 applying the Internet protocol. At this moment, Public Key 702 Infrastructure (PKI) can be a solution to support the integrity and 703 the origin-authentication of PCH because the participants in our 704 scheme are limited to some of routing facilities. We know that the 705 potential security problem of our scheme must be deeply considered. 706 We leave the detailed security consideration into the future work 707 item with high priority. 709 References 711 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 712 IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 713 2002. 715 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 716 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 718 [3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A. 719 Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix 720 Scope Binding Updates)", draft-ernst-mobileip-v6-network-03 721 (work in progress), March 2002. 723 [4] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header 724 and Its Application to Mobile Networks", Internet Draft: 725 draft-thubert-nemo-reverse-routing-header-01 726 (work in progress), Oct 2002. 728 [5] Chan-Wah Ng, and Takeshi Tanaka, "Securing Nested Tunnels 729 Optimization with Access Router Option", Internet Draft:draft 730 -ng-nemo-access-router-option-00(work in progress), Oct 2002. 732 [7] Kent, S. and R. Atkinson, "Security Architecture for the 733 Internet Protocol", RFC 2401, November 1998. 735 [8] Kent, S. and R. Atkinson, "IP Authentication Header", 736 RFC 2402, November 1998. 738 [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 739 (ESP)", RFC 2406, November 1998. 741 [10] Deering, S. and R. Hinden, "Internet Protocol, 742 Version 6 (IPv6) Specification", RFC 2460, December 1998. 744 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 745 for IP Version 6 (IPv6)", RFC 2461, December 1998. 747 [12] Conta, A. and S. Deering, "Internet Control Message Protocol 748 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 749 Specification", RFC 2463, December 1998. 751 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 752 an On-line Database", RFC 3232, January 2002. 754 [14] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization 755 Models in the NEMO Context", Internet Draft: draft-thubert- 756 nemo-ro-taxonomy-00(work in progress), Oct 2002. 758 [15] vijay, D., Ryuji, W., Alexandru, P., Pascal, T., "NEMO Basic 759 Support Protocol", draft-ietf-nemo-basic-support-00(work in 760 process), June 2003. 762 [16] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 763 Specificiation", RFC2473, December 1998. 765 Acknowledgments 767 Authors' Addresses 769 Jongkeun Na 770 Information Networking & Computing Lab. 771 School of Computer Science and Engineering, 772 Seoul National University, Seoul Korea 773 EMail: jkna@popeye.snu.ac.kr 775 Sungho Cho 776 Information Networking & Computing Lab. 777 School of Computer Science and Engineering, 778 Seoul National University, Seoul Korea 779 EMail: shcho@popeye.snu.ac.kr 781 Chongkwon Kim 782 Information Networking & Computing Lab. 783 School of Computer Science and Engineering, 784 Seoul National University, Seoul Korea 785 EMail: ckim@popeye.snu.ac.kr 787 Sungjin Lee 788 Global Standards & Research Team 789 Telecommunication R&D Center, 790 Samsung Electronics, KOREA 791 Email : steve.lee@samsung.com 793 Hyunjeong Kang 794 Global Standards & Research Team 795 Telecommunication R&D Center, 796 Samsung Electronics, KOREA 797 Email : hyunjeong.kang@samsung.com 799 Changhoi Koo 800 Global Standards & Research Team 801 Telecommunication R&D Center, 802 Samsung Electronics, KOREA 803 Email : chkoo@samsung.com