idnits 2.17.00 (12 Aug 2021) /tmp/idnits29066/draft-wakikawa-mip6-no-ndp-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, updated by RFC 4748 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. 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 : ---------------------------------------------------------------------------- No issues found here. 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 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 (November 18, 2007) is 5291 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: 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. '3') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') ** 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 (~~), 7 warnings (==), 7 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: May 21, 2008 M. Aramoto 5 Sharp 6 P. Thubert 7 Cisco 8 November 18, 2007 10 Elimination of Proxy NDP from Home Agent Operations 11 draft-wakikawa-mip6-no-ndp-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 May 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document summarizes how to eliminate the Proxy NDP from the Home 45 Agent's operations. Although the Proxy NDP is mainly used to 46 intercept packets by a Home Agent on Mobile IPv6 and NEMO, it brings 47 several limitations to the protocols. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Mobile IP6: Virtual Home Link and Performance . . . . . . 4 55 2.2. Network Mobility: Aggregated Home Link . . . . . . . . . . 4 56 2.3. Monami6: Simultaneous Use of Home and Foreign Link . . . . 5 58 3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 6 60 4. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Duplicate Address Detection . . . . . . . . . . . . . . . 7 62 4.2. Sending Router Advertisement . . . . . . . . . . . . . . . 7 63 4.3. Deliverying Packets to the Mobile Node . . . . . . . . . . 8 64 4.4. Returing Home . . . . . . . . . . . . . . . . . . . . . . 8 66 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.1. Normative reference . . . . . . . . . . . . . . . . . . . 10 72 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . . . . 12 77 1. Introduction 79 In Mobile IPv6, one of design limitations is the use of Proxy 80 Neighbor Discovery on Home Agent. Mobile IPv6 uses the proxy 81 Neighbor Discovery Protocol (proxy NDP) to intercept packets meant 82 for mobile nodes on a home agent at a home link. When the proxy NDP 83 is used, a home prefix must be strictly configured at the physical 84 link which the home prefix is defined in the Internet topology. 85 Moreover, the performance of NDP may effect that of Mobile IPv6 if 86 the number of mobile nodes are served by a home network prefix. 88 Elimination of the Proxy NDP from Mobile IPv6 and NEMO may bring some 89 advantages such as flexible home prefix configuration, reduction of 90 NDP overhead, disengagement from the home link bandwidth. In NEMO 91 Working Group, [1] introduces various home prefix configurations such 92 as the aggregated home prefix, the aggregated home prefix and the 93 virtual home prefix. Proxy NDP is useless specially when the 94 aggregated home prefix is used. Finally, the fact that packets are 95 captured by NDP shows that the maximum bandwidth for all the mobile 96 nodes are limited to the home link bandwidth. 98 We introduce special use case for Monami6 work. When a mobile node 99 returns home with multiple interfaces, it can only activate either an 100 interface attached to the home link or an interface attached to a 101 foreign link [9]. If it tries to active both interfaces, the Home 102 Agent and the Mobile Node will defend the Home Address by NDP 103 simultaneously. Consequently, it leads DAD problem. This problem 104 has been discussed on the Multiple Care-of Address Registration [2] 105 in Monami6 Working Group. By eliminating Proxy NDP, the mobile node 106 can utilize both of interfaces attached to the home and the foreign 107 link at the same time. 109 This document shows the possible configuration and modification when 110 a home agent stop the proxy NDP for Mobile IP and NEMO. The Mobile 111 Node is transparent to this NDP elimination, though it may skip 112 several steps from returning home operation. 114 Readers are expected to be familiar with all the terms defined in the 115 RFC3753 [3] and the NEMO Terminology draft [4] 117 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [5] 121 2. Use Case 123 2.1. Mobile IP6: Virtual Home Link and Performance 125 The first case is that home prefix is configured as the virtual home 126 link on Home Agent as shown in Figure 1. The operator may choose 127 this deployment scenario to reduce NDP overhead caused by number of 128 Mobile Nodes at the home link. 130 The home link is not configured at the physical link and all of the 131 Mobile Nodes moves only in foreign links and never come back to the 132 home link. The Home Agent does not intercept packets from a Mobile 133 Node and to the Mobile Node on the home link by the Proxy NDP. The 134 Home agent is configured as an external router in order to intercept 135 packets without the proxy NDP. 137 Even if the home link is configured at the physical link, the proxy 138 NDP can be skipped. This is also useful scenario for Mobile IP 139 operators, because the performance of packet interception is released 140 from the limitation of the home link bandwidth. Even if the external 141 link toward the Internet is high speed network like 10Gbps, the 142 performance is limited to the home link bandwidth on the regular 143 Mobile IP and NEMO. The operator needs not to invest to the home 144 link bandwidth with our modified operation. In addition to this, 145 plenty of Proxy NDP entries are burden to a Home Agent, if the number 146 of Mobile Nodes are served by the Home Agent. Our proposal can 147 remove this burden from the Home Agent. 149 +---=------+ 10Gbps +----+ 150 | Internet +==============+ HA | 151 +----+---+-+ +--+-+ 152 |Foreign Link | Virtual Home Link/64 153 -----+------- - - - - - - - - 154 |CoA1 (100Mbps) 155 +--+--+ 156 | MN | -----> No returning home 157 +--+--+ 159 Figure 1: MIP 161 2.2. Network Mobility: Aggregated Home Link 163 The NEMO Basic Support [6] allows that a home link is configured as 164 the aggregated home prefix. The Home Agent assigns an internal 165 network prefix(es) to a Mobile Router as shown in Figure 2. The Home 166 Agent cannot intercept the packets meant for the mobile network 167 prefix by the proxy NDP, because the Proxy NDP assumes /64 prefix 168 length on a link. This is not explicitly described in the NDP 169 specification, but the NDP specification implies this. It is 170 necessary for Home Agent to intercept the packets without using Proxy 171 NDP. 173 It is also useful that the Home Agent is configured as an external 174 router of the aggregated home networks and the Home Agent intercepts 175 packets according to the IP routing. There is no reasons to use 176 Proxy NDP for intercepting mobile nodes' packets. 178 +----------+ +----+ 179 | Internet +--------------+ HA | 180 +----+---+-+ +--+-+ 181 | | 182 +--+--+ ------+-------- 183 | MR | Aggregated Home Link P1::/48 184 +--+--+ 185 | P1:a::/64 186 ---------+----------- 187 | | | | ... 188 LFN LFN LFN LFN ... 190 Figure 2: Aggregated Home Link 192 2.3. Monami6: Simultaneous Use of Home and Foreign Link 194 The Multiple Care-of Address Registration [2] does not allow to 195 maintain multiple bindings that one is attached to the home link and 196 the other is attached to the foreign link simultaneously. This 197 restriction has been derived from the Proxy NDP operation on a Home 198 Agent. The Home Agent needs to defend a mobile node's home address 199 by the proxy NDP for packet interception, while the mobile node 200 defends its home address by regular NDP to send and receive packets 201 at the interface attached to the home link. Two nodes, Home Agent 202 and Mobile Node, compete ND state, so that it causes address 203 duplication problem consequently. 205 This document recommends not to use the Proxy NDP in order to support 206 simultaneous use of home and foreign link. If the proxy NDP is 207 disabled, the main problem, address duplication problem can be 208 solved. In this Multiple Care-of Address Registration case, Mobile 209 Node and Home Agent can maintain multiple bindings, the binding of 210 the Mobile Node's interface is attached to the home link and the 211 other(s) is attached to the foreign link. 213 3. Home Agent Configuration 215 In Mobile IPv6 and NEMO, two possible placements of Home Agents are 216 possible. The difference between them is whether the Home Agent acts 217 as an external router or not as shown in Figure Figure 3. 219 In this document, HA is always an external router so that it can 220 intercept all the packets meant for mobile nodes without the proxy 221 neighbor advertisement. The Home Agent intercepts packets according 222 to the IP routing. All the packets toward the home prefix will be 223 routed to the Home Agent. When the Home Agent receives packets meant 224 for the home prefix, it then route packets based on routing 225 information and binding cache to the target mobile node. . 227 +----------+ +----------+ 228 | Internet | | Internet | 229 +----+-----+ +----+-----+ 230 | | 231 +-+-+ +----+ +-+--+ 232 | R | | HA | | HA | 233 +---+ +--+-+ +----+ 234 | | Home Link | Home Link 235 -----+----------+----------- -----+------------- 237 Figure 3: Home Agent Placements 239 Note that there is one drawback when a HA is placed as an external 240 router. Operators cannot utilize multiple home agents for a same 241 home prefix at a home link as introduced in [7]. For the purpose of 242 the home agent reliability, the Home Agent Reliability protocol can 243 be operated with the specific configuration in Figure 4. In this 244 case, upper router can switch the routing information based on the HA 245 survivability as shown in Figure 4 247 +----------+ 248 | Internet | 249 +----+-----+ 250 | 251 +-+-+ 252 +--+ R +--+ 253 | +---+ | 254 +-+-+ +-+-+ 255 |HA1| |HA2| 256 +-+-+ +-+-+ 257 | | Home Link 258 --+---------+----- 260 Figure 4: Multiple Home Agents Placement 262 4. Home Agent Operation 264 4.1. Duplicate Address Detection 266 RFC3775[7] also uses the Proxy NDP to defend a Home Address of a 267 Mobile Node when the Mobile Node is away from the Home Link. Thus, 268 non of other nodes can pick the Home Address at the Home Link even if 269 the Mobile Node is not visible on the Home Link. 271 When the Proxy NDP is eliminated, the uniqueness of a home address 272 should be carefully examined. If a Mobile Node is away from the 273 Home, its home address can be picked by other Mobile Nodes on the 274 Home Link because of no Proxy ND entry of the Home Address. To 275 prevent address duplication, the Home Agent can filter the packets 276 originated from the Home Link based on the Binding Cache. Since the 277 Home Agent is an external router, all the packets are passed through 278 the Home Agent. When the Home Agent intercepts packets from the Home 279 Link and finds an active binding cache entry for the same address 280 with the packet's source address, it MUST drop packets. For incoming 281 packets, the Home Agent can prioritize the binding cache database 282 first and can tunnel packets to the Mobile Node. The packets are 283 never reached to the malicious node who takes the home address of 284 other mobile nodes. As a result, although a third node (malicious 285 node) can obtain a home address which is already taken by other 286 Mobile Node, it cannot send and receive packets by using the home 287 address. 289 4.2. Sending Router Advertisement 291 The Home Agent SHOULD send a Router Advertisement to the Home Link 292 for two purposes: address assignment and home link detection. The 293 Mobile Node generates a home address from the received router 294 advertisement. It also uses this to detect the home link. 296 In this document, the Home Agent MUST route all the incoming and 297 outgoing packets of the home link. Even for communication with a 298 Correspondent Node located on the home link, the packets MUST be 299 routed via the Home Agent. Otherwise, a malicious node can steal a 300 Home Address of the other Mobile nodes and communicates with 301 Correspondent nodes located on the Home Link by using the stolen Home 302 Address (HoA1) as shown in Figure 5. If the packet is always routed 303 to the Home Agent first, the packets sent by Correspondent Node will 304 be routed correctly to the right Mobile Node. 306 For doing so, the Home Agent MUST generate Router Advertisement which 307 the on-link flag (L flag) [8] is unset, so that all the packets will 308 be routed via the Home Agent. Malicious nodes may directly route the 309 packets with the stolen home address, but packets sent by 310 Correspondent Node will reach to the right Mobile Node. Moreover, 311 when the Home Agent receives packets which destination and source are 312 both located on the home link, it MUST NOT generate ICMP redirect to 313 the sender. 315 +----------+ 316 | Internet +--MN (HoA1) 317 +----+-----+ 318 | 319 +-+--+ 320 | HA | 321 +-+--+ 322 | Home Link 323 ---+--------+-------+----- 324 | | 325 CN Malicious (HoA1) 327 Figure 5: Malicious Node communicating with CN on the home link 329 4.3. Deliverying Packets to the Mobile Node 331 Home Agent intercepts packets meant for mobile node by IP routing 332 (See Section 3 and Section 4.2). How to deriver packets is same as 333 [7]. The Home Agent refers the Binding Cache and encapsulates 334 packets according to the binding cache entry. 336 If a correspondent node is located at the home link, the node routes 337 packets to the Home Agent first because the on-link flag of Router 338 Advertisement is unset (See Section 4.2. The Home Agent intercepts 339 packets and tunnels packets to the Mobile Node only when the binding 340 cache entry for the packet's destination is available. Otherwise, it 341 can re-send the packet back to the Home Link. 343 However, Home Agent MUST drop the packets by the malicious node who 344 steal the Home Address (See Section 4.1). For incoming packets from 345 the external network (ex.Internet), when the binding is not active, 346 Home Agent MUST drop the packets which source address is Mobile Node 347 itself. On the other hand, for incomming packets from the Home Link, 348 when the binding is active, Home Agent MUST drop the packets which 349 source address is Mobile Node itself. 351 4.4. Returing Home 353 For Returning home, no modification is given in this specification. 355 5. IANA considerations 357 This document does not require any IANA action. 359 6. Security Considerations 361 No security vulnerability is not introduced in this specification. 363 7. References 365 7.1. Normative reference 367 [1] Thubert, P., "NEMO Home Network models", 368 draft-ietf-nemo-home-network-models-06 (work in progress), 369 February 2006. 371 [2] Wakikawa, R., "Multiple Care-of Addresses Registration", 372 draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. 374 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 375 RFC 3753, June 2004. 377 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 378 draft-ietf-nemo-terminology-06 (work in progress), 379 November 2006. 381 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 382 Levels", BCP 14, RFC 2119, March 1997. 384 [6] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 385 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 386 January 2005. 388 [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 389 IPv6", RFC 3775, June 2004. 391 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 392 for IP Version 6 (IPv6)", RFC 2461, December 1998. 394 7.2. Informative Reference 396 [9] Ng, C., "Analysis of Multihoming in Network Mobility Support", 397 draft-ietf-nemo-multihoming-issues-06 (work in progress), 398 June 2006. 400 Authors' Addresses 402 Wakikawa Ryuji 403 Keio University 404 Department of Environmental Information, Keio University. 405 5322 Endo 406 Fujisawa, Kanagawa 252-8520 407 Japan 409 Phone: +81-466-49-1100 410 Fax: +81-466-49-1395 411 Email: ryuji@sfc.wide.ad.jp 412 URI: http://www.wakikawa.org/ 414 Aramoto Masafumi 415 SHARP Corporation. 416 Advanced Telecommunication Laboratory 417 Corporate Reserach And Development Group 418 Sharp Corporation. 419 22-22 Nagaike-cho 420 Abeno-ku, Osaka, Osaka 545-0013 421 Japan 423 Phone: +81-43-299-8532 424 Fax: +81-43-299-8719 425 Email: aramoto.masafumi@sharp.co.jp 426 URI: http://sharp.co.jp/ 428 Pascal Thubert 429 Cisco Systems 430 Village d'Entreprises Green Side 431 400, Avenue de Roumanille 432 Batiment T3 433 Biot - Sophia Antipolis 06410 434 FRANCE 436 Phone: +33 4 97 23 26 34 437 Email: pthubert@cisco.com 439 Full Copyright Statement 441 Copyright (C) The IETF Trust (2007). 443 This document is subject to the rights, licenses and restrictions 444 contained in BCP 78, and except as set forth therein, the authors 445 retain all their rights. 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 450 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 451 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 452 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Intellectual Property 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at 477 ietf-ipr@ietf.org. 479 Acknowledgment 481 Funding for the RFC Editor function is provided by the IETF 482 Administrative Support Activity (IASA).