One document matched: draft-bajko-mip6-rrtfw-03.txt
Differences from draft-bajko-mip6-rrtfw-02.txt
MIP6 G. Bajko
Internet Draft Nokia
Intended status: Standards Track H. Tschofenig
Expires: August 25, 2008 Nokia Siemens Networks
February 25, 2008
Firewall friendly Return-Routability Test (RRT) for Mobile IPv6
draft-bajko-mip6-rrtfw-03.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 August 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines a slightly modified Return Routability Test
(RRT) for MIPv6 [RFC3775]. 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 additional
mechanism, defined in [I-D.tschofenig-mip6-ice], 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 as described in [4].
The defined mechanism is intended to work with current firewalls
without requiring any support from them.
Bajko & Tschofenig Expires 08/25/08 [Page 1]
Firewall friendly RTT for MIPv6 February 2008
The document also addresses the use of UDP encapsulation to
facilitate MIPv6 signaling between involved nodes.
Table of Content
Abstract 1
Table of Content 2
1. Introduction 2
2. Terminology 3
3. Problems with Return Routability Procedure 3
4. Assumptions made in this document 4
5. UDP encapsulation 5
5.1 Problem description 5
5.2 UDP encapsulation procedures 5
6. Enabling route optimization through firewalls 6
6.1 Problem description 7
6.2. New RTT proposal 8
6.3 Modified RRT procedures 9
7. New Mobility Header types 10
7.1 CoTI-ICE message 10
7.2 CoT-ICE message 10
8. IANA considerations 11
9. Security considerations 11
10. Acknowledgements 11
11. Normative References 11
12. Informative References 12
13. Author's Addresses 12
1. Introduction
Most of today's IP networks are protected by state full firewalls
which filter the traffic based on the five tuple (sourceIP, destIP,
sourcePort, destPort). This filtering could be supplied to incoming
traffic or both incoming and outcoming. The problems which occur
when using MIPv6 in firewall protected networks are described in
detail in [RFC4487].
Most of the MIPv6 signalling is, as defined in [RFC3775], is secured
by IPSec ESP, and most of today's firewalls will drop ESP packets,
as there are no default rules defined for this traffic. So the
mobile node is not able to successfully complete the registration of
it's CoA in the new network and will not be able to communicate with
other nodes.
If the the Binding Update (BU) with the home agent (HA) is finished,
and the mobile node wants to use route optimization, it will start
the Return Routability Procedure (RRT). For this it will send a
HoTI and a CoTI message to the corresponend node (CN). The HoTI will
be sent over the HA to the CN and the CoTI message directly to the
CN. Normally, the HoTI and the correspondent HoT message will go
through, but the CoTI or CoT message will mostly be dropped. So no
Bajko & Tschofenig Expires 08/25/08 [Page 2]
Firewall friendly RTT for MIPv6 February 2008
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. 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.
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. Problems with Return Routability Procedure
Current firewalls typically create state and filter data traffic
based on the five tuple (sourceIP, destIP, Prot, sourcePort,
destPort). Filtering may be applied either to only incoming traffic
or both incoming and outgoing traffic.
MIP6 [RFC3775] faces a number of problems when used in an
environment with firewalls:
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 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-admin] describes best current practices
on how to configure firewalls to enable MIPv6. Alternatively, UDP
encapsulation might be used. Details in section 5.
b) current firewalls filter on udp and tcp protocol, thus when a
firewall is protecting the CN, that firewall will most likely not
Bajko & Tschofenig Expires 08/25/08 [Page 3]
Firewall friendly RTT for MIPv6 February 2008
allow a HoTI coming from an external MN to pass, as that is sent
using MH protocol [RFC3775]. If the 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: if at the time of generating a HoTI (i.e. start of route
optimization), there is already a data connection between the MN
and the CN (possibly through the HA), then it is likely that the
HoTI will make it through the FW protecting the CN.
c) a firewall protecting the CN will not allow a CoTI coming from an
external MN to pass, as that is sent from an untrusted address.
There are no static configuration possibilities or other known
mechanisms to date which provide solution for this issue. [I-
D.krishnan-mip6-firewall-vendor] suggests the Firewall be
configured to let unsolicited HoTI and CoTI messages pass through
and reach the CN. This document proposes a modified CoTI, called
CoTI-ICE, to take the same route as the HoTI, thus be handled by
the Firewall in a similar way as a HoTI is.
d) when both the HA and the MN and/or CN are behind firewalls, then
a combination of UDP encapsulation and 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
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.
Without applying route 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. 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 an environment with firewalls.
4. Assumptions made in this document
This document makes the assumption that the policy in the Firewall
will allow (even unsolicited) HoTI messages to pass through. A
similar assumption for the CoTI is not necessary, as this document
proposes a modified CoTI, called CoTI-ICE, to replace the CoTI
defined in [RFC3775].
As HoTI messages are reverse tunneled by the MNs through their HA,
it is possible to pre-establish a trust relationship with some HAs
acting as mobility service providers for external nodes, thus
allowing Firewalls to accept unsolicited HoTI messages only from
certain (trusted) sources. Similar trust cannot be established with
a source generating the CoTI, that is the reason of proposing the
new CoTI-ICE message.
Bajko & Tschofenig Expires 08/25/08 [Page 4]
Firewall friendly RTT for MIPv6 February 2008
While allowing unsolicited traffic through the FWs may constitute a
security threat in many cases, the limited scope of the HoTI message
limits the threat possibility. Letting unsolicited HoTI through the
FWs is in many cases the only possibility of letting external nodes
contact nodes behind the FWs. Local FW administrators may decide
whether contacting nodes behind FWs is an allowed scenario for the
FW protected network or not, and set up pinholes accordingly.
Comparison can be made with a scenario when an externally generated
SIP INVITE message is allowed to be received by a proxy in a
Firewall protected network. From the Firewall point of view, the SIP
INVITE message is unsolicited traffic.
5. UDP Encapsulation
This section addresses scenarios a) and b) from section 3.
5.1 Problem description
When the MN or the HA or both are behind firewalls that block IPsec
ESP, then the Binding Update to the Home Agent will fail. To
overcome this situation, firewall administrators may configure
static pinholes in the firewalls as described in [I-D.krishnan-mip6-
firewall-admin]. When that is not feasible, as an alternative, the
MN may use UDP encapsulation to wrap its MIPv6 messages destined to
the HA into a duplicate UDP/IP header. As the MN can not influence
or change the firewall behavior, it has to determine whether there
are any firewalls blocking ESP between itself and 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
which do not allow packets with MH protocol to pass, the MN, or the
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 the in-->out direction but
does not install state to allow the corresponding response in the
out-->in direction.
5.2 UDP encapsulation procedures
5.2.1 Procedures at the MN
When the MN detects that there is a firewall between itself and the
HA, it SHOULD start using UDP encapsulation to wrap its MIPv6
signaling messages destined to the HA into new UDP/IP header. When
using UDP encapsulation, the MN MUST use UDP port 500.
The MN can detect that there is a firewall on the path by either
using an external mechanism like STUN [RFC3489] or by simply
assuming that if the Binding Update to its HA fails, then that is
probably the case.
Bajko & Tschofenig Expires 08/25/08 [Page 5]
Firewall friendly RTT for MIPv6 February 2008
When the MN receives a packet on UDP port 500 from its HA, it MUST
inspect the first 8 bytes of the UDP payload. If those are set to
zero then the MN received a UDP encapsulated MH packet and it MUST
remove the UDP/IP header and process the inner packet as a MH
packet.
5.2.2 Procedures at the HA
When the HA receives a packet on UDP port 500, it MUST inspect the
first 8 bytes of the UDP payload. If those are set to zero then the
HA received a UDP encapsulated MH packet and it MUST remove the
UDP/IP header and process the inner packet as a MH packet.
The HA MUST also use UDP encapsulation with port 500 when sending a
response to a UDP encapsulated MH packet to the 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 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) |
| | |
|<----------------------------|<-----------------------------|
| | |
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)
5.2.3 Procedures at the CN
When the CN receives a packet on UDP port 500, it MUST inspect the
first 8 bytes of the UDP payload. If those are set to zero then the
Bajko & Tschofenig Expires 08/25/08 [Page 6]
Firewall friendly RTT for MIPv6 February 2008
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.
6. Enabling route optimization through firewalls
Route optimization 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.
6.1 Problem description
This section describes in more details scenario c) from section 3.
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.
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.
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 assume a communication
between an inner node A (protected by the firewall), and an external
mobile node B. It is assumed that the Firewall protecting the CN
(node A) trusts the HoA of the mobile node B, therefore MH packets
like HoTI are allowed to pass through the Firewall without problems.
As specified in the Mobile IP [RFC3775], the transport and above
layers should 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.
Bajko & Tschofenig Expires 08/25/08 [Page 7]
Firewall friendly RTT for MIPv6 February 2008
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 [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 nodes A and B might be located topologically closely
together while node B's Home Agent may be 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 [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 its Home Agent and a
Care of Test Init (CoTI) message directly to its correspondent node
A as illustrated in the figure below [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 sent from the new CoA, however such
packet will not match any entry in the packet filter in the firewall
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.
The above scenario is one from the problem statements described in
[RFC4487].
6.2. New RTT proposal
This document proposes a modified RRT for MIPv6 nodes behind
firewalls. In the new RRT mechanism the original HoTI and HoT remain
unchanged, while the new CoTI (called CoTI-ICE) and CoT (called CoT-
ICE) messages will be routed through the HA in a similar way as HoTI
and HoT. While the token exchange for binding management key
generation purposes from the original RRT is preserved, the new RRT
Bajko & Tschofenig Expires 08/25/08 [Page 8]
Firewall friendly RTT for MIPv6 February 2008
mechanism will be used to exchange the valid addresses the MN and CN
possess. Once the addresses - called candidate addresses - are
exchanged, both the MN and CN will run connectivity checks as
described in [I-D.tschofenig-mip6-ice] in order to enable and to
check the connectivity for the addresses. When a working address
pair is found, the MN will send a BU from that CoA to the CN's
address.
Mobile node Home agent Correspondent node
| |
| HoTI | |
|------------------------->|------------------------->|
| | |
| CoTI-ICE | |
|------------------------->|------------------------->|
| | |
| | HoT |
|<-------------------------|<-------------------------|
| | |
| | CoT-ICE |
|<-------------------------|<-------------------------|
| | |
Modified RRT mechanism
The new RRT mechanism will not test the connectivity on the direct
path between the MN and CN. As that is still needed before the nodes
engage in data exchange, a new mechanism, described in [I-
D.tschofenig-mip6-ice] is used for this purpose.
6.3 Modified RRT procedures
6.3.1 Modified RRT procedures at the MN
The MN following the new RRT procedure defined in this draft MUST
NOT send a CoTI as defined in [RFC3775] to the CN. Instead it MUST
generate a CoTI-ICE as defined in this document.
The MN MUST gather its addresses from all its interfaces as
described in [4]. The MN MUST 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 CoTI-ICE message.
6.3.2 Modified RRT procedures at the CN
The CN supporting the new RRT procedure defined in this document,
upon receiving a CoTI-ICE message MUST NOT send a CoT response as
defined in [RFC3775], instead follow the procedures below.
The CN upon receipt of a CoTI-ICE message MUST gather its addresses
from all its interfaces as described in [4]. 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
Bajko & Tschofenig Expires 08/25/08 [Page 9]
Firewall friendly RTT for MIPv6 February 2008
options defined in [I-D.tschofenig-mip6-ice] and MUST attach it to
the CoT-ICE message.
6.3.3 HA processing of 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 [RFC3775].
7. New Mobility Header types
7.1 CoTI-ICE message
A mobile node uses the CoTI-ICE message to finalize the return
routability procedure and request a care-of keygen token from a
correspondent. The CoTI-ICE message uses the MH Type value 22 (to be
registered with IANA).
A CoTI-ICE message MUST include a mobility options carrying the
candidate addresses of the MN sending it.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. MIP-ICE Mobility Options .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Care of Init Cookie: as defined in [RFC3775]
MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice]
7.2 CoT-ICE message
The Care-of Test ICE (CoT-ICE) message is a response to the Care-of
Test Init ICE (CoTI-ICE) message, and is sent from the correspondent
node to the mobile node. The Care-of Test ICE message uses the MH
Type value 23 (to be registered with IANA). When this value is
Bajko & Tschofenig Expires 08/25/08 [Page 10]
Firewall friendly RTT for MIPv6 February 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. MIP-ICE Mobility Options .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Care of Init Cookie: as defined in [RFC3775]
Care-of Keygen Token: as defined in [RFC3775]
MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice]
8. 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.
9. Security considerations
The security threats described in [4] are inherited in addition to
the existing ones mentioned in [RFC3775].
The security properties of the MIP6 Return Routability Procedure are
dramatically changed by this document. Since both the HoTI/HoT and
the CoTI/CoT message exchanges are sent through the HA, the HA will
be capable of constructing the Binding Management Key (Kbm). While
this may constitute a threat in most cases, since the HA is a
mobility service provider, the MNs should trust their HA. More
consideration is needed to determine in which circumstances this
security model is acceptable and in which is not.
Bajko & Tschofenig Expires 08/25/08 [Page 11]
Firewall friendly RTT for MIPv6 February 2008
10. Acknowledgments
We would like to thank Thomas Schreck for his contributions to this
document.
11. Normative References
[RFC3775] D. Johnson, C. Perkins, J. Arkko 'Mobility support in
IPv6', RFC3775, June 2004
[RFC3489] J. Rosemberg et al 'Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators (NATs)',
RFC3489
12. Informative References
[RFC4487] Franck Le, Stefano Faccin, Basavaraj Patil, Hannes
Tschofenig, 'Mobile IPv6 and Firewalls, Problem statement'
RFC4487, May 2006
[I-D.tschofenig-mip6-ice] H Tschofenig, G. Bajko 'Mobile IP
Interactive Connectivity Establishment (M-ICE)',
http://www.ietf.org/internet-drafts/draft-tschofenig-mip6-ice-
02.txt (work in progress)
[4] J. Rosemberg 'Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols' http://www.jdrosen.net/papers/draft-ietf-
mmusic-ice-14.txt
[I-D.krishnan-mip6-firewall-admin] Krishnan et al 'Firewall
Recommendations for MIPv6', draft-krishnan-mip6-firewall-admin-03
(work in progress)
[I-D.krishnan-mip6-firewall-vendor] Krishnan et al 'Guidelines for
firewall vendors regarding MIPv6 traffic', draft-krishnan-mip6-
firewall-vendor-02 (work in progress)
13. Author's Addresses
Gabor Bajko
Nokia
313 Fairchild dr
Mountain View, CA
gabor.bajko@nokia.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo, Finland
Hannes.Tschofenig@nsn.com
Bajko & Tschofenig Expires 08/25/08 [Page 12]
Firewall friendly RTT for MIPv6 February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bajko & Tschofenig Expires 08/25/08 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 07:37:12 |