idnits 2.17.1 draft-kumazawa-nemo-tbdnd-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 783. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 789. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 53 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 247 has weird spacing: '...cribing overv...' == Line 380 has weird spacing: '...sements from ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 11, 2005) is 6864 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) == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '1') == Outdated reference: A later version (-02) exists of draft-ernst-generic-goals-and-benefits-01 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group M. Kumazawa 3 Internet-Draft Y. Watanabe 4 Expires: January 12, 2006 T. Matsumoto 5 S. Narayanan 6 Panasonic 7 July 11, 2005 9 Token based Duplicate Network Detection for split mobile network (Token 10 based DND) 11 draft-kumazawa-nemo-tbdnd-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 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 This Internet-Draft will expire on January 12, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 When multiple Mobile Routers share the same prefix, a Home Agent must 45 be able to verify whether the Mobile Routers share the same Mobile 46 Network or not. Otherwise, the Home Agent may not be able to forward 47 a data packet to a correct recipient since the recipient may not be 48 connected to the mobile router the Home Agent chooses to forward the 49 packet. This document describes a Token based Duplicate Network 50 Detection mechanism that enables a Home Agent to detect whether 51 multiple Mobile Rotuers claiming the same prefix are in the same 52 Mobile Network. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1 Wireless Personal Area Network (W-PAN) . . . . . . . . . . 6 60 3.2 Automobile network . . . . . . . . . . . . . . . . . . . . 6 61 3.3 Mobile Routers in a plane . . . . . . . . . . . . . . . . 6 62 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.1 Registration as an Owner . . . . . . . . . . . . . . . . . 8 64 4.2 Registration as a Borrower . . . . . . . . . . . . . . . . 9 65 4.3 Refreshment of Token . . . . . . . . . . . . . . . . . . . 10 66 4.4 Registration Request from Token based DND-unaware 67 Mobile Routers . . . . . . . . . . . . . . . . . . . . . . 11 68 5. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1 Mobile Network Prefix Option . . . . . . . . . . . . . . . 12 70 5.2 Token Option . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.2.1 Binding Acknowledgement . . . . . . . . . . . . . . . 13 72 6. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 14 73 6.1 Data Structure . . . . . . . . . . . . . . . . . . . . . . 14 74 6.2 Sending Binding Updates . . . . . . . . . . . . . . . . . 14 75 6.3 Receiving Binding Acknowledgements . . . . . . . . . . . . 15 76 6.4 Error Processing . . . . . . . . . . . . . . . . . . . . . 16 77 6.5 Token Update . . . . . . . . . . . . . . . . . . . . . . . 16 78 6.6 Returning Home . . . . . . . . . . . . . . . . . . . . . . 16 79 7. Home Agent operation . . . . . . . . . . . . . . . . . . . . . 17 80 7.1 Data Structures . . . . . . . . . . . . . . . . . . . . . 17 81 7.1.1 Binding Cache . . . . . . . . . . . . . . . . . . . . 17 82 7.1.2 Prefix Table . . . . . . . . . . . . . . . . . . . . . 17 83 7.2 Mobile Network Prefix Registration . . . . . . . . . . . . 17 84 7.3 Forwarding Packets . . . . . . . . . . . . . . . . . . . . 18 85 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 19 86 8.1 Protection of Tokens . . . . . . . . . . . . . . . . . . . 19 87 8.2 how to generate Tokens . . . . . . . . . . . . . . . . . . 19 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 90 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 Intellectual Property and Copyright Statements . . . . . . . . 22 93 1. Introduction 95 Today, Mobile Internet Access using various kinds of wireless access 96 technologies is gaining in popularity. This leads to the demand for 97 ubiquitous networking, where portable devices can be connected to the 98 Internet anywhere, at any time. To realize ubiquity, it is necessary 99 to select the network most suitable for mobile Internet access from 100 the various access networks available according to the user's 101 location and preference. However, it is difficult to add various 102 wireless access interfaces to all portable devices for reasons of 103 cost and size. 105 Wireless PAN (W-PAN) is one possible solutions enabling ubiquity. A 106 W-PAN consists of a collection of portable devices with short 107 distance wireless interfaces and some of them have additional access 108 interfaces providing connectivity to the Internet. Devices with such 109 Internet access interfaces need to provide session continuity of all 110 nodes in W-PAN even when they change points of attachment to the 111 Internet. 113 The NEMO Basic Support [2] provides the mobility of an entire 114 network. It realizes session continuity to all nodes in the Mobile 115 Network by maintaining bi-directional tunnels between Mobile Routers 116 and their Home Agents. Devices with Internet access interfaces in a 117 W-PAN act as Mobile Routers. Mobile Network with multiple Mobile 118 Routers providing multiple points of attachments to the Internet is 119 one of Multihomed Mobile Networks [1] [3]. 121 It is necessary to consider the issues relevant to the support of 122 Mobile Network Prefixes by multiple Mobile Routers in a single Mobile 123 Network. If each Mobile Router supports different prefixes, nodes in 124 the Mobile Network must change its source address when they send 125 packets via a different Mobile Router, which makes it difficult to 126 maintain continous sessions. And a Home Agent needs to forward a 127 data packet meant for a node to just one Mobile Router which supports 128 the prefix of the node. Hence, to provide advantages of multihoming, 129 it is important to allow multiple Mobile Routers in the same mobile 130 network to support the same prefix. However, in the NEMO Basic 131 Support protocol, a Home Agent can't know whether Mobile Routers 132 claiming the same prefix are in the same Mobile Network or not. If 133 Mobile Routers claiming the same prefix are in different places, 134 packets forwarded from the Home Agent to one of the Mobile Routers 135 might not reach correct recipient since it might be behind another 136 Mobile Router. This problem is called "split mobile network" and the 137 solution to detect split mobile network is called Duplicate Network 138 Detection (DND) and they have been discussed in the NEMO working 139 group mailing list [6]. 141 Some solutions have already been proposed in the mailing list. In 142 the proposed solutions, a Home Agent confirms connectivity between 143 the Mobile Routers claiming the same prefix before it acknowledges a 144 new binding update. These solutions have the following problems: 146 o If the bi-directional tunnel between the first Mobile Router and 147 the Home Agent is unavailable temporarily, the DND test can't be 148 done. 150 o Confirmation of connectivity before acknowledgement leads to some 151 delay. 153 This document describes a new DND solution using Tokens (Token based 154 DND). The Token based DND can do DND tests without above problems. 155 Since the Token based DND is compatible with NEMO Basic Support, 156 Token-based-DND-aware Mobile Routers and Home Agent can coexist with 157 existing Mobile Routers and Home Agents. 159 2. Terminology 161 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119[7]. 165 This document assumes that the reader is familiar with Mobile IPv6 as 166 defined in [5] and with the concept of Mobile Router defined in the 167 NEMO terminology document [4]. 169 Owner 171 When a Mobile Router owns Mobile Network prefixes (ex. manual- 172 configured or obtains with DHCP), the Mobile Router is defined as 173 an Owner of the Prefixes. 175 Borrower 177 When a Mobile Router supports a Mobile Network prefix from the 178 Owner of the Prefix, the Mobile Router is defined as an Borrower 179 of the Prefix. 181 Token 183 It is a number associated with a Mobile Network Prefix. It is 184 generated and updated by the Owner of the Prefix. A Token is set 185 in a Token option following the Mobile Network Prefix Option in a 186 Binding Update and registered with its Home Agent. A Token is 187 also distributed with the Mobile Network Prefix from the Owner to 188 other Mobile Routers (Borrowers) using Router Advertisements. A 189 Token is used for the Home Agent to confirm whether the Borrowers 190 are connected to the Owner or not. The way to generate Token is 191 discussed in Section 8.2. One of the simplest ways is just 192 generating a random number. All zero means 'NULL' and that the 193 Owner doesn't allow its own Prefix to be shared. 195 3. Usage scenarios 197 3.1 Wireless Personal Area Network (W-PAN) 199 Alice enjoys music downloaded via her cellular phone (working as a 200 MR) with her silicon player. These devices are connected via 201 Bluetooth and they form a W-PAN . She adds a PDA with 802.11b 202 interface and Bluetooth into her W-PAN as a MR. The silicon player 203 doesn't have to change its source address in using the PDA since it 204 is configured with the same MNP as her cellular phone. 206 One day she leaves her PDA switched on at home. It continues sending 207 Binding Updates periodically and the Home Agent sends some packets 208 destined for the player to it. 210 When the DND operates, the HA will be aware that the PDA is away from 211 the cellular phone, and will reject the BU from PDA. Thereby, all 212 packets will be correctly sent to the player via the phone. 214 If she leaves the phone instead of the PDA, which is the owner of the 215 MNP, the PDA can't keep using it and has to obtain another MNP. 217 3.2 Automobile network 219 Bob goes for a drive with his friends. All of their cellular phones 220 work as MRs and so the NEMO has multiple cellular interfaces to 221 enable broadband communication. 223 When they enjoy video transferred via the MRs with a monitor in Bob's 224 car, one of them gets down off the car. 226 For the decreased bandwidth Bob sends the streaming server control 227 messages to lower the quality of the video. However, he can't 228 complete the operation since replies from the server are sent to the 229 cellular phone outside of the car. 231 Without DND, the user must operate his cellular phone when she/he 232 moves away from the NEMO. 234 3.3 Mobile Routers in a plane 236 A plane is equipped with Multiple MRs for load balancing and 237 increasing bandwidth. 239 A MNP of each MR will be shared among other MRs and be revoked in the 240 case it is relocated to another plane automatically using DND. 242 The DND will help network administrators to keep the integrity 243 between the location of MRs and the MNP shared by them. 245 4. Overview 247 Figure 1 shows an example network for describing overview of the 248 operation. 250 +----+ 251 | HA | 252 +--+-+ 253 | 254 +-----------------------+ +------+ 255 | Internet |-----+ CN | 256 +-----------------------+ +------+ 257 | | 258 +-----+ +-----+ 259 | MR1 | | MR2 | 260 +--+--+ +--+--+ 261 |P1:: |P2:: 262 --------------------------- 263 | P1::a | P2::b 264 +--+--+ +--+--+ 265 | LFNa| | LFNb| 266 +-----+ +-----+ 268 Figure 1: example network 270 MR1 and MR2 establish bi-directional tunnels with their Home Agent. 271 Mobile Network Prefixes MR1 and MR2 register are P1 and P2 272 respectively. LFNa and LFNb configures its address with P1::a and 273 P2::b. MR1, MR2, and LFNa,LFNb are connected via a link. This 274 configuration can be expressed as (2,1,2) based on the notation in 275 [1]. This Mobile Network consists of two logical independent network 276 P1::/64 and P2::/64. MR1 can neither forward LFNb's packets nor MR2 277 can do LFNb's ones currently. 279 4.1 Registration as an Owner 281 As MR1 is the Owner of prefix P1, MR1 generates and updates a Token 282 corresponding to P1. MR1 sends a Binding Update including a Mobile 283 Network Prefix Option of P1 to the Home Agent when it attaches to a 284 new access router. And MR1 sets a Prefix Delegated flag (D) to 0 in 285 the Mobile Network Prefix option to indicate that it is the Owner of 286 P1 and MUST put a Token option next to that in the Binding Update. 288 If the Home Agent receives and processes the message successfully, 289 the Home Agent stores the token and acknowledges it by sending MR1 a 290 Binding Acknowledgement indicating that the prefix and the Token is 291 processed successfully. 293 After MR1 receives the Binding Acknowledgement, MR1 starts 294 advertising P1 and the Token using Router Advertisements in the 295 Mobile Network. 297 After MR2 registers P2 and the corresponding Token, it advertises 298 them in the same way as MR1. 300 MR1(owner of P1) MR2(owner of P2) HA 301 | | | 302 |-----BU [P1, token, owner]--------|--------------------------------->| 303 | | | 304 |<---------------------------------|---------BA [status=OK]-----------| 305 | | | 306 |--------RA[P1, token]------------>| | 307 | | | 308 | |-----BU [P2, token, owner]------->| 309 | | | 310 | |<--------BA [status=OK]-----------| 311 | | | 312 |<--------RA[P1, token]------------| | 314 Figure 2: sequence: Registration as an Owner 316 Figure 2 shows the sequence where MR1 and MR2 register their own 317 prefixes as Owners. 319 4.2 Registration as a Borrower 321 When MR2 receives a Router Advertisement with prefix option including 322 P1 and the corresponding Token from MR1, MR2 configures P1 as a 323 prefix which it supports in addition to P2. 325 To indicate support of P1 and P2 to the Home Agent, MR2 sends a 326 Binding Update with two Mobile Network Prefix Options followed by 327 corresponding Token options respectively. The token options for each 328 of the prefix MUST follow the network prefix option as the ordering 329 is used to match a particular prefix to a particular token. 331 Figure 3 shows options in the Binding Update sent from MR2 to the 332 Home Agent. First MNP option includes P2 with the Prefix Delegated 333 Flag (D) set to 0 and the next MNP option includes P1 with the flag 334 set to '1'. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length |0| Reserved | Prefix Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 . Mobile Network Prefix(P2) . 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length | Reserved | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Token for P2 (generated by MR2) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length |1| Reserved | Prefix Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 . Mobile Network Prefix(P1) . 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Length | Reserved | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Token for P1 (generated by MR1) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Figure 3: Mobility Options of the Binding Update sent from MR2 362 When the Home Agent receives the Binding Update from MR2, it updates 363 the entry of P2 and examines the Token option following the prefix 364 option of P1. When it equals to the Token registered by MR1, the 365 Home Agent acknowledges the Binding Update by sending a Binding 366 Acknowledgement. MR2 becomes the Owner of P2 and the Borrower of P1 367 after the registration finishes successfully. MR1 registers as the 368 Owner of P1 and the Borrower of P2 as well. Hence data packets meant 369 for P1 and P2 can be forwarded via either MR1 or MR2. 371 4.3 Refreshment of Token 373 A Token is updated periodically and registered with a Home Agent by 374 the Owner of the prefix. After the Owner finishes registration 375 successfully, they include the updated Tokens in Router 376 Advertisements. 378 When the Borrower finds the Token updated, it sends a Binding Update 379 with the update Token to the Home Agent. If the Borrower moves away 380 from the Mobile Network and Router Advertisements from the Owner do 381 not reach it, it can't obtain the updated Token. After the Token is 382 updated, Binding Updates with old Tokens are rejected by the Home 383 Agent. Hence, a Borrower which moves away from the mobile network 384 can't keep sharing the prefix. 386 4.4 Registration Request from Token based DND-unaware Mobile Routers 388 A Binding Update without Token option means that the prefix must not 389 be shared with any Mobile Router. Hence Mobile Network Prefixes 390 owned by Mobile Routers unaware of Token based DND will not be 391 shared. 393 5. Format 395 5.1 Mobile Network Prefix Option 397 A new Prefix Delegated flag (D) is included in a Mobile Network 398 Prefix Option to indicate that the prefix is owned (0) or borrowed(1) 399 by a Mobile Router sending the Binding Update. The rest of the 400 Mobile Network Prefix Option format remains the same as defined in 401 [2]. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length |D| Reserved | Prefix Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 + + 410 | | 411 + Mobile Network Prefix + 412 | | 413 + + 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Prefix Delegated Flag (D) 419 The Prefix Delegated Flag is used to indicate to its Home Agent 420 that the Mobile Network Prefix is owned or borrowed. If the flag 421 is set to 0, the prefix is owned by the Mobile Router. If the 422 flag is set to 1, the prefix is borrowed from another Mobile 423 Router(Owner). 425 5.2 Token Option 427 Token options are included in a Binding Update. A Token option 428 corresponds to a Mobile Network Prefix Option placed ahead it. 430 Token options are also included in Router Advertisements distributed 431 from an Owner to Borrowers. In a Router Advertisement, a Token 432 option is placed next to a Prefix Option including the Mobile Network 433 Prefix. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | Length | Reserved | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Token | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Type 445 TBA 447 Length 449 8 bit unsigned integer indicating the length in octests of the 450 option excluding the type and length fields. Set to 8. 452 token 454 2 bytes field contains token. 456 5.2.1 Binding Acknowledgement 458 The Binding Acknowledgement format used in this document is the same 459 as defined in [2]. This document introduces the following new 460 Binding Acknowledgement status values. 462 2 (TBA) DND test and set up are completed successfully 464 6. Mobile Router Operation 466 A Mobile Router is defined as either Owner or Borrower for each 467 Mobile Network Prefix it supports. An Owner and Borrowers share 468 Mobile Network Prefixes using Token. 470 6.1 Data Structure 472 A Mobile Router maintains a Binding Update List, described in Section 473 5.1 of NEMO Basic Support specification [2]. This document 474 introduces a new Token field and a Prefix Delegated Flag (D). The 475 followings are relationships between Token and Prefix Delegated Flag 476 (D). 478 Prefix Delegated Flag (D) is set to 0 ( the Prefix is owned by the 479 Mobile Router) 481 * Token is generated or updated by the Owner. 'NULL' in Token 482 field means that the Prefix is not shared. 484 Prefix Delegated Flag (D) is set to 1 (the Prefix is borrowed from an 485 Owner) 487 * Token is extracted from Router Advertisements sent from the 488 Owner. 490 6.2 Sending Binding Updates 492 A Mobile Router sends a Binding Update including Mobile Network 493 Prefix Options described in Section 5.2 of [2]. The difference from 494 [2] is that a Mobile Router sets a Prefix Delegated Flag (D) of each 495 Mobile Network Prefix Option and adds Token Options if necessary. A 496 Mobile Router MUST send a Binding Update in Explicit mode when it 497 uses any Token option. A Mobile Router includes options and sets 498 flag of the options in the Binding Update as follows. When the 499 Mobile Router includes Token Options in a Binding Update, it MUST put 500 each Token Option next to the corresponding Mobile Network Prefix 501 option. 503 Owner 505 The Mobile Router sets the Prefix Delegated Flag (D) to 0 in a 506 Mobile Network Prefix Option and MUST put a Token Option next to 507 it when the Mobile Router allows the Prefix to be shared. The 508 Mobile Router doesn't put a Token Option when it doesn't allow 509 sharing the Prefix. 511 Borrower 513 A Mobile Router sets the Prefix Delegated Flag (D) to 1 in a 514 Mobile Network Prefix Option and puts a Token Option next to it. 515 Mobile Network Prefix Option MUST be followed by the corresponding 516 Token Option when its Prefix Delegate Flag is set to '1'. 518 6.3 Receiving Binding Acknowledgements 520 If the status field of Binding Acknowledgement is '2' to indicate 521 that the Home Agent processed prefixes and Tokens successfully, the 522 Mobile Router assumes that the Home Agent set up forwarding for all 523 the Prefixes including borrowed ones. The Mobile Router can then 524 start using bi-directional tunnels for the Prefixes. If the status 525 is set to '0', the Mobile Router assumes that the Home Agent isn't 526 aware of the Token based DND and acts as described in [2]. In this 527 case the Mobile Router SHOULD re-send the Binding Update including 528 only its own Prefixes without Token Options. 530 After the Binding finishes successfully, the Mobile Router then 531 starts sending Router Advertisement including Prefixes which it owns 532 and corresponding Tokens if any. The Mobile Router MUST NOT 533 advertise Prefixes nor Tokens of which it is not the Owner but the 534 Borrower. The Mobile Router SHOULD NOT include a Token option which 535 is set to NULL in Router Advertisement messages. 537 When the Mobile Router receives a Router Advertisement including a 538 new Prefix and a corresponding Token from the Owner of the Prefix, it 539 MAY become the Borrower of the Prefix by sending a Binding Update 540 along with the token option. 542 6.4 Error Processing 544 This document doesn't introduce any new Binding Acknowledgement 545 status value for errors. Since the Token based DND operates only in 546 Explicit mode, the Mobile Router interprets the Binding 547 Acknowledgement status values as described in Section 5.4.2 of [2]. 549 A Mobile Network Prefix with Prefix Delegated Flag set to '1' will be 550 rejected in two cases. One is when the Token is different from that 551 registered by the Owner and the other is when no Owner registers the 552 Prefix. The Binding Acknowledgement is returned with status '141' in 553 both of the cases. In these cases, the Mobile Router SHOULD wait 554 until an updated Token is distributed from the Owner or send a 555 Binding Update without the Mobile Network Prefix borrowed from the 556 Owner. 558 6.5 Token Update 560 An Owner MUST update Tokens periodically. When a Borrower moves away 561 from the mobile network, the Tokens held by the Borrower would be 562 obsolete and enable the Home Agent to find the movement of the 563 Borrower. The Owner MUST advertise the updated Tokens using Router 564 Advertisement as soon as it finishes the registration of the Tokens. 565 The Owner MUST NOT advertise the update Tokens until it receives the 566 Binding Acknowledgement message indicating that the Home Agent 567 finishes the registration successfully. The Owner need not include 568 Token options in the Binding Update when it doesn't intend to update 569 them. The Owner sets 'NULL' to the Token in the Binding Update when 570 it intends to stop the sharing of the prefix by other Mobile Routers 571 (Borrowers). The Borrower MUST send a Binding Update including the 572 update Tokens as soon as it finds the Tokens updated in Router 573 Advertisement. 575 6.6 Returning Home 577 When a Mobile Router returns home, it de-registers with its Home 578 Agent. After de-registration, the Mobile Router MUST NOT include any 579 Token option corresponding to its own Prefixes in Router 580 Advertisements since Tokens can't be registered with the Home Agent 581 at home. This means that Mobile Network Prefixes can't be shared 582 while the Owner of the Prefixes is connected to home link. The 583 Borrower MUST send a Binding Update not including the Prefixes as 584 soon as it finds the corresponding Token options removed from Router 585 Advertisement from the Owner. 587 7. Home Agent operation 589 7.1 Data Structures 591 7.1.1 Binding Cache 593 The Binding Cache is a conceptual data structure described in detail 594 in [5] and [2]. This document introduces a new Token field and a 595 Prefix Delegated Flag (D). A Home Agent stores a Token corresponding 596 to a Mobile Network Prefix when the Prefix Delegated Flag is set to 597 '0' in the Mobile Network Prefix Option. 599 7.1.2 Prefix Table 601 Prefix Delegated Flag (D) might need to be introduced in a Prefix 602 Table Entry since the Home Agent SHOLUD be able to prevent the 603 following cases: 605 o As an Owner, a Mobile Router claims Mobile Network Prefixes owned 606 by another Mobile Router (Owner). 608 o A Mobile Router borrows Mobile Network Prefixes not allowed from 609 the Owner of them. 611 7.2 Mobile Network Prefix Registration 613 A Home Agent performs the following check of all of the Mobile 614 Network Prefix Options and Token Options in the Binding Update in 615 addition to checks in [2] in the case Mobile Router Flag (R) is set. 617 o If there is any Token option which isn't placed next to a Mobile 618 Network Prefix Option, it MUST reject the Binding Update and send 619 a Binding Acknowledgement with status set to 143 (Forwarding Setup 620 failed). 622 When the Prefix Delegated Flag (D) is set to '0', it performs the 623 following checks. 625 o If there is already a binding cache entry or Prefix Table entry 626 which has the same Prefix owned by another Mobile Router (Prefix 627 Delegated Flag (D) is set to '0'), the Home Agent MUST reject the 628 Binding Update and send a Binding Acknowledgement with status set 629 to 142 ( Not Authorized for Prefix). 631 When the Prefix Delegated Flag (D) is set to '1', it performs the 632 following checks. 634 o The Home Agent MUST reject the Binding Update and send a Binding 635 Acknowledgement with status set to 141 (Invalid Prefix) in the 636 following cases: 638 * The Mobile Network Prefix Option isn't followed by a Token 639 Option. 641 * NULL (all zero) is set in a Token Option. 643 * The Mobile Network Prefix is not registered by any Owners. 645 * The Token is different from that registered by an Owner in the 646 Binding Cache Entry. 648 When the Home Agent has a valid binding cache entry with a Prefix 649 Delegate Flag (D) set '1', it SHOULD NOT delete the entry with just 650 one error of a Token. This is because a Borrower may not be able to 651 obtain an updated Token as soon as the update occurs necessarily. 652 However, the Home Agent might need to delete the entry if the number 653 of errors exceeds threshold before it expires. 655 If all checks are passed, the Home Agent creates a binding cache 656 entry for Mobile Router's Home Address, or updates the binding cache 657 entry if it already exists. When it has a valid binding cache entry 658 with a Prefix Delegated Flag (D) set to '0' and it receives the 659 Binding Update including the Mobile Network Prefix Option without a 660 Token Option, the Home Agent doesn't update the Token. When it 661 creates a binding cache entry with Prefix Delegated Flag (D) set to 662 '0' by receiving a Binding Update including a Mobile Network Prefix 663 Option without a Token Option, it sets NULL in the Token field of the 664 entry. 666 After setting up Mobile Network Prefixes and corresponding Tokens and 667 forwarding, the Home Agent sends a Binding Acknowledgement with 668 status set to '2' to indicate that the setup finishes successfully. 669 If all of the tokens set up with the Binding Update are configured to 670 'NULL' and no Token option is included in the Binding Update, it MUST 671 send the Binding Acknowledgement with status '0'. 673 7.3 Forwarding Packets 675 When the Home Agent forwards a data packet destined for a Mobile 676 Network Prefix, the Home Agent selects one Mobile Router among an 677 Owner and Borrowers of the Prefix. This selection will be done based 678 on various policies. The selection of Mobile Router is outside the 679 scope of this document. 681 8. Security Consideration 683 8.1 Protection of Tokens 685 Tokens MUST NOT be obtained except by a Home Agent and nodes 686 including Mobile Routers within a Mobile Network. Token Option in 687 Binding Updates from a Mobile Router to the Home Agent would be 688 protected with IPsec. Router Advertisements including Token Option 689 MUST be prevented from being snooped by nodes outside the Mobile 690 Network using some security mechanism such as layer 2 encryption. 692 8.2 how to generate Tokens 694 A Token is used for a Home Agent to confirm reachability between an 695 Owner and Borrowers via just one link. The following is not goal of 696 using Tokens: 698 o To indicate to the Home Agent that a Mobile Router claiming a 699 Mobile Network Prefix is a true Owner of the Prefix. 701 Hence it is enough to generate a random number as a Token and a Token 702 need not be associated with any information. 704 9. References 706 [1] Ernst, T., "Analysis of Multihoming in Network Mobility 707 Support", draft-ietf-nemo-multihoming-issues-02 (work in 708 progress), February 2005. 710 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 711 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 712 January 2005. 714 [3] Ernst, T., "Goals and Benefits of Multihoming", 715 draft-ernst-generic-goals-and-benefits-01 (work in progress), 716 February 2005. 718 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 719 draft-ietf-nemo-terminology-03 (work in progress), 720 February 2005. 722 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 723 IPv6", RFC 3775, June 2004. 725 [6] IETF NEMO (NEtwork MObility) working group mailing list, 726 Archive: http://www.ietf.org/html.charters/nemo-charter.html. 728 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 729 Levels", BCP 14, RFC 2119, March 1997. 731 Authors' Addresses 733 Masayuki Kumazawa 734 Panasonic (Matsushita Electric Industrial Co., Ltd.) 735 4-5-15 Higashi-shinagawa 736 Shinagawa-ku, Tokyo 737 Japan 739 Yasuhiko Watanabe 740 Panasonic (Matsushita Electric Industrial Co., Ltd.) 742 Taisuke Matsumoto 743 Panasonic (Matsushita Electric Industrial Co., Ltd.) 745 Sathya Narayanan 746 Panasonic Digital Networking Lab 747 Two Research Way, 3rd Floor 748 Princeton, NJ 08536 749 USA 751 Appendix A. Change Log 753 From -00 to -01 755 o Added (n,*,n) case to (n,*,1) case. 757 o Moved Prefix Delegated Flag from Binding Update to Mobile Network 758 Prefix Option 760 o Only Owner can generate tokens while a Home Agent could also do in 761 -00. 763 From -01 to -02 765 o Added usage scenarios (Section 3) 767 Intellectual Property Statement 769 The IETF takes no position regarding the validity or scope of any 770 Intellectual Property Rights or other rights that might be claimed to 771 pertain to the implementation or use of the technology described in 772 this document or the extent to which any license under such rights 773 might or might not be available; nor does it represent that it has 774 made any independent effort to identify any such rights. Information 775 on the procedures with respect to rights in RFC documents can be 776 found in BCP 78 and BCP 79. 778 Copies of IPR disclosures made to the IETF Secretariat and any 779 assurances of licenses to be made available, or the result of an 780 attempt made to obtain a general license or permission for the use of 781 such proprietary rights by implementers or users of this 782 specification can be obtained from the IETF on-line IPR repository at 783 http://www.ietf.org/ipr. 785 The IETF invites any interested party to bring to its attention any 786 copyrights, patents or patent applications, or other proprietary 787 rights that may cover technology that may be required to implement 788 this standard. Please address the information to the IETF at 789 ietf-ipr@ietf.org. 791 Disclaimer of Validity 793 This document and the information contained herein are provided on an 794 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 795 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 796 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 797 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 798 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 799 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 801 Copyright Statement 803 Copyright (C) The Internet Society (2005). This document is subject 804 to the rights, licenses and restrictions contained in BCP 78, and 805 except as set forth therein, the authors retain all their rights. 807 Acknowledgment 809 Funding for the RFC Editor function is currently provided by the 810 Internet Society.