wdiff draft-bajko-mip6-rrtfw-01.txt draft-bajko-mip6-rrtfw-02.txt

MIP6
Network Working Group Gabor G. Bajko
Internet Draft
Document: <draft-bajko-mip6-rrtfw-01.txt> October, 2006
Internet-Draft Nokia
Intended status: Standards Track H. Tschofenig
Expires: January 10, 2008 Nokia Siemens Networks
July 9, 2007

Firewall friendly RTT Return-Routability Test (RTT) for MIPv6 Mobile IPv6
draft-bajko-mip6-rrtfw-02.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 20, 2007. January 10, 2008.

1. IETF Trust (2007).

Abstract

Firewalls represent

This document defines a slightly modified Return Routability Test
(RRT) for MIPv6. The herein defined RRT mechanism is intended for
CoA exchanges between the MN and the CN. Once the MN and CN find out
their peers' valid addresses, an integral part additional mechanism will be used to
run connectivity checks to figure out which of the address pairs have
connectivity and, if needed, open the required pinholes in the
firewalls. The defined mechanism is intended to work with current
firewalls without requiring any support from them. The document also
addresses the use of UDP encapsulation to facilitate MIPv6 signaling
between involved nodes.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Return Routability Procedure . . . . . . . . . . . . . . . 4
4. UDP Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Problem Description . . . . . . . . . . . . . . . . . . . 5
4.2. UDP Encapsulation Procedures . . . . . . . . . . . . . . . 5
4.2.1. Procedures at the MN . . . . . . . . . . . . . . . . . 5
4.2.2. Procedures at the HA . . . . . . . . . . . . . . . . . 6
4.2.3. UDP encapsulated HoTI/HoT RRT messages . . . . . . . . 7
5. Enabling Route Optimization Through Firewalls . . . . . . . . 7
5.1. Problem Description . . . . . . . . . . . . . . . . . . . 7
5.2. New RTT Proposal . . . . . . . . . . . . . . . . . . . . . 9
5.3. Modified RRT Procedures . . . . . . . . . . . . . . . . . 10
5.3.1. Modified RRT Procedures at the MN . . . . . . . . . . 10
5.3.2. Modified RRT procedures at the CN . . . . . . . . . . 10
5.3.3. HA processing of CoTI-ICE and CoT-ICE . . . . . . . . 10
6. New Mobility Header Types . . . . . . . . . . . . . . . . . . 11
6.1. CoTI-ICE Message . . . . . . . . . . . . . . . . . . . . . 11
6.2. CoT-ICE Message . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14

1. Introduction

Most of today's IP networks,
currently networks are protected by state full firewalls
which filter the traffic based on IPv4 technology. Deployment the five tuple (sourceIP, destIP,
sourcePort, destPort). This filtering could be supplied to incoming
traffic or both incoming and outcoming. The problems which occure
when using MIPv6 in firewall protected networks are described in
detail in [RFC4487].

Most of IPv6 the MIPv6 signalling is, as defined in [RFC3775], is under way, secured
by IPSec ESP, and firewall vendors will need to deploy most of today's firewalls which will be drop ESP packets, as
there are no default rules defined for this traffic. So the mobile
node is not able to handle IPv6 packets, including its many extensions. Mobile
IPv6, standardized in RFC3775, specifies a number successfully complete the registration of extensions it's
CoA in the new network and
procedures to IPv6, which do will not work when firewalls are on be able to communicate with other
nodes.

If the data
communication path [1].

This document defines a slightly modified Return Routability Test
(RRT) for MIPv6 [2]. The new method the Binding Update (BU) with the home agent (HA) is firewall friendly finished,
and allows
a the mobile node wants to use route optimization, it will start
the Return Routability Procedure (RRT). For this it will send Binding Update a HoTI
and a CoTI message to its correspondent

1
Firewall friendly RTT for MIPv6
October 2006 the corresponend node (so that Route Optimization can (CN). The HoTI will be applied) and ensures that
send over the HA to the CN receives and the Binding Update, even when either CoTI message directly to the mobile
node, CN.
Normally the CN, HoTI and the corresponet HoT message will go through,
but the CoTI or both are located behind CoT message will mostly be dropped. So no route
optimization is available and all the traffic need to go over the HA.

