Network Working Group T. Kauppinen
Internet-Draft H. Mahkonen
Expires: April 19, 2007 M. Kuparinen
C. Larsson
H. Levkowetz
Ericsson AB
October 16, 2006
Filter Interface Identifier Binding in Mobile IPv6
draft-kauppinen-monami6-binding-filter-rule-00.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 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Mobile nodes using more than one interface for communicating with
other nodes in the network need a mechanism that controls how these
interfaces are used. One way of controlling the interface usage is
to define rules that map flows to network interfaces. These rules
can also be called filter rules that are bound to Filter Interface
Kauppinen, et al. Expires April 19, 2007 [Page 1]
Internet-Draft BFIID October 2006
Identifiers.
This document describes a mechanism to associate Filter Interface
Identifiers with the current location information of a mobile node in
case when the mobility protocol used by the mobile node is Mobile
IPv6.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Additions to BID Sub-option . . . . . . . . . . . . . . . . . 7
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Filter Interface Identifier Binding . . . . . . . . . . . 10
5.1.1. Sending FIID Bindings in a Binding Update . . . . . . 10
5.1.2. Receiving FIID Bindings in a Binding Update . . . . . 11
5.1.3. Creating and updating FIID Bindings . . . . . . . . . 12
5.1.4. Removing FIID Bindings . . . . . . . . . . . . . . . . 12
5.1.5. Error Handling in FIID Bindings . . . . . . . . . . . 13
5.1.6. Storing FIID Bindings . . . . . . . . . . . . . . . . 13
5.2. Binding an FIID to multiple BIDs . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Kauppinen, et al. Expires April 19, 2007 [Page 2]
Internet-Draft BFIID October 2006
1. Requirements notation
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].
Kauppinen, et al. Expires April 19, 2007 [Page 3]
Internet-Draft BFIID October 2006
2. Introduction
A Mobile Node (MN) is said to be simultaneous multiaccess capable if
it can attach to the Internet with several network interfaces at the
same time. In addition, the MN might have a need to route different
traffic flows trough different network interfaces simultaneously.
The Filter Rules draft [4] describes a way to perform flow
distribution between multiple interfaces of an MN. It describes how
a traffic flow can be represented by using the OpenBSD Packet Filter
syntax. The syntax is used to define rules called Filter Rules that
bind a flow to a Filter Interface Identifier (FIID). The
functionality specified in the draft is designed to be mobility
protocol independent and it therefore lacks details how to bind FIIDs
to network interfaces.
The Multiple Care-of Address (MCoA) draft [3] presented in the
Monami6 WG adds support for Mobile IPv6 [2] MNs to register multiple
CoAs for a single Home Address (HoA). The draft specifies a Binding
Unique Identifier (BID) which is used to uniquely identify a single
CoA. The BID can be reused when the MN performs a handover and the
CoA associated with the BID is changed. The BID can also be used to
remove the CoA from Mobile IPv6 data structures if the CoA is no
longer configured on any of the MNs network interfaces.
The association between a CoA and a Filter Rule is done by using the
BID of the CoA [3] and the FIID of the Filter Rule [4]. This
document describes how FIID to BID associations are distributed in
the Binding Update (BU) message inside a BID sub-option that has the
additional fields for FIIDs.
Figure 1 shows how different entities are related to each other. It
also shows where these entities are defined. This document defines
the association between the FIID ([4]) and the BID ([3]) entities.
Kauppinen, et al. Expires April 19, 2007 [Page 4]
Internet-Draft BFIID October 2006
MN Filter MN FIIDs BUL/BC HA FIIDs HA Filter
+-------+ +-------+
|Rule 1 |---+ +-------+ +---------+ +-------+ +---|Rule 1 |
+-------+ +--| fiid1 |--|BID1 CoA1|--| fiid1 |--+ +-------+
|Rule 2 |--+ +-------+ +---------+ +-------+ +--|Rule 2 |
+-------+ | +-------+ +---------+ +-------+ | +-------+
|Rule 3 |--+---| fiid2 |--|BID2 CoA2|--| fiid2 |---+--|Rule 3 |
+-------+ +-------+ +---------+ +-------+ +-------+
| ... | +-------+ +---------+ +-------+ | ... |
+-------+ +--| fiidN |--|BIDn CoAN|--| fiidN |--+ +-------+
|Rule n |---+ +-------+ +---------+ +-------+ +---|Rule n |
+-------+ +-------+
<----------------------> <--------->
Filter Rule [4] MCoA [3]
<-->
This document
Figure 1: Overview of Filter Interface Identifier Binding in Mobile
IPv6
The solutions described in [4] and in this document enable one FIID
(Filter Rule) to be mapped to one or more BIDs (one or more CoAs) or
several FIIDs to be mapped to one BID. Therefore, bi-casting and
load balancing functionality for the MN must also be considered. In
addition, the mechanism supports also bulk registration, i.e. sending
more than one flow binding in a single BU, with the home agent (HA)
and the correspondent node (CN). The importance of the bulk
registration with both the HA and the CN is pointed out in [5].
Kauppinen, et al. Expires April 19, 2007 [Page 5]
Internet-Draft BFIID October 2006
3. Terminology
Binding Unique Identification number (BID)
Binding Unique Identifier (BID) identifies a binding between a HoA
and a CoA. The BID is used when multiple CoAs are bound to a
single HoA. These bindings can be referenced with a BID. The BID
is specified in [3].
Filter Rule
Filter Rule distinguishes a traffic flow from one node to another.
A traffic flow is typically defined by the source and destination
addresses and ports and the used protocol. The Filter Rule
creation and distribution is specified in [4].
Filter Interface Identifier (FIID)
A Filter Interface Identifier (FIID) identifies a Filter Rule.
The creation of FIIDs is described in [4] whereas this document
describes a way to associate FIIDs with BIDs [3]. This
association is called an FIID binding.
Kauppinen, et al. Expires April 19, 2007 [Page 6]
Internet-Draft BFIID October 2006
4. Additions to BID Sub-option
The Binding Unique Identifier sub-option is added into a BU message
by an MN when it is registering new CoAs with its HA or CNs [3].
This section proposes a few modifications to the BID sub-option in
order to support FIID bindings.
The sub-option is extended by adding a new field and introducing two
new flags which are allocated from the Reserved field. The size of
the Reserve field is therefore reduced by two bits.
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) |Priority/Status|C|R|D|F| Res. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Address (CoA) +
| |
+---------------------------------------------------------------+
| Filter Interface ID 1 | FIID2 |
+---------------------------------------------------------------+
...
+-------------------------------+
+ FIIDN |
+-------------------------------+
Type
Type value for Filter Rule Identifier sub-option will be assigned
later.
Length
Length value is 4+N*2 when the C flag is unset. Length value is
20+N*2 when the C flag is set. N is the number of included FIIDs.
Binding Unique ID (BID)
The BID which is assigned to the binding carried in the BU with
this sub-option. BID is 16-bit unsigned integer. A value of zero
is reserved.
Kauppinen, et al. Expires April 19, 2007 [Page 7]
Internet-Draft BFIID October 2006
Priority/Status
When the Binding Unique Identifier sub-option is included in a
Binding Update, this field indicates the priority field assigned
to each binding. The receiver can utilize this priority to
determine which binding is used to deliver packets. The priority
is 8-bit unsigned integer. A value of zero indicates No Priority.
The higher value has higher priority.
When the Binding Unique Identifier sub-option is included in a
Binding Acknowledgment, this field indicates the status
correspondent to each binding in a bulk registration mode. The
mobile node can know the registration status of each binding. The
status is 8-bit unsigned integer. The possible status codes are
listed below. If the status field is below 128, it indicates that
the binding registration was successful.
ACCEPTING BID SUB-OPTION (0)
The registration of the correspond binding is successfully
operated.
INCOMPLIANT BID SUB-OPTION (128)
Registration failed because Binding Unique Identifier sub-
option is not compliant ([3]).
UNKNOWN FIID (129)
Flow binding failed because no filter rule matching the
specified FIID exists.
Filter Interface Identifier (FIID)
A set of Filter Interface Identifiers (here 16 bits are used for a
single FIID).
Delete (D) flag
When set, this flag indicates that bindings for specified FIIDs
MUST be removed. The MN can use this flag to remove binding for a
specific FIID or FIIDs. If the D flag is set then the F flag MUST
NOT be set.
Kauppinen, et al. Expires April 19, 2007 [Page 8]
Internet-Draft BFIID October 2006
Flush All (F) flag
When set, this flag indicates that all existing FIID bindings for
a specific BID MUST be removed prior to adding listed FIIDs. The
MN can use this flag to quickly substitute all existing bindings
for a specific BID with specified FIIDs. If the F flag is set
then the D flag MUST NOT be set.
Res.
4 bits Reserved field. Reserved field must be set with all 0.
It should be noted that both the D flag and the F flag MUST NOT be
set at the same time. Use of these flags is further described in
Section 5.1.1 and Section 5.1.4.
Kauppinen, et al. Expires April 19, 2007 [Page 9]
Internet-Draft BFIID October 2006
5. Protocol Overview
This section describes how FIID bindings are maintained and managed.
FIID bindings are sent inside the BID sub-option which is included in
the Binding Update message. Binding Update messages are sent when
the Mobile Node changes its location in the network or when FIIDs are
created or removed.
5.1. Filter Interface Identifier Binding
A Mobile Node (MN) creates and distributes Filter Rules with the
described in [4]. When the MN creates a Filter Rule it binds the
rule to an Filter Interface Identifier (FIID). This FIID must also
be associated with a network interface.
The MCoA draft [3] describes how multiple Care-of Addresses (CoAs)
can be associated with a Home Address by defining a Binding Unique
Identifier (BID). In this document we refer to a network interface
with one of its CoAs. Therefore the association between the FIID and
the BID effectively creates a binding between a FIID and a network
interface. This binding is called a Filter Interface Identifier
Binding or an FIID binding.
5.1.1. Sending FIID Bindings in a Binding Update
When an MN is sending a normally scheduled BU message it MUST check
if the message is going to be sent to the Home Agent (HA) or the
Correspondent Node (CN). In addition, the MN checks if the CoAs
which are being registered in the BU message have FIID bindings which
has not yet been sent to the peer node (HA or CN). If the peer node
is an HA of the MN it must always have all the FIID bindings up to
date. If the peer node is a CN only the FIID bindings used between
these nodes need to be up to date.
FIID bindings are added to the BU message inside a BID sub-option
which is described in the MCoA draft [3]. The additional fields to
carry FIIDs in BID sub-option are described in Section 4. Each FIID
which is associated with a specific BID MUST be added into a BID sub-
option carrying the BID in question. This means that the same FIID
MAY be added into more than one BID sub-option and that one BID sub-
option MAY hold more than one FIID.
If an MN creates a new FIID it MUST be sent to the peer nodes even if
the MN has no normally scheduled BU messages. For this purpose the
MN sends an unscheduled BU message which contains all the BIDs in BID
sub-options which are associated with the new FIID. In this case
it's possible to leave the CoAs out of the BID sub-options because
the receiver is already aware of the BID to CoA mapping.
Kauppinen, et al. Expires April 19, 2007 [Page 10]
Internet-Draft BFIID October 2006
The MN MAY have a need to update (remove/replace) several BIID
bindings in one BU message. The MN can use the D and F flags in the
BID sub-option (Section 4) to manage these simultaneous updates. Use
of the D flag is described in Section 5.1.4. The D flag is used to
remove specific BIID bindings from a specific BID. It should,
however, be noted that both the D flag and the F flag MUST NOT be set
at the same time.
The F flag can be used to replace all BIID bindings for a specific
BID with a set of new ones. When the F flag is set in the BID sub-
option all existing BIID bindings MUST BE removed prior to adding new
bindings. If the F flag is not set in the BID sub-option, BIID
bindings MUST be appended to the set of existing BIID bindings for
the specified BID.
5.1.2. Receiving FIID Bindings in a Binding Update
When a node receives a BU message containing BID sub-option(s) which
carry a number of FIIDs it MUST first proceed with the normal
processing of BID sub-options [3]. It MUST then check that the FIIDs
included in the sub-options are known to the node. If an FIID is
known to the node it associates the FIID with the specified BID. If
the FIID is unknown, the node MUST inform this to the MN by adding
the unknown FIID into a BID sub-option. The BID sub-option is added
into a Binding Acknowledgement (BA) message that is sent in reply to
the BU sent by the MN.
Because the mechanisms described in [3] and in this document MUST be
compliant with legacy MIPv6 nodes the receiver of a BU message MUST
reply with a BA message which contains at least one BID sub-option.
The existence of the BID sub-option in the BA message indicates that
the peer node (HA or CN) is MCoA and FIID compliant. If the BA
message contains no BID sub-options the MN MUST assume that the peer
node does not support MCoA and FIID binding mechanisms. In this case
the MN MUST NOT send BID sub-options to this peer node and therefore
FIID bindings cannot be made. If the peer node supports only the
MCoA mechanism and not the FIID binding mechanism a BID sub-option
which includes one or more FIIDs will result to an error. This is
due to the fact that valid lengths of the BID sub-option specified in
[3] are either 4 or 20 depending on the state of the C flag.
However, the BID sub-option specified in this document has the length
of 4+N*2 when the C flag is unset and 20+N*2 when the C flag is set.
In the case when the peer node receives a BID sub-option which is of
invalid size, it should reply with an error. This error will be
signaled inside a BID sub-option to the MN. In this case the MN MUST
NOT resend FIID bindings in the BID sub-option for this peer node.
Kauppinen, et al. Expires April 19, 2007 [Page 11]
Internet-Draft BFIID October 2006
5.1.3. Creating and updating FIID Bindings
FIID bindings on the node receiving the BU can be created and updated
by including FIID in the BID sub-options. If either the D nor the F
flag is set, FIID listed in the BID sub-option are appended to the
list of existing FIID bindings for the specified BID. If the F flag
is set, the current list of FIID bindings for the specified BID is
purged prior to adding listed FIID bindings.
The FIID(s) SHOULD NOT be added into the BID option every time BU
message is sent because the MCoA draft [3] describes a way to reuse
the BID when the CoA referenced with it changes. Normally the
traffic flows of the MN remain the same even when the MN moves
between attachment points to the Internet. Therefore the MN does not
have to update FIID bindings after every handover. The association
between BID(s) and FIID(s) MUST be updated only if either FIIDs or
BIDs are added or removed.
5.1.4. Removing FIID Bindings
There are a few cases that result in FIID bindings being removed. An
FIID binding can either be removed explicitly or implicitly, i.e. as
a result of another action. FIID bindings, for example, do not have
a timer of their own but their existence is limited to the existence
of the filter rule and the BID they are linked to.
When a filter rule is removed, either due to a timeout or a delete
command, the FIID binding will be removed only if there are no other
filter rules associated with it. Filter rule timeout issues are
handled via the filter rule management [3].
If a BID is removed, all FIID bindings to the BID in question MUST
also be removed. It should, however, be noted that removing an FIID
binding does not necessitate the removal of the FIID (and the filter
rule) it's linked to. An FIID (and the filter rule) can exist
without being associated with any of the BIDs. In this case a
default binding should be used. The default binding is set by using
the Priority field of the BID sub-option [3]. However, if a BID
which is associated with a disabled FIID binding(s) is removed, the
disabled FIID binding(s) is/are also removed (Section 5.1.5).
The final case that results in FIID bindings being removed is when
either D or F flag is specified in the BID sub-option. If the D flag
is specified, the FIID bindings listed in the sub-option are removed.
In the case the F flag is set, all existing FIID bindings for a
specific BID are removed prior to adding any of the new FIID
bindings.
Kauppinen, et al. Expires April 19, 2007 [Page 12]
Internet-Draft BFIID October 2006
5.1.5. Error Handling in FIID Bindings
If the MN sends an FIID to a peer node in the BID sub-option which
does not match with any of the Filter Rules the peer node has, the
peer node must signal this error case to the MN. The peer node might
not have the Filter Rule because the Filter Rule might have expired
or the Filter Rule distribution might have failed. In either case
the peer node must signal the MN that the Filter Rule is not present
at the peer node which means that the MN SHOULD not expect the peer
node to direct the matching traffic flows to the CoA associated with
the Filter Rule.
The peer node adds the erroneous FIIDs into a BA message which is
sent to the MN in reply to the received BU message. The Status
fields in BA message header and BID sub-option must be used to
indicate an error in the FIID to the MN. To indicate the error in
the FIID a new status field value must be defined Section 4.
Even if the peer node could not match the FIID with any of the Filter
Rules it has it SHOULD add the FIID binding but disabled it. This
would make the FIID binding not to be useable until the corresponding
Filter Rule is received. This way the MN does not have to resend the
FIID binding after the Filter Rule has been sent to the peer node.
There SHOULD be a timer which expiration would trigger a removal of
disabled FIID bindings.
When an MN receives a BA message containing one or more BID sub-
options indicating the FIID(s) carried in the option were erroneous
it should check that these Filter Rules are still present. If the MN
has the associated Filter Rule(s) it must distribute these Filter
Rules to the peer node. If the MN does not have these Filter Rules
anymore it SHOULD send a BU message to remove the disabled FIID
binding sent in the first BU message. If the MN chooses not to send
a new BU message to remove the disabled FIID bindings the expiration
timer will eventually trigger the removal of these bindings.
5.1.6. Storing FIID Bindings
The actual location to store FIID bindings is outside the scope of
this document and is considered as an implementation specific detail.
It can be done by adding FIID to the Binding Cache or Binding Update
List [2] or by maintaining a pointer in the Filter Rule database
entry which points to a right BC/BUL entry etc. It is however
important that each Filter Rule is matched with an IP address which
should be used for the traffic flow matching the rule.
Kauppinen, et al. Expires April 19, 2007 [Page 13]
Internet-Draft BFIID October 2006
5.2. Binding an FIID to multiple BIDs
This document does not limit the number of BIDs an single FIID is
bound to. If an FIID is bound to multiple BIDs, however, a mechanism
to determine which of the BIDs to choose in any particular case must
then be applied. This feature enables such functionality as load
balancing and bi-casting. However, these topics are outside the
scope of this document.
Kauppinen, et al. Expires April 19, 2007 [Page 14]
Internet-Draft BFIID October 2006
6. Security Considerations
The mechanism described in this document uses the same security as
the Binding Update. It can therefore be used to prevent rogue nodes
from providing false FIID binding information to the HA and/or CN.
Kauppinen, et al. Expires April 19, 2007 [Page 15]
Internet-Draft BFIID October 2006
7. IANA Considerations
None.
Kauppinen, et al. Expires April 19, 2007 [Page 16]
Internet-Draft BFIID October 2006
8. Conclusions
This document describes a mechanism to associate Filter Interface
Identifiers (FIIDs) of the Mobile Node ([4]) with Binding Unique
Identifiers (BIDs) [3]. This is achieved by extending the BID sub-
option to carry an FIID in order to create an association, which in
this document is called an FIID binding.
The design in this document makes it possible to transfer Filter
Rules independently of Mobile IPv6 signaling, which is of interest in
order to widen the applicability of the mechanism.
Kauppinen, et al. Expires April 19, 2007 [Page 17]
Internet-Draft BFIID October 2006
9. References
9.1. Normative 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.
9.2. Informative References
[3] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006.
[4] Larsson, C., "A Filter Rule Mechanism for Multi-access Mobile
IPv6", draft-larsson-monami6-filter-rules-00 (work in progress),
June 2006.
[5] Kuparinen, M., "Multiple CoA Performance Analysis",
draft-kuparinen-monami6-mcoa-performance-00 (work in progress),
April 2006.
Kauppinen, et al. Expires April 19, 2007 [Page 18]
Internet-Draft BFIID October 2006
Authors' Addresses
Tero Kauppinen
Ericsson AB
Hirsalantie 11
02420 Jorvas
Finland
Phone: +358 9 299 3057
Email: tero.kauppinen@ericsson.com
Heikki Mahkonen
Ericsson AB
Hirsalantie 11
02420 Jorvas
Finland
Phone: +358 9 299 3213
Email: heikki.mahkonen@ericsson.com
Martti Kuparinen
Ericsson AB
Hirsalantie 11
02420 Jorvas
Finland
Phone: +358 9 299 2191
Email: martti.kuparinen@ericsson.com
Conny Larsson
Ericsson AB
Torshamnsgatan 23
Stockholm S-164 80
Sweden
Phone: +46 8 404 8458
Email: conny.larsson@ericsson.com
Kauppinen, et al. Expires April 19, 2007 [Page 19]
Internet-Draft BFIID October 2006
Henrik Levkowetz
Ericsson AB
Torshamnsgatan 71
Stockholm S-113 37
Sweden
Phone: +46 708 32 16 08
Email: henrik@levkowetz.com
Kauppinen, et al. Expires April 19, 2007 [Page 20]
Internet-Draft BFIID October 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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kauppinen, et al. Expires April 19, 2007 [Page 21]