idnits 2.17.1 draft-petrescu-manemo-nano-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 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 579), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 41. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 10) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 28 instances of lines with control characters in the document. == 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust 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 'MUST not' in this paragraph: A Mobile Router MUST not include Prefix Information Options ([RFC2461bis]) into the special Router Advertisements so that the receiving Mobile Routers don't auto-configure addresses based on these prefixes ([RFC2462bis]). -- 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 (August 2007) is 6098 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) == Unused Reference: 'RFC2461' is defined on line 475, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-01) exists of draft-wakikawa-manemo-problem-statement-00 == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-04 == Outdated reference: A later version (-01) exists of draft-haberman-ipv6-ra-flags-option-00 -- Duplicate reference: RFC2461, mentioned in 'RFC2461bis', was also mentioned in 'RFC2461'. -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 No Working Group as of yet 2 Internet-Draft 3 Expires: 31st August 2007 5 A. Petrescu 6 C. Janneteau 7 Motorola 8 February 26th, 2007 10 The NANO Draft 11 (Scene Scenario for Mobile Routers and MNP in RA) 12 draft-petrescu-manemo-nano-00.txt 14 Status of this Nano 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 31st, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2007). 43 Abstract 45 This short NANO draft proposes scenarios for using Mobile Routers 46 at fixed scenes. The routers connect by their egress interfaces 47 and need to allow their Local Fixed Nodes to communicate directly. 48 What if the Mobile Network Prefixes are stored in special Router 49 Advertisements sent by each Mobile Router on their egress 50 interface. What are the issues and can it work. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Fixed Scene Scenario . . . . . . . . . . . . . . . . . . . . . 3 57 4. Mobile Network Prefixes in Router Advertisements . . . . . . . 3 58 4.1 Message Exchange . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2 Message Formats . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2 Problematic Issues . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 Intellectual Property and Copyright Statements . . . . . . . . . . 9 71 1. Introduction 73 The NANO draft proposes the fixed scene scenario for using Mobile 74 Routers. The routers connect their egress interfaces and need to 75 allow their Local Fixed Nodes to communicate directly. The egress 76 interfaces form a single IP subnet, and the link-layer is assured 77 for instance by technologies like IEEE 802.11 ad-hoc mode or IEEE 78 802.11s mesh or any other mesh-capable link-layer technology. 80 It is assumed in this fixed scene scenario that none of the Home 81 Agents of any of the Mobile Routers is reachable (for instance due 82 to lack of connectivity to the Internet). In this case 83 communication between the LFNs of different moving networks is 84 impossible, since the NEMOv6 tunnel between the Mobile Router and 85 the Home Agent can not be established. 87 This draft proposes a mechanism for allowing two Mobile Routers at 88 a fixed scene to exchange prefix information for allowing 89 forwarding between Local Fixed Nodes of different moving networks. 90 A Mobile Router sends on its egress interface special Router 91 Advertisements containing Mobile Network Prefixes, lifetimes and 92 the link-local address at which these prefixes are reachable. 94 The draft discusses several problematic issues with this mechanism: 95 risk of propagating topologically incorrect addresses, differences 96 of intent with rfc4191 and with rfc3963. It also hints at the 97 potential assignments needed from IANA and potentially use Secure 98 Neighbour Discovery SeND. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 Terminology for network mobility support is defined in [NEMOTERM]. 107 In addition, this document defines the following terms: 109 NEMOv6 - Network Mobility for IPv6, NEMOv6 RFC is [RFC3963], and NEMO 110 Working Group. 112 Mobile Router (MR) - a Mobile Router 114 Mobile Network Prefix (MNP) - the Mobile Network Prefix is 115 topologically correct on the ingress interface of a Mobile Router. 117 Egress interface of MR - the interface sending the special Router 118 Advertisements to other egress interface of other Mobile Routers 119 (by this draft's recommendation), connected at the fixed scene. 120 The egress interface of a Mobile Router defined in [RFC3963]. 122 Ingress interface of MR - the interface towards the Local Fixed 123 Nodes in the moving network and on which the Mobile Network Prefix 124 (MNP) is topologically correct. 126 NANO - Network Addresses for Network Nodes, name invented for 127 distinguishing the method of using MNPs in RA at a fixed scene, in 128 the MANEMO space (and for abbreviating the length of this draft). 130 3. Scenarios 132 3.1 Scene Scenario 134 The Fixed Scene scenario comprises a set of Mobile Routers that are 135 connected together through their egress interfaces. The Home 136 Agents are not reachable. 138 The following scenarios are out of scope currently at a Fixed 139 Scene: nested moving networks, Visiting Mobile Routers, Visiting 140 Mobile Hosts, egress interface connected to another MR's ingress 141 interface, spanning tree construction and maintenance, loop 142 avoidance in routes, Mobile Routers connected to the Internet 143 reaching their Home Agents. For discussion of these scenarios see 144 [MANEMOPS], [NEMOROPS], and [TD]. 146 We consider a number of vehicles each equipped of a Mobile Router 147 implementing the NEMOv6 protocol [RFC3963]. Within each vehicle, in 148 addition to the Mobile Router, there is a number of IP-addressable 149 computer equipment (Local Fixed Nodes - LFNs), all being connected 150 together, and to the respective Mobile Router - thus forming a 151 moving network. All computers in one vehicle are fixed with 152 respect to one another. Only the Mobile Router runs a mobility 153 management protocol (NEMOv6). 155 Vehicle 1 Vehicle 2 157 egress| egress| 158 ---- ---- ---- ---- ---- ---- 159 | MR | |LFN | |LFN | | MR | |LFN | |LFN | 160 ---- ---- ---- ---- ---- ---- 161 ingress| | Ether | ingress| | Ether | 162 --------------------- --------------------- 163 2001:1::/24 2001:2::/24 165 Moving Networks in Vehicles at a Fixed Scene 167 The vehicles arrive at a certain scene and remain fixed for a time 168 necessary to resolve the scene issues. The timespan can range from 169 a few hours at the simplest scenes to several hours but no longer 170 than a few days at most complex scenes. 172 Different Mobile Network Prefixes (MNPs) are assigned to each 173 vehicle, prior to arriving at the scene, and they can differ up to 174 the first three bytes of an IPv6 address. 176 During the time the Scene lasts, all LFNs need to be able to 177 communicate with each other - exchange IP messages. 179 3.2 Personal Mobile Routers and Personal Area Networks (PMRs and PANs) 181 A similar use scenario is two Personal Area Networks each composed 182 of a mobile phone (Personal Mobile Router) and a wifi photography 183 camera (Local Fixed Node), in an area where no cell network is 184 available. 186 4. Mobile Network Prefixes in Router Advertisements 188 It is proposed by this NANO draft to use a special kind of prefixes 189 in the Router Advertisements. MR sends RA on its egress interface. 190 A receiving MR installs the pair MNP-LL in its forwarding 191 information base (routing table, destination cache, tbd). MR 192 informs the other MRs before leaving the Scene. 194 4.0 Conceptual Data Structure 196 Each Mobile Router maintains a MANEMO forwarding information 197 structure that contains entries of the form: 199 -Mobile Network Prefix 200 -Gateway address 201 -lifetime 202 -name of outgoing interface 203 -optionally link-layer address of Gateway 205 This structure is maintained at the reception of the special Router 206 Advertisement and when timers expire. This structure can be 207 implemented as part of the Destination Cache, Binding Cache, 208 Routing Table or Forwarding Information Base. 210 4.1 Message Exchange 212 The mechanism is overviewed as follows: 214 - all Mobile Routers at the fixed Scene connect their egress 215 interface with a wireless MAC protocol, for example 802.11 216 MAC. And then: 218 MR1 MR2 MR3 219 | | | 220 | MLD REPORT (LL1) | | 221 |----------------->|----------------->|multicast 222 | |MLD REPORT (LL3) | 223 |<-----------------|<-----------------| 224 | MLD|REPORT (LL2) | 225 |<-----------------|----------------->| 226 | | | 227 | Special RA | | 228 |----------------->|----------------->| 229 | (MNP1-LL1) | | 230 | | Special RA | 231 |<-----------------|<-----------------| 232 | | (MNP3-LL3) | 233 | | | 234 | Special|RA | 235 |<-----------------|----------------->| 236 | (MNP2-LL2) | 238 - Following link-layer successful connectivity, each Mobile 239 Router joins the all-routers multicast address on the egress 240 interface (typically using a link-local address, pictured as 241 LL1). If the all-routers multicast address can not be used for 242 this goal then maybe a new address 'all-manemo-routers' should 243 be defined. 245 - Each Mobile Router multicasts special RAs on the egress 246 interface, containing the Mobile Network Prefix that is 247 assigned to its moving network. 249 - When receiving the special RA from another MR, a certain MR 250 parses the packet for the link-local address of the sending MR, 251 for the MNP sent by that MR and lifetime. It then installs the 252 corresponding entry into the manemo forwarding information 253 structure. 255 - Before leaving the Fixed Scene, a Mobile Router sends another 256 special RA to all routers this time informing them the 257 MNP-linklocaladdress is no longer present at the scene 258 (lifetime 0 as per [RFC4191]), so the other routers delete the 259 corresponding route. It could also courteously multicast a MLD 260 REPORT to leave the all-routers multicast group, if necessary. 262 - Operation of the Mobile Router when forwarding packets (after 263 installation of the MNP-ll route) is similar to that of any 264 router: for each packet not addressed to itself, longest-prefix 265 match the destination address of the packet to an entry in the 266 table, select the 'gateway' address, solicit that neighbour's 267 MAC address and put the received MAC address in the link-layer 268 dst address then send it. 270 With this mechanism, all LFNs at the fixed Scene are capable to 271 exchange IP messages, routed by two Mobile Routers each time. It 272 is out of the scope of this document the method by which LFNs can 273 learn the IP addresses of their correspondents, but hardcoded or 274 DNS resolution could be used. 276 For faster discovery of the Mobile NEtwork Prefixes of the other 277 Mobile Routers, a certain Mobile Router can send a special Router 278 Solicitation right after joining the scene. 280 It may be necessary that the Mobile Routers need to communicate 281 with their Home Addresses. In this case the special Router 282 Advertisements should contains several prefixes, one for the MNP 283 and one for the MR's Home Address. A MR's Home Address can be 284 encoded as a Mobile Network Prefix with length 128 in the special 285 RA. 287 4.2 Packet Formats - special Router Advertisement 289 Router Advertisement is a message format defined in [RFC2461bis] as 290 an ICMPv6 message. The document [RAOPTS] proposes an option for RA 291 extensibility: NDP Flags Expansion option. We reserve bit 16 for 292 Mobile Network Prefixes. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length |M| Bit fields available ... 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ... for assignment | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 'M' - Mobile Network Prefix present. Set to 1 if this Router 303 Advertisement contains a Mobile Network Prefix. 305 If the NDP Flags Expansion Option contais the flag M and it is set 306 to 1, then the Router Advertisement MUST contain a Route Information 307 Option [RFC4191] followed optionally by a Source-Link Layer Address 308 Option [RFC2461bis]. (If this SLLAO option is used it avoids the necessity 309 of doing NS/NA exchange for the link-local address of the Gateway 310 entry in the manemo forwarding information structure.) 311 A complete diagram of the Router Advertisement for this Scene is 312 presented in the figure below: 314 Base Header (2460) 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |Version| Traffic Class | Flow Label | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Payload Length | Next Header | Hop Limit | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 + + 322 | | 323 + Source Address + 324 | | 325 + + 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 + + 330 | | 331 + Destination Address + 332 | | 333 + + 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 RA (4191) 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type | Code | Checksum | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Reachable Time | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Retrans Timer | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 NDP Expansion Flags (draft-haberman) 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length |M| Bit fields available ... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 ... for assignment | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Route Information Option (4191) 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Route Lifetime | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Prefix (Variable Length) | 359 . . 360 . . 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 SLLAO (2461bis) 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type | Length | Link-Layer Address ... 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Source Address: 368 IPv6 Link Layer Address of sending MR. To be 369 installed as the Gateway address in the manemo 370 forwarding information structure. 372 Destination Address: 373 IPv6 all-routers multicast address with 374 link-scope. 376 Prf: 377 Preference, value 0x09; this route should not be 378 preferred over other default routes, far from 379 that. 381 Prefix (in Router Information Option): 382 The Mobile Network Prefix of this Mobile Router. 384 Link-Layer Address (optional): 385 Link-layer address of the egress interface of the 386 MR. The receiving MR can use this address for 387 sending packets to the MR that advertises a 388 certain MNP. 390 A Mobile Router MUST not include Prefix Information Options 391 ([RFC2461bis]) into the special Router Advertisements so that the 392 receiving Mobile Routers don't auto-configure addresses based on 393 these prefixes ([RFC2462bis]). 395 A Mobile Router MUST NOT auto-configure an address derived from the 396 Mobile Network Prefix found within a received special Router 397 Advertisement. 399 4.3 Problematic Issues 401 The mechanism of using Mobile Network Prefixes in special Router 402 Advertisements for a static Scene has not one problematic issue, 403 but several. Here's a short list: 405 - in general, prefixes advertised in Router Advertisements are not 406 destined to be assigned in routing tables by other routers. It 407 may lead to propagating routes in a completely undesired manner, 408 and to routing incoherencies. Only routing protocols, DHCP and 409 NEMO are current methods for transmitting prefixes and inserting 410 in routing tables. 412 - [RFC4191] provides a potential solving issue, by allowing prefixes 413 sent by a router to be installed in a host's routing table. 414 However, the Mobile Router is more of a router than a host (even 415 though [RFC3963] NEMOv6 requires the MR to behave more like a host 416 on the egress interface). 418 - [RFC3963] requires the MR to act as a host on its egress interface 419 and to not send Router Advertisements on that interface. 421 It is probably possible to solve all these issues. It is needed to 422 develop requirements for this kind of mechanism to work and to avoid 423 create routing incoherencies, especially if connecting to the 424 Internet. Do not advertise nor propagate topologically incorrect 425 addresses nor prefixes into the Internet. 427 5. Security Considerations 429 It is of utmost importance that the Mobile Routers exchange the 430 special Router Advertisements securely. 432 SeND [RFC3971] permits to bind an address to a public key. But not a 433 prefix. This may involve concepts of the prefix-ownership problem 434 space. 436 It is necessary to build a threat model for this scenario and 437 mechanism, analyze the security tools offered by SeND and identify 438 the potential risks and their mitigation. 440 6. IANA Considerations 442 IANA not to assign any type for this draft. But for [RAOPTS] yes, see 443 that draft. 445 It may be necessary to request assignment of a new multicast address 446 with link-local scope: "all-manemo-routers". 448 7. Acknowledgements 450 The authors would like to thank all people who contributed 451 stimulating discussion on the manemo@mobileip.jp list during 452 November 2006 to February 2007: Pascal Thubert, Ryuji Wakikawa, Jim 453 Bound, Jari Arkko, Roberto Baldessari, Ben McCarthy, Teco Boot, 454 Nicolas Chevrollier, Jean Lorchat, Fred Templin, Carlos Jesus 455 Bernardos Cano, Thierry Ernst, Bryan McLaughlin, Theo De Jongh, 456 Thomas Heide Clausen, Lim Hyung Jin, David Binet, Samita 457 Chakrabarti, Shubhranshu, Richard Bernhardt, Martin Dunmore, 458 Emmanuel Baccelli. 460 The authors would like to acknowledge a number of co-workers who 461 strongly supported work in this area a few years ago. Their names 462 will appear when deemed necessary. 464 8. References 466 8.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 472 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 473 RFC 3963, January 2005. 475 [RFC2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery 476 for IP Version 6 (IPv6)", RFC 2461, December 1998. 478 [RFC4191] Draves, R., Thaler, D., "Default Router Preferences and 479 More-Specific Routes", RFC 4191, November 2005. 481 [RFC3971] Arkko, J. Kempf, J., Zill, B., Nikander, P., "SEcure 482 Neighbor Discovery (SEND)", RFC 3971, March 2005. 484 8.2. Informative References 486 [NEMOTERM] Ernst, T., Lach, H-Y., "Network Mobility Support 487 Terminology", draft-ietf-nemo-terminology-06.txt, work in 488 progress, November 2006. 490 [MANEMOPS] Wakikawa, R., Thubert, P., Boot, T., Bound, J., 491 McCarthy, B., "MANEMO Problem Statement", IETF Internet 492 Draft, draft-wakikawa-manemo-problem-statement-00.txt, 493 work in progress, February 2007. 495 [NEMOROPS] Ng, C., Thubert, P., Watari, M., Zhao, F., "Network 496 Mobility Route Optimization Problem Statement", IETF 497 Internet Draft, 498 draft-ietf-nemo-ro-problem-statement-03.txt, work in 499 progress, September 2006. 501 [TD] Thubert, P., Bontoux, C., Montavont, N., "Nested Nemo Tree 502 Discovery", IETf Internet Draft, 503 draft-thubert-tree-discovery-04.txt, work in progress, 504 November 2006. 506 [RAOPTS] B. Haberman, B., Hinden, R., "IPv6 Router Advertisement 507 Flags Option", IETF Internet Draft, Work in Progress, 508 draft-haberman-ipv6-ra-flags-option-00.txt, July 2006. 510 [RFC2461bis] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 511 "Neighbor Discovery for IP verssion 6 (IPv6)", IETF 512 Internet Draft, Work in Progress, January 2007. 514 [RFC2462bis] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 515 Address Autoconfiguration", IETF Internet Draft, Work 516 in Progress, draft-ietf-ipv6-rfc2462bis-08.txt, May 517 2005. 519 9. Changelog 521 Initial version 00 523 Authors' Addresses 525 Alexandru Petrescu 526 Motorola 527 Parc les Algorithmes Saint Aubin 528 Gif-sur-Yvette 91193 529 France 531 Email: Alexandru.Petrescu@motorola.com 533 Christophe Janneteau 534 Motorola 535 Parc les Algorithmes Saint Aubin 536 Gif-sur-Yvette 91193 537 France 539 Email: Christophe.Janneteau@motorola.com 541 Intellectual Property Statement 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the procedures with respect to rights in RFC documents can be 550 found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org. 565 Disclaimer of Validity 567 This document and the information contained herein are provided on 568 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 569 REPRESENTS OR IS SPONSORED BY (IF ANY), THE IETF TRUST AND THE 570 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 571 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 572 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Copyright Statement 577 Copyright (C) The IETF Trust (2007). This document is subject to 578 the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.