This document will provide a solution that the MIPv6 signalling will
successfully complete. First a new return routability procedure will
be shown and then a was to encapsulate messages in UDP to traverse
the firewalls.

2. Conventions used in this document Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].

3. Abbreviation used in this document RFC 2119 [RFC2119].

This document uses the following abbreviations:

o CN: Correspondent Node
o CoA: Care of Address
o CoT: Care-of Test
o CoT-ICE: Care-of Test ICE
o CoTI: Care-of Test Init
o CoTI-ICE: Care-of Test Init ICE
o HA: Home Agent
o HoA: Home Address
o HoT Home Test
o HoTI: Home Test Init
o ICE: Interactive Connectivity Establishment
o MN: Mobile Node
o RO: Route Optimization
o RRT: Return Routability Test

3. Table of Content

1. Abstract 1
2. Conventions used in this document 1
3. Table of Content 2
4. Introduction 3
5. Enabling basic mobile IPv6 operation through firewalls 4
6. Enabling route optimization through firewalls 4
5. New RRT proposal 8
5.1 RRT procedures at the MN 9
5.2 RRT procedures at the CN 9
5.3 HA processing of CoTI-FW 9
5.4 CoTI-FW message 9
5.5 New Mobility Options 10
6. Race conditions 10
7. Security considerations 10
8. Contributors 10
9. References 11
10. Author's Addresses 12

4. Introduction Return Routability Procedure

Current firewalls typically create state and filter data traffic
based on the five tuple (sourceIP, destIP, Prot, sourcePort,

MIP6 Working Group Expiration 08/25/06 2

Firewall friendly RTT for MIPv6
October 2006
destPort). Filtering may be applied either to only incoming traffic
or both incoming and outgoing traffic.

RFC3775

MIP6 [RFC3775] faces a number of problems when used in an environment
with firewalls:

o (a) Mobile IP recommends the use of IPsec ESP to protect packets
between the MN and its home agent, while today's firewalls, as a
default rule, drop ESP packets, thus preventing the use of mobile IPv6. As
mobile IPv6 could MIP6.
It is possible to configure static pinholes in the firewalls to
allow ESP and IKE messages between MN and HA to pass
through.[I-D.krishnan-mip6-firewall] describes best current
practices on how to configure firewalls to enable MIPv6.
Alternatively, UDP encapsulation might be regarded as used.
o (b) current firewalls filter on udp and tcp protocol, thus when a
firewall is protecting the CN, that firewall might not allow a service offered
HoTI to pass, as that is sent using MH protocol [RFC3775]. If the mobile
nodes,
policy in the firewall would allow wildcard for the protocol
instead of filtering on udp or tcp, this problem would be solved
as well. Note: here it is expected assumed that firewalls placed when a HoTI is generated
by the MN (i.e. start of route optimisation), then there is
already a data connection between the access
network, where MN and the mobile node acquires its CoA, CN through the
HA.
o (c) similar to the above, when a firewall protecting the MN sees a
CoTI message, it would need to install state to allow the
corresponding CoT to pass and reach the home
network, where MN. Firewalls that do not
support MH and modifying the mobile node's HA firewall policy is residing, will relax not acceptable for
the
filtering rules based on some roaming agreements, thus allowing
mobile nodes administrator, UDP encapsulation might need to register their CoA with be used. This
is addressed in section 5.
o (d) a firewall protecting the CN will not allow a CoTI to pass, as
that is sent from an untrusted address.
o (e) when both the HA and use mobile IP.

Even though mobile IPv6 signaling between the MN and/or CN are behind firewalls,
then a combination of UDP encapsulation and its HA the modified RRT
mechanism defined in this document might need to be used to enable
MIPv6 operation.

As a summary, while some of the mobile IPv6 signaling could be guaranteed
enabled using static configurations in the firewalls, there is no way
to ensure the same for the signaling and data traffic on the direct
path between the MN and the CN (for the return routability test purposes). CN.

Without applying route optimization optimization, the MN and the CN would be
forced to communicate through their home agents, and that, based on
their topological location, could result in a trombone effect
introducing delays. increased latency and
cost. Such additional delays might not be tolerated by interactive
applications sensitive to delays.

