draft-ietf-nemo-requirements-01.txt   draft-ietf-nemo-requirements-02.txt 
NEMO Working Group Thierry Ernst, Editor NEMO Working Group Thierry Ernst, Editor
Internet-Draft WIDE and INRIA Internet-Draft WIDE and INRIA
May, 2003 February, 2004
"Network Mobility Support Goals and Requirements" "Network Mobility Support Goals and Requirements"
<draft-ietf-nemo-requirements-01.txt> <draft-ietf-nemo-requirements-02.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04
3. NEMO Working Group Goals and Methodology . . . . . . . . . . 04 3. NEMO Working Group Goals and Methodology . . . . . . . . . . 04
4. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 05 4. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 05
5. NEMO Basic Support One-liner Requirements . . . . . . . . . 09 5. NEMO Basic Support One-liner Requirements . . . . . . . . . 09
6. Changes From Previous Version . . . . . . . . . . . . . . . 11 6. Changes From Previous Version . . . . . . . . . . . . . . . 10
A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11
B. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 B. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
Conventions used in this document Conventions used in this document
skipping to change at page 6, line 15 skipping to change at page 6, line 15
MR(s) would better be avoided. MR(s) would better be avoided.
- Operational Transparency: NEMO support is to be implemented at - Operational Transparency: NEMO support is to be implemented at
the IP layer level. It is expected to be transparent to upper the IP layer level. It is expected to be transparent to upper
layers so that any upper layer protocol can run unchanged on top layers so that any upper layer protocol can run unchanged on top
of an IP layer extended with NEMO support. of an IP layer extended with NEMO support.
- Arbitrary Configurations: The formation of a mobile network can - Arbitrary Configurations: The formation of a mobile network can
exist in various levels of complexity. In the simplest case, a exist in various levels of complexity. In the simplest case, a
mobile network contains just a mobile router and a host. In the mobile network contains just a mobile router and a host. In the
most complicated case, a mobile network is multi-homed and is most complicated case, a mobile network is multihomed and is
itself a multi-level aggregation of mobile networks with itself a multi-level aggregation of mobile networks with
collectively thousands of mobile routers and hosts. While the list collectively thousands of mobile routers and hosts. While the list
of potential configurations of mobile networks cannot be limited, of potential configurations of mobile networks cannot be limited,
at least the following configurations are desirable: at least the following configurations are desirable:
o mobile networks of any size, ranging from a sole subnet with o mobile networks of any size, ranging from a sole subnet with
a few IP devices to a collection of subnets with a large a few IP devices to a collection of subnets with a large
number of IP devices, number of IP devices,
o nodes that change their point of attachment within the mobile o nodes that change their point of attachment within the mobile
network, network,
o foreign mobile nodes that attach to the mobile network, o foreign mobile nodes that attach to the mobile network,
o multi-homed mobile network either when a single MR has o multihomed mobile network either when a single MR has
multiple attachments to the internet, or when the mobile multiple attachments to the internet, or when the mobile
network is attached to the Internet by means of multiple network is attached to the Internet by means of multiple
MRs (see definition in [NEMO-TERMS]), MRs (see definition in [NEMO-TERMS]),
o nested mobile networks (mobile networks attaching to other o nested mobile networks (mobile networks attaching to other
mobile networks, see definition in [NEMO-TERMS]. Although the mobile networks, see definition in [NEMO-TERMS]. Although the
complexity requirements of those nested networks is not complexity requirements of those nested networks is not
clear, it is desirable to support arbitrary levels of clear, it is desirable to support arbitrary levels of
recursive networks, and only in the case where this is recursive networks, and only in the case where this is
impractical and protocol concerns preclude this support impractical and protocol concerns preclude this support
should the solution impose restrictions on nesting should the solution impose restrictions on nesting
(e.g. path MTU), (e.g. path MTU),
o distinct mobility frequencies, o distinct mobility frequencies (see mobility factor in
[MOBILITY-TERMS])
o distinct access medium. o distinct access medium.
In order to keep complexity minimal, transit networks are excluded In order to keep complexity minimal, transit networks are excluded
from this list. A transit network is one in which data would be from this list. A transit network is one in which data would be
forwarded between two endpoints outside of the network, so that forwarded between two endpoints outside of the network, so that
the network itself simply serves as a transitional conduit for the network itself simply serves as a transitional conduit for
packet forwarding. A stub network (leaf network), on the other packet forwarding. A stub network (leaf network), on the other
hand, does not serve as a data forwarding path. Data on a stub hand, does not serve as a data forwarding path. Data on a stub
network is either sent by or addressed to a node located within network is either sent by or addressed to a node located within
skipping to change at page 9, line 7 skipping to change at page 9, line 7
provide means for MNNs to hide their real topological location to provide means for MNNs to hide their real topological location to
their CNs. their CNs.
- IPv4 and NAT traversal: IPv4 clouds and NAT are likely to co- - IPv4 and NAT traversal: IPv4 clouds and NAT are likely to co-
exist with IPv6 for a long time, so it is desirable to ensure exist with IPv6 for a long time, so it is desirable to ensure
mechanisms developped for NEMO will be able to traverse such mechanisms developped for NEMO will be able to traverse such
clouds. clouds.
5. NEMO Basic Support One-liner Requirements 5. NEMO Basic Support One-liner Requirements
The NEMO WG will specify a unified and unique solution for "Basic The NEMO WG will specify a unified and unique "Network Mobility Basic
Network Mobility Support". The solution will allow all nodes in the Support" solution. The solution will allow all nodes in the mobile
mobile network to be reachable via permanent IP addresses, as well as network to be reachable via permanent IP addresses, as well as
maintain ongoing sessions as the MR changes its point of attachment maintain ongoing sessions as the MR changes its point of attachment
to the Internet topology. This will be done by maintaining a to the Internet topology. This will be done by maintaining a
bidirectional tunnel between a MR and its Home Agent. The Working bidirectional tunnel between a MR and its Home Agent. The Working
Group will investigate reusing the existing Mobile IPv6 mechanisms Group will investigate reusing the existing Mobile IPv6 mechanisms
for the tunnel management, or extend it if deemed necessary. for the tunnel management, or extend it if deemed necessary.
The following requirements are placed on the NEMO Basic Support The following requirements are placed on the NEMO Basic Support
solution, hereafter referred to as "the solution": solution, hereafter referred to as "the solution":
R01: The solution MUST be implemented at the IP layer level. R01: The solution MUST be implemented at the IP layer level.
skipping to change at page 9, line 42 skipping to change at page 9, line 42
R06: The solution MUST not require modifications to any node other R06: The solution MUST not require modifications to any node other
than MRs and HAs. than MRs and HAs.
R07: The solution MUST support fixed nodes, mobile hosts and mobile R07: The solution MUST support fixed nodes, mobile hosts and mobile
routers in the mobile network. routers in the mobile network.
R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile
network link as either a home link or a foreign link. network link as either a home link or a foreign link.
R09: The solution MUST not prevent the proper operation of Mobile R09: The solution MUST ensure backward compatibility with other
IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to operate standards defined by the IETF. This include particularly:
either the CN, HA, or MN operations defined in [MIPv6])
[SHOULD BE MOVED UNDER R17] R09:1: The solution MUST not prevent the proper operation of
Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled
MNNs to operate either the CN, HA, or MN operations
defined in [MIPv6])
R10: The solution MUST treat all the potential configurations the R10: The solution MUST treat all the potential configurations the
same way (whatever the number of subnets, MNNs, nested levels same way (whatever the number of subnets, MNNs, nested levels
of MRs, egress interfaces, ...) of MRs, egress interfaces, ...)
R11: The solution MUST support at least 2 levels of nested mobile R11: The solution MUST support at least 2 levels of nested mobile
networks, while, in principle, arbitrary levels of recursive networks, while, in principle, arbitrary levels of recursive
mobile networks SHOULD be supported. mobile networks SHOULD be supported.
R12: The solution MUST function for multihomed MR and multihomed R12: The solution MUST function for multihomed MR and multihomed
mobile networks as defined in [NEMO-TERMS]). Particularly: mobile networks as defined in [NEMO-TERMS]).
R12.1: The solution MUST function for multi-MR mobile networks
R12.2: The solution MUST function for multi-egress
interfaces
R12.3: The solution MUST function for MR with multiple global
addresses on an egress interface.
[I PROPOSE TO REMOVE R12.1, 2 and 3 BECAUSE THIS IS
CONTAINED IN THE DEFINITION IN [NEMO-TERMS]].
R13: NEMO Support signaling over the bidirectional MUST be minimized R13: NEMO Support signaling over the bidirectional MUST be minimized
[NEW REQUIREMENT PROPOSED BY EDITOR]
R14: Signaling messages between the HA and the MR MUST be secured: R14: Signaling messages between the HA and the MR MUST be secured:
R14.1: The receiver MUST be able to authenticate the sender R14.1: The receiver MUST be able to authenticate the sender
R14.2: The function performed by the sender MUST be authorized R14.2: The function performed by the sender MUST be authorized
for the content carried for the content carried
R14.3: Anti-replay MUST be provided R14.3: Anti-replay MUST be provided
R14.4: The signaling messages SHOULD be encrypted [ACCORDING TO R14.4: The signaling messages MAY be encrypted
DISCUSSION AT IETF56, SHALL BE REMOVED or SOFTENED TO
"MAY" (?)]
R15: The solution MUST ensure transparent continuation of routing and R15: The solution MUST ensure transparent continuation of routing and
management operations over the bi-directional tunnel when the MR management operations over the bi-directional tunnel (this
is away from home. (this includes e.g. routing protocols, router includes e.g. unicast and multicast routing protocols, router
renumbering, DHCPv6, etc) renumbering, DHCPv6, etc)
R16: The solution MUST not impact on the routing fabric neither on R16: The solution MUST not impact on the routing fabric neither on
the Internet addressing architecture. [ACCORDING TO IETF56 the Internet addressing architecture. [ACCORDING TO IETF56
minutes, SHOULD BE REMOVED] minutes, SHOULD BE REMOVED]
R17: The solution MUST ensure backward compatibility with other R18: The solution MAY preserve sessions established through
standards defined by the IETF [SPECIFIC PROTOCOLS SHOULD BE another egress interface when one fails
EXPLICITLY LISTED: MLD, ... etc. PLEASE CONTRIBUTE THE NAMES OF
PROTOCOLS TO BE INCLUDED ON THE MAILING LIST. MAYBE MIPV6 COULD
BE INCLUDED HERE INSTEAD OF R09.] Particularly:
R18: The solution SHOULD preserve sessions established through 6. Changes Between Versions
another egress interface when one fails [PROPOSED BY EDITOR OF
THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE
MAILING LIST]
6. Changes since last version 6.1. Changes Between Version -01 and -02
- removed sub-items in R12 (sub-cases are contained into the
definition of multihoming)
- minor typos
- R15: Added "multicast"
- R14.4: SHOULD softened to MAY according to discussion at IETF56th
meeting.
- R17 moved to R09 and contains former R09 as a sub-case.
- R18: relaxed from "SHOULD" to may based on Vijay Devarapalli
comment (030718)
6.2 Changes Between Version -00 and -01
- title of documents: included the word "goals" - title of documents: included the word "goals"
- entire document: some rewording - entire document: some rewording
- section 4: changed title of section to "NEMO Design Goals". - section 4: changed title of section to "NEMO Design Goals".
- section 4: removed "MUST" and "MAY" - section 4: removed "MUST" and "MAY"
- section 4: more text about location privacy - section 4: more text about location privacy
skipping to change at page 13, line 5 skipping to change at page 13, line 5
"Internet Protocol Version 6 (IPv6) Specification" "Internet Protocol Version 6 (IPv6) Specification"
IETF RFC 2460, December 1998. IETF RFC 2460, December 1998.
C. Editors's Addresses C. Editors's Addresses
Questions about this document can be directed to the NEMO working Questions about this document can be directed to the NEMO working
group chairs: group chairs:
Thierry Ernst, Thierry Ernst,
Keio University. Keio University.
5322 Endo, Fujisawa-shi, K-square Town Campus
Kanagawa 252-8520, Japan. 1488-8 Ogura, Saiwai-ku, Kawasaki
Phone : +81-466-49-1100 Kanagawa, 212-0054 Japan
Fax : +81-466-49-1395 Phone : +81-44-580-1600
Fax : +81-44-580-1437
Email : ernst@sfc.wide.ad.jp Email : ernst@sfc.wide.ad.jp
T. J. Kniveton T. J. Kniveton
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043, USA Mountain View, California 94043, USA
Phone : +1 650 625-2025 Phone : +1 650 625-2025
Fax : +1 650 625-2502 Fax : +1 650 625-2502
EMail : Timothy.Kniveton@Nokia.com EMail : Timothy.Kniveton@Nokia.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/