idnits 2.17.1
draft-ng-nemo-access-router-option-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1971.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1948.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1955.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1961.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
1977), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 37.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 649: '... Discovery [11], receivers that do not understand this new option MUST...'
RFC 2119 keyword, line 768: '...ally, the router MUST NOT change the s...'
RFC 2119 keyword, line 1033: '...also that the HA MUST accept BU with A...'
RFC 2119 keyword, line 1165: '... Thus, all home-agents SHOULD use the...'
RFC 2119 keyword, line 1170: '...stination option MUST be replaced with...'
(9 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 970 has weird spacing: '...er, the packe...'
== Line 1279 has weird spacing: '...er, the packe...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 12, 2004) is 7200 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275)
== Outdated reference: A later version (-06) exists of
draft-ietf-nemo-requirements-02
** Downref: Normative reference to an Informational draft:
draft-ietf-nemo-requirements (ref. '3')
== Outdated reference: A later version (-04) exists of
draft-thubert-nemo-ro-taxonomy-02
-- Possible downref: Normative reference to a draft: ref. '4'
== Outdated reference: A later version (-06) exists of
draft-ietf-nemo-terminology-01
** Downref: Normative reference to an Informational draft:
draft-ietf-nemo-terminology (ref. '5')
** Obsolete normative reference: RFC 2460 (ref. '7') (Obsoleted by RFC 8200)
** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301)
** Obsolete normative reference: RFC 2402 (ref. '9') (Obsoleted by RFC
4302, RFC 4305)
** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC
4303, RFC 4305)
** Obsolete normative reference: RFC 2461 (ref. '11') (Obsoleted by RFC
4861)
** Obsolete normative reference: RFC 2463 (ref. '12') (Obsoleted by RFC
4443)
Summary: 18 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 NEMO Working Group C. Ng
2 Internet-Draft Panasonic Singapore Labs
3 Expires: January 10, 2005 J. Hirano
4 Panasonic
5 July 12, 2004
7 Securing Nested Tunnels Optimization with Access Router Option
8 draft-ng-nemo-access-router-option-01
10 Status of this Memo
12 By submitting this Internet-Draft, I certify that any applicable
13 patent or other IPR claims of which I am aware have been disclosed,
14 and any of which I become aware will be disclosed, in accordance with
15 RFC 3668.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as
20 Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on January 10, 2005.
35 Copyright Notice
37 Copyright (C) The Internet Society (2004). All Rights Reserved.
39 Abstract
41 Network Mobility (NEMO) Basic Support provides global connectivity to
42 mobile network through the establishment of bi-directional tunnels
43 between a mobile router and home agent. However, this sub-optimal
44 routing, especially when nesting of mobile networks or Mobile IPv6
45 (MIPv6) host occurs within a mobile network. This memo proposes
46 using a new mobility header option called the Access Router Option to
47 allow a mobile node (host/router) to inform its home agent (HA) or
48 corespondent node (CN) the home-address (HoA) of the access router it
49 is currently attached to. From there, this memo lays out a mechanism
50 that allows mobile nodes to securely achieve nested tunnels
51 optimization, and even full route optimization.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
56 1.1 Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 5
57 1.2 Organization . . . . . . . . . . . . . . . . . . . . . . . 5
58 1.3 Change Log . . . . . . . . . . . . . . . . . . . . . . . . 6
59 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
60 2.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 7
61 2.2 Binding Update from MR1 to HA1 . . . . . . . . . . . . . . 7
62 2.3 Binding Update from MR2 to HA1 . . . . . . . . . . . . . . 8
63 2.4 Forwarding Packets from HA1 to MR1 . . . . . . . . . . . . 8
64 2.5 Forwarding Packets from MR1 to HA1 . . . . . . . . . . . . 9
65 2.6 Scenario with a Local Fixed Router . . . . . . . . . . . . 9
66 2.7 Route Optimization with Mobile Network Hosts . . . . . . . 10
67 3. Changes to Existing Protocols . . . . . . . . . . . . . . . . 12
68 3.1 Modifications to NEMO Basic Support / Mobile IPv6 . . . . 12
69 3.1.1 Addition of Access Router Option . . . . . . . . . . . 12
70 3.1.2 Extending Type 2 Router Header . . . . . . . . . . . . 13
71 3.1.3 Modification to Conceptual Data Structures . . . . . . 14
72 3.2 Modifications to IPv6 Neighbor Discovery . . . . . . . . . 15
73 3.2.1 Addition of New Option in Router Advertisement . . . . 15
74 3.3 Modifications to ICMPv6 . . . . . . . . . . . . . . . . . 16
75 3.3.1 New Router Global Address ICMP Message . . . . . . . . 16
76 3.4 Extending the Router Alert Option . . . . . . . . . . . . 18
77 4. Operation of ARO-Enabled Mobile Routers . . . . . . . . . . . 20
78 4.1 Operation When Mobile Router is At Home . . . . . . . . . 20
79 4.1.1 Sending Router Advertisement . . . . . . . . . . . . . 20
80 4.1.2 Processing Outbound Packets . . . . . . . . . . . . . 20
81 4.1.3 Processing Inbound Packets . . . . . . . . . . . . . . 20
82 4.2 Operation When Mobile Router is Away . . . . . . . . . . . 21
83 4.2.1 Sending Router Advertisement . . . . . . . . . . . . . 21
84 4.2.2 Receiving Router Advertisement . . . . . . . . . . . . 21
85 4.2.3 Sending Binding Updates . . . . . . . . . . . . . . . 21
86 4.2.4 Processing Outbound Packets . . . . . . . . . . . . . 22
87 4.2.5 Processing Inbound Packets . . . . . . . . . . . . . . 23
88 4.3 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 24
89 4.3.1 IPSec Processing on Inbound Packets . . . . . . . . . 24
90 4.3.2 IPSec Processing on Outbound Packets . . . . . . . . . 24
91 5. Operation of ARO-Enabled Home Agents . . . . . . . . . . . . . 25
92 5.1 Receiving Binding Updates . . . . . . . . . . . . . . . . 25
93 5.2 Receiving Tunneled Packets from Away Nodes . . . . . . . . 25
94 5.3 Tunneling Packets to Away Nodes . . . . . . . . . . . . . 26
95 5.4 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 28
96 5.4.1 IPSec Processing on Inbound Packets . . . . . . . . . 28
97 5.4.2 IPSec Processing on Outbound Packets . . . . . . . . . 28
98 6. Operation of ARO-Enabled Mobile Network Nodes . . . . . . . . 29
99 6.1 Nested Tunnel Optimization with Home Agent . . . . . . . . 29
100 6.2 Receiving Router Advertisement . . . . . . . . . . . . . . 29
101 6.3 Sending Binding Updates . . . . . . . . . . . . . . . . . 29
102 6.4 Sending Data Packets . . . . . . . . . . . . . . . . . . . 30
103 6.5 Processing Inbound Packets . . . . . . . . . . . . . . . . 30
104 6.6 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 31
105 6.6.1 IPSec Processing on Inbound Packets . . . . . . . . . 31
106 6.6.2 IPSec Processing on Outbound Packets . . . . . . . . . 31
107 7. Operation of ARO-Enabled Correspondent Node . . . . . . . . . 32
108 7.1 Receiving Binding Updates . . . . . . . . . . . . . . . . 32
109 7.2 Receiving Route Optimized Packets from Mobile Nodes . . . 32
110 7.3 Sending Route Optimized Packets to Mobile Nodes . . . . . 32
111 7.4 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 33
112 7.4.1 IPSec Processing on Inbound Packets . . . . . . . . . 33
113 7.4.2 IPSec Processing on Outbound Packets . . . . . . . . . 33
114 8. Design Considerations . . . . . . . . . . . . . . . . . . . . 34
115 8.1 Considerations in the Use of Mutable Router Alert
116 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 34
117 8.1.1 Overview of Router Alert Option . . . . . . . . . . . 34
118 8.1.2 Example where an Immutable RAO is Used . . . . . . . . 34
119 8.1.3 The Need for Mutable RAO . . . . . . . . . . . . . . . 36
120 8.1.4 Alternatives to the Mutable Router Alert Option . . . 36
121 8.2 Change of Source Address . . . . . . . . . . . . . . . . . 37
122 8.2.1 Justifications . . . . . . . . . . . . . . . . . . . . 37
123 8.2.2 Alternatives . . . . . . . . . . . . . . . . . . . . . 38
124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
125 9.1 Addition of Access Router Option . . . . . . . . . . . . . 39
126 9.2 Router Global Address Option . . . . . . . . . . . . . . . 40
127 9.3 Accepting Tunnel with a Source Address not Directly
128 Bound to the Home Address . . . . . . . . . . . . . . . . 40
129 9.4 Use of Extended Routing Header Type 2 . . . . . . . . . . 41
130 9.5 Mutable Router Alert Option . . . . . . . . . . . . . . . 42
131 9.6 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 43
132 9.6.1 Processing of Extended Routing Header Type 2 . . . . . 43
133 9.6.2 Processing of Home Address Destination Option . . . . 43
134 9.6.3 Processing of Mutable Router Alert Option . . . . . . 43
135 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
137 A. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 46
138 Intellectual Property and Copyright Statements . . . . . . . . 47
140 1. Introduction
142 This memo describes a proposed solution for provisioning route
143 optimization in Network Mobility (NEMO). This solution is built on
144 top of Mobile IPv6 (MIPv6) [1] and NEMO Basic Support [2][3]. The
145 general problem of route optimization in NEMO is analyzed and
146 summarized in [4].
148 The proposed solution described in this memo aims to solve the
149 following route optimizations problems:
151 o Nested Tunnel Optimization
153 This optimization problem is to eliminate the nesting of tunnels
154 for a nested mobile network. The proposed solution requires
155 changes to the mobile router (MR) and home agent (HA)
156 implementation so that no matter how many level of nesting a
157 mobile network has, there is only one tunnel between the innermost
158 MR and its HA.
160 o Nested Tunnel Optimization for MIPv6
162 This optimization problem is to eliminate the nesting of tunnels
163 for a MIPv6 host in a mobile network. The proposed solution
164 requires changes to the MR, MIPv6 host, and HA (for both the MR
165 and MIPv6 host) implementation so that for a visiting mobile host
166 in a mobile network, the only tunnel necessary is the one between
167 the MIPv6 host and its HA, without additional encapsulation at the
168 MR.
170 o MIPv6 over NEMO Optimization
172 This optimization problem is to allow the MIPv6 route optimization
173 to work between a MIPv6 host in a mobile network (i.e. visiting
174 mobile host) and its correspondent node (CN). The proposed
175 solution requires changes to the MR, MIPv6 host, and CN
176 implementation so that a visiting mobile host in a mobile network
177 can perform route optimization with a CN, without any tunneling
178 back to the home agents of either the MIPv6 host or MR.
180 Various different proposals have been submitted to the NEMO Working
181 Group to solve different aspects of the route optimization problem of
182 network mobility. Readers are encouraged to look at
183 for a complete list of Internet
184 Drafts that have been published.
186 1.1 Terms Used
188 It is assumed that readers are familiar with the NEMO terminology
189 described in [5] and those defined in [4]. In addition, [4] also
190 presents a detailed description of the problem of route optimization
191 in NEMO.
193 Apart from the terms described in [5] and [4], we further define the
194 following terminology:
196 Access Router (AR)
198 Any router that is the point of attachment to the Internet of one
199 or more visiting mobile node (VMN). We use the phrase "access
200 router of node X" to loosely refer to the router a node X attaches
201 to. An access router can be a MR.
203 ARO-Solution, ARO-enabled
205 To aid our illustration, we refer to the solution proposed in this
206 memo as the "ARO-Solution". Any network nodes that implements the
207 "ARO-Solution" is referred to as a "ARO-enabled" node.
209 1.2 Organization
211 In this memo, we first begin in Section 2 by giving a general
212 overview of the proposed ARO Solution in operation. This is followed
213 by a detailed description of the modifications to existing protocols
214 in Section 3. Following which, the operation of each entity: mobile
215 router, home agent, mobile network node, and correspondent node that
216 support the ARO Solution are detailed respectively from Section 4
217 through Section 7. In Section 8, we list some of the design
218 considerations when formulating the ARO Solution. Finally, security
219 considerations in discussed in Section 9.
221 1.3 Change Log
223 o Changes from version -00 to -01
225 * Extended solution to be able to optimized over local fixed
226 router with inclusion of NEMO-BU RAO
228 * Inclusion of NEMO-BU RAO and a new ICMPv6 message
230 * Extended solution for optimization between MR and CN
232 * Extended solution for optimization between VMN and CN/HA
234 * Included operations of CN and VMN
236 2. Overview of Operation
238 This section gives an overview of the operation of the proposed
239 solution. We use the scenario illustrated in Figure 1 below as an
240 example to describe the operation of the ARO-solution.
242 HA1
243 |
244 +---------|---------+
245 | |
246 LFN1---MR1---MR2---- Internet ----CN1
247 | |
248 +---------|---------+
249 |
250 HA2
252 Figure 1: Example Scenario
254 In Figure 1, LFN1 is a local fixed node attached to the ingress
255 interface of the visiting mobile router (VMR) MR1. MR1 is itself
256 attached to the ingress interface of another mobile router, MR2. HA1
257 is the home agent of MR1, and HA2 is the home agent of MR2. LFN1 is
258 communicating with a correspondent node CN1.
260 2.1 Router Advertisement
262 When MR1 first obtains a Router Advertisement (RA) from MR2, it
263 checks if MR2 supports the ARO-Solution. This is determined by an
264 additional option (known as Router Global Address Option, or RGAO)
265 that advertises the home-address (HoA) of MR2.
267 2.2 Binding Update from MR1 to HA1
269 After MR1 obtains a care-of-address (CoA), it sends Binding Update
270 (BU) to its home agent, HA1. The BU message, beside having the
271 prefix informations as detailed in [2], also contains an important
272 extension, known as the "Access Router Option" (ARO). This ARO
273 specifies the global address of MR2, thus informing HA1 the access
274 router MR1 is currently attached to. In this case, since MR2 is
275 itself a mobile router, the global address is the HoA of MR2.
277 HA1 records this together with the binding update in the
278 corresponding binding cache entry (BCE). When returning the Binding
279 Acknowledgment (BA), HA1 can then made use of the extended Type 2
280 Routing Header (RH2) to forward the BA message to MR1 via the HoA of
281 MR2. Here, the RH2 as defined by Mobile IPv6 specification [1] is
282 extended so that it can store more than one address. In addition,
283 HA1 should insert the same ARO in BA message to indicate that the BU
284 with ARO is accepted.
286 Since the BA message is addressed to the HoA of MR2, the BA message
287 will be intercepted by HA2. Here, we assume that the BCE of HA2
288 contains a binding of the current CoA and HoA of MR2. Thus, HA2 will
289 tunnel the packet to the CoA of MR2. When MR2 receives and
290 decapsulates the BA message, it notices that there is an extended
291 RH2. It proceeds to swap the destination address with the
292 appropriate entry in the RH2 (which should be the CoA of MR1), and
293 forward it to MR1. MR1 receives the packet, verifies that it is the
294 final destination of the packet, and consumes the BA message.
296 2.3 Binding Update from MR2 to HA1
298 From the processing of the extended RH2 as described previously, MR2
299 can deduce the following two facts:
301 1. the sender (i.e. HA1) does not have a BCE of MR2's current CoA,
302 since the received packet is encapsulated in a tunnel from HA2,
303 and
305 2. HA1 is ARO-enabled, since an extended RH2 is used.
307 Having established these, MR2 may then send a BU to HA1. In this
308 case, HA1 is treated as a correspondent node from the perspective of
309 MR2. Thus, the Return Routability (RR) procedure specified in [1]
310 must be carried out before sending the BU message. Note also that
311 since HA1 is treated as a correspondent node, MR2 should not insert
312 any prefix information (i.e. Mobile Network Prefix Option [2]) in
313 the BU message. Once the binding update is successful, MR2 should
314 add the host address of HA1 to a locally maintained Binding Update
315 List. This list contains a list of hosts that have an active binding
316 cache entry of MR2's current CoA.
318 Note that if the access router (fixed or mobile) of MR2 is ARO-
319 enabled, MR2 should add an ARO in the BU it sent to HA1 to inform HA1
320 the global address of the access router MR2 is currently attached to.
321 To simply our description, we assume that this is not the case.
323 2.4 Forwarding Packets from HA1 to MR1
325 After receiving the BU message from MR2, the bi-directional tunnel
326 between HA1 and MR1 need not go through the tunnel between HA2 and
327 MR2. Instead, tunnel packets from HA1 to MR1 can be sent directly to
328 the CoA of MR2 with an attached extended RH2.
330 As an illustration, suppose CN1 now sends a packet to LFN1. The
331 packet will be intercepted by HA1. HA1 checks its routing table and
332 notices that the packet should be forwarded to MR1. However, a check
333 of its binding cache reveals that MR1 is away. Hence, HA1 needs to
334 tunnel the packet to the current CoA of MR1. Furthermore, HA1 knows
335 that MR1 is currently attached to MR2, and HA1 has a BCE of MR2.
336 Thus, the tunnel should be configured, with an extended RH2, such
337 that it reaches CoA of MR1 via CoA MR2. In this case, the
338 destination address of the outer packet is set to the CoA of MR2, and
339 the entries in the RH2 are the CoA and HoA of MR1, in that order.
340 When MR2 receives such a packet, it updates the RH2 (i.e. swap the
341 destination address with the next entry in the RH2), and forward the
342 packet to the new destination (i.e. CoA of MR1). MR1 upon receiving
343 the packet will verify that it is the final destination of the outer
344 packet, and decapsulates the packet. The inner packet is addressed
345 to LFN1, a valid address in the subnet of MR1. Hence, MR1 forwards
346 the packet to its appropriate ingress interface.
348 2.5 Forwarding Packets from MR1 to HA1
350 When LFN1 sends a packet to CN1, MR1 will encapsulate the packet to
351 be sent through the reverse tunnel with its home agent HA1. The
352 outer packet is appended with a mutable Router Alert Option (RAO)
353 [6], in addition to the Home Address destination Option (HAO). This
354 RAO requests upstream routers that are ARO-enabled to forward packet
355 directly to the destination. When MR2 receives this packet and
356 noticed the RAO, it checks if it has a binding update with the
357 specified destination (from its Binding Update List). If so, it
358 changes the source address to its CoA and sends the packet to the
359 destination. Else, the packet is tunneled to HA2, i.e. normal
360 reverse tunneling between MR2 and HA2. For the latter case, MR2
361 might want to send a BU message to the destination (i.e. HA1) so
362 that subsequent packets can be forwarded directly to the destination
363 (without going through an additional level of encapsulation).
365 When HA1 receives an encapsulated packet, it verifies that the outer
366 packet originated from authentic source. This is done by checking
367 that the originator (that is specified by the HAO) has a BCE that
368 indicates the mobile router identified by the source address is a
369 valid access router of the originator. HA1 then overwrites the
370 source address with the HoA specified in HAO and processes it as per
371 MIPv6 specifications [1].
373 Section 4 describes in greater detail the operation of an ARO-enabled
374 mobile router, and Section 5 describes the operation of an
375 ARO-enabled home agent.
377 2.6 Scenario with a Local Fixed Router
379 The ARO-Solution is designed such that it will work even across a non
380 ARO-enabled router, such as in the case where there is a local fixed
381 router in between two ARO-enabled MR. Figure 2 show the scenario
382 with a non ARO-enabled router LFR1 in between MR1 and MR2. Again,
383 HA1 and HA2 are the home-agents of MR1 and MR2 respectively. LFR1
384 simply route packets between its ingress and egress interfaces, and
385 does not do any reverse tunneling.
387 HA1
388 |
389 +---------|---------+
390 | |
391 LFN1---MR1---LFR1---MR2---- Internet ----CN1
392 | |
393 +---------|---------+
394 |
395 HA2
397 Figure 2: Example Scenario with a LFR
399 The problem here is that although MR2 advertises its HoA in the RA
400 messages it broadcast, LFR1 being non ARO-enabled will ignore such
401 information. Also, MR1 will not see any RGAO in the RA messages
402 broadcasted by LFR1. Thus MR1 will not add in any RAO in the tunnel
403 packet to HA1, and hence MR2 will not attempt to send BU to HA1.
404 This will result in all packets sent between LFN1 and CN1 to go
405 through two levels of encapsulation.
407 To overcome this problem, when an ARO-enabled mobile router (eg MR1)
408 does not detect its access router to be ARO-enabled, it should try to
409 determine if there is any ARO-enabled router in its upstream. This
410 is done by adding a new RAO in the initial BU message it sent to its
411 HA. Any upstream ARO-enabled router (eg MR2) will detect this RAO,
412 and respond to MR1 with an ICMP message conveying its global address.
413 This way, MR1 can immediately send a new BU with the global address
414 of the MR2 in the ARO. This imply that for the purpose of route
415 optimization, MR1 treats MR2 as its access router.
417 2.7 Route Optimization with Mobile Network Hosts
419 The same mechanism can be extended to be used between a MIPv6 mobile
420 host and its home agent or correspondent node (CN). Here, the MIPv6
421 host needs to extract the RGAO from the RA messages it receives from
422 its access router, and insert the ARO in the BU messages it sent to
423 its HA or CN. After a successful binding, data packets sent from the
424 mobile host can be prepend with a RAO to request upstream routers to
425 attempt to route packets directly to the destination. The RAO can be
426 inserted when tunneling a packet back to its HA, or inserted when the
427 packet is sent directly to the CN using MIPv6 route optimization
428 mechanism. In this way, a visiting mobile host (VMH) can perform
429 route optimization over NEMO.
431 When attempting to use ARO-Solution for full route optimization with
432 a CN, the mobile host must first determine if the CN is ARO-enabled.
433 One possible way of such capability detection is to send a BU with
434 the ARO, and check if the BA returned contains the same ARO. An
435 ARO-enabled CN would return a BA with the same ARO found in a BU
436 message.
438 Section 6 describes in greater detail the operation of an ARO-enabled
439 mobile node, and Section 7 describes the operation of an ARO-enabled
440 correspondent node.
442 3. Changes to Existing Protocols
444 3.1 Modifications to NEMO Basic Support / Mobile IPv6
446 3.1.1 Addition of Access Router Option
448 The Access Router Option (ARO) is a new option for Mobility Header
449 defined in Mobile IPv6 and NEMO Basic Support. Its format is shown
450 below.
452 0 1 2 3
453 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
454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
455 | Type = TBA | Length = 16 |
456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
457 | |
458 + +
459 | |
460 + Access Router Address +
461 | |
462 + +
463 | |
464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
466 Figure 3: Access Router Option
468 Type
470 8-bit identifier of the Mobility Header option type. The value
471 that identifies an Access Router Option is yet to be assigned.
473 Length
475 8-bit unsigned integer that specifies the length of the mobility
476 option in octets, excluding Type and Length fields. Always 16 for
477 the Access Router Option.
479 Access Router Address
481 Global address of the access router that the sender is currently
482 attached to.
484 The Access Router Option is only valid in a BU and BA message. The
485 purpose of this option is to inform the recipient that the sender is
486 currently attached to the specified access router. Using this
487 information, recipient can route packets to the sender via the access
488 router by making use of extended Type 2 Routing Header. Section 9.1
489 addresses some security considerations on the use of the Access
490 Router Option.
492 3.1.2 Extending Type 2 Router Header
494 The Type 2 Routing Header (RH2) is now extended such that it can
495 contain more than one entry. This extension makes it more similar to
496 the type 0 routing header. The format of the modified Type 2 Routing
497 Header is shown below.
499 0 1 2 3
500 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
501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
502 | Next Header | Hdr Ext Len | Routing Type=2| Segments Left |
503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
504 | Reserved |
505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
506 | |
507 + +
508 | |
509 + Address [1] +
510 | |
511 + +
512 | |
513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
514 | |
515 . .
516 . . . . .
517 . .
518 | |
519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520 | |
521 + +
522 | |
523 + Address [n] +
524 | |
525 + +
526 | |
527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
529 Figure 4: Extended Type 2 Routing Header
531 Next Header
533 8-bit selector. Identifies the type of header immediately
534 following the Routing Header. Uses the same value as the IPv6
535 Next Header field [7].
537 Hdr Ext Len
539 8-bit unsigned integer. Length of the routing header in 8- octet
540 units, not including the first 8 octets. This value is always
541 equal to twice the number of addresses in the Address vector.
543 Routing Type
545 8-bit unsigned integer that contains the value 2.
547 Segments Left
549 8-bit unsigned integer. Number of route segments remaining; i.e.
550 number of explicitly listed intermediate nodes still to be visited
551 before reaching its final destination.
553 Address[1..n]
555 Vector of 128-bit addresses, numbered 1 to n.
557 This routing header is used by the sender to direct the packet to the
558 mobile node via a sequence of routers. The addresses of the sequence
559 of routers are placed in the order of visit to the Address[1..n]
560 vector. The last address, Address[n], must be the HoA of the
561 intended recipient. Note also that Hdr Ext Len field must always
562 contain an even number.
564 Each MR that receives a packet with the Type 2 Routing Header and the
565 destination field equals to its address must checked if Segments Left
566 field is equal to 1. If yes, the last address in the Address[]
567 vector must be its HoA. Else the packet is discarded. If
568 Segments-Left is non-zero, it decrements the Segment-Left field, and
569 swaps the destination field with the next address in the Address[]
570 vector. To work out which address to swap, the MR can divide the Hdr
571 Ext Len field by 2 (which gives the number of entries in Address[]
572 vector), and subtract Segment Left from it.
574 The extended Type 2 Routing Header is a mutable but predictable IPv6
575 header. Thus IP Security (IPSec) [8] protocols such as
576 Authentication Header (AH) [9] and Encapsulating Security Payload
577 (ESP) [10] can be used with the routing header. Security
578 considerations on the extension of Type 2 Routing Header are
579 presented in Section 9.4.
581 3.1.3 Modification to Conceptual Data Structures
583 In Mobile IPv6 [1], the Binding Cache data structure is defined to
584 contain entries of HoA to CoA bindings. NEMO Basic Support [2]
585 suggested the extension of each BCE to contain information on
586 prefixes injected by mobile routers. This ARO-Solution further
587 extends each BCE to contain an additional field known as the Access
588 Router Address. This field is used to store the global address of
589 the access router specified in the Access Router Option in a Binding
590 Update message.
592 When updating the BCE, the Access Router Address field is overwritten
593 with the address specified in the Access Router Option. If the
594 Access Router Option is absent, the Access Router Address field
595 should be marked to be invalid.
597 3.2 Modifications to IPv6 Neighbor Discovery
599 3.2.1 Addition of New Option in Router Advertisement
601 A new option, Router Global Address Option (RGAO) is defined here.
602 This new option can only appear in a Router Advertisement message,
603 its format is defined below.
605 0 1 2 3
606 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
607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
608 | Type | Length | Reserved |
609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
610 | Reserved |
611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
612 | |
613 + +
614 | |
615 + Router Global Address +
616 | |
617 + +
618 | |
619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
621 Figure 5: Router Global Address Option
623 Type
625 8-bit identifier to identify the type of the option. The value
626 used to identify the Router Global Address Option is yet to be
627 assigned.
629 Length
631 8-bit unsigned integer that gives the length of the option in
632 8-octet units. Always equals to 3 for the Router Global Address
633 Option.
635 Router Global Address
637 128-bit address. Contains the global address of the egress
638 interface of the sender. Should the sender be a mobile router,
639 this global address is the home-address of the sender.
641 This option allows the sender to advertise its egress interface
642 global address to nodes attached to its ingress interface(s). This
643 allows mobile nodes to include an Access Router Option when sending
644 BU. Inclusion of this option in a RA message would imply the sender
645 is ARO-enabled.
647 Security considerations for the Router Global Address Option are
648 listed in Section 9.2. According to Section 4.2 of IPv6 Neighbor
649 Discovery [11], receivers that do not understand this new option MUST
650 silently ignore the option and continue processing the Router
651 Advertisement message.
653 3.3 Modifications to ICMPv6
655 3.3.1 New Router Global Address ICMP Message
657 A new ICMP message to convey the global address of a mobile router is
658 needed in the ARO-Solution. This message, called the Router Global
659 Address Message, has a format as defined below.
661 0 1 2 3
662 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
663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
664 | Type | Code | CheckSum |
665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
666 | Reserved |
667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
668 | |
669 + +
670 | |
671 + Router Global Address +
672 | |
673 + +
674 | |
675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
677 Figure 6: Router Global Address ICMP Message
679 Type
681 8-bit identifier to identify the type of the ICMP Message. The
682 value used to identify the Router Global Address Message is yet to
683 be assigned.
685 Code
687 8-bit unsigned integer that gives the finer granularity on message
688 type differentiation. Set to 0 for the Router Global Address
689 Message.
691 CheckSum
693 8-bit ICMP Checksum (see [12]
695 Router Global Address
697 128-bit address. Contains the global address of the egress
698 interface of the sender. Should the sender be a mobile router,
699 this global address is the home-address of the sender.
701 This message is sent when a ARO-enabled router intercepts a packet
702 from its ingress interface containing a NEMO-BU RAO. This occurs
703 when a nested MR does not know its access router's global address,
704 and is attempting to learn its access router's global address. The
705 ARO-enabled router intercepting such a packet would send the Router
706 Global Address ICMP message to the source, revealing its global
707 address (or home-address if the ARO-enabled router is also a mobile
708 router).
710 3.4 Extending the Router Alert Option
712 The router alert option [6] has the following format:
714 0 1 2 3
715 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
716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
717 |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
720 Figure 7: Router Alert Option
722 The first three bits of the first byte are zero and the value 5 in
723 the remaining five bits is the Hop-by-Hop Option Type number. By
724 zeroing all three, this specification requires that nodes not
725 recognizing this option type should skip over this option and
726 continue processing the header, and that the option must not change
727 en route.
729 In this memo, we require the value field to be mutable en-route.
730 Specifically, the router that is not attached to a ARO- enabled
731 access router will change the value code. Thus, this memo propose a
732 mutable Router Alert Option, of the following format:
734 0 1 2 3
735 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
736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
737 |0 0 1|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
740 Figure 8: Mutable Router Alert Option
742 The first two bits of the first byte are zero, the third bit is 1 and
743 the value 5 in the remaining five bits. Thus the Hop-by-Hop Option
744 Type number is 0x25 (hexadecimal). By zeroing the first two bits,
745 this memo requires that nodes not recognizing this option type should
746 skip over this option and continue processing the header.
748 The Value code in the mutable Router Alert Option is extended to
749 contain three extra values to be assigned. For purpose of
750 description, we call these values the NEMO-Forward, NEMO-No-Forward,
751 and NEMO-BU. Hereafter, mutable Router Alert Option with Value code
752 equal to NEMO- Forward will be known as a NEMO-Forward Router Alert
753 Option, or simply, NEMO-Fwd RAO; mutable Router Alert Option with
754 Value code equal to NEMO-No-Forward will be known as a
755 NEMO-No-Forward Router Alert Option, or simply, NEMO-NoFwd RAO; and
756 mutable Router Alert Option with Value code equal to NEMO-BU will be
757 known as a NEMO-BU Router Alert Option, or simply, NEMO-BU RAO.
759 Intermediate routers that support the ARO-Solution should recognize
760 the NEMO-Fwd RAO and attempt to forward the packet directly to the
761 destination without using a reverse tunnel. If necessary, the router
762 can change the source address of the packet to the current CoA of the
763 router in order to pass through ingress filters of subsequent
764 routers/gateways.
766 Intermediate routers that support the ARO-Solution should recognize
767 the NEMO-NoFwd RAO, and behave as if the RAO is not present.
768 Specifically, the router MUST NOT change the source address of the
769 packet.
771 Intermediate routers that support the ARO-Solution should recognize
772 the NEMO-BU RAO, and realize that the sender (indicated by the source
773 address), is attempting to discover the global address of its access
774 router. The ARO-enabled intermediate router should then change the
775 NEMO-BU RAO to a NEMO-NoFwd RAO before forwarding the packet. In
776 addition, it should send a Router Global Address ICMP message (see
777 Section 3.3.1) to the source of the packet containing the NEMO-BU
778 RAO. This allows the source to learn the HoA of the MR.
780 Section 8.1 discusses some of the design considerations that lead to
781 the use of a mutable Router Alert Option.
783 4. Operation of ARO-Enabled Mobile Routers
785 4.1 Operation When Mobile Router is At Home
787 This section describes the operation of a MR when it is attached to
788 its home link.
790 4.1.1 Sending Router Advertisement
792 When the MR sends RA message, it should advertise its HoA by adding a
793 RGAO in the RA message. This also indicates to the recipients that
794 the MR is ARO-enabled.
796 4.1.2 Processing Outbound Packets
798 When the MR intercepts an outbound packet from its ingress interface,
799 it first checks if the packet contains a NEMO-Fwd RAO or a NEMO-BU
800 RAO. Packets that do not contain a NEMO-Fwd RAO, or packets that
801 contain a NEMO-NoFwd RAO are simply forwarded to its egress
802 interface. For packet that contains a NEMO-Fwd RAO, since the MR is
803 at home, it changes the NEMO-Fwd RAO to a NEMO-NoFwd RAO and forwards
804 the packet to its egress interface.
806 If the packet contains a NEMO-BU RAO, it implies that the originator
807 of that packet is an ARO-enabled node trying to learn if there is an
808 ARO-enabled access router in its upstream. The MR should send to
809 this originator a Router Global Address ICMP message (see Section
810 3.3.1). In addition, the MR should change the NEMO-BU RAO to a
811 NEMO-NoFwd RAO, and forward the packet to its egress interface.
813 4.1.3 Processing Inbound Packets
815 When the MR is at home, it functions like a normal router. Thus it
816 will consume any packet that is addressed to its HoA, forward any
817 packet with a destination address that is a valid address in one of
818 its ingress interface (e.g. the destination address must contain the
819 same network prefix as one of the ingress interface), and discard any
820 packet with an invalid destination address.
822 When the packet is addressed to the MR's HoA, the packet may contain
823 an extended RH2. The Segments Left field of RH2 is checked. If
824 Segments Left field is 0, the packet is consumed. If Segments Left
825 field is non-zero, it is checked to be smaller or equal to the number
826 of addresses in the Type 2 Routing Header (which can be calculated by
827 dividing the Ext Hdr Len field by two). If Segments Left field is
828 bigger, the packet is discarded, and an ICMP error may be returned to
829 the sender. Else, the Segments Left field is decremented by one and
830 the destination address is swapped with the next entry in the
831 Address[] vector of the RH2.
833 The new destination address is then checked if it is a valid address
834 in one of the ingress interfaces of the MR. If yes, the packet is
835 forwarded to the new destination. Else, the packet is silently
836 discarded.
838 4.2 Operation When Mobile Router is Away
840 This section describes the operation of a MR when it is away from its
841 home link.
843 4.2.1 Sending Router Advertisement
845 The MR would continue to send RA messages to its ingress interface(s)
846 when it is away. It should behave as specified in Section 4.1.1.
847 There is no difference in the RA message whether the MR is at home or
848 away.
850 4.2.2 Receiving Router Advertisement
852 The MR should solicit RA from its access router whenever it changes
853 its point of attachment to the Internet. When the MR receives the
854 RA, it should check if the access router has included the RGAO in the
855 RA message. If an RGAO is present, the access router is ARO-enabled.
856 If no RGAO is present, the access router is not ARO-enabled.
858 4.2.3 Sending Binding Updates
860 When the MR sends BU to other hosts, either its own HA or other
861 correspondent nodes, it should add an ARO to the BU messages if its
862 access router is ARO-enabled. The ARO should contain the global
863 address of the access router it learned from the RGAO in the RA
864 message. Otherwise, if its access router is not ARO-enabled, the MR
865 will not include the ARO in the BU messages.
867 When sending BU with the ARO, especially to nodes that the MR does
868 not know to be ARO-enabled, the MR should request for a BA so that it
869 can determine if the recipient supports the ARO-Solution by checking
870 if the ARO is present in the BA message. If the ARO is present, the
871 node is ARO-enabled.
873 If the access router is not ARO-enabled, a MR may attempt to discover
874 if there are any ARO-enabled routers upstream by prepending a NEMO-BU
875 RAO to the BU message it sends out. If there exist an ARO-enabled
876 router upstream, the ARO-enabled router will send an ICMP message
877 containing the global address (eg HoA) of the ARO-enabled router.
878 For this case, the MR can send another BU message with an ARO
879 containing this global address.
881 If no response is received after a short timeout period, the MR
882 should concede that there is no ARO-enabled router upstream.
884 4.2.4 Processing Outbound Packets
886 When the MR received a packet from its ingress interface for outbound
887 forwarding, the behavior of the MR will be different depending on
888 whether the outbound packet contains a RAO or not.
890 1. Packet does not have any RAO
892 When the MR intercepts a packet from one of its ingress
893 interfaces, it first checks if there is a NEMO-Fwd RAO or NEMO-BU
894 RAO attached to the packet. When the NEMO-Fwd RAO is absent (or
895 a NEMO- NoFwd RAO is present), the MR has to route this packet
896 through its own HA. The packet is encapsulated in an outer
897 packet addressed to the HA of the mobile router. If the MR's
898 access router is not ARO-enabled, the outer packet is sent to the
899 MR's home agent. The outer packet has the normal mobility
900 characteristics, i.e. the source field contains the CoA of the
901 MR and the destination field contains the address of the HA of
902 the MR.
904 If the MR's access router is ARO-enabled, reverse tunneling is
905 still necessary. However, in this case, the mobile router will
906 add a NEMO-Fwd RAO to the outer packet. The outer packet is then
907 marked with source address set to the CoA of the MR, destination
908 address set to the address of the MR's HA. and attached with a
909 Home Address destination Option containing the HoA of the MR.
911 2. Packet has a NEMO-NoFwd RAO
913 Processing of an outbound packet with a NEMO-NoFwd RAO is
914 identical to that when the packet contains no RAO.
916 3. Packet has a NEMO-Fwd RAO
918 On the other hand, when the MR received a packet with a NEMO-Fwd
919 RAO from one of its ingress interfaces, the MR will then attempt
920 to forward the packet directly to the destination. To do so, the
921 MR has to check if it has a binding update with the specified
922 destination (by checking its Binding Update List). If it does
923 not have an active binding update with the specified destination,
924 the MR will have to tunnel the received packet to its HA using
925 reverse tunneling. In this case, the NEMO-Fwd RAO is changed to
926 a NEMO-NoFwd RAO, and the packet is processed as though it does
927 not contain a NEMO-Fwd RAO (as described previously).
929 The presence of a NEMO-Fwd RAO should suggest to the MR that it
930 could perform a Return Routability Procedure and BU with the
931 specified destination, so that subsequent packets from the same
932 source to the same destination need not go through the bi-
933 directional tunnel.
935 If the MR does have an active binding update with the specified
936 destination, the source address of the packet is changed to the
937 CoA of the MR. In addition, if the access router of the MR is
938 not ARO-enabled, the NEMO-Fwd RAO is changed to a NEMO-NoFwd RAO.
939 The packet is then forwarded through the egress interface of the
940 MR.
942 4. Packet has a NEMO-BU RAO
944 When the MR intercepts a packet from one of its ingress
945 interfaces with a NEMO-BU RAO, it implies that the originator of
946 that packet is an ARO-enabled node trying to learn if there is an
947 ARO-enabled access router in its upstream. The MR should send to
948 this originator a Router Global Address ICMP message (see Section
949 3.3.1). In addition, the MR should change the NEMO-BU RAO to a
950 NEMO-NoFwd RAO, and process the packet as though it does not
951 contain a NEMO-BU RAO (as described previously).
953 4.2.5 Processing Inbound Packets
955 When the MR received a packet from its egress interface, the MR
956 checks if the packet is addressed to itself. Packets not addressed
957 to its CoA or HoA are discarded. When the packet is addressed to its
958 CoA, the MR checks for the presence of type 2 routing header (RH2).
959 Packets without the RH2 are processed as per specified in [2]. If
960 the packet contains a RH2 and is addressed to its CoA, the packet
961 must be sent from a host that has a BCE of the MR. If security
962 measures warrant it, the MR may want to verify the sender is indeed a
963 node in the MR's Binding Update List, and discard the packet if it
964 isn't.
966 The Segments Left field of RH2 is then checked. If Segments Left
967 field is 0, the packet is discarded. If Segments Left field is non-
968 zero, it is checked to be smaller or equal to the number of addresses
969 in the RH2 (which can be calculated by dividing the Ext Hdr Len field
970 by two). If Segments Left field is bigger, the packet is discarded,
971 and an ICMP error may be returned to the sender. Else, the Segments
972 Left field is decremented by one and the destination address is
973 swapped with the next entry in the Address[] vector of the RH2.
975 If the new destination address is the HoA of the MR, the Segments
976 Left field is checked if it is 0 (after decrementing). If so, the
977 packet is consumed by the MR. Otherwise, the packet is silently
978 discarded.
980 Alternatively, the new destination address may be an address in one
981 of the MR's ingress interfaces. If yes, the packet is forwarded to
982 the new destination. Else, if the new destination field of the
983 packet is neither the HoA nor a valid address in one of the MR's
984 ingress interfaces, the packet is silently discarded.
986 When a packet is consumed by the MR, the payload may be an
987 encapsulated packet. In this case, sender of the outer packet must
988 be the HA of the MR, or a node in MR's Binding Update List.
989 Processing of the inner packet is the same as though the mobile
990 router is at home.
992 4.3 IPSec Processing
994 It is recommended that the MR uses IPSec protocols such as AH [9] or
995 ESP [10] to secure the reverse tunnel with its HA [13]. This section
996 highlights changes to the IPSec processing for inbound and outbound
997 packets.
999 4.3.1 IPSec Processing on Inbound Packets
1001 Inbound packets may contain a RH2 with an AH/ESP. The RH2 should be
1002 processed before AH. If the MR is the final destination, the packet
1003 is passed to the IPSec module for AH/ESP processing. Since the HA or
1004 CN will generate the AH/ESP in a such a way that it is consistent
1005 with the state of the packet headers when the receiver received the
1006 packet (see Section 5.4.2), no additional processing needs to be done
1007 before the AH/ESP processing.
1009 4.3.2 IPSec Processing on Outbound Packets
1011 For outbound packets, the new options added to the packets by the
1012 ARO-Solution are the NEMO-Fwd, NEMO-BU and NEMO-NoFwd Router Alert
1013 Options. For simplicity, it is best that all IPSec implementations
1014 ignore these options and treat their values as all zero when
1015 processing.
1017 5. Operation of ARO-Enabled Home Agents
1019 5.1 Receiving Binding Updates
1021 When a HA receives a BU message, it needs to check for the necessary
1022 security measures as specified in Mobile IPv6 specifications [1] or
1023 NEMO Basic Support [2]. The only change this ARO Solution requires
1024 is for the HA to add a field to its Binding Cache: access router's
1025 address. Every valid BU is checked for the Access Router Option
1026 field. If one is absent, the corresponding BCE will have the access
1027 router field invalidated. If one is present, the corresponding BCE
1028 will have the access router field updated.
1030 In addition, when returning a BA for a BU that contains an Access
1031 Router Option, the ARO-Solution requires that the HA return a the BA
1032 with the same Access Router Option if the binding is successful.
1033 Note also that the HA MUST accept BU with Access Router Option
1034 regardless of whether the Home Registration bit is set.
1036 5.2 Receiving Tunneled Packets from Away Nodes
1038 When the HA received a packet that contains an encapsulated packet,
1039 it may choose to perform certain security checks. The obvious check
1040 is to ensure that the source address is either a valid CoA of the HoA
1041 in its binding cache, or the source address is a valid CoA or HoA of
1042 an access router that is in the upstream of the mobile node with the
1043 specified HoA in the Home Address Destination option. Section 9.3
1044 discusses the security considerations on accepting tunnels with a
1045 source address that is not directly bound to the HoA specified in the
1046 Home Address destination option.
1048 To establish this, the HA can use the pseudo algorithm depicted in
1049 Figure 9. The algorithm returns TRUE if the source address in a
1050 valid address, and FALSE otherwise. When the algorithm returns TRUE,
1051 the source address is a valid address, and the packet is decapsulated
1052 and processed as normal. Should the algorithm evaluates to FALSE,
1053 the packet is discarded.
1055 set start-address = HoA in HAO
1056 while (TRUE) do
1057 {
1058 find an entry in Binding Cache with HoA field == start-address
1059 if (no BCE is found)
1060 {
1061 return (FALSE)
1062 }
1063 if (CoA field in the BCE
1064 == source-address of outer packet)
1065 {
1066 return (TRUE)
1067 }
1068 if (the BCE does not contain a valid access
1069 router address)
1070 {
1071 return (FALSE)
1072 }
1073 if (access router address field in the BCE
1074 == source-address of outer packet)
1075 {
1076 return (TRUE)
1077 }
1078 set start-address = access router address field in the BCE
1079 }
1081 Figure 9: Algorithm to check source address is valid
1083 5.3 Tunneling Packets to Away Nodes
1085 When the HA intercepted a packet addressed to a node in its home
1086 domain, it checks the next hop to forward the packet from its routing
1087 table. This sub-section describes the operation of the HA when the
1088 next hop is away, i.e. the next hop is a mobile node, and the mobile
1089 node is away from home.
1091 In this case, the HA will forward the packet to the mobile node at
1092 the CoA of the mobile node. This is done by encapsulating the
1093 intercepted packet into a new packet. According to standard MIPv6
1094 specification [1], the packet will have the source address set to the
1095 address of the HA, destination set to the CoA of the mobile router,
1096 and a RH2 with only one address entry equals to the HoA of the mobile
1097 node.
1099 This ARO-Solution extends the RH2 to include addresses of access
1100 routers, and the pseudo algorithm depicted in Figure 10 can be used
1101 to construct such a routing header. In Figure 10, src-address and
1102 dst-address are the abbreviations for the source address and
1103 destination address fields of the outer packet respectively.
1105 initialize an empty stack
1106 set src-address = address of home agent
1107 set dst-address = HoA of mobile node
1108 set Finished = FALSE
1109 while (not Finished)
1110 {
1111 find BCE with HoA field = dst-address
1112 if (no BCE is found)
1113 {
1114 Finished = TRUE
1115 }
1116 else
1117 {
1118 if (dst-address == HoA of mobile node)
1119 {
1120 push dst-address to stack
1121 }
1122 set dst-address = CoA field of the found BCE
1123 if (the found BCE contains a valid access router address)
1124 {
1125 push dst-address to stack
1126 set dst-address = access router address field of BCE found
1127 }
1128 else
1129 {
1130 Finished = TRUE
1131 }
1132 }
1133 }
1134 if (stack is not empty)
1135 {
1136 prepare a type 2 routing header
1137 set Hdr Ext Len field of RH2 = (size of stack) x 2
1138 set Segments Left field of RH2 = size of stack
1139 for n=1 to (Segments Left field of RH2)
1140 {
1141 pop top of stack to Address[n] of RH2
1142 }
1143 }
1145 Figure 10: Algorithm to construct extended RH2
1147 The outer packet is then sent to the destination. If secure tunnel
1148 is used, the IPSec protocol used must be able to recognize that the
1149 RH2 is a mutable but predictable header, such that the two end-points
1150 use the same routing header and IPv6 destination field for IPSec
1151 processing. Particularly, the sender should calculate the IPSec
1152 parameters using values in the IPv6 headers that the receiver will
1153 receive.
1155 5.4 IPSec Processing
1157 It is recommended that the HA uses IPSec protocols such as AH [9] or
1158 ESP [10] to protect the tunnel with a mobile node [13]. This section
1159 highlights changes to the IPSec processing for inbound and outbound
1160 packets.
1162 5.4.1 IPSec Processing on Inbound Packets
1164 Packets that are inbound may have their source address modified en-
1165 route by access routers. Thus, all home-agents SHOULD use the
1166 algorithm shown in Figure 9 to establish the authenticity of the
1167 source address. Once the source address is verified, the source
1168 address field will be replaced by the HoA specified in the Home
1169 Address Destination option, and the Home Address field of the Home
1170 Address Destination option MUST be replaced with the CoA of the
1171 sender. In MIPv6, this CoA can be obtained from the source address
1172 field in the packet. However, the ARO-Solution allows intermediate
1173 mobile routers to modify the source address field. Thus, the home
1174 agent MUST obtain the CoA from its BCE.
1176 The above processing MUST be carried out before AH processing.
1178 5.4.2 IPSec Processing on Outbound Packets
1180 Outbound packets may contain an extended RH2. The extended RH2 is a
1181 mutable but predictable header. According to the usual norm of
1182 generating AH authentication data, the HA must order the contents of
1183 the RH2 as it will appear at the final destination when generating
1184 the AH authentication data.
1186 6. Operation of ARO-Enabled Mobile Network Nodes
1188 The operation of an ARO-enabled MNN is very similar to that of a MR.
1189 When the MNN is at home, there is no additional operation
1190 requirements imposed by the ARO Solution (i.e. the ARO-enabled MNN
1191 operation is similar to a normal MNN when it is at home). This
1192 section described the operation of MNN when it is away (i.e. it is a
1193 VMN).
1195 6.1 Nested Tunnel Optimization with Home Agent
1197 In this case, the MNN is VMN using MIPv6 bi-direction tunneling with
1198 its HA. If it is ARO-enabled, and its HA is also ARO-enabled, then
1199 the number of nested tunnel can be reduced to one.
1201 The MNN basically follows the same procedure as an ARO-enabled MR.
1202 It needs to detect the RGAO in the RA messages broadcasted by its
1203 access router to determine if its access router is ARO-enabled. When
1204 sending BU message to its HA, the MNN will insert an ARO to the BU
1205 message containing the home-address of its access router.
1207 After the binding is successful, the MNN can then attached a NEMO-Fwd
1208 RAO in the tunnel packets sent to its HA. Note that when doing so,
1209 the MNN needs to attach a Home Address Destination Option in the
1210 tunnel packet.
1212 6.2 Receiving Router Advertisement
1214 The MNN should solicit RA from its access router whenever it changes
1215 its point of attachment to the Internet. When the MNN receives the
1216 RA, it should check if the access router has included the RGAO in the
1217 RA message. If an RGAO is present, the access router is ARO-enabled.
1218 If no RGAO is present, the access router is not ARO-enabled.
1220 6.3 Sending Binding Updates
1222 When the MNN sends BU to other hosts, either its own HA or other
1223 correspondent nodes, it should add an ARO to the BU messages if its
1224 access router is ARO-enabled. The ARO should contain the global
1225 address of the access router it learned from the RGAO in the RA
1226 message. Otherwise, if its access router is not ARO-enabled, the MNN
1227 will not include the ARO in the BU messages.
1229 When sending BU with the ARO, especially to nodes that the MNN does
1230 not know to be ARO-enabled, the MNN should request for a BA so that
1231 it can determine if the recipient supports the ARO-Solution by
1232 checking if the ARO is present in the BA message. If the ARO is
1233 present, the node is ARO-enabled.
1235 If the access router is not ARO-enabled, a MNN may attempt to
1236 discover if there are any ARO-enabled routers upstream by prepending
1237 a NEMO-BU RAO to the BU message it sends out. If there exist an
1238 ARO-enabled router upstream, the ARO-enabled router will send an ICMP
1239 message containing the global address of the ARO-enabled router. For
1240 this case, the MNN can send another BU message with an ARO containing
1241 this global address.
1243 If no response is received after a short timeout period, the MNN
1244 should concede that there is no ARO-enabled router upstream.
1246 6.4 Sending Data Packets
1248 When the MNN is tunneling data packets to its HA, the MNN can add a
1249 NEMO-Fwd RAO to the tunnel packet (i.e. outer packet) if (1) its HA
1250 is ARO-enabled, and (2) its access router is ARO-enabled. Otherwise,
1251 the MNN should use the normal MIPv6 bi-directional tunneling to
1252 forward the data packet to its HA. When adding the NEMO-Fwd RAO, the
1253 MNN should also include a Home Address Destination Option in the
1254 tunnel packet.
1256 When the MNN knows (by other means) that the CN it is communicating
1257 with is ARO-enabled, the MNN can choose to employ full route
1258 optimization with the CN. This is done by adding a NEMO-Fwd RAO to
1259 the data packet. Note that the MNN should also include a Home
1260 Address Destination Option in the data packet.
1262 6.5 Processing Inbound Packets
1264 When the MNN received a packet from its egress interface, the MNN
1265 checks if the packet is addressed to itself. Packets not addressed
1266 to its CoA or HoA are discarded. When the packet is addressed to its
1267 CoA, the MNN checks for the presence of type 2 routing header (RH2).
1268 Packets without the RH2 are processed as per specified in [2]. If
1269 the packet contains a RH2 and is addressed to its CoA, the packet
1270 must be sent from a host that has a BCE of the MNN. If security
1271 measures warrant it, the MR may want to verify the sender is indeed a
1272 node in the MR's Binding Update List, and discard the packet if it
1273 isn't.
1275 The Segments Left field of RH2 is then checked. If Segments Left
1276 field is 0, the packet is discarded. If Segments Left field is non-
1277 zero, it is checked to be smaller or equal to the number of addresses
1278 in the RH2 (which can be calculated by dividing the Ext Hdr Len field
1279 by two). If Segments Left field is bigger, the packet is discarded,
1280 and an ICMP error may be returned to the sender. Else, the Segments
1281 Left field is decremented by one and the destination address is
1282 swapped with the next entry in the Address[] vector of the RH2.
1284 Being a host, the MNN must be the final destination of the packet.
1285 Thus, if the new destination address is not the HoA of MNN, or the
1286 Segments Left field is non-zero after decrementing, the packet is
1287 silently discarded. Else if the new destination address is the HoA
1288 of MNN, and the Segments Left field is zero after decrementing the
1289 packet is consumed.
1291 When a packet is consumed by the MNN, the payload may be an
1292 encapsulated packet. In this case, sender of the outer packet must
1293 be the HA of the MNN. Processing of the inner packet is the same as
1294 though the MNN is at home.
1296 6.6 IPSec Processing
1298 6.6.1 IPSec Processing on Inbound Packets
1300 Inbound packets may contain a RH2 with an AH/ESP. The routing header
1301 should be processed before AH. If the MNN is the final destination,
1302 the packet is passed to the IPSec module for AH/ESP processing.
1303 Since the HA or CN will generate the AH/ESP in a such a way that it
1304 is consistent with the state of the packet headers when the receiver
1305 received the packet (see Section 5.4.2), no additional processing
1306 needs to be done before the AH/ESP processing.
1308 6.6.2 IPSec Processing on Outbound Packets
1310 For outbound packets, the new options added to the packets by the
1311 ARO-Solution are the NEMO-Fwd, NEMO-BU and NEMO-NoFwd Router Alert
1312 Options. For simplicity, it is best that all IPSec implementations
1313 ignore these options and treat their values as all zero when
1314 processing.
1316 7. Operation of ARO-Enabled Correspondent Node
1318 7.1 Receiving Binding Updates
1320 When a CN receives a BU message, it needs to check for the necessary
1321 security measures as specified in Mobile IPv6 specifications [1] or
1322 NEMO Basic Support [2]. The only change this ARO Solution requires
1323 is for the CN to add a field to its Binding Cache: access router's
1324 address. Every valid BU is checked for the Access Router Option
1325 field. If one is absent, the corresponding BCE will have the access
1326 router field invalidated. If one is present, the corresponding BCE
1327 will have the access router field updated.
1329 In addition, when returning a BA for a BU that contains an Access
1330 Router Option, the ARO-Solution requires that the CN returns a the BA
1331 with the same Access Router Option if the binding is successful.
1332 Note that a BU sent to the CN MUST be preceded with a return
1333 routability procedure. Section 9.1 discusses possibility of
1334 extending the return routability procedure to protect the Access
1335 Router Option.
1337 7.2 Receiving Route Optimized Packets from Mobile Nodes
1339 When the CN received a packet that contains a Home Address
1340 Destination Option, it will have to perform certain security checks
1341 to ensure that the source address is either a valid CoA of the HoA in
1342 its binding cache, or the source address is a valid CoA or HoA of an
1343 access router that is in the upstream of the mobile node with the
1344 specified HoA in the Home Address Destination option. Section 9.3
1345 discusses the security considerations on accepting tunnels with a
1346 source address that is not directly bound to the HoA specified in the
1347 Home Address destination option.
1349 To establish this, the CN can use the pseudo algorithm depicted in
1350 Figure 9 shown in Section 5.2. The algorithm returns TRUE if the
1351 source address in a valid address, and FALSE otherwise. When the
1352 algorithm returns TRUE, the source address is a valid address, and
1353 the source address is replaced with the HoA contained in the Home
1354 Address Destination Option and processed as normal. Should the
1355 algorithm evaluates to FALSE, the packet is silently discarded.
1357 7.3 Sending Route Optimized Packets to Mobile Nodes
1359 When the CN sends a packet, it should check if the destination
1360 address is in its BCE. If the destination is not in the BCE, then
1361 the packet is sent as per normal IPv6 operation. If the destination
1362 is in its BCE, normal MIPv6 will require that the source address be
1363 set to the address of the CN, destination set to the CoA of the MR,
1364 and a RH2 with only one address entry equals to the HoA of the mobile
1365 node.
1367 This ARO-Solution extends the RH2 to include addresses of access
1368 routers, and the pseudo algorithm depicted in Figure 10 shown in
1369 Section 5.3 can be used to construct such a routing header. In
1370 Figure 10, src-address and dst-address are the abbreviations for the
1371 source address and destination address fields of the outer packet
1372 respectively.
1374 If IPSec protocol is used to protect the packet, the IPSec protocol
1375 used must be able to recognize that the RH2 is a mutable but
1376 predictable header, such that the two end-points use the same routing
1377 header and IPv6 destination field for IPSec processing.
1378 Particularly, the sender should calculate the IPSec parameters using
1379 values in the IPv6 headers that the receiver will receive.
1381 7.4 IPSec Processing
1383 7.4.1 IPSec Processing on Inbound Packets
1385 Packets that are inbound may have their source address modified en-
1386 route by access routers. Thus, all ARO-enabled correspondent nodes
1387 SHOULD use the algorithm depicted in Figure 9 shown in Section 5.2 to
1388 establish the authenticity of the source address. Once the source
1389 address is verified, the source address field will be replaced by the
1390 HoA specified in the Home Address Destination option, and the Home
1391 Address field of the Home Address Destination option MUST be replaced
1392 with the CoA of the sender. In MIPv6, this CoA can be obtained from
1393 the source address field in the packet. However, the ARO-Solution
1394 allows intermediate mobile routers to modify the source address
1395 field. Thus, the CN MUST obtain the CoA from its BCE.
1397 The above processing MUST be carried out before AH processing.
1399 7.4.2 IPSec Processing on Outbound Packets
1401 Outbound packets may contain an extended RH2. The extended RH2 is a
1402 mutable but predictable header. According to the usual norm of
1403 generating AH authentication data, the CN must order the contents of
1404 the RH2 as it will appear at the final destination when generating
1405 the AH authentication data.
1407 8. Design Considerations
1409 This section describes the rational behind some design decision made
1410 in the formulation of the ARO Solution. Some justifications are
1411 given, and in some cases, alternative approaches are discussed.
1413 8.1 Considerations in the Use of Mutable Router Alert Option
1415 8.1.1 Overview of Router Alert Option
1417 The ARO Solution described in this memo is designed so that it will
1418 work in a nested NEMO where some mobile routers are ARO-enabled and
1419 some are not. Thus, some form of indications on a packet is
1420 necessary to inform upstream mobile routers to attempt to use the ARO
1421 Solution. Since the indication is meant for intermediate routers, a
1422 hop-by-hop option is needed.
1424 The Router Alert Option [6] lends itself readily for use. By
1425 assigning a value in RAO, a ARO-enabled mobile router can request its
1426 access router to attempt to forward the packet directly to the
1427 destination without using reverse tunnel. However, further analysis
1428 reveals that there is a need for a mobile router that is not attached
1429 to a ARO-enabled access router to disable this behavior.
1431 8.1.2 Example where an Immutable RAO is Used
1433 To understand why a MR that is not attached to a ARO- enabled access
1434 router should disable the NEMO-Fwd RAO, consider the following
1435 scenario, where MR1, MR2, and MR4 are ARO-enabled mobile routers,
1436 LFR3 is a non-ARO-enabled local fixed router attached to MR4, and HA1
1437 is the home agent of MR1.
1439 MR1---MR2---LFR3---MR4---[Internet]---HA1
1441 Suppose both MR1 and MR2 have performed binding updates successfully
1442 with HA1, thus the state of the Binding Cache of HA1 will be:
1444 Home-Address Care-of-Address Access Router
1445 ------------ --------------- -------------
1446 MR1.HoA MR1.CoA MR2.HoA
1447 MR2.HoA MR2.CoA
1449 When MR1 encapsulates a packet to be tunneled to HA1, MR1 adds a
1450 NEMO-Fwd RAO in the outer packet (since MR2, the access router of
1451 MR1, is ARO-enabled). Thus the packet from MR1 to MR2 will contains
1452 the following contents:
1454 IPv6 Hdr (src=MR1.CoA, dst=HA1)
1455 Hop-by-Hop Opt
1456 RAO (NEMO-Fwd)
1457 Dest Opt
1458 HAO (MR1.HoA)
1460 Since MR2 has already performed a binding update with HA1, it changes
1461 the source address and forwards the packet to LFR3. LFR3 is a fixed
1462 router, thus it simply forwards the packet to MR4. At MR4, the
1463 packet contents is then:
1465 IPv6 Hdr (src=MR2.CoA, dst=HA1)
1466 Hop-by-Hop Opt
1467 RAO (NEMO-Fwd)
1468 Dest Opt
1469 HAO (MR1.HoA)
1471 When MR4 intercepts this packet, the presence of the NEMO-Fwd RAO
1472 will cause MR4 to start a binding update with HA1, and tunnels the
1473 packet to its home agent. From the home agent of MR4, the packet is
1474 forwarded to HA1.
1476 Suppose now HA1 accepts the binding update with MR4, and its Binding
1477 Cache is thus as follows:
1479 Home-Address Care-of-Address Access Router
1480 ------------ --------------- -------------
1481 MR1.HoA MR1.CoA MR2.HoA
1482 MR2.HoA MR2.CoA
1483 MR4.HoA MR4.HoA
1485 Now, when MR1 sends a tunnel packet to HA1 again, the packet will
1486 arrive at MR4 with the following contents:
1488 IPv6 Hdr (src=MR2.CoA, dst=HA1)
1489 Hop-by-Hop Opt
1490 RAO (NEMO-Fwd)
1491 Dest Opt
1492 HAO (MR1.HoA)
1494 This time, MR4 checks that HA1 is on its Binding Update List, thus it
1495 will change the source address of the packet to its CoA and forward
1496 the packet to HA1 through the Internet. When HA1 receives the
1497 packet, the contents will be:
1499 IPv6 Hdr (src=MR4.CoA, dst=HA1)
1500 Hop-by-Hop Opt
1501 RAO (NEMO-Fwd)
1503 Dest Opt
1504 HAO (MR1.HoA)
1506 Because the Access Router field of the BCE for MR2 is marked invalid,
1507 the algorithm for checking the validity of the source address as
1508 shown in Figure 9 of Section 5.2 will fail. Thus the packet will be
1509 discarded at HA1.
1511 8.1.3 The Need for Mutable RAO
1513 The example in the previous section shows that the presence of a
1514 local fixed router (LFR) that is not ARO-enabled may cause an
1515 unintentional denial-of-service to mobile routers that are attached
1516 to the LFR.
1518 To avoid this problem, MR4 must somehow realize that it should ignore
1519 the NEMO-Fwd RAO in a packet forwarded by MR2. One method is to
1520 check that the source address is a valid source address in the
1521 ingress interface of MR4. However, MR2 might obtain a CoA that
1522 contains a prefix that is valid in the ingress interface of MR4.
1523 Thus checking source address does not completely eliminate the
1524 problem.
1526 If MR2 can somehow invalidate the NEMO-Fwd RAO, the problem can be
1527 eliminated. But the Router Alert Option as defined in [6] is an
1528 immutable hop-by-hop option, so what is needed here is a mutable
1529 router alert option.
1531 8.1.4 Alternatives to the Mutable Router Alert Option
1533 There are other alternatives to the mutable Router Alert Option.
1534 These include using the Flow label in IPv6 header, and defining a new
1535 routing header type. These are briefly described below.
1537 o IPv6 Flow Label
1539 It is possible to use the IPv6 Flow label to achieve the same
1540 effects as the mutable Router Alert Option. A specific, universal
1541 Flow label can be reserved to indicate to NEMO-enabled routers
1542 that they should try to forward the packets directly to their
1543 destination (instead of using a reverse tunnel with home agents).
1545 This approach eliminates the need of defining a new hop-by-hop
1546 header option. However, this means that a specific flow label has
1547 to be reserved, which may be in contention with currently deployed
1548 IPv6 nodes. In addition, this will mean that NEMO-enabled mobile
1549 routers are unable to use Flow label for other purposes.
1551 o New Routing Header Type
1553 A new routing header type can be defined to store the address of
1554 the final destination. When such a routing header is used, the
1555 originator will place the address of the final destination in the
1556 routing header, and place the home-address of the access router of
1557 the originator in the destination (when the access router is NEMO-
1558 enabled). When a NEMO-enabled mobile router that is not attached
1559 to a NEMO-enabled access router receives a packet with this type
1560 of routing header, it will overwrite the destination address of
1561 the packet with the final destination specified in the routing
1562 header, and decrement the Segments Left field. When a
1563 NEMO-enabled mobile router that is attached to a NEMO-enabled
1564 access router receives a packet with this type of routing header,
1565 it will overwrite the destination address of this packet with the
1566 home-address of its access router and the leave the contents of
1567 the routing header untouched.
1569 There remain issues that are unclear when this new type of routing
1570 header is used with other routing headers. Also, the security
1571 implication of defining a new type of routing header is yet to be
1572 explored.
1574 o Discarding Immutable RAO
1576 Another possibility is to use the normal immutable RAO and instead
1577 allow routers en-route to simply discard the RAO (instead of
1578 changing it to a NEMO-NoFwd RAO). This will work exactly the
1579 same, and is both applicable to NEMO-Fwd and NEMO-BU RAO. It will
1580 in fact reduce processing delay when the RAO is only option in the
1581 hop-by-hop header. Since this will cause the hop-by-hop header to
1582 be removed, and en-route router need not process the hop-by-hop
1583 header and only to find that it contains a NEMO-NoFwd RAO which
1584 requires no processing.
1586 8.2 Change of Source Address
1588 This memo proposed to allow intermediate routers to change the source
1589 address of a packet en-route. It is expected that this will cause
1590 some disturbances, as it is generally not allowed for routers to
1591 change the source address. We hope to justify our design decision in
1592 this section, and discuss some alternatives.
1594 8.2.1 Justifications
1596 The main factor in consideration to changing the source address en-
1597 route is to overcome ingress filtering. In order for a packet to be
1598 able to pass through an ingress filter, the source address must be
1599 topologically compatible with where the packet is originated. Thus,
1600 to overcome ingress filtering, the source address must somehow be
1601 changed. We view the change of source address as somewhat akin to
1602 the use of a CoA as the packet source address in MIPv6.
1604 For the case of MIPv6, mobile nodes use the CoA to overcome ingress
1605 filtering, and use the BU mechanism and Home Address Destination
1606 Option to allow receivers to establish a relationship between the
1607 source address (i.e. CoA) and the HoA. In the ARO Solution,
1608 receivers can use the algorithm depicted in Figure 9 of Section 5.2
1609 to establish a similar relationship between the source address (in
1610 this case, the CoA/HoA of an upstream access router) and the HoA.
1612 8.2.2 Alternatives
1614 There are alternatives to changing source address for the purpose of
1615 overcoming ingress filters. One method is to use packet
1616 encapsulation to achieve the same effect as changing of source
1617 address (since the outer packet has a different source address).
1618 Currently, evaluating such a scheme is in progress.
1620 9. Security Considerations
1622 This proposal introduces several modifications to existing protocols.
1623 In this section, we will discuss additional security issues that
1624 arise due to these modifications.
1626 9.1 Addition of Access Router Option
1628 Access Router Option is introduced so that a recipient can establish
1629 a credible link between the global address of the access router
1630 specified, and the HoA of the mobile node that sends the Access
1631 Router Option.
1633 When a mobile node sends BU to its HA, current MIPv6 draft specifies
1634 that the BU should be secured (either by ESP or AH). For this case,
1635 the introduction of Access Router Option does not introduce new
1636 security threats.
1638 When sending BU to CN, the mobile node inserts the Access Router
1639 Option only when sending the actual BU message. The BU message is
1640 protected using a key generated after obtaining the Care-of-Test
1641 (CoT) and Home-Test (HoT) messages, so the Access Router Option
1642 should be relatively secure. However, there exist the slight
1643 possibility of an attacker snooping on both the CoT and HoT messages,
1644 thus allowing the attacker to generate the key independently. The
1645 attacker can then proceed to change the values in the Access Router
1646 Option and change the Authenticator value of the BU message using the
1647 generated key, thus leading the correspondent node to believe that
1648 the mobile node is attached to another access router.
1650 To overcome this, the mobile node may insert the Access Router Option
1651 when sending the CoT Init Message. The ARO-enabled CN, should then
1652 generate the care-of cookie using
1654 Care-of cookie = First64(MAC_Kcn(CoA | access router address |
1655 nonce))
1657 instead of using only the CoA and nonce. In this way, the global
1658 address of the access router in the Access Router Option is protected
1659 the same way the CoA is protected.
1661 Note that if the CN does not recognize the Access Router Option, it
1662 will not use the access router address to generate the
1663 care-of-cookie. However, we do not require the mobile node to change
1664 the way the Authenticator value is generated, i.e. the value is
1665 generated using the method as specified in MIPv6 [1]:
1667 Kbu = Hash(home cookie | care-of cookie)
1668 Authenticator = MAC_Kbu(CoA | CN address | BU)
1670 So, the BU will be verified to be authentic by the CN regardless of
1671 how the care-of cookie is generated, provided the generation of
1672 care-of cookie is consistent. The mobile node must still request for
1673 BA so that it if the CN has accepted the Access Router Option.
1675 9.2 Router Global Address Option
1677 The introduction of global address of the access router in the BU
1678 message is the crux of the ARO Solution, since this is the link which
1679 allows HA and CN to set up the RH2 and to accept packets from
1680 otherwise unknown sources. From previous discussion, the global
1681 address of the access router is fairly secure since
1683 o BU sent by an away node to its home agent that contains the access
1684 router's global address is secure, and
1686 o BU sent to CN are reasonably protected using the Return
1687 Routability Procedure.
1689 The weakest link is now the method in which the mobile node learns
1690 the global address of the access router it attaches to. The method
1691 proposed in this memo is to use the Router Advertisement. Two
1692 possible security threats are identified here:
1694 1. a malicious access router advertising false global address in the
1695 RA messages it broadcasts, and
1697 2. an attacker replays a RA message from a legitimate access router,
1698 but changes the global address contained in the Router Global
1699 Address Option to a false entry.
1701 The severity of the two threats is yet to be fully analyzed. We do
1702 provide our initial analysis here to invite further discussion. For
1703 the first case, advertising a false global address is believed to be
1704 one of least harm a malicious access router could do. There are
1705 other far more potent threats faced by the mobile router when it
1706 attaches itself to a malicious access router. For the second case
1707 where an attacker replays a modified RA, we believed that the threat
1708 existed in IPv6 Neighbor Discovery [11]. In [11], security issues
1709 pertaining to RA are discussed. This discussion should be able to
1710 shed some light on how to advert such an attack.
1712 9.3 Accepting Tunnel with a Source Address not Directly Bound to the
1713 Home Address
1715 MIPv6 forbids home agent from accepting tunnels with a source address
1716 that is not bound to the HoA specified in a Home Address Option.
1717 This proposal relaxed this security measure. The home agent should
1718 now admit tunnels from a source address that is "indirectly" bound
1719 (through the linkage of access router field in the binding cache) to
1720 the home-address specified in the Home Address Option. The algorithm
1721 presented in Figure 9 of Section 5.2 can be used to verify if the
1722 source address is "indirectly" bound to the HoA specified in the Home
1723 Address Option.
1725 As considered above in Section 8.2, the Access Router Option is
1726 secured by the fact that a BU to the HA is always secure. In
1727 addition, the Access Router Option is fairly secured with the Return
1728 Routability Procedure. Thus the relaxation of the security measure
1729 of source address verification of a tunnel does not significantly
1730 increase the HA's vulnerability to attacks. It is also recommended
1731 that the tunnel between the mobile node and the home agent to be
1732 secured by ESP or AH. In addition, we also recommend that all
1733 implementations to allow the support of this ARO Solution to be
1734 administratively disabled or enabled. The default should be enabled.
1736 9.4 Use of Extended Routing Header Type 2
1738 The extension of the RH2 exposes this solution to additional security
1739 threats in that attackers can change the entries in the RH2 to be
1740 routed to another entity. However, we note that this extension is
1741 designed so that the extended RH2 is now very similar to the Type 0
1742 Routing Header. Thus, the security threats faced by RH2 is not a new
1743 threat introduced by this solution itself. In any case, the harm an
1744 attacker can do by changing the entries in the routing header is
1745 limited to:
1747 o causing the packet to be routed to another entity for snooping
1748 into the contents of the payloads;
1750 o denial-of-service attack causing the packet to be discarded by
1751 intermediate routers; and
1753 o using the RH2 to reflect packets off a mobile network.
1755 In the first two cases, given that the attacker has the ability to
1756 change the contents in the routing header, it can perform the same
1757 attack even if a RH2 is not used. For the threat where attacker
1758 construct a RH2 to reflect packets off a mobile network, we recommend
1759 that all routers supporting the RH2 to perform the following security
1760 measures:
1762 o When the mobile node receives a packet with the destination field
1763 set to its HoA or CoA, it should check for the existence of a RH2.
1765 Any packet that is sent to the mobile node's CoA without a RH2
1766 should be discarded.
1768 o If the Segment Left field has a value of 1, the last address in
1769 the routing header must contain the HoA of the mobile node.
1771 o If the Segment Left field has a value greater than 1, the new
1772 destination address must contain a valid address in one of the
1773 mobile router's ingress links. If the mobile node is a mobile
1774 host, the packet should be discarded.
1776 Effectively, the above security checks ensure the mobile node will
1777 discard any packets it received with a RH2 that requires it to
1778 forward the packet through an egress link. This should reduce, if
1779 not eliminate, the possibility of using the extended RH2 for
1780 reflection attacks.
1782 In addition, it must be noted that the extended RH2 is mutable but
1783 predictable. Thus, it can be protected using AH.
1785 9.5 Mutable Router Alert Option
1787 The mutable Router Alert Option is used in this memo to request/stop
1788 subsequent routers to attempt to forward the packet directly to its
1789 destination. Possible security threats identified are:
1791 The attacker can add a NEMO-Fwd RAO to a packet. This will cause
1792 subsequent mobile routers to perform BU with the destination.
1793 When BU is successful, subsequent mobile routers will forward the
1794 packets directly to the destination, causing the packet to be
1795 discarded (due to failure of algorithm in Figure 9).
1797 The attacker can add a NEMO-NoFwd RAO to a packet. This has no
1798 effect, since the default behavior of processing a packet with
1799 NEMO-NoFwd RAO at a mobile router is the same as the default
1800 behavior of processing a packet without any RAO.
1802 The attacker can change the value of the NEMO-Fwd RAO to a NEMO-
1803 NoFwd RAO. The effect of this form of attack is to cause the
1804 packet to be delivered sub-optimally (i.e. nested tunnels).
1806 The attacker can change the value of the NEMO-NoFwd RAO to a
1807 NEMO-Fwd RAO. The effect of this form of attack is to cause
1808 subsequent mobile routers to perform BU with the destination.
1809 When BU is successful, subsequent mobile routers will forward the
1810 packets directly to the destination, causing the packet to be
1811 discarded (due to failure of algorithm in Figure 9).
1813 All the security threats described above require the attacker to be
1814 on the path of the packet route. In addition, the most severe effect
1815 the attacker can achieve is causing packets to be discarded at the
1816 receiver. Since the attacker must be on the path of the packet
1817 route, the attacker can achieve the same effect by simply discarding
1818 the intercepted packet. Thus, the use of mutable router alert option
1819 described in this memo does not introduce any new security threats.
1821 9.6 IPSec Processing
1823 9.6.1 Processing of Extended Routing Header Type 2
1825 As covered in Section 5.4.2, the extended RH2 is a mutable but
1826 predictable header, thus the sender must ordered the fields in the
1827 RH2 (and the destination address of the IPv6 header) as they will
1828 appear at the final destination when generating the AH authentication
1829 header.
1831 9.6.2 Processing of Home Address Destination Option
1833 As specified in MIPv6, the originator should use its HoA as the IPv6
1834 source address in the IPv6 header, and place its CoA in the Home
1835 Address field of the Home Address destination option, when generating
1836 the AH authentication data.
1838 The ARO Solution allows mobile routers to modify the source address
1839 of the IPv6 Header, thus when the source address field may no longer
1840 contain the CoA of the sender at the final destination.
1842 All home agents MUST use the algorithm shown in Figure 9 of Section
1843 5.2 to establish the authenticity of the source address. Once the
1844 source address is verified, the source address field will be replaced
1845 by the HoA specified in the Home Address destination option, and the
1846 Home Address field of the Home Address destination option will be
1847 replaced with the CoA of the sender. This CoA is obtained from the
1848 receiver's BCE.
1850 The above processing MUST be carried out before AH processing.
1852 9.6.3 Processing of Mutable Router Alert Option
1854 As described in Section 4.3.2, when the sender of a packet inserts a
1855 NEMO-Fwd RAO or NEMO-BU RAO to the packet, the receiver always
1856 received the RAO modified to NEMO-NoFwd. Thus the mutable NEMO-Fwd
1857 RAO is predictable. It is thus possible for the originator to use
1858 NEMO-NoFwd RAO to generate the AH authentication data. However, it
1859 is recommended that the RAO simply be left out of any IPSec
1860 processing.
1862 10 References
1864 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
1865 IPv6", RFC 3775, June 2004.
1867 [2] Devarapalli, V., "Network Mobility (NEMO) Basic Support
1868 Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
1869 June 2004.
1871 [3] Ernst, T., "Network Mobility Support Goals and Requirements",
1872 draft-ietf-nemo-requirements-02 (work in progress), February
1873 2004.
1875 [4] Thubert, P., Molteni, M. and C. Ng, "Taxonomy of Route
1876 Optimization models in the Nemo Context",
1877 draft-thubert-nemo-ro-taxonomy-02 (work in progress), February
1878 2004.
1880 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
1881 draft-ietf-nemo-terminology-01 (work in progress), February
1882 2004.
1884 [6] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC
1885 2711, October 1999.
1887 [7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
1888 Specification", RFC 2460, December 1998.
1890 [8] Kent, S. and R. Atkinson, "Security Architecture for the
1891 Internet Protocol", RFC 2401, November 1998.
1893 [9] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
1894 November 1998.
1896 [10] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
1897 (ESP)", RFC 2406, November 1998.
1899 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
1900 for IP Version 6 (IPv6)", RFC 2461, December 1998.
1902 [12] Conta, A. and S. Deering, "Internet Control Message Protocol
1903 (ICMPv6) for the Internet Protocol Version 6 (IPv6)
1904 Specification", RFC 2463, December 1998.
1906 [13] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
1907 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
1908 Agents", RFC 3776, June 2004.
1910 Authors' Addresses
1912 Chan-Wah Ng
1913 Panasonic Singapore Laboratories Pte Ltd
1914 Blk 1022 Tai Seng Ave #06-3530
1915 Tai Seng Industrial Estate
1916 Singapore 534415
1917 SG
1919 Phone: +65 65505420
1920 EMail: cwng@psl.com.sg
1922 Jun Hirano
1923 Matsushita Electric Industrial Co., Ltd. (Panasonic)
1924 5-3 Hikarino-oka
1925 Yokosuka, Kanagawa 239-0847
1926 JP
1928 Phone: +81 46 840 5123
1929 EMail: hirano.jun@jp.panasonic.com
1931 Appendix A. Acknowledgement
1933 The authors would like to express our sincere gratitude to Takeshi
1934 Tanaka for his contribution to the initial version of this draft. In
1935 addition, appreciation is also extended to Thierry Ernst, Pascal
1936 Thubert, and various people in the NEMO WG who have given us valuable
1937 comments.
1939 Intellectual Property Statement
1941 The IETF takes no position regarding the validity or scope of any
1942 Intellectual Property Rights or other rights that might be claimed to
1943 pertain to the implementation or use of the technology described in
1944 this document or the extent to which any license under such rights
1945 might or might not be available; nor does it represent that it has
1946 made any independent effort to identify any such rights. Information
1947 on the procedures with respect to rights in RFC documents can be
1948 found in BCP 78 and BCP 79.
1950 Copies of IPR disclosures made to the IETF Secretariat and any
1951 assurances of licenses to be made available, or the result of an
1952 attempt made to obtain a general license or permission for the use of
1953 such proprietary rights by implementers or users of this
1954 specification can be obtained from the IETF on-line IPR repository at
1955 http://www.ietf.org/ipr.
1957 The IETF invites any interested party to bring to its attention any
1958 copyrights, patents or patent applications, or other proprietary
1959 rights that may cover technology that may be required to implement
1960 this standard. Please address the information to the IETF at
1961 ietf-ipr@ietf.org.
1963 Disclaimer of Validity
1965 This document and the information contained herein are provided on an
1966 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1967 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1968 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1969 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1970 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1971 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1973 Copyright Statement
1975 Copyright (C) The Internet Society (2004). This document is subject
1976 to the rights, licenses and restrictions contained in BCP 78, and
1977 except as set forth therein, the authors retain all their rights.
1979 Acknowledgment
1981 Funding for the RFC Editor function is currently provided by the
1982 Internet Society.