In order to ensure a successful deployment of IPv6 and mobile IPv6 in
current IP networks, it is important to have mechanisms and
guidelines in place which help the smooth operation of the protocol
in a firewalled environment.

There are a limited number of possibilities on how to enable
mobile IPv6 through an environment with firewalls. One proposal, using

4. UDP Encapsulation

This section addresses scenarios a), b) and c) from Section 1.

4.1. Problem Description

When the NSLP NATFW
protocol can be found in [3]. The document proposes that MN or the
mobile node running mobile IPv6 uses HA or both are behind firewalls that block IPsec
ESP, then the NSLP NATFW protocol Binding Update to
open the required Home Agent will fail. To
overcome this situation, firewall administrators may configure static
pinholes in the firewalls on firewalls, as described in
[I-D.krishnan-mip6-firewall]. When that is not feasible, as an
alternative, the path between MN may use UDP encapsulation to wrap its MIPv6
messages destined to the HA into a UDP/IP header. As the MN and can not
influence or change the CN, before firewall behavior, it has to determine
whether there are any firewalls blocking ESP between itself and each mobile IPv6 signaling is
initiated. The proposal also requires that all the
HA or not. When there are, it will need to use UDP encapsulation.

Additionally, when the MN or the CN or both are behind firewalls on that
do not allow packets with MH protocol to pass, the path support MN, or the NSLP NATFW protocol.

The proposal CN or
both may need to use UDP encapsulation to wrap their MIPv6 messages
into a duplicate UDP/IP header. Same applies when the firewall
allows MH packets to pass in this document describes an alternative solution
for the problem by making some recommendations on in-->out direction but does not
install state to allow the corresponding response in the out-->in
direction.

4.2. UDP Encapsulation Procedures

4.2.1. Procedures at the MN

When the MN detects that there is a firewall
configuration between itself and defining an extension the
HA, it SHOULD start using UDP encapsulation to mobile IPv6.

5. Enabling basic mobile IPv6 operation through firewalls

MIP6 Working Group Expiration 04/20/07 3

Firewall friendly RTT for wrap its MIPv6
October 2006

In order
signaling messages destined to enable the mobile node to HA into new UDP/IP header. When
using UDP encapsulation, the MN MUST use mobile IPv6, it UDP port 500.

[Editor's Note: If there is
required to allow a communication path NAT between the MN mobile node and its HA.
More specifically, the Binding Update, Binding Acknowledgement,
Binding error and Binding Refresh Request messages
home agent then IKEv2 will need to
pass through the enable UDP encapsulation for subsequent
traffic. For firewalls on the path unaltered.

RFC3775 mandates the use this UDP encapsulation can either be provided
by IKEv2 or as part of IPsec and recommends the use of ESP
for these messages.

It mobile IP stack. For the usage with RFC
4285 mobile IP has to enable this UDP encapsulation procedure since
IKEv2 is thus recommended not used in this case.]

The MN can detect that there is a firewall administrators create on the path by either
using an external mechanism like STUN [6] or by simply assuming that
if the Binding Update to its HA fails, then that is probably the
case.

When the MN receives a rule
in packet on UDP port 500 from its HA, it MUST
inspect the firewall first 8 bytes of the UDP payload. If those are set to allow ESP protected packets between
zero then the MN received a UDP encapsulated MH packet and
its it MUST
remove the UDP/IP header and process the inner packet as a MH packet.

4.2.2. Procedures at the HA to pass through. As these packets might not necessarily be
ESP protected,

When the firewall would need HA receives a packet on UDP port 500, it MUST inspect the
first 8 bytes of the UDP payload. If those are set to recognize mobility zero then the
HA received a UDP encapsulated MH packet and it MUST remove the
UDP/IP header packets and create process the inner packet as a rule to allow these packets MH packet.

The HA MUST also use UDP encapsulation with port 500 when sending a
response to pass
through. One example of such a rule could be UDP encapsulated MH packet to filter on the
sourceIP, destIP MN.

When the HA receives a UDP encapsulated packet containing a HoTI or a
HoT or a CoTI-ICE (defined in this document) or a CoT-ICE (defined in
this document) MH packet, it MUST decapsulate and next re-encapsulate it
using UDP port 500 before sending it to the MN or CN, respectively:

