Network Working Group J.-H. Lee Internet-Draft M. Tsukada Intended status: Informational T. Ernst Expires: April 22, 2010 INRIA Rocquencourt October 19, 2009 Mobile Network Prefix Provisioning draft-jhlee-mext-mnpp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Lee, et al. Expires April 22, 2010 [Page 1] Internet-Draft Mobile Network Prefix Provisioning October 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract In the context of vehicular networks for Intelligent Transportation Systems (ITS), vehicles that comprise in-vehicle networks require to discover Mobile Network Prefixes (MNPs) of other vehicles in order to communicate with other vehicles or the roadside infrastructure on the same wireless link. This document proposes Mobile Network Prefix Provisioning (MNPP), a solution to advertise an MNP assigned to a vehicle to others in both a proactive or reactive fashion. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 3. Mobile Network Prefix Provisioning . . . . . . . . . . . . . . 4 4. Applicable Scenarios . . . . . . . . . . . . . . . . . . . . . 4 4.1. Infrastructure-based scenario . . . . . . . . . . . . . . . 4 4.2. Infrastructure-less scenario . . . . . . . . . . . . . . . 5 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Mobile Network Prefix Provisioning Solicitation . . . . . . 5 5.2. Mobile Network Prefix Provisioning Advertisement . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. Next Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Lee, et al. Expires April 22, 2010 [Page 2] Internet-Draft Mobile Network Prefix Provisioning October 2009 1. Introduction In vehicular networks for ITS, vehicles require to communicate with other vehicles or the roadside infrastructure on the same wireless link. Vehicles comprise their in-vehicle networks where permanent IPv6 prefixes are allocated. The permanet IPv6 prefix is here referred as an MNP as defined in [RFC3753], [RFC3963]. The MNP being used in the in-vehicle network of the vehicle is provided by a Home Agent operating in a remote central ITS network. The in-vehicle network is attached to a public or private network through its Vehicular Mobile Router (VMR) operating as NEMO Basic Support [RFC3963] for maintaining IP session continuity while performing vertical and horizontal handovers. As such, VMRs attached to the in- vehicle network of the VMR have permanent Home Addresses (HoAs) configured from the MNP. While VMRs remain in a reachable wireless communication range of a Roadside Access Router (RAR), the VMRs would configure a link-local address and a global Care-of Address (CoA). However, vehicles need to discover IPv6 prefixes, i.e., MNPs, associated with neighbor vehicles in order for Mobile Network Nodes (MNNs) to talk to one another. Without any specific mechanisms, VMRs would only know what is the link-local address or CoA of neighbor vehicles, but not their associated MNPs. This document proposes Mobile Network Prefix Provisioning (MNPP), a solution based on an extension of Neighbor Discovery Protocol (NDP) [RFC4861] to distribute the MNP in both a proactive or reactive fashion. 2. Requirements Notation 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]. The document uses the terminology specified in [RFC3753], [RFC3963]. In addition, this document defines the following: o Vehicular Mobile Router (VMR): A mobile router located at the vehicle that provides communication service to devices connected to its in-vehicle network. o Roadside Access Router (RAR): An access router located at the roadside infrastructure that provides communication service to vehicles. Lee, et al. Expires April 22, 2010 [Page 3] Internet-Draft Mobile Network Prefix Provisioning October 2009 o Mobile Network Prefix Provisioning (MNPP) Solicitation Message: A solicitation message sent by the VMR or the RAR to receive an advertisement message containing the MNP information quickly. o Mobile Network Prefix Provisioning (MNPP) Advertisement Message: An advertisement message sent by the VMR to announce its MNP information. This message is periodically sent, or in response to a solicitation message. 3. Mobile Network Prefix Provisioning The proposed mechanism in this document extends the router advertisement (RA) and router solicitation (RS) messages defined in NDP to announce the MNP assigned to a vehicle to other vehicles or the roadside infrastructure on the same wireless link. In order to distribute the MNP, MNPP Advertisement messages are sent through the egress interface of VMR which is used to communicate with other vehicles or the roadside infrastructure. Note that the ingress interface of the VMR is connected with its in-vehicle network. MNPP Solicitation messages are used to request MNPP Advertisement messages quickly. o As a proactive fashion, the VMR periodically sends the unsolicited MNPP Advertisement messages including the MNP being used in its in-vehicle network. Upon reception of the MNPP Advertisement message, other VMRs and RARs obtain the MNP of the VMR. It is similar to the case of sending unsolicited RA messages defined in NDP. o As a reactive fashion, the VMR upon reception of the MNPP Solicitation messages immediately sends the solicited MNPP Advertisement messages including the MNP being used in its in- vehicle network. The MNPP Solicitation messages SHOULD be used to prompt VMRs to generate the MNPP Advertisement messages quickly. It is similar to the case of requesting solicited RA messages defined in NDP. 4. Applicable Scenarios TBA. 4.1. Infrastructure-based scenario TBA. Lee, et al. Expires April 22, 2010 [Page 4] Internet-Draft Mobile Network Prefix Provisioning October 2009 4.2. Infrastructure-less scenario TBA. 5. Message Formats This section provides message formats for MNPP Solicitation and MNPP Advertisement messages used in this document. 5.1. Mobile Network Prefix Provisioning Solicitation VMRs and RARs send MNPP Solicitation messages in order to prompt VMRs to generate MNPP Advertisement messages quickly. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IPv6 address assigned to the sending interface. Destination Address The all-routers multicast address or the specific IPv6 address. Hop Limit 255 ICMP Fields: Type TBA. The ICMP type number MUST be allocated by the IANA. Lee, et al. Expires April 22, 2010 [Page 5] Internet-Draft Mobile Network Prefix Provisioning October 2009 Code 0 Checksum The ICMP checksum. See [RFC4443]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender SHOULD be included. Receivers MUST sliently igonore any options if they do not recognize and continue processing. 5.2. Mobile Network Prefix Provisioning Advertisement VMRs send out MNPP Advertisement messages periodically (as a proactive fashion), or in response to MNPP Solicitation messages (as a reactive fashion). 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IPv6 address assigned to the sending interface. Destination Address Lee, et al. Expires April 22, 2010 [Page 6] Internet-Draft Mobile Network Prefix Provisioning October 2009 The all-routers multicast address or the specific IPv6 address. Hop Limit 255 ICMP Fields: Type TBA. The ICMP type number MUST be allocated by the IANA. Code 0 Checksum The ICMP checksum. See [RFC4443]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender SHOULD be included. In-vehicle MTU The MTU used in the in-vehicle network SHOULD be sent. Mobile Network Prefix Option The MNP MUST be included to indicate which prefix is being used in the in-vehicle network. Receivers MUST sliently igonore any options if they do not recognize and continue processing. Lee, et al. Expires April 22, 2010 [Page 7] Internet-Draft Mobile Network Prefix Provisioning October 2009 6. Security Considerations TBA. 7. IANA Considerations The ICMP type numbers for MNPP Solicitation and Advertisement messages MUST be allocated by the IANA. 8. Next Text The following issues will be covered in the next version of this document. o Applicable Scenarios: MNPP operates in both infrastructure-based and infrastructure-less scenarios. In the next version of this document, applicable scenarios will be covered. o Security Considerations: A number of threats addressed in [RFC3756] are expected to launch on MNPP used to announce the MNP of a VMR. Secure Neighbor Discovery (SEND) [RFC3971] SHOULD be extended to protect the transaction of MNPP Solicitation and Advertisement messages. In the next version of this document, security considerations will be covered. 9. Acknowledgment Comments are solicited and should be addressed to the MEXT working group's mailing list at mext@ietf.org and/or the authors. 10. References [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Lee, et al. Expires April 22, 2010 [Page 8] Internet-Draft Mobile Network Prefix Provisioning October 2009 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Authors' Addresses Jong-Hyouk Lee INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay, 78153 France Phone: +33 1 39 63 59 30 Email: jong-hyouk.lee@inria.fr; jonghyouk@gmail.com Manabu Tsukada INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay, 78153 France Phone: +33 1 39 63 59 30 Email: manabu.tsukada@inria.fr Thierry Ernst INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay, 78153 France Phone: +33 1 39 63 59 30 Email: thierry.ernst@inria.fr Lee, et al. Expires April 22, 2010 [Page 9]