idnits 2.17.00 (12 Aug 2021) /tmp/idnits26433/draft-wakikawa-mip6-no-ndp-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 722. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the Mobile Node returns home, it de-registers a binding for the interface. While the bindings for the interfaces attached to the foreign link are still active. Intercepting packets, the Home Agent can decide whether it tunnels to the foreign interface or routes to the home interface of the Mobile Node. To do so, the Home Agent must know that the Mobile Node is back to the home link. However, if the binding is deleted according to [7], there is no way for the Home Agent to know that the Mobile Node is at the home, too. The Home Agent SHOULD invalidate the binding for the interface attached to the home link and MAY NOT delete it. It can alternatively mark that the Mobile Node is at the home link, too. In this document, as an example, the Home Agent inserts the Home Address of the Mobile Node in the Care-of Address field of the Mobile Node. The binding is named "Home Binding" in this doc. The Home Agent MAY manage this home binding as same as the other binding entry in terms of lifetime validation, etc. The Mobile Node MAY send multiple binding de-registration to keep this home binding active. Alternatively, the Home Agent can use infinity lifetime for the lifetime of the home binding. When the Mobile Node leaves the Home Link, it can update the home binding to the normal binding. Before that, the Home Agent believes the Mobile Node is at the home and may route packets for the Mobile Node to the Home Link. -- 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 (February 2007) is 5574 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: draft-ietf-nemo-home-network-models has been published as RFC 4887 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '1') == Outdated reference: draft-ietf-monami6-multiplecoa has been published as RFC 5648 ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '4') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '5') ** Obsolete normative reference: RFC 3775 (ref. '7') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) == Outdated reference: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group R. Wakikawa 3 Internet-Draft Keio University 4 Expires: August 5, 2007 M. Aramoto 5 Sharp 6 February 2007 8 Elimination of Proxy NDP from Home Agent Operations 9 draft-wakikawa-mip6-no-ndp-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document summarizes operations of home agent without using the 43 proxy NDP. The Proxy NDP is mainly used to intercept packets by a 44 Home Agent on Mobile IPv6 and NEMO. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Mobile IP6: Virtual Home Link . . . . . . . . . . . . . . 5 54 3.2. Network Mobility: Aggregated Home Link . . . . . . . . . . 6 55 3.3. Monami6: Simultaneous Use of Home and Foreign Link . . . . 7 57 4. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 9 59 5. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 11 60 5.1. Duplicate Address Detection . . . . . . . . . . . . . . . 11 61 5.2. Sending Router Advertisement . . . . . . . . . . . . . . . 11 62 5.3. Deliverying Packets to the Mobile Node . . . . . . . . . . 12 63 5.4. Filtering Packets for Home Addresses . . . . . . . . . . . 12 64 5.5. Returing Home . . . . . . . . . . . . . . . . . . . . . . 14 66 6. Mobile Node & Correspondent Node Operation . . . . . . . . . . 15 68 7. Multiple Care-of Address Registration . . . . . . . . . . . . 16 70 8. Related Information . . . . . . . . . . . . . . . . . . . . . 19 72 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 11.1. Normative reference . . . . . . . . . . . . . . . . . . . 21 78 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 80 Appendix A. Change Log From Previous Version . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 83 Intellectual Property and Copyright Statements . . . . . . . . . . 23 85 1. Introduction 87 In Mobile IPv6, one of design limitations is the use of Proxy 88 Neighbor Discovery on Home Agent. Mobile IPv6 uses the proxy 89 Neighbor Discovery Protocol (proxy NDP) to intercept packets meant 90 for mobile nodes on a home agent at a home link. When the proxy NDP 91 is used, a home prefix must be strictly configured at the physical 92 link which the home prefix is defined in the Internet topology. 93 Moreover, the performance of NDP may effect that of Mobile IPv6 if 94 the number of mobile nodes are served by a home network prefix. 96 Elimination of the Proxy NDP from Mobile IPv6 and NEMO may bring some 97 advantages such as flexible home prefix configuration, reduction of 98 NDP overhead, disengagement from the home link bandwidth. In NEMO 99 Working Group, [1] introduces various home prefix configurations such 100 as the extended home prefix, the extended home prefix and the virtual 101 home prefix. Proxy NDP is useless specially when the extended home 102 prefix is used. Finally, the fact that packets are captured by NDP 103 shows that the maximum bandwidth for all the mobile nodes are limited 104 to the home link bandwidth. 106 We introduce special use case for Monami6 work. When a mobile node 107 returns home with multiple interfaces, it can only activate either an 108 interface attached to the home link or an interface attached to a 109 foreign link [9]. If it tries to active both interfaces, the Home 110 Agent and the Mobile Node will defend the Home Address by NDP 111 simultaneously. Consequently, it leads DAD problem. This problem 112 has been discussed on the Multiple Care-of Address Registration [2] 113 in Monami6 Working Group. By eliminating Proxy NDP, the mobile node 114 can utilize both of interfaces attached to the home and the foreign 115 link at the same time. 117 This document shows the possible configuration and modification when 118 a home agent stop the proxy NDP for Mobile IP and NEMO. The Mobile 119 Node is transparent to this NDP elimination, though it may skip 120 several steps from returning home operation. 122 2. Terminology 124 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [3] 128 Readers are expected to be familiar with all the terms defined in the 129 RFC3753 [4] and the NEMO Terminology draft [5] 131 No new additional term is defined in this document. 133 3. Use Case 135 3.1. Mobile IP6: Virtual Home Link 137 The first case is that home prefix is configured as the virtual home 138 link on Home Agent as shown in Figure 1. The operator may choose 139 this deployment scenario to reduce NDP overhead caused by number of 140 Mobile Nodes at the home link. 142 The home link is not configured at the physical link and all of the 143 Mobile Nodes moves only in foreign links and never come back to the 144 home link. The Home Agent does not intercept packets from a Mobile 145 Node on the home link by the Proxy NDP. On the other hand, the Home 146 agent intercepts all the packets sent by a Correspondent node. The 147 correspondent node is always located on the Internet (i.e. not home 148 link). To do so, the Home agent is configured as an external router 149 at the routing functions in order to intercept packets without the 150 proxy NDP. 152 Even if the home link is configured at the physical link, the proxy 153 NDP can be skipped. This is also useful scenario for Mobile IP 154 operators, because the performance of packet interception is released 155 from the limitation of the home link bandwidth. Even if the external 156 link toward the Internet is high speed network like 10Gbps, the 157 performance is limited to the home link bandwidth on the regular 158 Mobile IP and NEMO. The operator needs not to invest to the home 159 link bandwidth with our modified operation. In addition to this, 160 plenty of Proxy NDP entries are burden to a Home Agent, if the number 161 of Mobile Nodes are served by the Home Agent. Our proposal can 162 remove this burden from the Home Agent. 164 For this operation, the Home Agent SHOULD send Router Advertisements 165 which on-link flag is unset. A node receiving the Router 166 Advertisements does not maintain a prefix route (on-link route) and 167 always uses a default route to send packets. Even if a destination 168 node is on-link node, the node sends packets through its default 169 route (i.e. Home Agent in this case). The detail operation is 170 explained in Section 5.2. 172 +---=------+ 10Gbps +----+ 173 | Internet +==============+ HA | 174 +----+---+-+ +--+-+ 175 |Foreign Link | Virtual Home Link/64 176 -----+------- - - - - - - - - 177 |CoA1 (100Mbps) 178 +--+--+ 179 | MN | -----> No returning home 180 +--+--+ 182 Figure 1: MIP 184 3.2. Network Mobility: Aggregated Home Link 186 The NEMO specification [6] allows that a home link is configured as 187 the aggregated home prefix. The Home Agent manages the aggregated 188 network address blocks and assigns an internal network prefix(es) to 189 a Mobile Router as shown in Figure 2. In such a deployment scenario, 190 the Home Agent cannot intercept the packets meant for the mobile 191 network prefix by the proxy NDP, because the Proxy NDP assumes 64 192 prefix length on a link. This is not explicitly described in the NDP 193 specification, but the NDP specification implies this. It is 194 necessary for Home Agent to intercept the packets without using Proxy 195 NDP. 197 It is also useful that the Home Agent is configured as an external 198 router of the aggregated home networks and the Home Agent intercepts 199 packets according to the IP routing. After the Home Agent receives 200 packets meant for the mobile network prefix, it routes packets based 201 on binding caches to the target mobile router. 203 +----------+ +----+ 204 | Internet +--------------+ HA | 205 +----+---+-+ +--+-+ 206 | | 207 +--+--+ ------+-------- 208 | MR | Aggregated Home Link P1::/48 209 +--+--+ 210 | P1:a::/64 211 ---------+----------- 212 | | | | ... 213 LFN LFN LFN LFN ... 215 Figure 2: Aggregated Home Link 217 3.3. Monami6: Simultaneous Use of Home and Foreign Link 219 According to the Multiple Care-of Address Registration [2], when a 220 multihomed mobile node returns home, it MUST choose one operation 221 from following options: 223 o The mobile node returns home by an interface attached to the home 224 link. It de-registers all its bindings from the Home Agent. 225 After the de-registration, the mobile node sends and receives all 226 the packets via the interfaces attached to the home link. 228 o The mobile node does not return home and intentionally disables 229 the interfaces attached to the home link. The mobile node sends 230 and receives all its packets via the interfaces attached to 231 foreign links. 233 The current specification does not allow to maintain multiple 234 bindings that one is attached to the home link and the other is 235 attached to the foreign link simultaneously. This restriction is 236 related to the Proxy NDP operation on a Home Agent. The Home Agent 237 needs to defend a mobile node's home address by the proxy NDP for 238 packet interception, while the mobile node defends its home address 239 by regular NDP to send and receive packets at the interface attached 240 to the home link. Two nodes, Home Agent and Mobile Node, compete ND 241 state. This will causes address duplication problem at the end. 243 This document recommends not to use the Proxy NDP for the scenario 244 shown in Figure 3. If the proxy NDP is disabled, the main problem 245 can be solved. In the Multiple Care-of Address Registration case, 246 the elimination of Proxy NDP enable that Mobile Node and Home Agent 247 maintain multiple bindings, one of the Mobile Node's interface is 248 attached to the home link and the other is attached to the foreign 249 link. 251 +----------+ +----+ +----+ 252 | Internet +--------------+ R | | HA | 253 +----+---+-+ +--+-+ +--+-+ 254 |Foreign Link | | 255 --------+------------ ------+---+---+--------- 256 | | Home Link 257 |CoA1 | 258 +--+--+ | 259 | MN +------------------------+ 260 +--+--+ 261 Figure 3: MCoA 263 4. Home Agent Configuration 265 In Mobile IPv6 and NEMO, two possible placements of Home Agents are 266 originally introduced. The difference between them is whether the 267 Home Agent acts as an external router or not as shown in Figure 268 Figure 4. 270 In this document, HA is always an external router so that it can 271 intercept all the packets meant for mobile nodes without the proxy 272 neighbor discovery protocol. The Home Agent intercepts packets 273 according to the IP routing. All the packets toward the home prefix 274 will be routed to the Home Agent first. When the Home Agent receives 275 packets meant for the home prefix, it then route packets based on 276 routing information and binding cache to the target mobile node. If 277 a binding cache is found for the packets' destination, it then 278 tunnels the packets to the mobile node according to the binding cache 279 entry. Otherwise, the Home Agent routes packets to the home link. 281 +----------+ +----------+ 282 | Internet | | Internet | 283 +----+-----+ +----+-----+ 284 | | 285 +-+-+ +----+ +-+--+ 286 | R | | HA | | HA | 287 +---+ +--+-+ +----+ 288 | | Home Link | Home Link 289 -----+----------+----------- -----+------------- 291 Figure 4: Home Agent Placements 293 Note that there is one drawback when a HA is placed as an external 294 router. Operators cannot utilize multiple home agents for a same 295 home prefix at a home link as introduced in [7]. Since the home 296 agent intercepts packets based on IP routing, it must be external 297 router. It is harder to achieve load-balancing by utilizing multiple 298 home agents on the home link. However, for the purpose of the home 299 agent reliability, the Home Agent Reliability protocol can be 300 operated with the specific configuration in Figure 5. In this case, 301 upper router can switch the routing based on the HA survivability as 302 shown in Figure 5 303 +----------+ 304 | Internet | 305 +----+-----+ 306 | 307 +-+-+ 308 +--+ R +--+ 309 | +---+ | 310 | | 311 +-+-+ +-+-+ 312 |HA1| |HA2| 313 +-+-+ +-+-+ 314 | | 315 --+---------+----- 316 Home Link 318 Figure 5: Multiple Home Agents Placement 320 5. Home Agent Operation 322 5.1. Duplicate Address Detection 324 RFC3775[7] uses the Proxy NDP to defend a Home Address of a Mobile 325 Node when the Mobile Node is away from the Home Link. When the 326 Mobile Node is away from the Home and registers its Care-of Address 327 to the Home Agent, the Home Agent defends the Home Address by the 328 proxy NDP for the Home Address. Thus, non of other nodes can pick 329 the Home Address at the Home Link even if the Mobile Node is not 330 visible on the Home Link. 332 When the Proxy NDP is eliminated specially on a physical configured 333 home link, the uniqueness of a home address should be carefully 334 verified. If a Mobile Node is away from the Home, its home address 335 can be picked by other Mobile Nodes on the Home Link because of no 336 Proxy ND entry of the Home Address. To prevent address duplication, 337 the Home Agent can filter the packets originated from the Home Link 338 based on the Binding Cache. Since the Home Agent is an external 339 router, all the traffic is passed through the Home Agent. When the 340 Home Agent intercepts packets from the Home Link and finds an active 341 binding cache entry for the same address with the packet's source 342 address, it can drop packets. For incoming packets, the Home Agent 343 can prioritize the binding cache database first and can tunnel 344 packets to the Mobile Node. The packets are never reached to the 345 malicious node who takes the home address of other mobile nodes. 347 As a result, although a third node (malicious node) can obtain a home 348 address which is already taken by other Mobile Node, it cannot send 349 and receive packets by using the home address. 351 5.2. Sending Router Advertisement 353 The Home Agent SHOULD send a Router Advertisement to the Home Link 354 for two purposes: address assignment and home link detection. The 355 Mobile Node generates a home address from the received router 356 advertisement. It also uses this to detect the home link. 358 In this document, the Home Agent MUST route all the incoming and 359 outgoing packets of the home link. For communication with a 360 Correspondent Node located on the home link, the packets MUST be 361 routed via the Home Agent. Otherwise, a malicious node can steal a 362 Home Address of the other Mobile nodes and communicates with 363 Correspondent nodes located on the Home Link by using the stolen Home 364 Address (HoA1) as shown in Figure 6. If the packet is always routed 365 to the Home Agent first, the packets sent by Correspondent Node will 366 be routed correctly to the right Mobile Node. 368 +----------+ 369 | Internet +--MN (HoA1) 370 +----+-----+ 371 | 372 +-+--+ 373 | HA | 374 +-+--+ 375 | Home Link 376 ---+--------+-------+----- 377 | | 378 CN Malicious (HoA1) 380 Figure 6: Malicious Node communicating with CN on the home link 382 For doing so, the Home Agent MUST generate Router Advertisement which 383 the on-link flag (L flag) [8] is unset, so that all the packets will 384 be routed via the Home Agent. Malicious nodes may directly route the 385 packets with the stolen home address, but packets sent by 386 Correspondent Node will reach to the right Mobile Node. 388 Moreover, when the Home Agent receives packets which destination and 389 source are both located on the home link, it MUST NOT generate ICMP 390 redirect to the sender. 392 5.3. Deliverying Packets to the Mobile Node 394 Although the Home Agent intercepts packets by IP routing, how to 395 tunnel packets to the Mobile Node is same as [7]. The Home Agent 396 refers the Binding Cache and encapsulates packets according to the 397 binding cache entry. 399 If a correspondent node is located at the home link, the node routes 400 packets to the Home Agent first because the on-link flag of Router 401 Advertisement is unset (See Section 5.2. The Home Agent intercepts 402 packets and tunnels packets to the Mobile Node only when the binding 403 cache entry for the packet's destination is available. Otherwise, it 404 can re-send the packet to the Home Link. In this case, the Home 405 Agent MUST NOT generate ICMP Redirect message to the sender. 407 5.4. Filtering Packets for Home Addresses 409 The Home Agent MUST operate the binding de-registration carefully if 410 the Proxy NDP is disabled on a physical home link. As soon as a 411 Mobile Node returns home, the Mobile Node can do DAD before binding 412 update for de-registration. It means the Home Agent cannot 413 distinguish whether either a right Mobile Node or a malicious node 414 operates DAD on the Home Link. Home Agent MUST prevent routing 415 packets of a Home Address during binding cache of the Home Address is 416 active so that it drops packets when the malicious node acquires the 417 Home Address of other Mobile Node. 419 All traffic is through the Home Agent (see Section 5.2), the Home 420 Agent MUST drop all the packets originated from the Home Link unless 421 the binding is deleted. When the binding is active, any packets 422 which source address is the Home Address MUST NOT generate from the 423 Home Link. For incoming packets from the external network (ex. 424 Internet), the Home Agent MUST NOT route the packets meant for a Home 425 Address to the Home Link when the binding cache for the Home Address 426 is active. If the packets meant for the Home Address are arrived 427 from a Correspondent Node located on the Home Link, it can tunnel 428 packets to the Mobile Node according to the Binding Cache. 429 Otherwise, it can routes packets to the Mobile Node located on the 430 Home Link. Figure 7 and Figure 8 show the example routing rules of 431 the Home Agent. 433 HoA:= Home Address 434 BC:= Binding Cache for HoA 435 source:= IPv6 Source Address Field 436 dest:= IPv6 Destination Address Field 438 If (BC == true) { 439 if (source == HoA) { 440 /* drop the packet */ 441 } else if (dest == HoA) { 442 /* tunnel the packet */ 443 } 444 } else if (BC == None) { 445 if (source == HoA) { 446 /* route the packet to the destination*/ 447 } else if (dest == HoA) { 448 /* route the packet to the Home Link */ 449 } 451 Figure 7: Rules for Packets meant for a Home Address Received from 452 the Home Link 454 HoA:= Home Address 455 innersource:= IPv6 Source Address Field of Inner IPv6 Header 456 source:= IPv6 Source Address Field 457 dest:= IPv6 Destination Address Field 458 BC:= Binding Cache for the innersource 459 tunneled:= IPv6-IPv6 Encapsulation Packet 461 if (tunneled == true && innersouce == HoA) { 462 /* for tunneled packets (i.e. packets to CN from MN) */ 463 if (BC == true) { 464 /* 465 * Route to the Destination after depacauslatition. 466 * 467 * It's required the outer source address (CoA) 468 * verification, too. 469 */ 470 } else { /* BC == none */ 471 /* drop the packet */ 472 } 473 } else { 474 /* for no tunneled packets (i.e. packets to MN from CN) */ 475 if (source == HoA) { 476 /* drop the packet, something odd happened. */ 477 } else if (dest == HoA) { 478 if (BC == true) { 479 /* Tunnel to the Mobile Node */ 480 } else if (BC == none) { 481 /* Route to the Home Link */ 482 } 483 } 484 } 486 Figure 8: Rules for Packets meant for a Home Address Received from 487 the external network (ex. Internet) 489 5.5. Returing Home 491 For Returning home, no modification is given in this specification. 493 6. Mobile Node & Correspondent Node Operation 495 No modification is required. This Specification is transparent to 496 Mobile Nodes and Correspondent Nodes 498 7. Multiple Care-of Address Registration 500 In the Multiple Care-of Address Registration [2], the Mobile Node 501 MUST disable either the interface attached to the home link or the 502 interfaces attached to the foreign link. This is because the Home 503 Agent defends the home address of the Mobile Node by proxy neighbor 504 advertisements. So as to avoid the home address duplication at the 505 home link, the Mobile Node MUST select whether it returns home or 506 not. If a binding is active for the Mobile Node, all packets routed 507 to the home link are intercepted by the Home Agent. On the other 508 hand, if the Mobile Node returns home, the Home Agent no longer 509 intercept packets and cannot tunnel the packets to the Mobile Node's 510 interface attached to the foreign link. 512 Figure 9 depicts the scenario where Mobile Node activates the 513 interface attached to the home link and the foreign link, and 514 communicates with all of the interfaces. Since the Home Agent does 515 not use Proxy Neighbor Advertisement to intercept packets, the Mobile 516 Node can utilize both of interfaces attached to the home link and the 517 foreign link simultaneously. The Home Agent can intercept packets by 518 IP routing, but not by proxy Neighbor Discovery. 520 +----+ 521 | CN | 522 +--+-+ 523 | 524 +----+-----+ +----+ 525 | Internet |--------------+ HA | 526 +----+---+-+ +--+-+ 527 |Foreign Link |Home Link 528 --------+------------ ------+------ 529 | | 530 |CoA1 | 531 +--+--+ | 532 | MN +--------------------+ 533 +-----+ 535 Binding Cache Database: 536 Home Agent's binding (No Proxy neighbor advertisement) 537 binding [a:b:c:d::EUI a:b:c:d::EUI BID1] (Home BC) 538 binding [a:b:c:d::EUI Care-of Address1 BID2] 539 Correspondent Node's binding 540 binding [a:b:c:d::EUI a:b:c:d::EUI BID1] (Home BC) 541 binding [a:b:c:d::EUI Care-of Address1 BID2] 542 or 543 None 545 Figure 9: Utilizing of both an interface attached to the Home Link 546 and an interface attached to the Foreign Link 548 When the Mobile Node returns home, it de-registers a binding for the 549 interface. While the bindings for the interfaces attached to the 550 foreign link are still active. Intercepting packets, the Home Agent 551 can decide whether it tunnels to the foreign interface or routes to 552 the home interface of the Mobile Node. To do so, the Home Agent must 553 know that the Mobile Node is back to the home link. However, if the 554 binding is deleted according to [7], there is no way for the Home 555 Agent to know that the Mobile Node is at the home, too. The Home 556 Agent SHOULD invalidate the binding for the interface attached to the 557 home link and MAY NOT delete it. It can alternatively mark that the 558 Mobile Node is at the home link, too. In this document, as an 559 example, the Home Agent inserts the Home Address of the Mobile Node 560 in the Care-of Address field of the Mobile Node. The binding is 561 named "Home Binding" in this doc. The Home Agent MAY manage this 562 home binding as same as the other binding entry in terms of lifetime 563 validation, etc. The Mobile Node MAY send multiple binding de- 564 registration to keep this home binding active. Alternatively, the 565 Home Agent can use infinity lifetime for the lifetime of the home 566 binding. When the Mobile Node leaves the Home Link, it can update 567 the home binding to the normal binding. Before that, the Home Agent 568 believes the Mobile Node is at the home and may route packets for the 569 Mobile Node to the Home Link. 571 For this operation, the Binding Unique Identifier sub-option is 572 modified as described in Figure Figure 10. The new Home flag is 573 introduced. When the H flag is set, the Home Agent MUST treat the 574 binding as the home binding. After intercepting the packets, the 575 Home Agent may tunnel the packets according to the active binding 576 cache(s) or route the packets to the home link according to the home 577 binding cache. Note that the H flag MUST be used only for the 578 binding de-registration. Note that the same mechanism is used for 579 the correspondent node. 581 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 = TBD | Length | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Binding Unique ID (BID) |Priority/Status|C|R|H|Reserved | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 588 + + 589 + Care-of Address (CoA) + 590 + + 591 +---------------------------------------------------------------+ 592 Figure 10: BID Sub-Option 594 Home Binding (H) flag 596 When this flag is set, a home agent stores a Home Address in the 597 Care-of Address field of the binding cache entry. This flag must 598 be used only for binding de-registration. This flag is not used 599 in the bulk registration mode. 601 Reserved 603 5 bits Reserved field. Reserved field must be set with all 0. 605 8. Related Information 607 Related Documents can be found in the Informative Reference section 609 9. IANA considerations 611 This document does not require any IANA action. 613 10. Security Considerations 615 No security vulnerability is not introduced in this specification. 617 11. References 619 11.1. Normative reference 621 [1] Thubert, P., "NEMO Home Network models", 622 draft-ietf-nemo-home-network-models-06 (work in progress), 623 February 2006. 625 [2] Wakikawa, R., "Multiple Care-of Addresses Registration", 626 draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. 628 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 629 Levels", BCP 14, RFC 2119, March 1997. 631 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 632 RFC 3753, June 2004. 634 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 635 draft-ietf-nemo-terminology-06 (work in progress), 636 November 2006. 638 [6] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 639 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 640 January 2005. 642 [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 643 IPv6", RFC 3775, June 2004. 645 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 646 for IP Version 6 (IPv6)", RFC 2461, December 1998. 648 11.2. Informative Reference 650 [9] Ng, C., "Analysis of Multihoming in Network Mobility Support", 651 draft-ietf-nemo-multihoming-issues-06 (work in progress), 652 June 2006. 654 Appendix A. Change Log From Previous Version 656 o Initial Documentation 658 Authors' Addresses 660 Wakikawa Ryuji 661 Keio University 662 Department of Environmental Information, Keio University. 663 5322 Endo 664 Fujisawa, Kanagawa 252-8520 665 Japan 667 Phone: +81-466-49-1100 668 Fax: +81-466-49-1395 669 Email: ryuji@sfc.wide.ad.jp 670 URI: http://www.wakikawa.org/ 672 Aramoto Masafumi 673 Sharp Inc. 674 Department of Environmental Information, Keio University. 675 5322 Endo 676 Fujisawa, Kanagawa 252-8520 677 Japan 679 Phone: +81-466-49-1100 680 Fax: +81-466-49-1395 681 Email: ryuji@sfc.wide.ad.jp 682 URI: http://www.wakikawa.org/ 684 Full Copyright Statement 686 Copyright (C) The IETF Trust (2007). 688 This document is subject to the rights, licenses and restrictions 689 contained in BCP 78, and except as set forth therein, the authors 690 retain all their rights. 692 This document and the information contained herein are provided on an 693 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 694 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 695 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 696 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 697 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 698 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 700 Intellectual Property 702 The IETF takes no position regarding the validity or scope of any 703 Intellectual Property Rights or other rights that might be claimed to 704 pertain to the implementation or use of the technology described in 705 this document or the extent to which any license under such rights 706 might or might not be available; nor does it represent that it has 707 made any independent effort to identify any such rights. Information 708 on the procedures with respect to rights in RFC documents can be 709 found in BCP 78 and BCP 79. 711 Copies of IPR disclosures made to the IETF Secretariat and any 712 assurances of licenses to be made available, or the result of an 713 attempt made to obtain a general license or permission for the use of 714 such proprietary rights by implementers or users of this 715 specification can be obtained from the IETF on-line IPR repository at 716 http://www.ietf.org/ipr. 718 The IETF invites any interested party to bring to its attention any 719 copyrights, patents or patent applications, or other proprietary 720 rights that may cover technology that may be required to implement 721 this standard. Please address the information to the IETF at 722 ietf-ipr@ietf.org. 724 Acknowledgment 726 Funding for the RFC Editor function is provided by the IETF 727 Administrative Support Activity (IASA).