Mobile Node Home Agent Correspondent Node
| | |
| HoTI:=IPv6(MN_COA, HA_ADDR) | HoTI:=IPv6(HA_ADDR, CN_ADDR) |
| UDP header | UDP header |
| IPv6 header | IPv6 header |
| Mobility header | Mobility header |
| type: HoTI (1) | type: HoTI (1) |
| | |
|---------------------------->|----------------------------->|
| | |
| HoT:=IPv6(HA_ADDR, MN_CoA) | HoT:=IPv6(CN_ADDR, HA_ADDR) |
| UDP header | UDP header |
| IPv6 header | IPv6 header |
| Mobility header | Mobility header |
| type: HoT (3) | type: HoT (3) |
| | |
|<----------------------------|<-----------------------------|
| | |

4.2.3. UDP encapsulated HoTI/HoT RRT messages

The CoTI-ICE/CoT-ICE messages are treated similarly, only the MH type
will have a different value (22 and 23 respectively)

4.2.3.1. Procedures at the CN

When the CN receives a packet on UDP port 500, it MUST inspect the
first 8 bytes of 135.

6. the UDP payload. If those are set to zero then the
CN received a UDP encapsulated MH packet and it MUST remove the
UDP/IP header and process the inner packet as a MH packet.

When the CN receives a UDP encapsulated MH message, it MUST send the
response using UDP encapsulation.

5. Enabling route Route Optimization Through Firewalls

Route optimization through firewalls can be enabled by either using dedicated signaling
to instruct the firewall to create a pinhole, or using a mechanism
which would make the firewall to install pinholes as part of its
normal operation. This draft addresses the latter solution.

5.1. Problem Description

This section describes in more details scenario d) from Section 1.

The Return Routability Test defined in [RFC4487] enables the
correspondent node to obtain some reasonable assurance that the
mobile node is in fact addressable at its claimed care-of address as
well as at its home address, while keygen tokens are exchanged and
combined into a binding management key. In order to enable route
optimizations through firewalls, both HoTI and CoTI messages (and the
corresponding HoT and CoT) need to successfully pass through. It is
assumed that at the time when the MN initiates a route optimization
procedure towards the CN, there is already some sort of data
communication between the MN and the CN. If the CN is behind
firewall and that firewall does have a rule to allow packets from the
HoA of the MN to the address of the CN, then there is a good chance
that HoTI would also make it through the firewall. The filtering rule would need to be relaxed to allow in
addition MH packets through between the two destinations (HoA of
the MN and the address of the CN).

If such a rule does not exist in the firewall protecting the CN, then
HoTI will be dropped and the return routability test will fail.
In order to facilitate the communication between the mobile nodes,
firewalls on the data path between an MN and a CN could also
create the following pinholes automatically:

- a pinhole from the address of the CN to the HoA of the MN
present in the type 2 Routing Header
- - a pinhole from the CoA of the MN to the HoA of the CN present
in the Destination Options extension Header

MIP6 Working Group Expiration 04/20/07 4

Firewall friendly RTT for MIPv6
October 2006

If it is only the MN protected by firewalls but the CN is not,
then HoTI will successfully arrive to the CN. The firewall
protecting the MN would need to allow the corresponding HoT to
pass through and reach the MN. For this, the firewall may need to
create a rule when forwarding the HoTI. An example of such a rule
is to allow packets between the HoA of the MN and the address of
the CN with the Next Header value of 135 to pass through.

Once HoTI is sent out and a HoT response is received, the MN will
send a CoTI message from its current CoA. If there is a firewall
protecting the CN, that firewall will drop the CoTI message as it is
coming from an untrusted source.

In order to illustrate the problem, let�s let's assume a communication
between an inner node A (protected by the firewall), and an external
mobile node B. It is assumed that the Firewall firewall protecting the CN
(node A) trusts the HoA of is configured in such a way that it allows traffic from the mobile
node B, B's HoA to bypass, therefore MH packets like HoTI are allowed to pass through the Firewall without
problems. not
filtered.

