One document matched: draft-jhlee-mext-mnpp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 20:25:19 |