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]