As specified in the Mobile IP [2], [RFC3775], the transport and above higher layers
of the ongoing communications
should be based on use the Home IP address and HoA of node B, and not the local
IP address that node B might get while roaming in order to support
mobility. The state created in the firewall protecting node A is
therefore initially based on the IP address of node A, and the home
address of the node B, HoA of node B. If the mobile node B is in its
home network, the packets are directly exchanged between the nodes A
and B. If the mobile node B is roaming, the session can be maintained
thanks to the Home Agent of node B and the reverse tunneling
mechanism [2]. [RFC3775]. Packets forwarded by the Home Agent to node A
will have the source IP address indicating the Home IP address of
node B and the destination IP address indicating the IP address of
node A. Such packets can thus pass the packet filter inspection in
the firewall protecting node A.
However However, nodes A and B might be close
located topologically closely together while node B�s B's Home agent Agent may
be far, far away, resulting in a 'trombone effect' that can create delay
and degrade the performance. The Mobile IP specifications have
defined the route optimization procedure [2] [RFC3775] in order to solve
this issue. The mobile node should first execute a Return
Routability Test: the Mobile Node B should send a Home Test Init
message (HoTI) via

MIP6 Working Group Expiration 04/20/07 5

Firewall friendly RTT for MIPv6
October 2006 its Home Agent and a Care of Test Init (CoTI)
message directly to its correspondent node A as illustrated in the
figure below [1]:

MIP6 Working Group Expiration 04/20/07 6

Firewall friendly RTT for MIPv6
October 2006 [RFC4487]:

+----------------+
| +----+ HoTI (HoA) +----+
| | FW |<----------------|HA B|
| +----X +----+
| +---+ | ^ CoTI � - dropped ^
| | A | | | by the FW |
| +---+ | | | HoTI
| | | |
| | | CoTI (CoA)+---+
| | +------------------| B |
+----------------+ +---+
Network protected External Mobile
by a firewall Node

The Care of Test Init message is more particularly sent from the new CoA, however such CoA. However,
this packet will not match any entry in the packet filter in the
firewall and, and the CoTI message will thus be dropped. As a consequence, the
RRT cannot be completed and Route optimization cannot be applied due
to the presence of a firewall.

Support for route optimization is not a non-standard set of
extensions, but a fundamental part of the protocol. Firewalls
however prevent route optimisation to be applied by blocking the
Return Routability Test messages.

The above scenario is one from the problem statements described in
[1].

One could argue that CoTI could be reverse tunneled in the same
way as HoTI, and the problem would be solved. Even though sending
CoTI through the HA provides solution
[RFC4487].

5.2. New RTT Proposal

This document proposes a modified RRT for the case when the CN is MIPv6 nodes behind Firewall,
firewalls. In the problem would not be solved for new RRT mechanism the symmetric
scenario, when original HoTI and HoT remain
unchanged, while the MN is behind Firewall: if a new CoTI is not sent
from the CoA of the MN, the Firewall protecting the MN would not
open a pinhole for the <MN CoA, CN CoA> address pair, (called CoTI-ICE) and thus CoT (called CoT-
ICE) messages will be dropped, resulting routed through the HA in a failed RRT.

If CoTI would follow the path of similar way as HoTI
and CoT would follow HoT. While the
path of HoT, then token exchange for binding management key
generation purposes from the Return Routability Test would original RRT is preserved, the new RRT
mechanism will be successful,
without actually testing used to exchange the direct path between valid addresses the MN and CN. If
Firewalls are on CN
possess. Once the path of addresses - called candidate addresses - are
exchanged, both the data between MN and CN, the data

MIP6 Working Group Expiration 04/20/07 7

Firewall friendly RTT for MIPv6
October 2006

packets would be dropped, CN will run connectivity checks as corresponding pinholes were not
opened. Thus RRT would not reach its purpose.

7. New RTT proposal

This document proposes an additional procedure for the Return
Routability Test to be performed by mobile nodes who wish to
communicate with CNs and either or both parties are behind
Firewalls.

