< draft-thubert-nemo-reverse-routing-header-04.txt   draft-thubert-nemo-reverse-routing-header-05.txt >
Network Working Group P. Thubert Network Working Group P. Thubert
Internet-Draft M. Molteni Internet-Draft M. Molteni
Expires: ao“t 1, 2004 Cisco Systems Expires: November 30, 2004 Cisco Systems
February 2004 June 2004
IPv6 Reverse Routing Header and its application to Mobile Networks IPv6 Reverse Routing Header and its application to Mobile Networks
draft-thubert-nemo-reverse-routing-header-04 draft-thubert-nemo-reverse-routing-header-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on ao“t 1, 2004. This Internet-Draft will expire on November 30, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Already existing proposals enable Mobile Networks by extending Mobile NEMO basic support enables Mobile Networks by extending Mobile IP to
IP to support Mobile Routers. In order to enable nested Mobile Mobile Routers. In the case of nested Mobile Networks, this involves
Networks, some involve the overhead of nested tunnels between the the overhead of nested tunnels between the Mobile Routers and their
Mobile Routers and their Home Agents. Home Agents, and causes a number of security issues.
This proposal allows the building of a nested Mobile Network avoiding This proposal alleviates those problems as well as other minor ones,
the nested tunnel overhead. This is accomplished by using a new by using a source routing within the mobile nested structure,
routing header, called the reverse routing header, and by overlaying introducing a new routing header, called the reverse routing header.
a layer 3 tree topology on the evolving Mobile Network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Recursive complexity . . . . . . . . . . . . . . . . . . . 3 1.1 Recursive complexity . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Assumptions . . . . . . . . . . . . . . . 5 2. Terminology and Assumptions . . . . . . . . . . . . . . . . 5
2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
3. An Example . . . . . . . . . . . . . . . . . . . . . . . . 7 3. An Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. New Routing Headers . . . . . . . . . . . . . . . . . . . 11 4. New Routing Headers . . . . . . . . . . . . . . . . . . . . 11
4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . 11 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . 11
4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . 13 4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . 13
4.3 Extension Header order . . . . . . . . . . . . . . . . . . 15 4.3 Extension Header order . . . . . . . . . . . . . . . . . . 15
5. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Optimum number of slots in RRH . . . . . . . . . . . . . . . 17
6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . 19 6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 19
6.1 Modified Router Advertisement Message Format . . . . . . . 19 6.1 Modified Router Advertisement Message Format . . . . . . . 19
6.2 New Tree Information Option Format . . . . . . . . . . . . 20 7. MIPv6 flows . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Binding Cache Management . . . . . . . . . . . . . . . . . 23 7.1 DHAAD . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1 Binding Updates . . . . . . . . . . . . . . . . . . . . . 23 7.2 Binding Updates . . . . . . . . . . . . . . . . . . . . . 20
7.2 RRH Heartbeat . . . . . . . . . . . . . . . . . . . . . . 23 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 21
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . 24 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 23
9. Mobile Router Operation . . . . . . . . . . . . . . . . . 26 9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 23
9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 26 9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 24
9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 27 9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 24
9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 27 9.4 Processing of the extended Routing Header Type 2 . . . . . 25
9.4 Processing of Tree Information Option . . . . . . . . . . 28 9.5 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 27
9.5 Processing of the extended Routing Header Type 2 . . . . . 28 10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 27
9.6 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . 28
10. Mobile Host Operation . . . . . . . . . . . . . . . . . . 30 11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . 30 11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . 28
11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . . 30 11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . 28
11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . . . . 31 11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . 30
11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . . . . 31 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 31
11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 34
A. Optimizations . . . . . . . . . . . . . . . . . . . . . . 36 A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 34
A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 36 A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 35
A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 37 A.2.1 Routing Header Type 3 (Home Address option
A.2.1 Routing Header Type 3 (Home Address option replacement) . 38 replacement) . . . . . . . . . . . . . . . . . . . . . 36
B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . 40 B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 38
B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 40 B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 38
B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 41 B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 39
C. Changes from Previous Version of the Draft . . . . . . . . 42 C. Changes from Previous Version of the Draft . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . 42
1. Introduction 1. Introduction
This document assumes the reader is familiar with the Mobile Networks This document assumes that the reader is familiar with the Mobile
terminology defined in [2] and with Mobile IPv6 defined in [1]. Networks terminology defined in [9] and [11], with Mobile IPv6
defined in [10], and with the NEMO basic support defined in [12].
Generally a Mobile Network may be either simple (a network with one Generally a Mobile Network may be either solid (a network with one
mobile router) or nested, single or multi-homed. This proposal starts mobile router) or nested, single or multi-homed. This proposal
from the assumption that nested Mobile Networks will be the norm, and starts from the assumption that nested Mobile Networks will be the
so presents a solution that avoids the tunnel within tunnel overhead norm, and so presents a solution that avoids the tunnel within tunnel
of already existing proposals. overhead of already existing proposals.
The solution is based on a single bi-directional tunnel between the The solution is based on a single, telescopic tunnel between the
first Mobile Router (MR) to forward a packet and its Home Agent (HA). first Mobile Router (MR) to forward a packet and its Home Agent (HA).
By using IPsec ESP on that tunnel, home equivalent privacy is By using IPsec ESP on that tunnel, home equivalent privacy is
obtained without further encapsulation. obtained without further encapsulation.
The solution uses a new Routing Header (RH), called the Reverse The solution introduces a new Routing Header (RH), called the Reverse
Routing Header (RRH), to provide an optimized path for the single Routing Header (RRH), to perform source routing within the mobile
tunnel. RRH is a variant of IPv4 Loose Source and Record Route (LSRR) structure. RRH is a variant of IPv4 Loose Source and Record Route
[6] adapted for IPv6. RRH records the route out of the nested Mobile (LSRR) [1] adapted for IPv6. RRH records the route out of the nested
Network and can be trivially converted into a routing header for Mobile Network and can be trivially converted into a routing header
packets destined to the Mobile Network. for packets destined to the Mobile Network.
This version focuses on single-homed Mobile Networks. Hints for This version focuses on single-homed Mobile Networks. Hints for
further optimizations and multi-homing are given in the appendixes. further optimizations and multi-homing are given in the appendixes.
Local Fixed Node (LFN) and Correspondent Node (CN) operations are Local Fixed Node (LFN) and Correspondent Node (CN) operations are
left unchanged as in Mobile IPv6 [1]. Specifically the CN can also be left unchanged from Mobile IPv6 [10]. Specifically the CN can also
a LFN. be a LFN.
Section 3 proposes an example to illustrate the operation of the Section 3 proposes an example to illustrate the operation of the
proposed solution, leaving detailed specifications to the remaining proposed solution, leaving detailed specifications to the remaining
chapters. The reader may refer to Section 2.1 for the specific chapters. The reader may refer to Section 2.1 for the specific
terminology. terminology.
1.1 Recursive complexity 1.1 Recursive complexity
A number of drafts and publications suggest -or can be extended to- a A number of drafts and publications suggest -or can be extended to- a
model where the Home Agent and any arbitrary Correspondent would model where the Home Agent and any arbitrary Correspondent would
actually get individual binding from the chain of nested Mobile actually get individual binding from the chain of nested Mobile
Routers, and form a routing header appropriately. Routers, and form a routing header appropriately.
An intermediate MR would keep track of all the pending communications An intermediate MR would keep track of all the pending communications
between hosts in its subtree of Mobile Networks and their CNs, and a between hosts in its subtree of Mobile Networks and their CNs, and a
binding message to each CN each time it changes its point of binding message to each CN each time it changes its point of
attachment. attachment.
skipping to change at page 4, line 13 skipping to change at page 4, line 15
If this was done, then each CN, by receiving all the binding messages If this was done, then each CN, by receiving all the binding messages
and processing them recursively, could infer a partial topology of and processing them recursively, could infer a partial topology of
the nested Mobile Network, sufficient to build a multi-hop routing the nested Mobile Network, sufficient to build a multi-hop routing
header for packets sent to nodes inside the nested Mobile Network. header for packets sent to nodes inside the nested Mobile Network.
However, this extension has a cost: However, this extension has a cost:
1. Binding Update storm 1. Binding Update storm
when one MR changes its point of attachment, it needs to send a when one MR changes its point of attachment, it needs to send a
BU to all the CNs of each node behind him. When the Mobile BU to all the CNs of each node behind him. When the Mobile
Network is nested, the number of nodes and relative CNs can be Network is nested, the number of nodes and relative CNs can be
huge, leading to congestions and drops. huge, leading to congestions and drops.
2. Protocol Hacks 2. Protocol Hacks
Also, in order to send the BUs, the MR has to keep track of all Also, in order to send the BUs, the MR has to keep track of all
the traffic it forwards to maintain his list of CNs. In case of the traffic it forwards to maintain his list of CNs. In case of
IPSec tunneled traffic, that CN information may not be available. IPSec tunneled traffic, that CN information may not be available.
3. CN operation 3. CN operation
The computation burden of the CN becomes heavy, because it has to The computation burden of the CN becomes heavy, because it has to
analyze each BU in a recursive fashion in order to infer nested analyze each BU in a recursive fashion in order to infer nested
Mobile Network topology required to build a multi hop routing Mobile Network topology required to build a multi hop routing
header. header.
4. Missing BU 4. Missing BU
skipping to change at page 4, line 42 skipping to change at page 4, line 44
If a CN doesn't receive the full set of PSBU sent by the MR, it If a CN doesn't receive the full set of PSBU sent by the MR, it
will not be able to infer the full path to a node inside the will not be able to infer the full path to a node inside the
nested Mobile Network. The RH will be incomplete and the packet nested Mobile Network. The RH will be incomplete and the packet
may or may not be delivered. may or may not be delivered.
5. Obsolete BU 5. Obsolete BU
If the Binding messages are sent asynchronously by each MR, then, If the Binding messages are sent asynchronously by each MR, then,
when the relative position of MRs and/or the TLMR point of when the relative position of MRs and/or the TLMR point of
attachment change rapidly, the image of Mobile Network that the attachment change rapidly, the image of Mobile Network that the
CN maintains is highly unstable. If only one BU in the chain is CN maintains is highly unstable. If only one BU in the chain is
obsolete due to the movement of an intermediate MR, the obsolete due to the movement of an intermediate MR, the
connectivity may be lost. connectivity may be lost.
A conclusion is that the path information must be somehow aggregated A conclusion is that the path information must be somehow aggregated
to provide the CN with consistent snapshots of the full path across to provide the CN with consistent snapshots of the full path across
the Mobile Network. This can be achieved by an IPv6 form of loose the Mobile Network. This can be achieved by an IPv6 form of loose
source / record route header, that we introduce here as a Reverse source / record route header, that we introduce here as a Reverse
Routing Header Routing Header
2. Terminology and Assumptions 2. Terminology and Assumptions
2.1 Terminology 2.1 Terminology
Simple Mobile Network This document assumes that the reader is familiar with Mobile IPv6 as
defined in [10] and with the concept of Mobile Router defined in the
NEMO terminology document [11]. In particular, the "Nested Mobility
Terms" introduced in the NEMO terminology are repeatedly used in this
document.
One or more IP subnets attached to a MR and mobile as a unit, with Solid Mobile Network:
respect to the rest of the Internet. A simple Mobile Network can
be either single or multi-homed.
The IP subnets may have any kind of topology and may contain fixed One or more IP subnets attached to a MR and mobile as a unit, with
routers. All the access points of the Mobile Network (to which respect to the rest of the Internet. A Solid Mobile Network can
further MRs may attach) are on the same layer 2 link of the MR. be either singly or multi-homed. A Solid Mobile Network may be
composed of more then one link and may interconnect several
routers, but all routers in the Solid Mobile Network are fixed
with respect to each other.
We like to represent a simple single-homed Mobile Network as an We like to represent a simple single-homed Mobile Network as an
hanger, because it has only one uplink hook and a bar to which hanger, because it has only one uplink hook and a bar to which
multiple hooks can be attached. Graphically we use the question multiple hooks can be attached. Graphically we use the question
mark "?" to show the uplink hook (interface) connected to the MR, mark "?" to show the uplink hook (interface) connected to the MR,
and the "=" sign to represent the bar: and the "=" sign to represent the bar:
? ?
MR1 MR1
| |
=============== ===============
Nested Mobile Network IPv6 Mobile Host:
A group of simple Mobile Networks recursively attached together
and implementing nested Mobility as defined in [2].
?
MR1
|
====?===============?====
MR2 MR3
| |
=========== ===?==========?===
MR4 MR5
| |
========== ============
IPv6 Mobile Host
A IPv6 Host, with support for MIPv6 MN, and the additional Nemo A IPv6 Host, with support for MIPv6 MN, and the additional NEMO
capability described in this draft. capability described in this draft.
Home prefix Home prefix
Network prefix, which identifies the home link within the Internet Network prefix, which identifies the home link within the Internet
topology. topology.
Mobile Network prefix Mobile Network prefix
Network prefix, common to all IP addresses in the Mobile Network Network prefix, common to all IP addresses in the Mobile Network
when the MR is attached to the home link. It may or may not be a when the MR is attached to the home link. It may or may not be a
subset of the Home subnet prefix. subset of the Home subnet prefix.
Inbound direction: Inbound direction:
direction from outside the Mobile Network to inside direction from outside the Mobile Network to inside
Outbound direction: Outbound direction:
direction from inside the Mobile Network to outside direction from inside the Mobile Network to outside
2.2 Assumptions RRH:
Reverse Routing Header, defined in this specification
NULL RRH:
A NULL RRH is an RRH with a null "Segments Used" field
2.2 Assumptions
We make the following assumptions: We make the following assumptions:
1. A MR has one Home Agent and one Home Address -> one primary CoA. 1. A MR has one Home Agent and one Home Address -> one primary CoA.
2. A MR attaches to a single Attachment Router as default router. 2. A MR attaches to a single Attachment Router as default router.
3. A MR may have more than one uplink interface. 3. A MR may have more than one uplink interface.
4. An interface can be either wired or wireless. The text assumes 4. An interface can be either wired or wireless. The text assumes
that interfaces are wireless for generality. that interfaces are wireless for generality.
5. Each simple Mobile Network may have more that one L2 Access 5. Each Solid Mobile Network may have more that one L2 Access Point,
Point, all of them controlled by the same Attachment Router, all of them controlled by the same Attachment Router, which we
which we assume to be the Mobile Router. assume to be the Mobile Router.
Since an MR has only one primary CoA, only one uplink interface can Since an MR has only one primary CoA, only one uplink interface can
be used at a given point of time. Since the MR attaches to a single be used at a given point of time. Since the MR attaches to a single
attachment router, if due care is applied to avoid loops, then the attachment router, if due care is applied to avoid loops, then the
resulting topology is a tree. resulting topology is a tree.
3. An Example 3. An Example
The nested Mobile Network in the following figure has a tree The nested Mobile Network in the following figure has a tree
topology, according to the assumptions in Section 2.2. In the tree topology, according to the assumptions in Section 2.2. In the tree
each node is a simple Mobile Network, represented by its MR. each node is a Solid Mobile Network, represented by its MR.
+---------------------+ +---------------------+
| Internet |---CN | Internet |---CN
+---------------|-----+ +---------------|-----+
/ Access Router / Access Router
MR3_HA | MR3_HA |
======?====== ======?======
MR1 MR1
| |
====?=============?==============?=== ====?=============?==============?===
skipping to change at page 7, line 33 skipping to change at page 7, line 33
MR3 MR3
| |
==|=========?== <-- Mobile Network3 ==|=========?== <-- Mobile Network3
LFN1 MR4 LFN1 MR4
| |
========= =========
An example nested Mobile Network An example nested Mobile Network
This example focuses on a Mobile Network node at depth 3 (Mobile This example focuses on a Mobile Network node at depth 3 (Mobile
Network3) inside the tree, represented by its mobile router MR3. The Network3) inside the tree, represented by its mobile router MR3. The
path to the Top Level Mobile Router (TLMR) MR1 and then the Internet path to the Top Level Mobile Router (TLMR) MR1 and then the Internet
is is
MR3 -> MR2 -> MR1 -> Internet MR3 -> MR2 -> MR1 -> Internet
Consider the case where a LFN belonging to Mobile Network3 sends a Consider the case where a LFN belonging to Mobile Network3 sends a
packet to a CN in the Internet, and the CN replies back. With the packet to a CN in the Internet, and the CN replies back. With the
tunnel within tunnel approach described by [3], we would have three tunnel within tunnel approach described by [12], we would have three
bi-directional nested tunnels: bi-directional nested tunnels:
-----------. -----------.
--------/ /-----------. --------/ /-----------.
-------/ | | /----------- -------/ | | /-----------
CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN
MR3_HA -------\ | | \----------- MR3 MR3_HA -------\ | | \----------- MR3
MR2_HA --------\ \----------- MR2 MR2_HA --------\ \----------- MR2
MR1_HA ----------- MR1 MR1_HA ----------- MR1
skipping to change at page 8, line 18 skipping to change at page 8, line 18
On the other hand, with the RRH approach we would have only one On the other hand, with the RRH approach we would have only one
bi-directional tunnel: bi-directional tunnel:
--------------------------------- MR1 ---- MR2 ---- MR3 --------------------------------- MR1 ---- MR2 ---- MR3
CN ------( - - - - - - - - - - - - - - - - (-------- LFN CN ------( - - - - - - - - - - - - - - - - (-------- LFN
MR3_HA --------------------------------- MR1 ---- MR2 ---- MR3 MR3_HA --------------------------------- MR1 ---- MR2 ---- MR3
The first mobile router on the path, MR3, in addition to tunneling The first mobile router on the path, MR3, in addition to tunneling
the packet to its HA, adds a reverse routing header with N = 3 the packet to its HA, adds a reverse routing header with N = 3
pre-allocated slots. Choosing the right value for N is discussed in pre-allocated slots. Choosing the right value for N is discussed in
Section 6.2. The bottom slot is equivalent to the MIPv6 Home Address Section 5. The bottom slot is equivalent to the MIPv6 Home Address
option. MR3 inserts its home address MR3_HoA into slot 0. option. MR3 inserts its home address MR3_HoA into slot 0.
The outer packet has source MR3's Care of Address, MR3_CoA, and The outer packet has source MR3's Care of Address, MR3_CoA, and
destination MR3's Home Agent, MR3_HA: destination MR3's Home Agent, MR3_HA:
<-------------- outer IPv6 header --------------------> <-------------- outer IPv6 header -------------------->
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
|MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET |MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET
| | |: :| 4 | | | | | | | |: :| 4 | | | | |
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
skipping to change at page 9, line 6 skipping to change at page 9, line 6
RRH from top to bottom is MR3_CoA | MR3_HoA: RRH from top to bottom is MR3_CoA | MR3_HoA:
<-------------- outer IPv6 header --------------------> <-------------- outer IPv6 header -------------------->
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
|MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA|MR3_HoA | |iPACKET |MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA|MR3_HoA | |iPACKET
| | |: :| 4 | | | | | | | |: :| 4 | | | | |
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
In general the process followed by the second router is repeated by In general the process followed by the second router is repeated by
all the routers on the path, including the TLMR (in this example all the routers on the path, including the TLMR (in this example
MR1). When the packet leaves MR1 the source address is MR1_CoA and MR1). When the packet leaves MR1 the source address is MR1_CoA and
the RRH is MR2_CoA | MR3_CoA | MR3_HoA: the RRH is MR2_CoA | MR3_CoA | MR3_HoA:
<-------------- outer IPv6 header --------------------> <-------------- outer IPv6 header -------------------->
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
|MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET |MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET
| | |: :| 4 | | | | | | | |: :| 4 | | | | |
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
In a colloquial way we may say that while the packet travels from MR3 In a colloquial way we may say that while the packet travels from MR3
to MR3_HA, the Mobile Network tunnel end point "telescopes" from MR3 to MR3_HA, the Mobile Network tunnel end point "telescopes" from MR3
to MR2 to MR1. to MR2 to MR1.
When the home agent MR3_HA receives the packet it notices that it When the home agent MR3_HA receives the packet it notices that it
contains a RRH and it looks at the bottom entry, MR3_HoA. This entry contains a RRH and it looks at the bottom entry, MR3_HoA. This entry
is used as if it were a MIPv6 Home Address destination option, i.e. is used as if it were a MIPv6 Home Address destination option, i.e.
as an index into the Binding Cache. When decapsulating the inner as an index into the Binding Cache. When decapsulating the inner
packet the home agent performs the checks described in Section 8, and packet the home agent performs the checks described in Section 8, and
if successful it forwards the inner packet to CN. if successful it forwards the inner packet to CN.
MR3_HA stores two items in the Bind Cache Entry associated with MR3: MR3_HA stores two items in the Bind Cache Entry associated with MR3:
the address entries from RRH, to be used to build the RH, and the the address entries from RRH, to be used to build the RH, and the
packet source address MR1_CoA, to be used as the first hop. packet source address MR1_CoA, to be used as the first hop.
Further packets from the CN to the LFN are plain IPv6 packets. Further packets from the CN to the LFN are plain IPv6 packets.
Destination is LFN, and so the packet reaches MR3's home network. Destination is LFN, and so the packet reaches MR3's home network.
MR3_HA intercepts it, does a Bind Cache prefix lookup and obtains as MR3_HA intercepts it, does a Bind Cache prefix lookup and obtains as
match the MR3 entry, containing the first hop and the information match the MR3 entry, containing the first hop and the information
required to build the RH. It then puts the packet in the tunnel required to build the RH. It then puts the packet in the tunnel
MR3_HA -- MR3 as follows: source address MR3_HA and destination MR3_HA -- MR3 as follows: source address MR3_HA and destination
address the first hop, MR1_CoA. The RH is trivially built out of the address the first hop, MR1_CoA. The RH is trivially built out of the
previous RRH: MR2_CoA | MR3_CoA | MR3_HoA: previous RRH: MR2_CoA | MR3_CoA | MR3_HoA:
<-------------- outer IPv6 header --------------------> <-------------- outer IPv6 header -------------------->
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
|oSRC |oDST |: :|oRH | | | | | |oSRC |oDST |: :|oRH | | | | |
|MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET |MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET
| | |: :| 2 | | | | | | | |: :| 2 | | | | |
+-------+-------++ -- ++----+-------+-------+---------+ +------- +-------+-------++ -- ++----+-------+-------+---------+ +-------
The packet is routed with plain IP routing up to the first The packet is routed with plain IP routing up to the first
destination MR1_CoA. destination MR1_CoA.
The RH of the outer packet is type 2 as in MIPv6 [1], but has The RH of the outer packet is type 2 as in MIPv6 [10], but has
additional semantics inherited from type 0: it contains the path additional semantics inherited from type 0: it contains the path
information to traverse the nested Mobile Network from the TLMR to information to traverse the nested Mobile Network from the TLMR to
the tunnel endpoint MR3. Each intermediate destination forwards the the tunnel endpoint MR3. Each intermediate destination forwards the
packet to the following destination in the routing header. The packet to the following destination in the routing header. The
security aspects of this are treated in Section 11.2. security aspects of this are treated in Section 11.2.
MR1, which is the initial destination in the IP header, looks at the MR1, which is the initial destination in the IP header, looks at the
RH and processes it according to Section 9, updating the RH and the RH and processes it according to Section 9, updating the RH and the
destination and sending it to MR2_CoA. MR2 does the same and so on destination and sending it to MR2_CoA. MR2 does the same and so on
until the packet reaches the tunnel endpoint, MR3. until the packet reaches the tunnel endpoint, MR3.
When the packet reaches MR3, the source address in the IP header is When the packet reaches MR3, the source address in the IP header is
MR3_HA, the destination is MR3_CoA and in the RH there is one segment MR3_HA, the destination is MR3_CoA and in the RH there is one segment
left, MR3_HoA. As a consequence the packet belongs to the MR3_HA -- left, MR3_HoA. As a consequence the packet belongs to the MR3_HA --
MR3 tunnel. MR3 decapsulates the inner packet, applying the rules MR3 tunnel. MR3 decapsulates the inner packet, applying the rules
described in Section 9 and sends it to LFN. The packet that reaches described in Section 9 and sends it to LFN. The packet that reaches
LFN is the plain IPv6 packet that was sent by CN. LFN is the plain IPv6 packet that was sent by CN.
4. New Routing Headers 4. New Routing Headers
This draft modifies the MIPv6 Routing Header type 2 and introduces This draft modifies the MIPv6 Routing Header type 2 and introduces
two new Routing Headers, type 3 and 4. Type 3, which is an two new Routing Headers, type 3 and 4. Type 3, which is an
optimization of type 4 will be discussed in Appendix A.2.1. The draft optimization of type 4 will be discussed in Appendix A.2.1. The
presents their operation in the context of Mobile Routers although draft presents their operation in the context of Mobile Routers
the formats are not tied to Mobile IP and could be used in other although the formats are not tied to Mobile IP and could be used in
situations. other situations.
4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics)
Mobile IPv6 uses a Routing header to carry the Home Address for Mobile IPv6 uses a Routing header to carry the Home Address for
packets sent from a Correspondent Node to a Mobile Node. In [1], this packets sent from a Correspondent Node to a Mobile Node. In [10],
Routing header (Type 2) is restricted to carry only one IPv6 address. this Routing header (Type 2) is restricted to carry only one IPv6
The format proposed here extends the Routing Header type 2 to be address. The format proposed here extends the Routing Header type 2
multi-hop. to be multi-hop.
The processing of the multi-hop RH type 2 inherits from the RH type 0 The processing of the multi-hop RH type 2 inherits from the RH type 0
described in IPv6 [10]. Specifically: the restriction on multicast described in IPv6 [5]. Specifically: the restriction on multicast
addresses is the same; a RH type 2 is not examined or processed until addresses is the same; a RH type 2 is not examined or processed until
it reaches the node identified in the Destination Address field of it reaches the node identified in the Destination Address field of
the IPv6 header; in that node, the RH type 0 algorithm applies, with the IPv6 header; in that node, the RH type 0 algorithm applies, with
added security checks. added security checks.
The construction of the multi-hop RH type 2 by the HA is described in The construction of the multi-hop RH type 2 by the HA is described in
Section 8; the processing by the MRs is described in Section 9.5; and Section 8; the processing by the MRs is described in Section 9.4; and
the security aspects are treated in Section 11.2. the security aspects are treated in Section 11.2.
The destination node of a packet containing a RH type 2 can be a MR The destination node of a packet containing a RH type 2 can be a MR
or some other kind of node. If it is a MR it will perform the or some other kind of node. If it is a MR it will perform the
algorithm described in Section 9.5, otherwise it will operate as algorithm described in Section 9.4, otherwise it will operate as
prescribed by IPv6 [10] when the routing type is unrecognized. prescribed by IPv6 [5] when the routing type is unrecognized.
The multi-hop Routing Header type 2, as extended by this draft, has The multi-hop Routing Header type 2, as extended by this draft, has
the following format: the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=2| Segments Left | | Next Header | Hdr Ext Len | Routing Type=2| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
skipping to change at page 12, line 48 skipping to change at page 12, line 48
+ Address[n] + + Address[n] +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Routing header. Uses the same values as the IPv4 following the Routing header. Uses the same values as the IPv4
Protocol field [13]. Protocol field [8].
Hdr Ext Len Hdr Ext Len
8-bit unsigned integer. Length of the Routing header in 8-octet 8-bit unsigned integer. Length of the Routing header in 8-octet
units, not including the first 8 octets. For the Type 2 Routing units, not including the first 8 octets. For the Type 2 Routing
header, Hdr Ext Len is equal to two times the number of addresses header, Hdr Ext Len is equal to two times the number of addresses
in the header. in the header.
Routing Type Routing Type
8-bit unsigned integer. Set to 2. 8-bit unsigned integer. Set to 2.
Segments Left Segments Left
8-bit unsigned integer. Number of route segments remaining, i.e., 8-bit unsigned integer. Number of route segments remaining, i.e.,
number of explicitly listed intermediate nodes still to be visited number of explicitly listed intermediate nodes still to be visited
before reaching the final destination. before reaching the final destination.
Reserved Reserved
32-bit reserved field. Initialized to zero for transmission; 32-bit reserved field. Initialized to zero for transmission;
ignored on reception. ignored on reception.
Address[1..n] Address[1..n]
Vector of 128-bit addresses, numbered 1 to n. Vector of 128-bit addresses, numbered 1 to n.
4.2 Routing Header Type 4 (The Reverse Routing Header) 4.2 Routing Header Type 4 (The Reverse Routing Header)
The Routing Header type 4, or Reverse Routing Header (RRH), is a The Routing Header type 4, or Reverse Routing Header (RRH), is a
variant of IPv4 loose source and record route (LSRR) [6] adapted for variant of IPv4 loose source and record route (LSRR) [1] adapted for
IPv6. IPv6.
Addresses are added from bottom to top (0 to n-1 in the picture). The Addresses are added from bottom to top (0 to n-1 in the picture).
RRH is designed to help the destination build an RH for the return The RRH is designed to help the destination build an RH for the
path. return path.
When a RRH is present in a packet, the rule for upper-layer checksum When a RRH is present in a packet, the rule for upper-layer checksum
computing is that the source address used in the pseudo-header is computing is that the source address used in the pseudo-header is
that of the original source, located in the slot 0 of the RRH, unless that of the original source, located in the slot 0 of the RRH, unless
the RRH slot 0 is empty, in which case the source in the IP header of the RRH slot 0 is empty, in which case the source in the IP header of
the packet is used. the packet is used.
As the 'segment left' field of the generic RH is reassigned to the As the 'segment left' field of the generic RH is reassigned to the
number of segments used, an IPv6 node that does not support RRH will number of segments used, an IPv6 node that does not support RRH will
discard the packet, unless the RRH is empty. discard the packet, unless the RRH is empty.
The RRH contains n pre-allocated address slots, to be filled by each The RRH contains n pre-allocated address slots, to be filled by each
MR in the path. It is possible to optimize the number of slots using MR in the path. It is possible to optimize the number of slots using
the Tree Information Option described in Section 6.2. the Tree Information Option described in Section 5.
The Type 4 Routing Header has the following format: The Type 4 Routing Header has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=4| Segments Used | | Next Header | Hdr Ext Len | Routing Type=4| Segments Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 46 skipping to change at page 14, line 46
+ Slot[0] (Home address) + + Slot[0] (Home address) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Routing header. Uses the same values as the IPv4 following the Routing header. Uses the same values as the IPv4
Protocol field [13]. Protocol field [8].
Hdr Ext Len Hdr Ext Len
8-bit unsigned integer. Length of the Routing header in 8-octet 8-bit unsigned integer. Length of the Routing header in 8-octet
units, not including the first 8 octets. For the Type 4 Routing units, not including the first 8 octets. For the Type 4 Routing
header, Hdr Ext Len is equal to two times the number of addresses header, Hdr Ext Len is equal to two times the number of addresses
in the header. in the header.
Routing Type Routing Type
8-bit unsigned integer. Set to 4. 8-bit unsigned integer. Set to 4.
Segments Used Segments Used
8-bit unsigned integer. Number of slots used. Initially set to 1 8-bit unsigned integer. Number of slots used. Initially set to 1
by the MR when only the Home Address is there. Incremented by the by the MR when only the Home Address is there. Incremented by the
MRs on the way as they add the packets source addresses to the MRs on the way as they add the packets source addresses to the
RRH. RRH.
Sequence Number Sequence Number
32-bit unsigned integer. The Sequence Number starts at 0, and is 32-bit unsigned integer. The Sequence Number starts at 0, and is
incremented by the source upon each individual packet. Using the incremented by the source upon each individual packet. Using the
Radia Perlman's lollipop algorithm, values between 0 and 255 are Radia Perlman's lollipop algorithm, values between 0 and 255 are
'negative', left to indicate a reboot or the loss of HA 'negative', left to indicate a reboot or the loss of HA
connectivity, and are skipped when wrapping and upon positive connectivity, and are skipped when wrapping and upon positive
Binding Ack. The sequence number is used to check the freshness of Binding Ack. The sequence number is used to check the freshness
the RRH; anti-replay protection is left to IPsec AH. of the RRH; anti-replay protection is left to IPsec AH.
Slot[n-1..0] Slot[n-1..0]
Vector of 128-bit addresses, numbered n-1 to 0. Vector of 128-bit addresses, numbered n-1 to 0.
When applied to the Nemo problem, the RRH can be used to update the When applied to the NEMO problem, the RRH can be used to update the
HA on the actual location of the MR. Only MRs forwarding packets on HA on the actual location of the MR. Only MRs forwarding packets on
an egress interface while not at home update it on the fly. an egress interface while not at home update it on the fly.
A RRH is inserted by the first MR on the Mobile Network outbound A RRH is inserted by the first MR on the Mobile Network outbound
path, as part of the reverse tunnel encapsulation; it is removed by path, as part of the reverse tunnel encapsulation; it is removed by
the associated HA when the tunneled packet is decapsulated. the associated HA when the tunneled packet is decapsulated.
4.3 Extension Header order 4.3 Extension Header order
The RH type 2 is to be placed as any RH as described in [10] section The RH type 2 is to be placed as any RH as described in [5] section
4.1. If a RH type 0 is present in the packet, then the RH type 2 is 4.1. If a RH type 0 is present in the packet, then the RH type 2 is
placed immediately after the RH type 0, and the RH type 0 MUST be placed immediately after the RH type 0, and the RH type 0 MUST be
consumed before the RH type 2. consumed before the RH type 2.
RH type 3 and 4 are mutually exclusive. They are to be placed right RH type 3 and 4 are mutually exclusive. They are to be placed right
after the Hop-by-Hop Options header if any, or else right after the after the Hop-by-Hop Options header if any, or else right after the
IPv6 header. IPv6 header.
As a result, the order prescribed in section 4.1 of RFC 2460 becomes: As a result, the order prescribed in section 4.1 of RFC 2460 becomes:
IPv6 header IPv6 header
Hop-by-Hop Options header Hop-by-Hop Options header
Routing header type 3 or 4 Routing header type 3 or 4
skipping to change at page 17, line 5 skipping to change at page 17, line 5
Fragment header Fragment header
Authentication header (note 2) Authentication header (note 2)
Encapsulating Security Payload header (note 2) Encapsulating Security Payload header (note 2)
Destination Options header (note 3) Destination Options header (note 3)
upper-layer header upper-layer header
5. ICMP 5. Optimum number of slots in RRH
The RRH could have fewer slots than the number of MRs in the path If its current Attachment Router conforms to Tree Discovery as
because either the nested Mobile Network topology is changing too specified in [13], a MR knows its current tree depth from the Tree
quickly or the MR that inserted the RRH could have a wrong Information Option (RA-TIO). The maximum number of slots needed in
representation of the topology. the RRH is the same value as the MR's own tree depth (that is the
TreeDepth as received from the AR incremented by one).
When sending a Binding Update, a MR always reinitializes the number
of slots in the RRH to the maximum of DEF_RRH_SLOTS and its tree
depth, if the latter is known from a reliable hint such as RA-TIO.
The message may have a number of unused (NULL) slots, when it is
received by the Home Agent. The HA crops out the extra entries in
order to send a RH of type 2 back with its response. The RH type 2
in the resulting Binding Ack contains the number of required slots
that the MR now uses until it gets a hint that the topology changes
or until the next Binding update.
In the case of a NULL RRH, the HA does not include a RH 2 at all.
This may happen in the process of a DHAAD message (see Section 7.1)
The number of slots in the RRH MUST NOT be larger than MAX_RRH_SLOTS.
If a MR is deeper in a tree then MAX_RRH_SLOTS, the packets will be
reencapsulated by a MR up high in the tree, or dropped, depending on
that MR security policy.
In runtime, it may happen that the RRH has fewer slots than required
for the number of MRs in the path because either the nested Mobile
Network topology is changing too quickly, or the MR that inserted the
RRH had a wrong representation of the topology.
To solve this problem a new ICMP message is introduced, "RRH To solve this problem a new ICMP message is introduced, "RRH
Warning", type 64. Note that this ICMP message creates a new class of Warning", type 64. A MR on the tree egress path that gets a packet
warning messages besides the error messages and the control messages without a free slot in the RRH MAY send that ICMP "RRH warning" back
of ICMP. to the MR that inserted the RRH in the first place.
This message allows a MR on the path to propose a larger number of This message allows a MR on the path to propose a larger number of
slots to the MR that creates the RRH. The Proposed Size MUST be slots to the MR that creates the RRH. The Proposed Size MUST NOT be
larger than the current size and MUST NOT be larger than 8. larger than MAX_RRH_SLOTS. The originating MR must rate-limit the
ICMP messages to avoid excessive ICMP traffic in the case of the
The originating MR must rate-limit the ICMP messages to avoid source failing to operate as requested.
excessive ICMP traffic in the case of the source failing to operate
as requested.
The originating MR must insert an RH type 2 based on the RRH in the The originating MR must insert an RH type 2 based on the RRH in the
associated IP header, in order to route the ICMP message back to the associated IP header, in order to route the ICMP message back to the
source of the reverse tunnel. A MR that receives this ICMP message is source of the reverse tunnel. A MR that receives this ICMP message
the actual destination and it MUST NOT forward it to the (LFN) source is the actual destination and it MUST NOT forward it to the (LFN)
of the tunneled packet. source of the tunneled packet.
A MR on the path that finds no more space in the RRH SHOULD send an
ICMP "RRH warning" back to the MR that inserted the RRH. On the other
hand, a MR should always be able, by receiving TI option with up to
date tree depth (see Section Section 6.2). to correctly size the RRH
to insert in an outgoing packet.
The type 64 ICMP has the following format: The type 64 ICMP has the following format:
0 1 2 3 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 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 = 64 | Code = 0 | Checksum | | Type = 64 | Code = 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Size | Proposed Size | Reserved | | Current Size | Proposed Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 28 skipping to change at page 18, line 28
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
64 [To Be Assigned] 64 [To Be Assigned]
Code 0: RRH too small Code 0: RRH too small
The originating MR requires the source to set the RRH size to a The originating MR requires the source to set the RRH size to a
larger value. The packet that triggered the ICMP will still be larger value. The packet that triggered the ICMP will still be
forwarded by the MR, but the path cannot be totally optimized (see forwarded by the MR, but the path cannot be totally optimized (see
Section 9.3). Section 9.3).
Checksum Checksum
The ICMP checksum [12]. The ICMP checksum [7].
Current Size Current Size
RRH size of the invoking packet, as a reference. RRH size of the invoking packet, as a reference.
Proposed Size Proposed Size
The new value, expressed as a number of IPv6 addresses that can The new value, expressed as a number of IPv6 addresses that can
fit in the RRH. fit in the RRH.
Reserved Reserved
16-bit reserved field. Initialized to zero for transmission; 16-bit reserved field. Initialized to zero for transmission;
ignored on reception. ignored on reception.
6. Modifications to IPv6 Neighbor Discovery 6. Modifications to IPv6 Neighbor Discovery
6.1 Modified Router Advertisement Message Format 6.1 Modified Router Advertisement Message Format
Mobile IPv6 [1] modifies the format of the Router Advertisement Mobile IPv6 [10] modifies the format of the Router Advertisement
message [11] by the addition of a single flag bit (H) to indicate message [6] by the addition of a single flag bit (H) to indicate that
that the router sending the Advertisement message is serving as a the router sending the Advertisement message is serving as a home
home agent on this link. agent on this link.
This draft adds another single flag bit (N) to indicate that the This draft adds another single flag bit (N) to indicate that the
router sending the advertisement message is a MR. This means that the router sending the advertisement message is a MR. This means that
link on which the message is sent is a Mobile Network, which may or the link on which the message is sent is a Mobile Network, which may
may not be at home. or may not be at home.
The Router Advertisement message has the following format: The Router Advertisement message has the following format:
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [11]: specified for Neighbor Discovery [6]:
Home Agent (H) Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is also indicate that the router sending this Router Advertisement is also
functioning as a Mobile IP home agent on this link. functioning as a Mobile IP home agent on this link.
NEMO Capable (N) NEMO Capable (N)
The NEMO Capable (N) bit is set in a Router Advertisement to The NEMO Capable (N) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is also indicate that the router sending this Router Advertisement is also
functioning as a Mobile Router on this link, so that the link is a functioning as a Mobile Router on this link, so that the link is a
Mobile Network, possibly away from home. Mobile Network, possibly away from home.
6.2 New Tree Information Option Format 7. MIPv6 flows
This draft defines a new Tree Information option, used in Router
Advertisement messages. Fields set by the TLMR are propagated
transparently by the MRs. Mobile Routers SHOULD add that option to
the Router Advertisement messages sent over the ingress interfaces.
The Tree Information option has the following format:
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 = 6 | TreePreference| TreeDepth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|H| Reserved | Bandwidth | DelayTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRPreference | BootTimeRandom |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathCRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Tree TLMR Identifier +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Tree Group +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8-bit unsigned integer set to 10 by the TLMR.
Length
8-bit unsigned integer set to 6 by the TLMR. The length of the
option (including the type and length fields) in units of 8
octets.
TreePreference
8-bit unsigned integer set by the TLMR to its configured
preference. Range from 0 = lowest to 255 = highest.
TreeDepth
8-bit unsigned integer set to 0 by the TLMR and incremented by 1
by each MR down the tree.
Grounded (G)
1-bit flag. Set by the TLMR to indicate that it is either attached
to a fixed network or at home.
Home Agent (H)
1-bit flag. Set by the TLMR to indicate that it is also
functioning as a Home Agent, for re-homing purposes.
Reserved
6-bit unsigned integer, set to 0 by the TLMR.
Bandwidth
8-bit unsigned integer set by the TLMR and decremented by MRs with
lower egress bandwidth. This is a power of 2 so that the available
egress bandwidth in bps is between 2^Bandwidth and
2^(Bandwidth+1). 0 means 'unspecified' and can not be modified
down the tree.
DelayTime
16-bit unsigned integer set by the TLMR. Tree time constant in
milliseconds.
MRPreference
8-bit signed integer. Set by each MR to its configured preference.
Range from 0 = lowest to 255 = highest.
BootTimeRandom
24-bit unsigned integer set by each MR to a random value that the
MR generates at boot time.
PathCRC
32-bit unsigned integer CRC, updated by each MR. This is the
result of a CRC-32c computation on a bit string obtained by
appending the received value and the MR CareOf Address. TLMRs use
a 'previous value' of zeroes to initially set the pathCRC.
Tree TLMR Identifier
IPv6 global address, set by the TLMR. Identifier of the tree.
Tree Group 7.1 DHAAD
IPv6 global address, set by the TLMR. Identifier of the tree Conforming MIPv6 [10], a MR normally does not identify itself in its
group. A MR may use the Tree Group in its tree selection DHAAD messages, using a Home Address option. For the same reason, a
algorithm. RRH with a Home address in slot 0 is not required here, either. Yet,
this specification allows a MR to send its DHAAD messages with a NULL
RRH, as opposed to no RRH at all.
The TLMR MUST include this option in its Router Advertisements. This is generally useful if the attachment router is not bound yet,
for whatever reason, and more specifically in the case of the Mobile
Home Network as described in [14]. In the latter case, an HA is
mobile and may happen to be located under one of its MRs (within its
subtree), which is a dead lock for the NEMO basic support..
A MR receiving this option from its Attachment Router MUST update the Since MRs may forward packets with an RRH even if themselves are not
TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST bound yet, the packets from nested MRs can be forwarded and the
propagate it on its ingress interface(s), as described in Section responses are source routed back, allowing the nested MRs to bind.
9.4. In particular, if a nested MR is also a mobile Home Agent, it becomes
reachable from its own MRs, which breaks the deadlock.
The alignment requirement of the Tree Information option is 8n. Also, this alleviates the need for the attachment router to forward
DHAAD messages across its own MRHA tunnel.
7. Binding Cache Management HAs MUST respond by reversing the RRH into a RH2 if a RRH is present
and not NULL. A NULL RRH is ignored.
7.1 Binding Updates 7.2 Binding Updates
A MIPv6 or NEmo Binding Update provides more information than just A MIPv6 or NEMO Binding Update provides more information than just
the path in the nested cloud so they are still used as described in the path in the nested cloud so they are still used as described in
MIPv6 [1] for Home Registration and de-registration. The only MIPv6 [10] for Home Registration and de-registration. The only
difference when using RRH is that the Home Address Destination Option difference when using a RRH is that the Home Address Destination
and the alternate CareOf MIP option MUST be omitted. Option and the alternate CareOf MIP option MUST be omitted.
7.2 RRH Heartbeat
Intermediate updates (or just refreshes) between BUs are obtained as The Binding Update flow is also used to update the optimum size of
one of the results of processing the RRH by the HA. the RRH, as described in Section 5.
When the MR becomes aware of a topology change in the tree (for The HA MUST save the RRH in its binding cache, either in the original
examples it changes point of attachment, it obtains a new CoA, it form or in the form of an RH type 2, ready to be added to the tunnel
receives a Tree Information Option in an RA message that indicates a header of the MRHA packets. The RRH format is very close to that of
change in the attachment tree) or in the absence of traffic (detected the RH type 2, designed to minimize the process of the transmutation.
by a timeout) to the HA, it must send an RRH Heartbeat, which is a
binding update with a RRH.
8. Home Agent Operation 8. Home Agent Operation
This section inherits from chapter 10 of MIPv6 [1], which is kept This section inherits from chapter 10 of MIPv6 [10], which is kept
unmodified except for parts 10.5 and 10.6 which are extended. This unmodified except for parts 10.5 and 10.6 which are extended. This
draft mostly adds the opportunity for a MN to update the Binding draft mostly adds the opportunity for a MN to update the Binding
Cache of its Home Agent using RRH, though it does not change the fact Cache of its Home Agent using RRH, though it does not change the fact
that MNs still need to select a home agent, register and deregister that MNs still need to select a home agent, register and deregister
to it, using the MIP Bind Update. to it, using the MIP Bind Update.
This draft extends [1] section 10.6 as follows: This draft extends [10] section 10.6 as follows:
o The entry point of the tunnel is now checked against the TLMR as o The entry point of the tunnel is now checked against the TLMR as
opposed to the primary CoA. opposed to the primary CoA.
o The Binding Cache can be updated based on RRH with proper AH o The Binding Cache can be updated based on RRH with proper AH
authentication. authentication.
As further explained in Section 7.1, this specification modifies MIP As further explained in Section 7.2, this specification modifies MIP
so that the HA can rely on the RH type 4 (RRH) to update its Bind so that the HA can rely on the RH type 4 (RRH) to update its Bind
Cache Entry (BCE), when the Mobile Node moves. The conceptual content Cache Entry (BCE), when the Mobile Node moves. The conceptual
of the BCE is extended to contain a sequence counter, and the content of the BCE is extended to contain a sequence counter, and the
sequence of hops within the --potentially nested-- Mobile Network to sequence of hops within the --potentially nested-- Mobile Network to
a given Mobile Node. The sequence counter is initially set to 0. a given Mobile Node. The sequence counter is initially set to 0.
When the HA receives a packet destined to itself, it checks for the When the HA receives a packet destined to itself, it checks for the
presence of a Routing Header of type 3 or 4. Both contain as least presence of a Routing Header of type 3 or 4. Both contain as least
the entry for the home address of the MN in slot 0; this replaces the the entry for the home address of the MN in slot 0; this replaces the
MIP Home Address Option and allows the HA to determine the actual MIP Home Address Option and allows the HA to determine the actual
source of the packet, to access the corresponding security source of the packet, to access the corresponding security
association. association.
As explained in Section 11.2, the HA MUST verify the authenticity of As explained in Section 11.2, the HA MUST verify the authenticity of
the packet using IPSEC AH and drop packets that were not issued by the packet using IPSEC AH and drop packets that were not issued by
the proper Mobile Node. An RRH is considered only if the packet is the proper Mobile Node. An RRH is considered only if the packet is
authenticated and if its sequence number is higher than the one saved authenticated and if its sequence number is higher than the one saved
in the BCE. in the BCE.
Also, an RRH is considered only if an initial Bind Update exchange Also, an RRH is considered only if an initial Bind Update exchange
has been successfully completed between the Mobile Node and its Home has been successfully completed between the Mobile Node and its Home
Agent for Home Registration. If the RRH is valid, then the Bind Cache Agent for Home Registration. If the RRH is valid, then the Bind
Entry is revalidated for a lifetime as configured from the initial Cache Entry is revalidated for a lifetime as configured from the
Bind Update. initial Bind Update.
The BCE abstract data is updated as follows: The BCE abstract data is updated as follows:
The first hop for the return path is the last hop on the path of The first hop for the return path is the last hop on the path of
the incoming packet, that is between the HA and the Top Level the incoming packet, that is between the HA and the Top Level
Mobile Router (TLMR) of the Mobile Network. The HA saves the IP Mobile Router (TLMR) of the Mobile Network. The HA saves the IP
address of the TLMR from the source field in the IP header. address of the TLMR from the source field in the IP header.
The rest of the path to the MN is found in the RRH. The rest of the path to the MN is found in the RRH.
The sequence counter semantics is changed as described in Section The sequence counter semantics is changed as described in Section
4.2 4.2
This draft extends [1] section 10.5 as follows: This draft extends [10] section 10.5 as follows:
A Home Agent advertises the prefixes of its registered Mobile A Home Agent advertises the prefixes of its registered Mobile
Routers, during the registration period, on the local Interior Routers, during the registration period, on the local Interior
Gateway Protocol (IGP). Gateway Protocol (IGP).
The Routing Header type 2 is extended to be multi-hop. The Routing Header type 2 is extended to be multi-hop.
The Home Agent is extended to support routes to prefixes that are The Home Agent is extended to support routes to prefixes that are
owned by Mobile Routers. This can be configured statically, or can be owned by Mobile Routers. This can be configured statically, or can
exchanged using a routing protocol as in [3], which is out of the be exchanged using a routing protocol as in [12], which is out of the
scope of this document. As a consequence of this process, the Home scope of this document. As a consequence of this process, the Home
Agent which is selected by a Mobile Router advertises reachability of Agent which is selected by a Mobile Router advertises reachability of
the MR prefixes for the duration of the registration over the local the MR prefixes for the duration of the registration over the local
IGP. IGP.
When a HA gets a packet for which the destination is a node behind a When a HA gets a packet for which the destination is a node behind a
Mobile Router, it places the packet in the tunnel to the associated Mobile Router, it places the packet in the tunnel to the associated
MR. This ends up with a packet which destination address in the IP MR. This ends up with a packet which destination address in the IP
Header is the TLMR, and with a Routing Header of type 2 for the rest Header is the TLMR, and with a Routing Header of type 2 for the rest
of the way to the Mobile Router, which may be multi-hop. of the way to the Mobile Router, which may be multi-hop.
To build the RH type 2 from the RRH, the HA sets the type to 2, and To build the RH type 2 from the RRH, the HA sets the type to 2, and
clears the bits 32-63 (byte 4 to 7). clears the bits 32-63 (byte 4 to 7).
9. Mobile Router Operation 9. Mobile Router Operation
This section inherits from chapter 11 of [1], which is extended to This section inherits from chapter 11 of [10], which is extended to
support Mobile Networks and Mobile Routers as a specific case of support Mobile Networks and Mobile Routers as a specific case of
Mobile Node. Mobile Node.
This draft extends section 11.2.1 of MIPv6 [1] as follows: This draft extends section 11.2.1 of MIPv6 [10] as follows:
o When not at home, an MR uses a reverse tunnel with its HA for all o When not at home, an MR uses a reverse tunnel with its HA for all
the traffic that is sourced in its mobile network(s); traffic the traffic that is sourced in its mobile network(s); traffic
originated further down a nested network is not tunneled twice but originated further down a nested network is not tunneled twice but
for exception cases. for exception cases.
o The full path to and within the Mobile Network is piggy-backed o The full path to and within the Mobile Network is piggy-backed
with the traffic on a per-packet basis to cope with rapid with the traffic on a per-packet basis to cope with rapid
movement. This makes the packet construction different from MIPv6. movement. This makes the packet construction different from
MIPv6.
The MR when not at home sets up a bi-directional tunnel with its HA. The MR when not at home sets up a bi-directional tunnel with its HA.
The reverse direction MR -> HA is needed to assure transparent The reverse direction MR -> HA is needed to assure transparent
topological correctness to LFNs, as in [3]. But, as opposed to that topological correctness to LFNs, as in [12]. But, as opposed to the
solution, nested tunnels are generally avoided. NEMO Basic Support, nested tunnels are generally avoided.
9.1 Processing of ICMP "RRH too small" 9.1 Processing of ICMP "RRH too small"
The New ICMP message "RRH too Small" is presented in Section 5. This The New ICMP message "RRH too Small" is presented in Section 5. This
message is addressed to the MR which performs the tunnel message is addressed to the MR which performs the tunnel
encapsulation and generates the RRH. encapsulation and generates the RRH.
Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate
it to the originating LFN or inner tunnel source, but MUST process it it to the originating LFN or inner tunnel source, but MUST process it
for itself. for itself.
If the Current Size in the ICMP messages matches the actual current If the Current Size in the ICMP messages matches the actual current
number of slots in RRH, and if the ICMP passes some safety checks as number of slots in RRH, and if the ICMP passes some safety checks as
described in Section 5, then the MR MAY adapt the number of slots to described in Section 5, then the MR MAY adapt the number of slots to
the Proposed Size. the Proposed Size.
9.2 Processing of ICMP error 9.2 Processing of ICMP error
ICMP back { ICMP back {
if RRH is present { if RRH is present {
compute RH type 2 based on RRH compute RH type 2 based on RRH
get packet source from IP header get packet source from IP header
send ICMP error to source including RH type 2. send ICMP error to source including RH type 2.
} }
else { else {
get packet source from IP header get packet source from IP header
send ICMP error to source with no RH. send ICMP error to source with no RH.
} }
} }
When the MR receives an ICMP error message, it checks whether it is When the MR receives an ICMP error message, it checks whether it is
the final destination of the packet by looking at the included the final destination of the packet by looking at the included
packet. If the included packet has an RRH, then the MR will use the packet. If the included packet has an RRH, then the MR will use the
RRH to forward the ICMP to the original source of the packet. RRH to forward the ICMP to the original source of the packet.
9.3 Processing of RHH for Outbound Packets 9.3 Processing of RHH for Outbound Packets
The forwarding of a packet with a non saturated RRH consists in fact
in passing the hot potato to the attachment router, which does not
require the MRHA tunnel to be up.
So, it happens as soon as a MR has selected its attachment router and
before the binding flow has actually taken place. Also, this process
is much safer since the packet is not forwarded home.
if no RRH in outer header /* First Mobile Router specific */ if no RRH in outer header /* First Mobile Router specific */
or RRH present but saturated { /* Need a nested encapsulation */ or RRH present but saturated { /* Need a nested encapsulation */
if RRH is saturated { if RRH is saturated {
do ICMP back (RRH too small) do ICMP back (RRH too small)
} }
/* put packet in sliding reverse tunnel */ /* put packet in sliding reverse tunnel if bound */
insert new IP header plus RRH if reverse tunnel is established {
set source address to the MR Home Address insert new IP header plus RRH
set destination address to the MR Home Agent Address set source address to the MR Home Address
add an RRH with all slots zeroed out set destination address to the MR Home Agent Address
compute IPsec AH on the resulting packet add an RRH with all slots zeroed out
compute IPsec AH on the resulting packet
} else return
} }
/* All MRs including first */ /* All MRs including first, even if not bound home */
if packet size <= MTU { if packet size <= MTU {
select first free slot in RRH bottom up select first free slot in RRH bottom up
set it to source address from IP header set it to source address from IP header
overwrite source address in IP header with MR CareOf overwrite source address in IP header with MR CareOf
transmit packet transmit packet
} else { } else {
do ICMP back (Packet too Big) do ICMP back (Packet too Big)
} }
If the packet already contains an RRH in the outer header, and has a If the packet already contains an RRH in the outer header, and has a
spare slot, the MR adds the source address from the packet IP header spare slot, the MR adds the source address from the packet IP header
to the RRH and overwrites the source address in the IP header with to the RRH and overwrites the source address in the IP header with
its CoA. As a result, the packets are always topologically correct. its CoA. As a result, the packets are always topologically correct.
Else, if the RRH is present but is saturated, and therefore the Else, if the RRH is present but is saturated, and therefore the
source IP can not be added, the MR sends a ICMP 'RRH too small' to source IP can not be added, the MR sends a ICMP 'RRH too small' to
the tunnel endpoint which originated the outer packet, using the RRH the tunnel endpoint which originated the outer packet, using the RRH
info to route it back. The ICMP message is a warning, and the packet info to route it back. The ICMP message is a warning, and the packet
is not discarded. Rather, the MR does a nested encapsulation of the is not discarded. Rather, the MR does a nested encapsulation of the
packet in its own reverse tunnel home with an additional RRH. packet in its own reverse tunnel home with an additional RRH.
Else, if the packet does not have an RRH, the MR puts it in its Else, if the packet does not have an RRH, the MR puts it in its
reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0 reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0
the Home Address of the MR, and with proper IPsec AH as described the Home Address of the MR, and with proper IPsec AH as described
further in Section 11.1. further in Section 11.1.
9.4 Processing of Tree Information Option 9.4 Processing of the extended Routing Header Type 2
The Tree Information option in Router Advertisement messages allows
the Mobile Router to select a tree and learn about its capabilities.
The treeDepth can be used to compute the optimum number of slots in
the RRH.
The RRH contains an entry for the home address in slot 0, and one for
every CareOf on the way but that of the last Mobile Router (TLMR). As
the TLMR sets the treeDepth to 0 and each MR increments it on the way
down the tree, the optimum number of slots is normally (treeDepth+1),
where treeDepth is the depth advertised by the MR over its Mobile
Networks.
9.5 Processing of the extended Routing Header Type 2
if Segments Left = 0 { if Segments Left = 0 {
/* new check: packet must be looped back internally */ /* new check: packet must be looped back internally */
if packet doesn't come from a loopback interface { if packet doesn't come from a loopback interface {
discard the packet discard the packet
return return
} }
proceed to process the next header in the packet, whose type is proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header identified by the Next Header field in the Routing header
} }
else if Hdr Ext Len is odd { else if Hdr Ext Len is odd {
skipping to change at page 30, line 5 skipping to change at page 27, line 18
} }
else { else {
decrement the Hop Limit by 1 decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission resubmit the packet to the IPv6 module for transmission
to the new destination; to the new destination;
} }
} }
} }
} }
9.6 Decapsulation 9.5 Decapsulation
A MR when decapsulating a packet from its HA must perform the A MR when decapsulating a packet from its HA must perform the
following checks following checks
1. Destination address 1. Destination address
The destination address of the inner packet must belong to one of The destination address of the inner packet must belong to one of
the Mobile Network prefixes. the Mobile Network prefixes.
10. Mobile Host Operation 10. Mobile Host Operation
When it is at Home, a Mobile Host issues packets with source set to When it is at Home, a Mobile Host issues packets with source set to
its home address and with destination set to its CN, in a plain IPv6 its home address and with destination set to its CN, in a plain IPv6
format. format.
When a MH is not at home but is attached to a foreign link in the When a MH is not at home but is attached to a foreign link in the
Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to
manage its mobility. manage its mobility.
When a MH is visiting a foreign Mobile Network, it forwards its When a MH is visiting a foreign Mobile Network, it forwards its
skipping to change at page 30, line 39 skipping to change at page 28, line 8
As a result, the encapsulating header include: As a result, the encapsulating header include:
with source set to the MH COA and destination set to the MH HA with source set to the MH COA and destination set to the MH HA
with slot 0 set to the MH Home Address with slot 0 set to the MH Home Address
The inner packet is the plain IPv6 packet from the MH Home Address to The inner packet is the plain IPv6 packet from the MH Home Address to
the CN. the CN.
11. Security Considerations 11. Security Considerations
This section is not complete; further work is needed to analyse and This section is not complete; further work is needed to analyze and
solve the security problems of record and source route. solve the security problems of record and source route.
Compared to MIPv6, the main security problem seems to be the fact Compared to MIPv6, the main security problem seems to be the fact
that the RRH can be modified in transit by an attacker on the path. that the RRH can be modified in transit by an attacker on the path.
It has to be noted that such an attacker (for example any MR in the It has to be noted that such an attacker (for example any MR in the
Mobile Network) can perform more effective attacks than modifying the Mobile Network) can perform more effective attacks than modifying the
RRH. RRH.
11.1 IPsec Processing 11.1 IPsec Processing
The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to
The IPsec [2] AH [3] and ESP [4] can be used in tunnel mode to
provide different security services to the tunnel between a MR and provide different security services to the tunnel between a MR and
its HA. ESP tunnel mode SHOULD be used to provide confidentiality and its HA. ESP tunnel mode SHOULD be used to provide confidentiality
authentication to the inner packet. AH tunnel mode MUST be used to and authentication to the inner packet. AH tunnel mode MUST be used
provide authentication of the outer IP header fields, especially the to provide authentication of the outer IP header fields, especially
Routing Headers. the Routing Headers.
11.1.1 Routing Header type 2 11.1.1 Routing Header type 2
Due to the possible usage of Doors [5] to enable IPv4 traversal, the Due to the possible usage of Doors [15] to enable IPv4 traversal, the
Routing Header type 2 cannot be treated as type 0 for the purpose of Routing Header type 2 cannot be treated as type 0 for the purpose of
IPsec processing (i.e. it cannot be included in its intierity in the IPsec processing (i.e. it cannot be included in its intirety in the
Integrity Check Value (ICV) computation, because NAT/PAT may mangle Integrity Check Value (ICV) computation, because NAT/PAT may mangle
one of the MR care-of-addresses along the HA-MR path. one of the MR care-of-addresses along the HA-MR path.
The sender (the HA) will put the slot 0 entry (the MR Home Address) The sender (the HA) will put the slot 0 entry (the MR Home Address)
of the RH as destination of the outer packet, will zero out of the RH as destination of the outer packet, will zero out
completely the Routing Header and will perform the ICV computation. completely the Routing Header and will perform the ICV computation.
The receiver (the MR) will put the slot 0 entry as destination of the The receiver (the MR) will put the slot 0 entry as destination of the
outer packet, will zero out the Routing Header and will perform the outer packet, will zero out the Routing Header and will perform the
ICV verification. ICV validation.
11.1.2 Routing Header type 4 11.1.2 Routing Header type 4
The Routing Header type 4 is "partially mutable", and as such can be The Routing Header type 4 is "partially mutable", and as such can be
included in the Authentication Data calculation. Given the way type 4 included in the Authentication Data calculation. Given the way type
is processed, the sender cannot order the field so that it appears as 4 is processed, the sender cannot order the field so that it appears
it will at the receiver; this means the receiver will have to shuffle as it will at the receiver; this means the receiver will have to
the fields. shuffle the fields.
The sender (the MR) will zero out all the slots and the Segment Used The sender (the MR) will zero out all the slots and the Segment Used
field of the RRH, and will put as source address of the outer packet field of the RRH, and will put as source address of the outer packet
its Home Address, and then will perform the ICV computation. its Home Address, and then will perform the ICV computation.
The receiver (the HA) will put the entry in slot 0 (the MR Home The receiver (the HA) will put the entry in slot 0 (the MR Home
Address) in the source address and will zero out all the slots and Address) in the source address and will zero out all the slots and
the Segment Used field of the RRH, and then will perform the ICV the Segment Used field of the RRH, and then will perform the ICV
verification. verification.
11.2 New Threats 11.2 New Threats
The RH type 4 is used to construct a MIPv6 RH type 2 with additional The RH type 4 is used to construct a MIPv6 RH type 2 with additional
semantics, as described in Section 4.1. Since RH type 2 becomes a semantics, as described in Section 4.1. Since RH type 2 becomes a
multi hop option like RH type 0, care must be applied to avoid the multi hop option like RH type 0, care must be applied to avoid the
spoofing attack that can be performed with the IPv4 source route spoofing attack that can be performed with the IPv4 source route
option. This is why IPv6 [10] takes special care in responding to option. This is why IPv6 [5] takes special care in responding to
packets carrying Routing Headers. packets carrying Routing Headers.
AH authenticates the MR Home Address identity and the RRH sequence AH authenticates the MR Home Address identity and the RRH sequence
number. The RRH sequence number is to be used to check the freshness number. The RRH sequence number is to be used to check the freshness
of the RRH; anti-replay protection can be obtained if the receiver of the RRH; anti-replay protection can be obtained if the receiver
enables the anti-replay service of AH [8]. enables the anti-replay service of AH [3].
In particular, if IPSec is being used, the content is protected and In particular, if IPSec is being used, the content is protected and
can not be read or modified, so there is no point in redirecting the can not be read or modified, so there is no point in redirecting the
traffic just to screen it. traffic just to screen it.
Say a MR in a nested structure modifies the RRH in order to bomb a Say a MR in a nested structure modifies the RRH in order to bomb a
target outside of the tree. If that MR forwards the packet with target outside of the tree. If that MR forwards the packet with
itself as source address, the MR above it will make sure that the itself as source address, the MR above it will make sure that the
response packets come back to the attacker first, since that source response packets come back to the attacker first, since that source
is prepended to the RRH. If it forges the source address, then the is prepended to the RRH. If it forges the source address, then the
ingress filtering at the MR above it should detect the irregularity ingress filtering at the MR above it should detect the irregularity
and drop the packet. Same if the attacker is actually TLMR. The and drop the packet. Same if the attacker is actually TLMR. The
conclusion is that ingress filtering is recommended at MR and AR. conclusion is that ingress filtering is recommended at MR and AR.
Say that an attacker in the infrastructure and on the path of the Say that an attacker in the infrastructure and on the path of the
MRHA tunnel modifies the RRH in order to redirect the response MRHA tunnel modifies the RRH in order to redirect the response
packets and bomb a target. Considering the position of the attacker - packets and bomb a target. Considering the position of the attacker
a compromised access or core router - there's a lot more it could do - a compromised access or core router - there's a lot more it could
to send perturbations to the traffic, like changing source and do to send perturbations to the traffic, like changing source and
destinations of packets on the fly or eventually polute the routing destinations of packets on the fly or eventually pollute the routing
protocols. protocols.
Say a MR in a nested structure modifies the RH 2 in order to attack a Say a MR in a nested structure modifies the RH 2 in order to attack a
target outside of the tree. The RH type 2 forwarding rules make sure target outside of the tree. The RH type 2 forwarding rules make sure
that the packet can only go down a tree. So unless the attacker is that the packet can only go down a tree. So unless the attacker is
TLMR, the packet will not be forwarded. In any case, the attacker TLMR, the packet will not be forwarded. In any case, the attacker
will be bombed first. will be bombed first.
Say that an attacker on the path of the MRHA tunnel modifies the RRH Say that an attacker on the path of the MRHA tunnel modifies the RRH
in order to black out the MR. The result could actually be in order to black out the MR. The result could actually be
accomplished by changing any bit in the packet since the IPSec accomplished by changing any bit in the packet since the IPSec
signature would fail, or scrambling the radio waves in the case of signature would fail, or scrambling the radio waves in the case of
wireless. wireless.
Selecting the tree to attach to is a security critical operation Selecting the tree to attach to is a security critical operation
outside of the scope of this draft. Note that the MR should not outside of the scope of this draft. Note that the MR should not
select a path based on trust but rather on measured service. If a select a path based on trust but rather on measured service. If a
better bandwidth is obtained via an untrusted access using IPSec, better bandwidth is obtained via an untrusted access using IPSec,
isn't it better than a good willing low bandwidth trusted access? isn't it better than a good willing low bandwidth trusted access?
12. Acknowledgements 12. Protocol Constants
DEF_RRH_SLOTS: 7
MAX_RRH_SLOTS: 10
13. Acknowledgements
The authors wish to thank David Auerbach, Fred Baker, Dana Blair, The authors wish to thank David Auerbach, Fred Baker, Dana Blair,
Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur, Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur,
Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick
Wetterwald -last but not least :)-. Wetterwald -last but not least :)-.
References 14 References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
2003.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-00 (work in progress), May 2003.
[3] kniveton, t., "Mobile Router Support with Mobile IP",
draft-kniveton-mobrtr-02 (work in progress), July 2002.
[4] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6",
draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
November 2001.
[5] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for
MIPv6 based Mobile Routers",
draft-thubert-nemo-ipv4-traversal-01 (work in progress), May
2003.
[6] Postel, J., "Internet Protocol", STD 5, RFC 791, September [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[7] Kent, S. and R. Atkinson, "Security Architecture for the [2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Conta, A. and S. Deering, "Internet Control Message Protocol [7] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
[13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an [8] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an
On-line Database", RFC 3232, January 2002. On-line Database", RFC 3232, January 2002.
[9] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[10] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[11] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-01 (work in progress), February
2004.
[12] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[13] Thubert, P. and N. Montavont, "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-00 (work in progress), May 2004.
[14] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home
Network models", draft-ietf-nemo-home-network-models-00 (work
in progress), April 2004.
[15] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for
MIPv6 based Mobile Routers",
draft-thubert-nemo-ipv4-traversal-01 (work in progress), May
2003.
Authors' Addresses Authors' Addresses
Pascal Thubert Pascal Thubert
Cisco Systems Technology Center Cisco Systems Technology Center
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille 400, Avenue Roumanille
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
EMail: pthubert@cisco.com EMail: pthubert@cisco.com
Marco Molteni Marco Molteni
Cisco Systems Technology Center Cisco Systems Technology Center
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille 400, Avenue Roumanille
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
EMail: mmolteni@cisco.com EMail: mmolteni@cisco.com
Appendix A. Optimizations Appendix A. Optimizations
A.1 Path Optimization with RRH A.1 Path Optimization with RRH
The body of the draft presents RRH as a header that circulates in the The body of the draft presents RRH as a header that circulates in the
reverse tunnel exclusively. The RRH format by itself has no such reverse tunnel exclusively. The RRH format by itself has no such
limitation. This section illustrates a potential optimization for limitation. This section illustrates a potential optimization for
end-to-end traffic between a Mobile Network Node and its end-to-end traffic between a Mobile Network Node and its
Correspondent Node. Correspondent Node.
The MNN determines that it is part of a Mobile Network by screening The MNN determines that it is part of a Mobile Network by screening
the Tree Information option in the RA messages from its Attachment the Tree Information option in the RA messages from its Attachment
Router. In particular, the MNN knows the TreeDepth as advertised by Router. In particular, the MNN knows the TreeDepth as advertised by
the AR. An initial test phase could be derived from MIPv6 to decide the AR. An initial test phase could be derived from MIPv6 to decide
whether optimization with a given CN is possible. whether optimization with a given CN is possible.
When an MNN performs end-to-end optimization with a CN, the MNN When an MNN performs end-to-end optimization with a CN, the MNN
inserts an empty RRH inside its packets, as opposed to tunneling them inserts an empty RRH inside its packets, as opposed to tunneling them
home, which is the default behavior of a Mobile Host as described in home, which is the default behavior of a Mobile Host as described in
Section 10. Section 10.
The number of slots in the RRH is initially the AR treeDepth plus 1, The number of slots in the RRH is initially the AR treeDepth plus 1,
but all slots are clear as opposed to the MR process as described in but all slots are clear as opposed to the MR process as described in
Section 9. The source address in the header is the MNN address, and Section 9. The source address in the header is the MNN address, and
the destination is the CN. the destination is the CN.
The AR of the MNN is by definition an MR. Since an RRH is already The AR of the MNN is by definition an MR. Since an RRH is already
present in the packet, the MR does not put the packets from the MNN present in the packet, the MR does not put the packets from the MNN
on its reverse tunnel, but acts as an intermediate MR; it adds the on its reverse tunnel, but acts as an intermediate MR; it adds the
source address of the packet (the MNN's address) in the RRH (in slot source address of the packet (the MNN's address) in the RRH (in slot
0) and stamps its careOf instead in the IP header source address 0) and stamps its careOf instead in the IP header source address
field. Recursively, all the MRs on a nested network trace in path in field. Recursively, all the MRs on a nested network trace in path in
the RRH and take over the source IP. the RRH and take over the source IP.
The support required on the CN side extends MIPv6 in a way similar to The support required on the CN side extends MIPv6 in a way similar to
the extension that this draft proposes for the HA side. The CN is the extension that this draft proposes for the HA side. The CN is
required to parse the RRH when it is valid, refresh its BCE required to parse the RRH when it is valid, refresh its BCE
accordingly, and include an RH type 2 with the full path to its accordingly, and include an RH type 2 with the full path to its
packets to the MNN. packets to the MNN.
Note that there is no Bind Update between the MNN and the CN. The RRH Note that there is no Bind Update between the MNN and the CN. The
must be secured based on tokens exchanged in the test phase. For the RRH must be secured based on tokens exchanged in the test phase. For
sake of security, it may be necessary to add fields to the RRH or to the sake of security, it may be necessary to add fields to the RRH or
add a separate option in the Mobility Header. to add a separate option in the Mobility Header.
A.2 Packet Size Optimization A.2 Packet Size Optimization
RRH allows to update the Correspondent BCE on a per packet basis, RRH allows to update the Correspondent BCE on a per packet basis,
which is the highest resolution that we can achieve. While this may which is the highest resolution that we can achieve. While this may
cope with highly mobile and nested configurations, it can also be an cope with highly mobile and nested configurations, it can also be an
overkill in some situations. overkill in some situations.
The RRH comes at a cost: it requires processing in all intermediate The RRH comes at a cost: it requires processing in all intermediate
Mobile Routers and in the Correspondent Node. Also, a RRH increases Mobile Routers and in the Correspondent Node. Also, a RRH increases
the packet size by more than the size of an IP address per hop in the the packet size by more than the size of an IP address per hop in the
Mobile Network. Mobile Network.
This is why an additional Routing Header is proposed (type 3). The This is why an additional Routing Header is proposed (type 3). The
semantics of type 3 are very close to type 4 but: semantics of type 3 are very close to type 4 but:
o Type 3 has only one slot, for the Home Address of the source. o Type 3 has only one slot, for the Home Address of the source.
o When it can not add the source to the RH type 3 of an outbound o When it can not add the source to the RH type 3 of an outbound
packet, an intermediate MR: packet, an intermediate MR:
* MR MUST NOT send ICMP (RRH too small) * MR MUST NOT send ICMP (RRH too small)
* MUST NOT put the packet in a reverse tunnel * MUST NOT put the packet in a reverse tunnel
Rather, it simply overwrites the source and forwards the packet up Rather, it simply overwrites the source and forwards the packet up
the tree as if the RRH had been properly updated. the tree as if the RRH had been properly updated.
o Since the path information is not available, the correspondent o Since the path information is not available, the correspondent
MUST NOT update its BCE based on the RH type 3. The CN (or HA) MUST NOT update its BCE based on the RH type 3. The CN (or HA)
identifies the source from the entry in slot 0 and may reconstruct identifies the source from the entry in slot 0 and may reconstruct
the initial packet using the CareOf in slot 1 as source for AH the initial packet using the CareOf in slot 1 as source for AH
purposes. purposes.
/* MR processing on outbound packet with RH type 3 support */ /* MR processing on outbound packet with RH type 3 support */
{ {
if no RH type 3 or 4 in outer header /* First Mobile Router specific */ if no RH type 3 or 4 in outer header /* First Mobile Router specific */
or RH type 4 present but saturated { /* Need a nested encapsulation */ or RH type 4 present but saturated { /* Need a nested encapsulation */
skipping to change at page 38, line 41 skipping to change at page 36, line 41
} else if RH type 3 { } else if RH type 3 {
if slot 0 is still free { if slot 0 is still free {
/* this is end-to-end optimization */ /* this is end-to-end optimization */
set it to source address from IP header set it to source address from IP header
} }
overwrite source address in IP header with MR CareOf overwrite source address in IP header with MR CareOf
transmit packet transmit packet
} }
} }
A.2.1 Routing Header Type 3 (Home Address option replacement) A.2.1 Routing Header Type 3 (Home Address option replacement)
This is an RH-based alternative to the Home Address destination This is an RH-based alternative to the Home Address destination
option. Its usage is described in Appendix A.2. option. Its usage is described in Appendix A.2.
The decision to send RH type 3 or type 4 is up to the source of the The decision to send RH type 3 or type 4 is up to the source of the
RRH. Several algorithms may apply, one out of N being the simplest. RRH. Several algorithms may apply, one out of N being the simplest.
IPsec HA processing is done as described in Section 11.1 for Type 4. IPsec HA processing is done as described in Section 11.1 for Type 4.
The Type 3 Routing Header has the following format: The Type 3 Routing Header has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=3| Segments Used | | Next Header | Hdr Ext Len | Routing Type=3| Segments Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 27 skipping to change at page 37, line 27
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Routing header. Uses the same values as the IPv4 following the Routing header. Uses the same values as the IPv4
Protocol field [13]. Protocol field [8].
Hdr Ext Len Hdr Ext Len
8-bit unsigned integer. Length of the Routing header in 8-octet 8-bit unsigned integer. Length of the Routing header in 8-octet
units, not including the first 8 octets. For the Type 3 Routing units, not including the first 8 octets. For the Type 3 Routing
header, Hdr Ext Len is always 2. header, Hdr Ext Len is always 2.
Routing Type Routing Type
8-bit unsigned integer. Set to 3. 8-bit unsigned integer. Set to 3.
Segment Used Segment Used
8-bit unsigned integer. Number of slots used. Either 0 or 1. When 8-bit unsigned integer. Number of slots used. Either 0 or 1.
the field is zero, then there is no MR on the path and it is valid When the field is zero, then there is no MR on the path and it is
for a CN that does not support RRH to ignore this header. valid for a CN that does not support RRH to ignore this header.
Reserved Reserved
32-bit reserved field. Initialized to zero for transmission; 32-bit reserved field. Initialized to zero for transmission;
ignored on reception. ignored on reception.
Home Address Home Address
128-bit home address of the source of the packet. 128-bit home address of the source of the packet.
Appendix B. Multi Homing Appendix B. Multi Homing
B.1 Multi-Homed Mobile Network B.1 Multi-Homed Mobile Network
Consider difference between situation A and B in this diagram: Consider difference between situation A and B in this diagram:
===?== ==?=== ===?== ==?===
MR1 MR2 MR1 MR2
| | | |
==?=====?== ==?====== situation A ==?=====?== ==?====== situation A
MR3 MR4 MR5 MR3 MR4 MR5
| | | | | |
=== === === === === ===
===?== ==?=== ===?== ==?===
MR1 MR2 MR1 MR2
| | | |
==?=====?=======?====== situation B ==?=====?=======?====== situation B
MR3 MR4 MR5 MR3 MR4 MR5
| | | | | |
=== === === === === ===
Going from A to B, MR5 may now choose between MR1 and MR2 for its Going from A to B, MR5 may now choose between MR1 and MR2 for its
Attachment (default) Router. In terms of Tree Information, MR5, as Attachment (default) Router. In terms of Tree Information, MR5, as
well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once MR5 well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once
selects its AR, MR2, say, MR5 belongs to the associated tree and MR5 selects its AR, MR2, say, MR5 belongs to the associated tree and
whether MR1 can be reached or not makes no difference. whether MR1 can be reached or not makes no difference.
As long as each MR has a single default router for all its outbound As long as each MR has a single default router for all its outbound
traffic, 2 different logical trees can be mapped over the physical traffic, 2 different logical trees can be mapped over the physical
configurations in both situations, and once the trees are configurations in both situations, and once the trees are
established, both cases are equivalent for the processing of RRH. established, both cases are equivalent for the processing of RRH.
Note that MR5 MUST use a CareOf based on a prefix owned by its AR as Note that MR5 MUST use a CareOf based on a prefix owned by its AR as
source of the reverse tunnel, even if other prefixes are present on source of the reverse tunnel, even if other prefixes are present on
the Mobile Network, to ensure that a RH type 2 can be securely routed the Mobile Network, to ensure that a RH type 2 can be securely routed
back. back.
B.2 Multihomed Mobile Router B.2 Multihomed Mobile Router
Consider the difference between situation B and C in this diagram: Consider the difference between situation B and C in this diagram:
===?== ==?=== ===?== ==?===
MR1 MR2 MR1 MR2
| | | |
==?=====?=======?====== situation B ==?=====?=======?====== situation B
MR3 MR4 MR5 MR3 MR4 MR5
| | | | | |
=== === === === === ===
==? ?== ==? ?==
MR1 MR1
| |
==?=====?=======?====== situation C ==?=====?=======?====== situation C
MR3 MR4 MR5 MR3 MR4 MR5
| | | | | |
=== === === === === ===
In situation C, MR2's egress interface and its properties are In situation C, MR2's egress interface and its properties are
migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home
Agents, and 2 active interfaces. Agents, and 2 active interfaces.
If MR1 uses both CareOf addresses at a given point of time, and if If MR1 uses both CareOf addresses at a given point of time, and if
they belong to different prefixes to be used via different attachment they belong to different prefixes to be used via different attachment
routers, then MR1 actually belongs to 2 trees. It must perform some routers, then MR1 actually belongs to 2 trees. It must perform some
routing logic to decide whether to forward packets on either egress routing logic to decide whether to forward packets on either egress
interface. Also, it MUST advertise both tree information sets in its interface. Also, it MUST advertise both tree information sets in its
RA messages. RA messages.
The difference between situations C and B is that when an attached The difference between situations C and B is that when an attached
router (MR5, say) selects a tree and forwards egress packets via MR1, router (MR5, say) selects a tree and forwards egress packets via MR1,
it can not be sure that MR1 will actually forward the packets over it can not be sure that MR1 will actually forward the packets over
that tree. If MR5 has selected a given tree for a specific reason, that tree. If MR5 has selected a given tree for a specific reason,
then a new source route header is needed to enforce that path on MR1. then a new source route header is needed to enforce that path on MR1.
The other way around, MR5 may leave the decision up to MR1. If MR1 The other way around, MR5 may leave the decision up to MR1. If MR1
uses the same attachment router for a given flow or at least a given uses the same attachment router for a given flow or at least a given
destination, then the destination receives consistent RRHs. destination, then the destination receives consistent RRHs.
Otherwise, the BCE cache will flap, but as both paths are valid, the Otherwise, the BCE cache will flap, but as both paths are valid, the
traffic still makes it through. traffic still makes it through.
Appendix C. Changes from Previous Version of the Draft Appendix C. Changes from Previous Version of the Draft
From -04 to -05
Tree Information option: now a reference to a separate draft.
Removed RRH heartbeat.
Added a DHAAD section
Clarified how RRH solves the mobile home deadlock.
new section "Optimum number of slots in RRH" from ICMP section
From -03 to -04 From -03 to -04
TI option: renamed the F (fixed) flag bit to G (grounded). TI option: renamed the F (fixed) flag bit to G (grounded).
Binding Update: Made clear that the BU flow conforms MIPv6 and Binding Update: Made clear that the BU flow conforms MIPv6 and
Nemo but that RRH replaces both Home address Option and Alternate NEMO but that RRH replaces both Home address Option and Alternate
CareOf option. CareOf option.
From -02 to -03 From -02 to -03
Reworded the security part to remove an ambiguity that let the Reworded the security part to remove an ambiguity that let the
reader think that RRH is unsafe. reader think that RRH is unsafe.
From -01 to -02 From -01 to -02
Made optional the usage of ICMP warning "RRH too small" (Section Made optional the usage of ICMP warning "RRH too small" (Section
skipping to change at page 42, line 38 skipping to change at page 40, line 50
From -00 to -01 From -00 to -01
Added new Tree Information Option fields: Added new Tree Information Option fields:
A 8 bits Bandwidth indication that provides an idea of the A 8 bits Bandwidth indication that provides an idea of the
egress bandwidth. egress bandwidth.
A CRC-32 that changes with the egress path out of the tree. A CRC-32 that changes with the egress path out of the tree.
a 32 bits unsigned integer, built by each MR out of a high a 32 bits unsigned integer, built by each MR out of a high
order configured preference and 24 bits random constant. This order configured preference and 24 bits random constant. This
can help as a tie break in Attachment Router selection. can help as a tie break in Attachment Router selection.
Reduced the 'negative' part of the lollipop space to 0..255 Reduced the 'negative' part of the lollipop space to 0..255
Fixed acknowledgements (sorry Patrick :) Fixed acknowledgements (sorry Patrick :)
Changed the type of Tree Information Option from 7 to 10. Changed the type of Tree Information Option from 7 to 10.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 202 change blocks. 
548 lines changed or deleted 478 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/