Internet DRAFT - draft-zhang-mip6-fsup
draft-zhang-mip6-fsup
Network Working Group Yang Shen
Internet-Draft Zhang Hongke
Expires: November, 2006 Zhang Sidong
Beijing Jiaotong University
Miao Fuyou
Huawei Technologies
May, 2006
Firewall State Update Process for Mobile IPv6
draft-zhang-mip6-fsup-01
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 November, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
A mobile IPv6 node remains reachable when it moves in a IPv6
Internet. However, if such a node, i.e. MN, moves to a network which
is protected by firewalls, the communication that is already existed
before its moving may be blocked by firewall. The document presents a
mechanism to update the corresponding access control entry of
firewall to avoid the communication interrupted.
Zhang, et al. Expires: November 2006 [Page 1]
draft-zhang-mip6-fsup-01 May 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of CGA. . . . . . . . . . . . . . . . . . . . . . . 5
4. New Mobile IPv6 Option . . . . . . . . . . . . . . . . . . . 5
4.1. CGA Parameter Option. . . . . . . . . . . . . . . . . 5
4.2. Public Key Option . . . . . . . . . . . . . . . . . . 7
5. New ICMPv6 Message . . . . . . . . . . . . . . . . . . . . . 7
5.1. state_create_request. . . . . . . . . . . . . . . . . 7
5.2. state_create_reply. . . . . . . . . . . . . . . . . . 9
6. Protocol Description . . . . . . . . . . . . . . . . . . . .12
6.1 Modification to Mobile IPv6 . . . . . . . . . . . . .13
6.2. Protocol Process. . . . . . . . . . . . . . . . . . .13
7. Security Considerations. . . . . . . . . . . . . . . . . . .15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .15
9. References . . . . . . . . . . . . . . . . . . . . . . . . .15
10. Author's address . . . . . . . . . . . . . . . . . . . . . .16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . .16
Intellectual Property Statement . . . . . . . . . . . . . . . . .17
Expiration. . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Zhang, et al. Expires: November 2006 [Page 2]
draft-zhang-mip6-fsup-01 May 2006
1. Introduction
It's well known that Mobile IPv6 does not works well along with
firewall. It's a very complex problem because there are different
types of node (MN, CN and HA) and firewall may exist between any two
nodes. The nature of firewall as a perimeter protection complicates
the situation because the "direction" must also be considered. The
document will address a subclass of the MIP6 firewall traversal
problem and propose a simple solution.
When MN moves in the internet, it may move into a new network that is
protected by firewalls. In the other case, the MN's moving may cause
the changing of the routing path, if the CN is protected by several
firewalls, the incoming data traffic comes to another firewall
different from the original one. In both scenarios, one or many
firewalls without entry for the communication is inserted between MN
and CN. The scenario is specific to mobile networks, and some new
methods are desired to get entry updated/added by firewall in a secure
manner.
There is a binding update procedure after MN's moving. So the BU/BA
message may be considered as an indicator of the potential data
traffic in the same direction. When an incoming BU/BA is intercepted
and if there is no existing filtering entry in firewall, a firewall
update process is triggered.
Otherwise, Cryptographically Generated Addresses (CGA) is introduced.
A public key is associated with the IPv6 address in the CGA address
and the corresponding private key may sign the packet. With the help
of CGA address, the state update process could became more robust.
Zhang, et al. Expires: November 2006 [Page 3]
draft-zhang-mip6-fsup-01 May 2006
2. Problem Statements
Scenario 1: MN moves into a new network protected by firewall.
+----------------+ +----+
| | ***********| CN |~~~
| | * +----+ ~
| | * Correspondent ~
| +---+ +----+ * Node ~
| |MN |<*****| FW |**** ~
| +---+ +----+ ~
| ^ | +----+ ~
| |-----------|--<-------------| MN |<~~
| | +----+
+----------------+ Mobile Node
Network protected
by a firewall
Figure 1: ------> MN's moving track
~~~~~~> traffic from CN to MN before MN's moving
******> traffic from CN to MN after MN's moving
When communication is going on, a MN may move into a network which is
protected by a firewall. It's assumed that the Return Routability
Procedure and Binding Update had already finished. The incoming
packets from CN to MN is dropped because there no filtering entry in
the firewall. When MN is communicating with HA, the same scenario may
also happen.
Scenario 2: route path changing caused by MN's moving
+----------------+ +----+
| | ***********| MN |
| | * +----+
| +---+ +----+ * ^
| | |<*****| FW1|**** |
| | | +----+ |
| |CN | | |
| | | +----+ |
| | |<~~~~~| FW2|~~~~ |
| +---+ +----+ ~ |
| Correspondent | ~ +----+
| Node | ~~~~~~~~~~~| MN |
| | +----+
+----------------+ Mobile Node
Network protected
by firewalls
Zhang, et al. Expires: November 2006 [Page 4]
draft-zhang-mip6-fsup-01 May 2006
Figure 2: ------> MN's moving track
~~~~~~> traffic from MN to CN before MN's moving
******> traffic from MN to CN after MN's moving
Another similar scenario is that CN is in network with more than one
firewall, Iif the MN moves, the incoming traffic may come to another
firewall, because the new Care-of Address may cause the change of
routing path. The same scenario is also applied to HA.
3. Overview of CGA
Cryptographically Generated Addresses (CGA) is IPv6 address, whose
interface identifier is computed by hashing the public key and
auxiliary parameters. The corresponding private key could be used to
sign the packets sent from this address. The CGA address is
authenticated by recomputing the hash value and comparing it to the
interface identifier. No CAs and infrastructure are needed in the
implementation of CGA address.
A parameter data structure is attached to the packets being
protected. The receiver could use the parameters to recompute the
hash value when authenticating the CGA address. The data structure
contains four parameters: Modifier, Subnet Prefix, Collision Count
and Public Key.
The CGA address has four main advantages: a public key is bound to
the IPv6 address; address spoofing attack is much more harder; the
modification to packets could be detected; no more infrastructure is
required.
4. New Mobility Option in Mobile IPv6
4.1. CGA Parameter Option
The CGA Parameter Option is about the CGA parameter data structure
that each CGA address must have. The receiver nodes can use the data
structure to verify the CGA address. The option has the following
format:
Zhang, et al. Expires: November 2006 [Page 5]
draft-zhang-mip6-fsup-01 May 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Modifier (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Collision Count| |
+-+-+-+-+-+-+-+-+ |
| |
~ Public Key (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be designed.
Length
The length field contains the length of the option in octets,
excluding the type and length fields.
Modifier
This field contains a 128-bit unsigned integer, which can be any
value. The modifier is used during CGA generation to implement
the hash extension and to enhance privacy by adding randomness to
the address.
Subnet Prefix
This field contains the 64-bit subnet prefix of the CGA.
Collision Count
This is an eight-bit unsigned integer that MUST be 0, 1, or 2.
The collision count is incremented during CGA generation to
recover from an address collision detected by duplicate address
detection.
Zhang, et al. Expires: November 2006 [Page 6]
draft-zhang-mip6-fsup-01 May 2006
Public Key
This is a variable-length field containing the public key of the
address owner. The public key is the one that used to generate
the CGA address. The concrete desire of the format of the public
key is described in [3].
4.2. Public Key Option
The Public Key Option is about the public key that the destination
node used in CGA address. It is mainly designed for firewalls. The
option must be contained in BU and BA message and it has the
following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ |
| Public Key (variable length) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be designed. The identifier of the type of the mobility option.
Length
The option length field contains the length of the Public Key in
octets.
Public Key
This is a variable-length field containing the public key of the
the destination node. If the host is a MN, "the destination node"
means a CN, and vice versa. The public key must be identical with
the destination node's public key that used for generating CGA
address.
5. New ICMPv6 Message
5.1. state_create_request
The state_create_request message is a new type of ICMPv6 message, it
is used by firewall to request inner node to update the related
filtering entry. The message has the following format:
Zhang, et al. Expires: November 2006 [Page 7]
draft-zhang-mip6-fsup-01 May 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Cookie (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Inner Node Address (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Node Address (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be designated. The type field contains the identifier of the type
of the ICMPv6 message.
Code
To be designated. The code field depends on the message type. It is
used to create an additional level of message granularity.
Ckecksum
The checksum field is used to detect data corruption in the ICMPv6
message and parts of the IPv6 header.
Encrypted Cookie
The encrypted cookie field contains the cookie that is encrypted
with the inner node's public key. The cookie is generated by
firewall randomly and identical for each inner node.
Zhang, et al. Expires: November 2006 [Page 8]
draft-zhang-mip6-fsup-01 May 2006
Inner Node Address
The inner node address field contains the IPv6 address of the node
that is protected by the firewall. If the inner node is MN, the
address is the home address.
Outer Node Address
The outer node address field contains the IPv6 address of the node
that is outside of the firewall. If the outer node is MN, the
address is the home address.
5.2. state_create_reply
The state_create_reply message is a new type of ICMPv6 message, it is
used by inner node to inform the firewall of the traffic related
information, with which the firewall could build filtering entry. The
message has the following format:
Zhang, et al. Expires: November 2006 [Page 9]
draft-zhang-mip6-fsup-01 May 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Signature (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Inner Node Address (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Node Address (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Node Port (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Node Port (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Modifier (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Collision Count| |
+-+-+-+-+-+-+-+-+ |
| |
~ Public Key (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang, et al. Expires: November 2006 [Page 10]
draft-zhang-mip6-fsup-01 May 2006
Type
To be designated. The type field contains the identifier of the
type of the ICMPv6 message.
Code
To be designated. The code field depends on the message type. It
is used to create an additional level of message granularity.
Ckecksum
The checksum field is used to detect data corruption in the ICMPv6
message and parts of the IPv6 header.
Signature
The signature field contains the signature of state information
and cookie, it is computed as, Signature = First (128, DSA (Cookie
| Inner Node Address | Outer Node Address | Inner Node Port |
Outer Node Port)). The inner node get the cookie from the
state_create_request message, it decrypts the "encrypted cookie"
field with its private key. The firewall uses the signature to
authenticate the state information.
Encrypted Cookie
The encrypted cookie field contains the cookie that is encrypted
with the inner node's public key. The cookie is generated by
firewall randomly and identical for each inner node.
Inner Node Address
The inner node address field contains the IPv6 address of the node
that is protected by the firewall. If the inner node is MN, the
address is the home address.
Outer Node Address
The outer node address field contains the IPv6 address of the node
that is outside of the firewall. If the outer node is MN, the
address is the home address.
Inner Node Port
The inner node port field contains the transport layer port number
of the node that is protected by the firewall. The firewall uses
the port number to build the filterig entry.
Zhang, et al. Expires: November 2006 [Page 10]
draft-zhang-mip6-fsup-01 May 2006
Outer Node Port
The outer node port field contains the transport layer port number
of the node that is outside of the firewall. The firewall uses the
port number to build the filtering entry.
Modifier
This field contains a 128-bit unsigned integer, which can be any
value. The modifier is used during CGA generation to implement
the hash extension and to enhance privacy by adding randomness to
the address.
Subnet Prefix
This field contains the 64-bit subnet prefix of the CGA.
Collision Count
This is an eight-bit unsigned integer that MUST be 0, 1, or 2. The
collision count is incremented during CGA generation to recover
from an address collision detected by duplicate address detection.
Public Key
This is a variable-length field containing the public key of the
address owner. The public key is the one that used to generate
the CGA address. The concrete desire of the format of the public
key is described in [3].
6. Protocol Description
In this document, we only focus on the data traffic between MN and
CN/HA, but not the signaling message such as BU, BA, RRT and etc.
In the real world, the signaling message will also be blocked by
firewalls, but that case could be dealt with easily by other means.
So in this document, it is assumed that the signaling messages could
pass through the firewall freely, only the data traffic is concerned.
Another assumption is that the firewall could identify the home
address of MN, it means that firewall takes the HoA as the filtering
information and also checks the packets with that address. This means
could simplify the protocol and improve the efficiency.
The implementation of the above two assumption is described clearly
in the[5], draft-miao-mip6-ft-01.
As described in section 2, there are some reasons that may cause the
firewall switching. But, whatever the reason is, a binding update
Zhang, et al. Expires: November 2006 [Page 12]
draft-zhang-mip6-fsup-01 May 2006
procedure is always between the firewall switching and the following
data traffic. The data traffic from MN to CN will be routed along the
same path as BU message, and the data traffic from CN to MN will be
routed along the same path as BA message. So the BU/BA message could
be considered as the indication of the potential data traffic.
6.1 Modification to Mobile IPv6
All the MN/CN/HA must support the CGA address, they should be able to
generate and verify the CGA address. In this document, the CGA
address is used to authenticate the filtering state update message
only, but it can be utilized for other purpose, such as protecting the
binding update message in Mobile IPv6.
Two mobility option, CGA Parameter Option and Public Key Option, are
introduced into mobile IPv6 protocol.
The CGA Parameter Option is required by CGA address, the receiver
could use the parameter to authenticate the CGA address. In this
document, the parameter is not used directly.
The Public Key Option contains the public key of the destination
node, that is to say, it contains the public key of CN in the BU
message sent to CN, the public key of HA in the BU message sent to HA
and public key of MN in the BA message. The firewall intercepts the
incoming BU or BA message, gets the public key of the inner node and
encrypts the cookie with it in the next state_create_request message.
6.2. Protocol Process
The firewall intercepts the incoming BU or BA message, and gets the
information of addresses in the IP header. The firewall uses the
addrsses to search in the filtering state database. If there is
matching entries, it lets the BU/BA pass through and nothing else is
done. If there is no matching entry, it saves the address information
in the IP header and public key information in the Public Key Option.
After saving the related information, the firewall starts the
state_create_request message. It first generates a cookie randomly
for the inner node and then encrypts it using the inner node's public
key. The public key is got from BU/BA message in the previous step.
The cookie is stored in the local for authenticating the signature in
state_create_reply message in the futuer. The IP addresses of the
inner node and outer node and encrypted cookie are encapsulated into
the state_create_request message, and then the message was sent to
inner node.
When the inner node receives a state_create_request message, it uses
the IP information in the Inner Node Address and outer Node Address
Zhang, et al. Expires: November 2006 [Page 13]
draft-zhang-mip6-fsup-01 May 2006
fields as an indication to search in the kernel for the related
transport layer port number. After gaining the traffic infromation,
it then decrypts the cookie with the private key related with the CGA
address and signs a signature. The cookie is in the encrypted cookie
field, this could assure that only the node having the private key
could know the cookie. The signature is computed as,
Signature = First (128, DSA (Cookie | Inner Node Address | Outer Node
Address | Inner Node Port | Outer Node Port)). The signature could
guarantee that the traffic information is not modified and the
information is indeed sent from the desired inner node. The
state_create_reply message is then completed with the CGA parameter
appended and sent to firewall.
When the firewall receives the state_create_reply message, it must
authenticate the message and the traffic state information. The
authentication procedure is as follows:
o Compare the public key previously stored locally with the public
key in the state_create_reply message.
o Authenticate the CGA address. The details of the authentication
procedure is described in [3].
o Authenticate the signature by recomputing the signature with the
locally stored cookie. This could assure the state_create_reply
message is not replied, because the cookie is generated randomly
each time for each node.
After the authentication, the traffic state information is considered
authentic. The firewall could use the provided information, inner
node address, outer node address, inner node port and outer node
port, to update the filtering state database securely.
The following figure illustrates the signaling exchange procedure
when the mobile node moves into a new network protected by firewall.
The incoming BA message indicates the potential new MN, and the
firewall configuration protocol is trigered.
Zhang, et al. Expires: November 2006 [Page 14]
draft-zhang-mip6-fsup-01 May 2006
++++++++++++++++++++++++++++++++++++++
Correspondent node Firewall Mobile node +
| + | +
| Binding Update (BU) | +
|<----------------------------------------------------| +
| + | +
| Binding Acknowledgement (BA) | +
|---------------------------------------------------->| +
| + | +
| +| state_create_request | +
| +|------------------------->| +
| +| | +
| +| state_create_reply | +
| +|<-------------------------| +
| +| | +
++++++++++++++++++++++++++++++++++++++
Figure 3: Signaling Exchange Procedure
7. Security Considerations
The cookie generated by firewall must be different for each inner
node and even each time moving happens.
This state update process could not prevent hijacking attack, the
information about IP address and transport layer port may be leaked.
But it is not sensitive, the following communication between MN and
CN may also expose the same thing.
8. Acknowledgments
I would like to appreciate all the project members Chen Jian,
Lu Hongmei, Ren Yan, Zhang Hui.
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[4] Fuyou Miao and Shen Yang, "Firewall Traversal for Mobile IPv6",
draft-miao-mip6-ft-01 (work in progress), November 2005.
Zhang, et al. Expires: November 2006 [Page 15]
draft-zhang-mip6-fsup-01 May 2006
[5] Le, F., "Mobile IPv6 and Firewalls: Problem statement",
draft-ietf-mip6-firewalls-03 (work in progress), October 2005.
10. Author's address
Yang Shen Tel: +86 10 5168 5677
IP Lab,EIES Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing http://iplab.njtu.edu.cn
China,100044 EMail: belton.yang@hotmail.com
Zhang Hongke Tel: +86 10 5168 5677
IP Lab,EIES Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing http://iplab.njtu.edu.cn
China,100044 EMail: hkzhang@center.njtu.edu.cn
Zhang Sidong Tel: +86 10 5168 5677
IP Lab,EIES Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing http://iplab.njtu.edu.cn
China,100044 EMail: sdzhang@center.njtu.edu.cn
Miao Fuyou Tel: +86 10 8288 2350
Huawei Technologies Fax: +86 10 8288 2537
No. 3, Xinxi Road, Shangdi, Haidian
Beijing
China,100085 Email: miaofy@huawei.com
Full Copyright Statement
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.
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 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.
Zhang, et al. Expires: November 2006 [Page 16]
draft-zhang-mip6-fsup-01 May 2006
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.
Expiration
This Internet-Draft (draft-zhang-mip6-fsup-01) expires in
November 2006.
Zhang, et al. Expires: November 2006 [Page 17]