A failure
described in RRT is usually detected [I-D.tschofenig-mip6-ice] in order to enable and to
check the CN by not receiving a
CoTI after HOT was sent out. The MN detects connectivity for the RRT failure by not
receiving a CoT after sending out addresses. When a CoTI. To solve this problem,
this document proposes that when working address
pair is found, the MN detects the RRT failure, it will send out a new MH message, called CoTI-FW. The CoTI-FW will
contain the CoA of the MN in the Mobility Options header field and
it will need to be reverse tunneled through the HA. A CN receiving a
CoTI-FW will know BU from that a CoTI has been probably dropped by the
Firewall. It will send a CoT message to the CoA of the MN in
response to the CoTI-FW. Even if the MN is behind Firewall, the
initial CoTI opened a pinhole which would allow the CoT response to
CoTI-FW to pass through the Firewall and reach the MN.

Figure 1 illustrates the new RRT procedure (the first three messages
are part of the original RRT): CN's
address.

Mobile node Home agent Correspondent node
| |
| Home Test Init (HoTI) HoTI | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|-----------|FW|---------------------->x|FW| dropped |
| CoTI-ICE | |
|------------------------->|------------------------->|
| Home Test (HoT) |
|<-------------------------|<-------------------------| |
| | HoT | CoT not sent (as CoTI was not received by CN)<......|

timeout waiting for CoT
|<-------------------------|<-------------------------|
| | | CoTI-FW
| |
|------------------------->|------------------------->| CoT-ICE | Care-of Test (CoT)
|<-------------------------|<-------------------------|
|
|<----------|FW|------------------------|FW|----------| | |

Figure 1

The new RRT procedure

MIP6 Working Group Expiration 04/20/07 8

Firewall friendly RTT for MIPv6
October 2006

A MN SHOULD always perform mechanism will not test the herein described procedure when it
experiences problems with connectivity on the original RTT direct
path between the MN and CN. As that is still needed before the nodes
engage in data exchange, a new mechanism, described in [2].

7.1
[I-D.tschofenig-mip6-ice] is used for this purpose.

5.3. Modified RRT procedures Procedures

5.3.1. Modified RRT Procedures at the MN

A MN MUST NOT send a COTI-FW without sending first a COTI.

The MN following the new RRT procedure defined in this draft MUST NOT
send a COTI-FW if a CoT response has been received for CoTI, as defined in [RFC3775], to the
CoTI.
A MN SHOULD always send a CoTI-FW if CN. Instead it does not receive MUST
generate a CoT
response to the previously sent CoTI. CoTI-ICE, as defined in this document. The CoTI-FW MN MUST contain the
same care-of init cookie gather
its addresses from all its interfaces as the one sent out described in CoTI.
A CoTI-FW
[I-D.tschofenig-mip6-ice]. The MN MUST contain the MN's CoA form candidate-addresses as
described in [I-D.tschofenig-mip6-ice]. The MN MUST put all of its
candidate-addresses into a MIP-ICE mobility options defined in
[I-D.tschofenig-mip6-ice] and MUST attach it to the Mobility Options field.

7.2 CoTI-ICE message.

5.3.2. Modified RRT procedures at the CN

Upon

The CN supporting the new RRT procedure defined in this document,
upon receiving a CoTI-FW request, the CN creates CoTI-ICE message MUST NOT send a care-of keygen
token and uses the current nonce index CoT response, as the Care-of Nonce Index.
It then creates
defined in [RFC3775]. The CN upon receipt of a Care-of Test CoTI-ICE message MUST
gather its addresses from all its interfaces as described in
[I-D.tschofenig-mip6-ice]. The CN MUST form candidate-addresses as
described in [I-D.tschofenig-mip6-ice]. The CN MUST put all of its
candidate-addresses into a MIP-ICE mobility options defined in
[I-D.tschofenig-mip6-ice] and sends MUST attach it to the care-of
address of the mobile node found in the Mobility Options field.

7.3 CoT-ICE message.

5.3.3. HA processing of CoTI-FW

A CoTI-FW message CoTI-ICE and CoT-ICE

Both CoTI-ICE and CoT-ICE messages MUST be processed by the HA as any
other Mobility Header message, as described in [2].

7.4 CoTI-FW message [RFC3775].

6. New Mobility Header Types

6.1. CoTI-ICE Message

A mobile node uses the CoTI-FW CoTI-ICE message to finalize the return
routability procedure and request a care-of keygen token from a
correspondent node when a CoT response to CoTI has not been
received.
correspondent. The CoTI-FW CoTI-ICE message uses the MH Type value 22 (to be
registered with IANA). A CoTI-FW message MUST include a mobility
options carrying the CoA candidate addresses of the MN sending it.

