idnits 2.17.1 draft-wakikawa-manet-ipv6-support-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 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '... local addresses MUST NOT be exchanged...' RFC 2119 keyword, line 179: '...t. These routes MUST NOT be leaked ou...' RFC 2119 keyword, line 200: '...ever, these routes MUST be aggregated....' RFC 2119 keyword, line 202: '... manet, SHOULD NOT be re-distributed...' RFC 2119 keyword, line 208: '... network prefix SHOULD NOT be leaked ...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Most manet routing protocols uses hello message to sense 1-hop neighbors. IPv6 permits allocating multiple addresses to a single interface. For example, a manet node may have 3 addresses (such as a link-local address, a unique local address, and a global address). In that case, each manet node SHOULD contain addresses except for link local addresses (i.e. the unique local and global address). Even if the link local address is included in hello messages, the route for the link local address SHOULD not be maintained on each manet node. The link local address SHOULD be used to send NS and NA for Neighbor Cache resolution. -- 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 (07 Mar 2006) is 6596 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 (-01) exists of draft-clausen-nemo-ro-problem-statement-00 -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3484 (ref. '5') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3315 (ref. '6') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (ref. '8') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '9') ** Obsolete normative reference: RFC 2461 (ref. '10') (Obsoleted by RFC 4861) -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2462 (ref. '12') (Obsoleted by RFC 4862) -- Possible downref: Normative reference to a draft: ref. '13' Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Working Group Ryuji Wakikawa 3 INTERNET DRAFT Keio University/WIDE 4 Expires:07 Sep 2006 Antti Tuimonen 5 Helsinki University of Technology 6 Thomas Clausen 7 LIX, Ecole Polytechnique 8 07 Mar 2006 10 IPv6 Support on Mobile Ad-hoc Network 11 draft-wakikawa-manet-ipv6-support-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 27 any 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 August 30, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This draft defines the IPv6 addressing architecture for Mobile Ad-hoc 45 Network. This document includes problem statements when manet using 46 IPv6, IPv6 addressing model, IPv6 manet node's required addresses. 47 Note that this document does not discuss how an IPv6 address is 48 allocated to each manet node. 50 Contents 52 Status of This Memo 1 54 Copyright Notice 1 56 Abstract 1 58 1. Introduction 2 60 2. IPv6 Addressing for MANET 2 61 2.1. Link Local Unicast Address . . . . . . . . . . . . . . . 2 62 2.2. Unique Local Unicast Address . . . . . . . . . . . . . . 3 63 2.3. Global Unicast Address . . . . . . . . . . . . . . . . . 4 65 3. Manet node requirements 4 66 3.1. General node's required Address . . . . . . . . . . . . . 4 67 3.2. Optional required address for global communication . . . 5 69 4. Source Address Selection 5 71 5. Neighbor Discovery Protocol for MANET 5 72 5.1. Neighbor Cache Resolution . . . . . . . . . . . . . . . . 6 73 5.2. Address Auto-configuration . . . . . . . . . . . . . . . 6 74 5.3. Duplicate Address Detection . . . . . . . . . . . . . . . 6 76 6. MANET Routing Protocols 7 77 6.1. Message Flooding . . . . . . . . . . . . . . . . . . . . 7 78 6.2. Neighbor Sensing . . . . . . . . . . . . . . . . . . . . 8 79 6.3. Consideration of Longer IPv6 Address . . . . . . . . . . 8 81 7. Running Mobility Protocols 8 82 7.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 8 83 7.2. Network Mobility . . . . . . . . . . . . . . . . . . . . 9 85 References 10 87 Authors' Addresses 12 88 1. Introduction 90 This document investigates issues when IPv6 [3] is operated with 91 mobile ad hoc networks. In general, routing protocols disregard 92 differences between IPv4 and IPv6, and suggest both can be supported 93 if routing messages for both protocols are defined. However, there 94 are some differences which may well affect how the routing protocols 95 should work with IPv6. 97 In addition there are several issues that may or may not be covered 98 in other documents. This document tries to provide information about 99 implementing and deploying IPv6 mobile ad hoc networks. Addressing 100 in mobile ad hoc networks is a problem for both IPv4 and IPv6. When 101 manet connects to the global Internet, IPv4 might do NAT, but in IPv6 102 we want to have a more integrated solution. This means potentially 103 acquiring an address with global scope. In an effort to alleviate 104 problems related to address scopes [2], we first study applicability 105 of each scope of addresses to mobile ad hoc networks and give 106 guidelines for IPv6 address assignment. After defining address 107 assignment, we briefly discuss the Neighbor Discovery Protocol [10] 108 operations and manet operations on IPv6 mobile ad hoc networks. 110 2. IPv6 Addressing for MANET 112 IPv6 has a notion of ``scope'' to control validity of each IPv6 113 address. In a manet, a link-local scope is used to identify a 114 physical link and an edge of a manet is identified by a unique-local 115 scope. A global scope is used for global communication to the 116 Internet. 118 2.1. Link Local Unicast Address 120 A link local unicast address is designed to use with on-link 121 neighbors, but not over multi-hop. The IPv6 specification prohibits 122 forwarding packets sent to/from a link local address over a link. 124 A manet does not have a clear link definition in terms of multi-hop 125 routing. Indeed, there are two interpretations of ``on-link'' in 126 manet observation. 128 - physical medium [9] 129 The link local address is valid only with one-hop neighbors. 131 - manet wide (till an edge of a manet) 132 The link local address is valid over multi-hop. However it 133 breaks the original definition of link local address. 135 Considering fact that many IPv6 related protocol including the 136 Neighbor Discovery Protocol have already been operated with the 137 legacy link local address definition, it is reasonable to inherit 138 the original interpretation of ``link'' for manets. Otherwise, it 139 could break interoperability between a manet node and a node on the 140 Internet. It is possible that a node visits both an IPv6 network and 141 a manet. 143 The link local address is used only for communication with 144 1-hop neighbors. This address is also used for the Neighbor 145 Discovery Protocol. The link-local all-manet-node multicast 146 address (ff02::TBD) is used for application flooding described in 147 Section 6.1. 149 Routes for link local addresses MUST NOT be exchanged over multi-hop 150 neighbors by manet routing protocols. A node may exchange routes 151 for link local address with 1-hop neighbors, but this should be done 152 carefully. This is because whenever a manet node moves and a set of 153 1-hop neighbors is changed, the route becomes invalid. Thus, each 154 manet node must carefully maintain routes for link local address. 156 2.2. Unique Local Unicast Address 158 A unique local unicast address is not routable on the global 159 Internet, however it can be used for local communication within 160 limited area such as site and manet. More characteristics 161 are described in [7]. A unique local unicast address is not 162 automatically generated, but it is assigned through address 163 auto-configuration [12], DHCPv6 [6], static, etc in an IPv6 network. 164 The locally assigned unique local prefix is generated randomly 165 by each network and assigned it without any verification of its 166 uniqueness. Even when a unique local prefix is duplicated, the 167 damage of this duplication is kept in minimum, because the duplicated 168 prefix is valid within each limited area and is not used for global 169 communication. Unless two networks are merged, they cannot know of 170 duplication of the unique local prefix. 172 IPv6 enabled mobile ad-hoc networks can be treated as a limited area 173 due to its different routing approaches from the Internet (IGP, BGP, 174 etc). A unique Local Unicast address is expected to be assigned to 175 all manet nodes. The unique local unicast address is used only for 176 local communication within manets. 178 Routes for unique local address should be advertised and exchanged 179 within a manet. These routes MUST NOT be leaked out to the Internet. 180 Even if some routes for unique local addresses are leaked out, the 181 backbone routers located to the Internet would often reject and 182 ignored these routes. It is easier to exclude routes for unique 183 local addresses from the global Internet in terms of different 184 address scope. 186 2.3. Global Unicast Address 188 A global unicast address is routable on the global Internet and 189 used for communications on the Internet. A global unicast address 190 must be unique on the Internet. Having a global unicast address 191 is not mandated to all manet nodes, but only to manet nodes which 192 need global Internet connectivity. The notion of global unicast 193 address is applied without any changes to manets. Only manet nodes 194 which want global connectivity acquires a global unicast address 195 through some mechanism. A global unicast address can be used for 196 both local communication within a manet and global communication to 197 the Internet. 199 Routes for topologically correct global address can be advertised 200 to the Internet. However, these routes MUST be aggregated. 201 Un-aggregated routes, like host routes often used within a 202 manet, SHOULD NOT be re-distributed to outside the manet without 203 aggregation. 205 On the other hand, some manet nodes may have a home address of 206 Mobile IPv6 [8] and a mobile network prefix of the NEMO basic 207 support protocol [4]. The routes for a home address and a mobile 208 network prefix SHOULD NOT be leaked to the Internet because of 209 topologically incorrectness. Otherwise, it will disrupt the IPv6 210 routing architecture. Detailed operations can be found in Section 7 212 3. Manet node requirements 214 This section describes required address(es) for each manet 215 node. There are two classification, General required address and 216 extra-required address for Connected manet ( [11]) 218 3.1. General node's required Address 220 An isolated manet is a network formed dynamically with wireless manet 221 nodes, but which is disconnected from the global Internet. This is 222 defined in [11]. 224 Each manet node MUST generate a link local address according to the 225 IPv6 specification [3] and MUST also obtain a unique local address. 226 A unique local prefix, used for the generation of the unique local 227 address, is identical to all nodes within each mobile ad-hoc network. 228 The unique local address is generated from locally assigned unique 229 global ID [7]. How to auto-configure an unique local address is out 230 of scope for this specification. 232 Even if two manets are merged, or if a manet is partitioned, the 233 nodes should keep the originally assigned unique local prefix. 234 When two manets are merged, they can exchange routes of two unique 235 local prefixes within the merged manet, and can communicate between 236 different unique local prefixes. This can avoid address conflicts 237 and prevents storm of duplicate address detection when manets are 238 merged. When a manet is partitioned, two networks now share the 239 same unique local prefix. However, these prefixes are not routed in 240 the global Internet. Thus, this is not problematic unless the two 241 manets re-merge. Each manet may re-assign a new unique local prefix 242 for merged/separated scenarios. However, this completely depends on 243 address configuration mechanism and its operation. 245 3.2. Optional required address for global communication 247 A connected mobile ad-hoc network is a wireless multi-hop network 248 that has global connectivity to the Internet by using Internet 249 Gateway [13] or OSPF extensions. 251 Each manet node acquires a global unicast address for global 252 communication. The assignment of global unicast address is needed 253 for connected mobile ad-hoc network. Whenever a manet node detects 254 that the global address is not topologically correct in a foreign 255 network, it MUST release the invalid global address and obtain 256 topologically correct address. 258 Note that manet routes for global addresses should not be leaked to 259 the Internet without aggregation. 261 4. Source Address Selection 263 RFC3484 [5] specifies the source/destination address selection 264 algorithm. There is no special treatment for manets and each manet 265 node uses the proposed default algorithm defined in [5]. 267 5. Neighbor Discovery Protocol for MANET 269 Neighbor Discovery Protocol (NDP) assumes to be run on a link. 270 However a manet does not have clear definition of ``link'' as 271 described in Section 2. A manet is wireless multi-hop network and 272 all manet nodes inside a manet is expected to be a router. Thus, 273 this section discuss how NDP can be made fit for manets. 275 Similar to the current NDP protocol, the IPv6 Hop Limit field of 276 both Router Solicitation (RS), Router Advertisement (RA), Neighbor 277 Solicitation (NS), Neighbor Advertisement (NA), and Redirect message 278 must be set to '255' all the time. The IP Hop Limit field set to 255 279 indicates, that the packet should not be forwarded by a router. 281 5.1. Neighbor Cache Resolution 283 Although a manet does not have the clear definition of link, a manet 284 node can resolve a neighbor cache (i.e. MAC address) of one-hop 285 neighbors by using NS and NA messages sent to and from link-local 286 addressed. It is enough for manet nodes to resolve neighbor caches 287 of one-hop neighbors, because manet nodes do not share the physical 288 link with two-hop neighbors. 290 Even if a manet node can resolve a neighbor cache of two-hop 291 neighbors, it can not send packets directly to the two-hop neighbors 292 due to lack of L2 routing mechanisms. Each manet node manages 293 neighbor caches for one-hop neighbors and confirms manet node's 294 reachability for one-hop neighbors by using NS and NA (i.e. NDP). 295 Neighbor nodes, located more than one-hop away, are confirmed by the 296 manet routing protocol governing the network. 298 It is important to inherit original interpretation of link for NDP. A 299 manet node is not always connected to a manet, but it can be attached 300 to an IPv6 link. In such case, a manet node does not need to change 301 the operation of NDP, while there is no mechanism to detect whether 302 attached network is a manet or a normal IPv6 network. 304 5.2. Address Auto-configuration 306 IPv6 has an address auto-configuration scheme based on exchange of RS 307 and RA. However, the address auto-configuration is not designed for 308 wireless multi-hop networks (i.e. manets). A manet needs to extend 309 or re-invent address auto-configuration schemes for global addresses 310 and unique local addresses. For global addresses, it is required 311 that the addresses must be topologically correct and routable. 312 [13]. 314 5.3. Duplicate Address Detection 316 Duplicate Address Detection (DAD) can guarantee the uniqueness of any 317 scope of addresses by sending a NS for a target address. If a NA 318 is detected in response to the NS, the address is duplicated. DAD 319 only defends addresses on a physical link due to link-local scope 320 limitation of NS and NA. Thus, DAD can be conducted to guarantee 321 only the uniqueness of addresses within one-hop neighbors. (Note 322 that even if there is no duplication within on-hop neighbors, it 323 is possible that two-hop neighbors may have a duplicated address.) 324 This is not useful because one-hop neighbors are often changed due 325 to node mobility. Once neighbors are changed, the uniqueness is not 326 guaranteed. Each manet node SHOULD stop using DAD and use another 327 duplication address detection mechanism specially tuned for manet. 329 6. MANET Routing Protocols 331 6.1. Message Flooding 333 There are two different forwarding engines for message flooding for 334 manet routing protocols such as ``application forwarding'' and ``IP 335 forwarding''. 337 - Application Forwarding: 338 For application forwarding, it is required that each application 339 (ex. routing daemon) must send a flooded packet with single 340 hop-limit to all neighbors. The recipient processes the 341 flooded packet and will re-send it to all its neighbors if 342 necessary. The flooded packets are thus repeatedly forwarded 343 by an application until it has reached all nodes inside mobile 344 ad-hoc network. Most of manet routing protocol use application 345 flooding for protocol message exchanges. 347 - IP Forwarding 348 Flooded packets can be forwarded by IP layer. The forwarding is 349 totally blind from applications. If a destination is multicast 350 address, an application on each manet node receive the flooded 351 packet, but the flooded packet is forwarded to next neighbors at 352 IP layer at the same time. The application should not need to 353 re-send the flooded packet. 355 For application flooding, each manet node sends a flooded packet to 356 the link-local all-manet-node multicast address (ff02::TBD). If the 357 flooded packet is used to setup a route for the sender node (i.e. 358 reverse route), it should use the address except for link-local 359 address as a source address. This is because routes for link local 360 addresses are garbage on multihop networks. Otherwise, the source 361 address should be set to a link-local address due to one hoplimit 362 packets. 364 For IP forwarding, each manet node needs to send a flooded 365 packet from either global address or unique local address to an 366 all-manet-multicast address that is currently undefined. The 367 all-manet-multicast address can be defined for global scope, but must 368 be defined for unique local scope, too. This is because all manet 369 nodes do not always have global address. 371 6.2. Neighbor Sensing 373 Most manet routing protocols uses hello message to sense 1-hop 374 neighbors. IPv6 permits allocating multiple addresses to a single 375 interface. For example, a manet node may have 3 addresses (such as 376 a link-local address, a unique local address, and a global address). 377 In that case, each manet node SHOULD contain addresses except for 378 link local addresses (i.e. the unique local and global address). 379 Even if the link local address is included in hello messages, the 380 route for the link local address SHOULD not be maintained on each 381 manet node. The link local address SHOULD be used to send NS and NA 382 for Neighbor Cache resolution. 384 6.3. Consideration of Longer IPv6 Address 386 The length of IPv6 address is 128-bit which is 4 times longer than 387 IPv4 address. Therefore, protocol messages including IPv6 routes are 388 tend to be longer than the IPv4 counterparts. Specially in proactive 389 routing protocols, as a number of manet nodes are increased, routing 390 messages could be longer. If routing messages becomes larger than 391 the link MTU, the messages are fragmented by IP layer. This should 392 be avoided since one piece of fragmented packets can be dropped due 393 to unstable manet path (depending on topology change speed). Each 394 manet node SHOULD avoid IP fragmentation of each routing messages by 395 divided the routing messages into multiple messages at higher than IP 396 layer (i.e., applications). In alternative way, routing messages can 397 be shorten by any header or data compression mechanisms. 399 7. Running Mobility Protocols 401 7.1. Mobile IPv6 403 In Mobile IPv6 [8], a mobile host has a permanent global scope 404 address called its ``home address''. When a mobile host roams into a 405 manet, it can still use the home address as a source or destination 406 address of communications. 408 Although a mobile host can exchange routes for its home address 409 (global scope) within manet by using the appropriate manet routing 410 protocol, these routes should not be leaked to the Internet (i.e. 411 IGP) as described in Section 2.3. This is because a home address is 412 not topologically correct global address and leaking topologically 413 incorrect routes disturbs the IPv6 routing architecture. 415 When a manet is an isolated manet, a mobile host can not acquire a 416 global address and can not form a care-of address so that it will 417 give up sending a binding update to its home agent. Although Mobile 418 IPv6 does not explicitly prohibit using unique-local address as a 419 care-of address, but there is no specification for that. A mobile 420 host can keep using its home address in a visiting manet by exchange 421 a manet route of its home address. In such case, the mobile host 422 does not use a bi-directional tunnel between it and home agent, but 423 it sends packets along to manet routes. 425 On the other hand, when a manet is connected manet, a mobile host 426 can acquire a global address and register the care-of address to 427 its home agent. The mobile host can communicate with either a home 428 address and a care-of address in a manet by route exchanges. When 429 the mobile host communicates with a destination located in the same 430 manet, it may have a host route toward the destination and can skip 431 using bi-directional tunnel for the destination. If a destination 432 is outside manet, the mobile host must encapsulate packets to its 433 home agent as Mobile IPv6 does [8]. The mobile host may use route 434 optimization for a destination located in either manet or the 435 Internet. 437 7.2. Network Mobility 439 In the NEMO Basic Support protocol (NEMO) [4], a mobile router has 440 a permanent global scope prefix called ``mobile network prefix''. 441 A mobile router may also roam into manet with its mobile network 442 prefix. 444 A mobile router can exchange a route of its home address (global 445 scope) and its mobile network prefix within manet by using manet 446 routing protocols. However these routes should not be leaked to 447 the Internet (i.e. IGP) as described in Sectionglobal, too. It 448 is because a home address and a mobile network prefix are not 449 topologically correct global address at the visiting manet and 450 leaking topologically incorrect routes disturbs the IPv6 routing 451 architecture. 453 When a mobile router, which is NEMO mobile router but not manet node, 454 roams into an isolated manet, it can not acquire a care-of address 455 and will give up home registration to its home agent. However, 456 the mobile router can exchange manet route for its mobile network 457 prefix and use the manet route for communications from/to its mobile 458 network. The mobile router should not try to use a bi-directional 459 tunnel as NEMO does. 461 On the other hand, when a manet is connected manet, a mobile router 462 can acquire a global address and register the care-of address to its 463 home agent. The mobile router also exchange manet route for its 464 mobile network prefix. When the mobile route finds that a manet 465 route of a destination is in its routing table (i.e. destination 466 is located within the same manet), it can bypass all procedure of 467 NEMO (i.e. tunneling to home agent, etc) and will forward packets 468 along the manet route. If not, the mobile router process packets and 469 tunnel them to its home agent according to binding information. NEMO 470 does not specify any route optimization scheme. 472 Note that some issues related NEMO might be solved by using 473 manet [1]. 475 Acknowledgments 477 The authors would like to thank all the participants of OLSR 478 workshop@San Diego. 480 References 482 [1] T. Clausen, E. Baccelli, and R. Wakikawa. NEMO 483 Route Optimisation Problem Statement (expired, 484 draft-clausen-nemo-ro-problem-statement-00.txt). Internet 485 Draft, Internet Engineering Task Force, October 2004. 487 [2] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, and B. Zill. 488 IPv6 Scoped Address Architecture. Request for Comments 489 (Standards Track) 4007, Internet Engineering Task Force, March 490 2005. 492 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) 493 Specification. Request for Comments (Draft Standard) 2460, 494 Internet Engineering Task Force, December 1998. 496 [4] V. Devaraplli, R. Wakikawa, A. Petrescu, and P. Thubert. 497 Network Mobility (NEMO) Basic Support Protocol (proposed 498 standard). Request for Comments 3963, Internet Engineering Task 499 Force, January 2005. 501 [5] R. Draves. Default Address Selection for Internet Protocol 502 (IPv6). Request for Comments (Standards Track) 3484, Internet 503 Engineering Task Force, February 2003. 505 [6] R. Droms, J. Bound, B. Volz, and T. Lemon. Dynamic Host 506 Configuration Protocol for IPv6 (DHCPv6). Request for Comments 507 (Best Current Practice) 3315, Internet Engineering Task Force, 508 July 2003. 510 [7] R. Hinden and B. Haberman. IPv6 Scoped Address Architecture. 511 Request for Comments (Standards Track) 4193, Internet 512 Engineering Task Force, October 2005. 514 [8] D. Johnson, C. Perkins, and J. Arkko. Mobility support in 515 IPv6. Request for Comments (Proposed Standard) 3775, Internet 516 Engineering Task Force, June 2004. 518 [9] J. Manner and M. Kojo. Mobility related terminology. Request 519 for Comments 3753, Internet Engineering Task Force, June 2003. 521 [10] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 522 IP Version 6 (ipv6). Request for Comments (Draft Standard) 523 2461, Internet Engineering Task Force, December 1998. 525 [11] S. Ruffino, P. Stupar, and T. Clausen. Autoconfiguration in a 526 MANET: connectivity scenarios and technical issues. Internet 527 Draft (draft-ruffino-manet-autoconf-scenarios-00) , Internet 528 Engineering Task Force, October 2004. 530 [12] S. Thomson and T. Narten. IPv6 Stateless Address 531 Autoconfiguration. Request for Comments (Draft Standard) 2462, 532 Internet Engineering Task Force, December 1998. 534 [13] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson, and 535 A. Tuominen. Global Connectivity for IPv6 Mobile Ad Hoc 536 Networks (work in progress, draft-wakikawa-manet-globalv6-05). 537 Internet Draft, Internet Engineering Task Force, March 2005. 539 Authors' Addresses 541 Ryuji Wakikawa 542 Keio University 543 Dept. of Environmental Information 544 5322 Endo Fujisawa Kanagawa 545 252, JAPAN 546 Phone: +81-466 49-1394 547 EMail: ryuji@sfc.wide.ad.jp 549 Antti J. Tuominen 550 Helsinki University of Technology 551 Laboratory for Theoretical Computer Science 552 P.O. Box 9201 553 HUT FIN-02015, Finland 554 Phone: +358 9 451 5136 555 Fax: +358 9 451 5351 556 EMail: anttit@tcs.hut.fi 558 Thomas Heide Clausen 559 Project PCRI 560 Pole Commun de Recherche en Informatique du plateau de Saclay 561 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud 562 Ecole polytechnique 563 Laboratoire d'informatique 564 91128 Palaiseau Cedex, France 565 Email: T.Clausen@computer.org 566 Phone: +33 1 69 33 40 73 568 Intellectual Property Statement 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the 582 use of such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Disclaimer of Validity 594 This document and the information contained herein are provided on 595 an ``AS IS'' basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 596 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 597 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 598 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 599 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 Copyright Statement 604 Copyright (C) The Internet Society (2006). This document is subject 605 to the rights, licenses and restrictions contained in BCP 78, and 606 except as set forth therein, the authors retain all their rights. 608 Acknowledgement 610 Funding for the RFC Editor function is currently provided by the 611 Internet Society.