No Working Group as of yet Internet-Draft Expires: 31st August 2007 A. Petrescu C. Janneteau Motorola February 26th, 2007 The NANO Draft (Scene Scenario for Mobile Routers and MNP in RA) draft-petrescu-manemo-nano-00.txt Status of this Nano By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31st, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This short NANO draft proposes scenarios for using Mobile Routers at fixed scenes. The routers connect by their egress interfaces and need to allow their Local Fixed Nodes to communicate directly. What if the Mobile Network Prefixes are stored in special Router Advertisements sent by each Mobile Router on their egress interface. What are the issues and can it work. Petrescu, et al. Expires August 2007 [Page i] Internet-Draft The NANO Draft February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Fixed Scene Scenario . . . . . . . . . . . . . . . . . . . . . 3 4. Mobile Network Prefixes in Router Advertisements . . . . . . . 3 4.1 Message Exchange . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Message Formats . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Problematic Issues . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 9 1. Introduction The NANO draft proposes the fixed scene scenario for using Mobile Routers. The routers connect their egress interfaces and need to allow their Local Fixed Nodes to communicate directly. The egress interfaces form a single IP subnet, and the link-layer is assured for instance by technologies like IEEE 802.11 ad-hoc mode or IEEE 802.11s mesh or any other mesh-capable link-layer technology. It is assumed in this fixed scene scenario that none of the Home Agents of any of the Mobile Routers is reachable (for instance due to lack of connectivity to the Internet). In this case communication between the LFNs of different moving networks is impossible, since the NEMOv6 tunnel between the Mobile Router and the Home Agent can not be established. This draft proposes a mechanism for allowing two Mobile Routers at a fixed scene to exchange prefix information for allowing forwarding between Local Fixed Nodes of different moving networks. A Mobile Router sends on its egress interface special Router Advertisements containing Mobile Network Prefixes, lifetimes and the link-local address at which these prefixes are reachable. The draft discusses several problematic issues with this mechanism: risk of propagating topologically incorrect addresses, differences of intent with rfc4191 and with rfc3963. It also hints at the potential assignments needed from IANA and potentially use Secure Neighbour Discovery SeND. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Petrescu, et al. Expires August 2007 [Page 1] Internet-Draft The NANO Draft February 2007 Terminology for network mobility support is defined in [NEMOTERM]. In addition, this document defines the following terms: NEMOv6 - Network Mobility for IPv6, NEMOv6 RFC is [RFC3963], and NEMO Working Group. Mobile Router (MR) - a Mobile Router Mobile Network Prefix (MNP) - the Mobile Network Prefix is topologically correct on the ingress interface of a Mobile Router. Egress interface of MR - the interface sending the special Router Advertisements to other egress interface of other Mobile Routers (by this draft's recommendation), connected at the fixed scene. The egress interface of a Mobile Router defined in [RFC3963]. Ingress interface of MR - the interface towards the Local Fixed Nodes in the moving network and on which the Mobile Network Prefix (MNP) is topologically correct. NANO - Network Addresses for Network Nodes, name invented for distinguishing the method of using MNPs in RA at a fixed scene, in the MANEMO space (and for abbreviating the length of this draft). 3. Scenarios 3.1 Scene Scenario The Fixed Scene scenario comprises a set of Mobile Routers that are connected together through their egress interfaces. The Home Agents are not reachable. The following scenarios are out of scope currently at a Fixed Scene: nested moving networks, Visiting Mobile Routers, Visiting Mobile Hosts, egress interface connected to another MR's ingress interface, spanning tree construction and maintenance, loop avoidance in routes, Mobile Routers connected to the Internet reaching their Home Agents. For discussion of these scenarios see [MANEMOPS], [NEMOROPS], and [TD]. We consider a number of vehicles each equipped of a Mobile Router implementing the NEMOv6 protocol [RFC3963]. Within each vehicle, in addition to the Mobile Router, there is a number of IP-addressable computer equipment (Local Fixed Nodes - LFNs), all being connected together, and to the respective Mobile Router - thus forming a moving network. All computers in one vehicle are fixed with respect to one another. Only the Mobile Router runs a mobility management protocol (NEMOv6). Petrescu, et al. Expires August 2007 [Page 2] Internet-Draft The NANO Draft February 2007 Vehicle 1 Vehicle 2 egress| egress| ---- ---- ---- ---- ---- ---- | MR | |LFN | |LFN | | MR | |LFN | |LFN | ---- ---- ---- ---- ---- ---- ingress| | Ether | ingress| | Ether | --------------------- --------------------- 2001:1::/24 2001:2::/24 Moving Networks in Vehicles at a Fixed Scene The vehicles arrive at a certain scene and remain fixed for a time necessary to resolve the scene issues. The timespan can range from a few hours at the simplest scenes to several hours but no longer than a few days at most complex scenes. Different Mobile Network Prefixes (MNPs) are assigned to each vehicle, prior to arriving at the scene, and they can differ up to the first three bytes of an IPv6 address. During the time the Scene lasts, all LFNs need to be able to communicate with each other - exchange IP messages. 3.2 Personal Mobile Routers and Personal Area Networks (PMRs and PANs) A similar use scenario is two Personal Area Networks each composed of a mobile phone (Personal Mobile Router) and a wifi photography camera (Local Fixed Node), in an area where no cell network is available. 4. Mobile Network Prefixes in Router Advertisements It is proposed by this NANO draft to use a special kind of prefixes in the Router Advertisements. MR sends RA on its egress interface. A receiving MR installs the pair MNP-LL in its forwarding information base (routing table, destination cache, tbd). MR informs the other MRs before leaving the Scene. 4.0 Conceptual Data Structure Each Mobile Router maintains a MANEMO forwarding information structure that contains entries of the form: -Mobile Network Prefix -Gateway address -lifetime -name of outgoing interface -optionally link-layer address of Gateway This structure is maintained at the reception of the special Router Advertisement and when timers expire. This structure can be implemented as part of the Destination Cache, Binding Cache, Routing Table or Forwarding Information Base. Petrescu, et al. Expires August 2007 [Page 3] Internet-Draft The NANO Draft February 2007 4.1 Message Exchange The mechanism is overviewed as follows: - all Mobile Routers at the fixed Scene connect their egress interface with a wireless MAC protocol, for example 802.11 MAC. And then: MR1 MR2 MR3 | | | | MLD REPORT (LL1) | | |----------------->|----------------->|multicast | |MLD REPORT (LL3) | |<-----------------|<-----------------| | MLD|REPORT (LL2) | |<-----------------|----------------->| | | | | Special RA | | |----------------->|----------------->| | (MNP1-LL1) | | | | Special RA | |<-----------------|<-----------------| | | (MNP3-LL3) | | | | | Special|RA | |<-----------------|----------------->| | (MNP2-LL2) | - Following link-layer successful connectivity, each Mobile Router joins the all-routers multicast address on the egress interface (typically using a link-local address, pictured as LL1). If the all-routers multicast address can not be used for this goal then maybe a new address 'all-manemo-routers' should be defined. - Each Mobile Router multicasts special RAs on the egress interface, containing the Mobile Network Prefix that is assigned to its moving network. - When receiving the special RA from another MR, a certain MR parses the packet for the link-local address of the sending MR, for the MNP sent by that MR and lifetime. It then installs the corresponding entry into the manemo forwarding information structure. - Before leaving the Fixed Scene, a Mobile Router sends another special RA to all routers this time informing them the MNP-linklocaladdress is no longer present at the scene (lifetime 0 as per [RFC4191]), so the other routers delete the corresponding route. It could also courteously multicast a MLD REPORT to leave the all-routers multicast group, if necessary. Petrescu, et al. Expires August 2007 [Page 4] Internet-Draft The NANO Draft February 2007 - Operation of the Mobile Router when forwarding packets (after installation of the MNP-ll route) is similar to that of any router: for each packet not addressed to itself, longest-prefix match the destination address of the packet to an entry in the table, select the 'gateway' address, solicit that neighbour's MAC address and put the received MAC address in the link-layer dst address then send it. With this mechanism, all LFNs at the fixed Scene are capable to exchange IP messages, routed by two Mobile Routers each time. It is out of the scope of this document the method by which LFNs can learn the IP addresses of their correspondents, but hardcoded or DNS resolution could be used. For faster discovery of the Mobile NEtwork Prefixes of the other Mobile Routers, a certain Mobile Router can send a special Router Solicitation right after joining the scene. It may be necessary that the Mobile Routers need to communicate with their Home Addresses. In this case the special Router Advertisements should contains several prefixes, one for the MNP and one for the MR's Home Address. A MR's Home Address can be encoded as a Mobile Network Prefix with length 128 in the special RA. 4.2 Packet Formats - special Router Advertisement Router Advertisement is a message format defined in [RFC2461bis] as an ICMPv6 message. The document [RAOPTS] proposes an option for RA extensibility: NDP Flags Expansion option. We reserve bit 16 for Mobile Network Prefixes. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| Bit fields available ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... for assignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'M' - Mobile Network Prefix present. Set to 1 if this Router Advertisement contains a Mobile Network Prefix. If the NDP Flags Expansion Option contais the flag M and it is set to 1, then the Router Advertisement MUST contain a Route Information Option [RFC4191] followed optionally by a Source-Link Layer Address Option [RFC2461bis]. (If this SLLAO option is used it avoids the necessity of doing NS/NA exchange for the link-local address of the Gateway entry in the manemo forwarding information structure.) Petrescu, et al. Expires August 2007 [Page 5] Internet-Draft The NANO Draft February 2007 A complete diagram of the Router Advertisement for this Scene is presented in the figure below: Base Header (2460) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RA (4191) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NDP Expansion Flags (draft-haberman) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| Bit fields available ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... for assignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route Information Option (4191) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SLLAO (2461bis) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Petrescu, et al. Expires August 2007 [Page 6] Internet-Draft The NANO Draft February 2007 Source Address: IPv6 Link Layer Address of sending MR. To be installed as the Gateway address in the manemo forwarding information structure. Destination Address: IPv6 all-routers multicast address with link-scope. Prf: Preference, value 0x09; this route should not be preferred over other default routes, far from that. Prefix (in Router Information Option): The Mobile Network Prefix of this Mobile Router. Link-Layer Address (optional): Link-layer address of the egress interface of the MR. The receiving MR can use this address for sending packets to the MR that advertises a certain MNP. 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]). A Mobile Router MUST NOT auto-configure an address derived from the Mobile Network Prefix found within a received special Router Advertisement. 4.3 Problematic Issues The mechanism of using Mobile Network Prefixes in special Router Advertisements for a static Scene has not one problematic issue, but several. Here's a short list: - in general, prefixes advertised in Router Advertisements are not destined to be assigned in routing tables by other routers. It may lead to propagating routes in a completely undesired manner, and to routing incoherencies. Only routing protocols, DHCP and NEMO are current methods for transmitting prefixes and inserting in routing tables. - [RFC4191] provides a potential solving issue, by allowing prefixes sent by a router to be installed in a host's routing table. However, the Mobile Router is more of a router than a host (even though [RFC3963] NEMOv6 requires the MR to behave more like a host on the egress interface). - [RFC3963] requires the MR to act as a host on its egress interface and to not send Router Advertisements on that interface. Petrescu, et al. Expires August 2007 [Page 6] Internet-Draft The NANO Draft February 2007 It is probably possible to solve all these issues. It is needed to develop requirements for this kind of mechanism to work and to avoid create routing incoherencies, especially if connecting to the Internet. Do not advertise nor propagate topologically incorrect addresses nor prefixes into the Internet. 5. Security Considerations It is of utmost importance that the Mobile Routers exchange the special Router Advertisements securely. SeND [RFC3971] permits to bind an address to a public key. But not a prefix. This may involve concepts of the prefix-ownership problem space. It is necessary to build a threat model for this scenario and mechanism, analyze the security tools offered by SeND and identify the potential risks and their mitigation. 6. IANA Considerations IANA not to assign any type for this draft. But for [RAOPTS] yes, see that draft. It may be necessary to request assignment of a new multicast address with link-local scope: "all-manemo-routers". 7. Acknowledgements The authors would like to thank all people who contributed stimulating discussion on the manemo@mobileip.jp list during November 2006 to February 2007: Pascal Thubert, Ryuji Wakikawa, Jim Bound, Jari Arkko, Roberto Baldessari, Ben McCarthy, Teco Boot, Nicolas Chevrollier, Jean Lorchat, Fred Templin, Carlos Jesus Bernardos Cano, Thierry Ernst, Bryan McLaughlin, Theo De Jongh, Thomas Heide Clausen, Lim Hyung Jin, David Binet, Samita Chakrabarti, Shubhranshu, Richard Bernhardt, Martin Dunmore, Emmanuel Baccelli. The authors would like to acknowledge a number of co-workers who strongly supported work in this area a few years ago. Their names will appear when deemed necessary. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Petrescu, et al. Expires August 2007 [Page 7] Internet-Draft The NANO Draft February 2007 [RFC2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC4191] Draves, R., Thaler, D., "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC3971] Arkko, J. Kempf, J., Zill, B., Nikander, P., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 8.2. Informative References [NEMOTERM] Ernst, T., Lach, H-Y., "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06.txt, work in progress, November 2006. [MANEMOPS] Wakikawa, R., Thubert, P., Boot, T., Bound, J., McCarthy, B., "MANEMO Problem Statement", IETF Internet Draft, draft-wakikawa-manemo-problem-statement-00.txt, work in progress, February 2007. [NEMOROPS] Ng, C., Thubert, P., Watari, M., Zhao, F., "Network Mobility Route Optimization Problem Statement", IETF Internet Draft, draft-ietf-nemo-ro-problem-statement-03.txt, work in progress, September 2006. [TD] Thubert, P., Bontoux, C., Montavont, N., "Nested Nemo Tree Discovery", IETf Internet Draft, draft-thubert-tree-discovery-04.txt, work in progress, November 2006. [RAOPTS] B. Haberman, B., Hinden, R., "IPv6 Router Advertisement Flags Option", IETF Internet Draft, Work in Progress, draft-haberman-ipv6-ra-flags-option-00.txt, July 2006. [RFC2461bis] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP verssion 6 (IPv6)", IETF Internet Draft, Work in Progress, January 2007. [RFC2462bis] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", IETF Internet Draft, Work in Progress, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005. 9. Changelog Initial version 00 Petrescu, et al. Expires August 2007 [Page 8] Internet-Draft The NANO Draft February 2007 Authors' Addresses Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France Email: Alexandru.Petrescu@motorola.com Christophe Janneteau Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France Email: Christophe.Janneteau@motorola.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Petrescu, et al. Expires August 2007 [Page 9] Internet-Draft The NANO Draft February 2007 Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Petrescu, et al. Expires August 2007 [Page 10]