MIP6 Working Group Expiration 04/20/07 9

Firewall friendly RTT for MIPv6
October 2006

7.5 New Mobility Options

This specification defines a new Mobility Options called 'MN FW-RRT
CoA' which has an alignment requirement of 8n+6. Its

When value 22 is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Length = 16 Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care of Init Cookie +
| |
+ MN FW-RRT Care-of Address +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. MIP-ICE Mobility Options .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The MN FW-RRT CoA mobility options is

Care of Init Cookie: as defined to be carried in RFC 3775
MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice]

6.2. CoT-ICE Message

The Care-of Test ICE (CoT-ICE) message is a
CoTI-FW message.

8. Race conditions

There are a few cases when the CN may receive both CoTI and CoTI-FW
messages, e.g. when CoT got delayed and response to the MN sends a CoTI-FW after
sending a CoTI.

The CN can and SHOULD detect whether CoTI Care-of
Test Init ICE (CoTI-ICE) message, and CoTI-FW were is sent from the same CoA or not. If they came from correspondent
node to the same CoA, mobile node. The Care-of Test ICE message uses the CN SHOULD
NOT respond to both with a CoT, but only to one of them. If CoTI and
CoTI-FW came from different CoA, that might MH
Type value 23 (to be registered with IANA). When this value is
indicated in the result MH Type field, the format of the MN
changing CoA (e.g. from a CoA not belonging to Message Data field
in the same FW protected
network Mobility Header is as the CN, to a CoA belonging there) and initiating RRT from
both CoA. The CN SHOULD respond to both messages with a CoT.

9. follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |
. MIP-ICE Mobility Options .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Care of Init Cookie: as defined in RFC 3775
Care-of Keygen Token: as defined in RFC 3775
MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice]

7. IANA Considerations

This specification registers new MH type values:

CoTI-ICE message uses MH type value 22.

CoT-ICE message uses MH type value 23.

8. Security considerations Considerations

The proposal herein assumes that future Firewalls supporting MIPv6,
will install states for MH packet initiated flows too, security threats described in [I-D.tschofenig-mip6-ice] are
inherited in addition to the same
way as it is currently done for UDP flows. It existing ones mentioned in [RFC3775].

[Editor's Note: More work is needed on the understanding
of security consideration
section particularly since the authors, that this does not introduce any additional security
threads to properties of the system.

10. Contributors

Acknowledgements return
routability check might be changed.]

9. Acknowledgments

We would like to Franck Le thank Thomas Schreck for contributing his contributions to this draft. Thanks
to Lassi Hippelainen for valuable comments.

MIP6 Working Group Expiration 04/20/07 10

Firewall friendly RTT
document.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for MIPv6
October 2006

11. use in RFCs to Indicate
Requirement Levels", March 1997.

[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.

[I-D.tschofenig-mip6-ice]
Tschofenig, H. and G. Bajko, "Mobile IP Interactive
Connectivity Establishment (M-ICE)",
draft-tschofenig-mip6-ice-00 (work in progress),
June 2007.

10.2. Informative References

[1] Franck

[RFC4487] Le, Stefano F., Faccin, Basavaraj S., Patil, Hannes B., and H. Tschofenig,
'Mobile "Mobile
IPv6 and Firewalls, Firewalls: Problem statement' IETF Internet
draft, Statement", RFC 4487,
May 2005.

[2] D. Johnson, C. Perkins, J. Arkko �Mobility support 2006.

[I-D.krishnan-mip6-firewall]
Krishnan, S., "Firewall Recommendations for MIPv6",
draft-krishnan-mip6-firewall-00 (work in IPv6�,
RFC3775, June 2004

[3] http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-
mip6-fw-04.txt, wprk in progress

12. Author's progress),
July 2007.

Authors' Addresses

Gabor Bajko
gabor.bajko@nokia.com
Nokia

Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany

Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

MIP6 Working Group Expiration 04/20/07 11

Firewall friendly RTT for MIPv6
October 2006

THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

MIP6 Working Group Expiration 04/20/07 12 IETF
Administrative Support Activity (IASA).