MIPSHOP WG Gabor Bajko
Internet Draft Nokia
Intended Status: Standards Track Subir Das
Expires: August 8, 2008 Telcordia
February 8, 2008
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
Mobility Server (MoS) discovery
draft-bajko-mos-dhcp-options-02
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 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines a number of Dynamic Host Configuration
Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a
list of domain names or IP addresses that can be mapped to servers
providing IEEE 802.21 type of Mobility Services. These Mobility
Services are used to assist an MN in handover preparation (network
discovery) and handover decision (network selection). The services
addressed by this document are the Media Independent Handover
Services defined in [IEEE802.21].
Conventions used in this document
G. Bajko & S Das Expires 08/08/08 [Page 1]
Mobility Services DHCP Options August 2007
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.
Terminology and abbreviations used in this document
Mobility Services: comprises of a set of different services provided
by the network to mobile nodes to facilitate handover preparation
and handover decision.
Mobility Server: a network node providing Mobility Support Services.
MIH: Media Independent Handover, as defined in [IEEE802.21].
MIH Service: IS, ES or CS type of service, as defined in
[IEEE802.21].
Table of Content
1. Introduction ...................................................2
2. DHCPv4 Options for MoS Discovery................................3
2.1 Domain Name List .........................................4
2.2 IPv4 Address List ........................................5
3. DHCPv6 Options for MoS Discovery................................5
3.1 MoS Identifier Option.....................................6
3.2 IPv6 Relay Agent MoS Option...............................7
3.3 MoS Information Option....................................8
4. Option Usage...................................................10
4.1 Usage of DHCPv4 Options for MoS Discovery................10
4.2 Usage of DHCPv6 Options for MoS Discovery................11
5. Security Considerations .......................................11
6. IANA Considerations ...........................................11
7. Acknowledgements ..............................................12
8. Normative References ..........................................12
9. Informative References ........................................12
10. Author's Addresses ...........................................12
1. Introduction
IEEE 802.21 [IEEE802.21] defines three distinct service types to
facilitate link layer handovers across heterogeneous technologies:
a) Information Services (IS)
IS provides a unified framework to the higher layer entities
across the heterogeneous network environment to facilitate discovery
and selection of multiple types of networks existing within a
geographical area, with the objective to help the higher layer
mobility protocols to acquire a global view of the heterogeneous
networks and perform seamless handover across these networks.
b) Event Services (ES)
G. Bajko & S. Das Expires 08/08/08 [Page 2]
Mobility Services DHCP Options August 2007
Events may indicate changes in state and transmission behavior
of the physical, data link and logical link layers, or predict state
changes of these layers. The Event Service may also be used to
indicate management actions or command status on the part of the
network or some management entity.
c) Command Services (CS)
The command service enables higher layers to control the
physical, data link, and logical link layers. The higher layers may
control the reconfiguration or selection of an appropriate link
through a set of handover commands.
In IEEE terminology these services are called Media Independent
Handover (MIH) services.
While these services may be co-located, the different pattern and
type of information they provide does not necessitate the co-
location.
An MN may make use of any of these MIH service types separately or
any combination of them.
In practice a Mobility Server may not necessarily host all three of
these MIH services together, thus there is a need to discover the
MIH services types separately.
This document defines three dhcpv4 options, one for each of the
services defined in [IEEE802.21], which allow the MN to locate a
Mobility Server which hosts the desired service type (i.e. IS, ES or
CS). The document also defines three DHCPv6 options which allow the
MN to discover Mobility Servers hosting MIH services in different
deployment scenarios. Apart from manual configuration, this is one
of the possible solutions for locating a server providing Mobility
Services.
2. DHCPv4 Options for MoS Discovery
This section describes the three options for DHCPv4.
The DHCPv4 options for MoS discovery carry either a 32-bit (binary)
IPv4 address or, preferably, a DNS [RFC1035] fully-qualified domain
name (FQDN) to be used by the MN to locate a server hosting either
an IS, an ES or a CS MIH service.
The options have two encodings, specified by the encoding byte
('enc') that follows the code byte. If the encoding byte has the
value 0, it is followed by a list of domain names, as described
below (Section 2.1). If the encoding byte has the value 1, it is
followed by one or more IPv4 addresses (Section 2.2). All
implementations MUST support both encodings.
A DHCP server MUST NOT mix the two encodings in the same DHCP
message, even if it sends two different instances of the same
option. Attempts to do so would result in incorrect client behavior
G. Bajko & S. Das Expires 08/08/08 [Page 3]
Mobility Services DHCP Options August 2007
as DHCP processing rules call for the concatenation of multiple
instances of an option into a single option prior to processing the
option [RFC3396].
The code for the MIH IS option is XXX (to be assigned by IANA, TBD).
The code for the MIH ES option is YYY (to be assigned by IANA, TBD).
The code for the MIH CS option is ZZZ (to be assigned by IANA, TBD).
2.1 Domain Name List
If the 'enc' byte has a value of 0, the encoding byte is followed by
a sequence of labels, encoded according to Section 3.1 of [RFC1035],
quoted below:
Domain names in messages are expressed in terms of a sequence
of labels. Each label is represented as a one octet length
field followed by that number of octets. Since every domain
name ends with the null label of the root, a domain name is
terminated by a length byte of zero. The high order two bits of
every length octet must be zero, and the remaining six bits of
the length field limit the label to 63 octets or less. To
simplify implementations, the total length of a domain name
(i.e., label octets and label length octets) is restricted to
255 octets or less.
[RFC1035] encoding was chosen to accommodate future international-
lized domain name mechanisms. The minimum length for this encoding
is 3.
The option MAY contain multiple domain names, but these SHOULD refer
to different NAPTR records, rather than different A records. The
client MUST try the records in the order listed, applying the
mechanism described in [MoS-DNS] for each. The client only resolves
the subsequent domain names if attempts to contact the first one
failed or yielded no common transport protocols between the MN and
the server.
Use of multiple domain names is not meant to replace NAPTR and SRV
records, but rather to allow a single DHCP server to indicate MIH
servers operated by multiple providers.
Clients MUST support compression according to the encoding in
Section 4.1.4 of "Domain Names - Implementation And Specification"
[RFC1035].
Since the domain names are supposed to be different domains,
compression will likely have little effect, however.
If the length of the domain list exceeds the maximum permissible
within a single option (254 octets), then the domain list MUST be
represented in the DHCP message as specified in [RFC3396].
G. Bajko & S. Das Expires 08/08/08 [Page 4]
Mobility Services DHCP Options August 2007
The DHCP option for this encoding has the following format:
Code Len enc DNS name of MoS server
+-----+-----+-----+-----+-----+-----+-----+-----+--
| XXX | n | 0 | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
As an example, consider the case where the server wants to offer two
MIH IS servers, "example.com" and "example.net". These would be
encoded as follows:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|XXX|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
2.2 IPv4 Address List
If the 'enc' byte has a value of 1, the encoding byte is followed by
a list of IPv4 addresses indicating appropriate MIH servers
available to the MN. Servers MUST be listed in order of preference.
Its minimum length is 5, and the length MUST be a multiple of 4 plus
one. The DHCP option for this encoding has the following format:
Code Len enc IPv4 Address 1 IPv4 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| XXX | n | 1 | a1 | a2 | a3 | a4 | a1 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
3. DHCPv6 Options for MoS discovery
This section introduces new DHCPv6 options used for MoS discovery.
Whether the MN receives an MoS address from local or home network
will depend on the actual network deployment. In general, following
rules apply to discovery rules:
a) In a split scenario, where the network access authentication is
independent of the home network authentication, the MN will discover
the MoS in the local (visited) network.
b) In an integrated scenario, where the network access
authentication is performed by the home network, the MN will
discover the MoS as per the home network policy, usually stored in
the subscription profile. When the policy dictates that an MoS
located in the home network has to be used, the address of the MoS
from the home network may be sent to a NAS (via AAA protocols) to
the visited network during the authentication procedure.DHCP relay
G. Bajko & S. Das Expires 08/08/08 [Page 5]
Mobility Services DHCP Options August 2007
agent may be provisioned accordingly to foward the MOS address to
the DHCP Server.
The DHCPv6 options defined in this section together with the
procedures defined in section 4 can support both scenarios.
3.1 MoS Identifier Option
This option is included in the Information-request message and used
to request the address of a specific (e.g., IS, ES, CS or its
combination) MoS-type from a DHCP server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION IPv6-MoS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MoS-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code
OPTION_IPv6-MoS (TBD) - 2 bytes
option-len
2 bytes
MoS-Type
The type of Mobility Services the MN is looking for,
i.e. IS, ES or CS or a combination of these:
1 IS service
2 ES service
3 both IS and ES services
4 CS service
5 IS and CS services
6 ES and CS services
7 IS, ES and CS services
3.2 IPv6 Relay Agent MoS Option
This option carries the home network information which was
transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius-MoS,
TBD]. The DHCP relay agent sends this option to the DHCP server in
the Relay-forward Message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IPv6-MoS-RELAY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G. Bajko & S. Das Expires 08/08/08 [Page 6]
Mobility Services DHCP Options August 2007
. sub-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code
OPTION_IPv6-MoS-RELAY (TBD) - 2 bytes .
option-len
The length of sub-options
sub-options
A series of IPv6 Relay Agent sub-options.
3.2.1. IPv6 Relay Agent Sub-option
This sub-option carries the MoS information to the DHCP server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt-code | sub-opt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MoS Type | |
+-+-+-+-+-+-+-+-+ MoS Information .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sub-opt-code
A 16-bit unsigned integer for the type of the following
MoS Information field. Possible values are:
1 MoS IP address list
2 MoS FQDN list
sub-opt-len
1 + the length of MoS Information field.
MoS type
The type of MoS services the server supports. Valid
values:
1 IS service
2 ES service
3 both IS and ES services
4 CS service
5 IS and CS services
G. Bajko & S. Das Expires 08/08/08 [Page 7]
Mobility Services DHCP Options August 2007
6 ES and CS services
7 IS, ES and CS services
MoS Information
An MoS IP address or MoS FQDN to be provided to a mobile
node according to the sub-opt-code.
When the sub-opt-code is set to 1, the MoS Information field MUST
contain the 128-bit IPv6 address of the MoS.
When the sub-opt-code is set to 2, the MoS Information field MUST
contain the FQDN of the MoS as described in Section 8 of [RFC3315].
Multiple sub-options may exist in a IPv6 Relay Agent option to carry
more than one MoS Information (IPv6 address or FQDN).
3.3 MoS Information Option
This option is included in the Reply message and used to carry MoS
information to the mobile node in the form of one or more of MoS IP
address(es) or MoS FQDN(s).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IPv6-MoSINF | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. sub-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code
OPTION_IPv6-MoSINF (TBD).- 2 bytes
option-len
length of sub-options
sub-options
A series of MoS Information sub-options.
3.3.1 MoS Information Sub-option
This sub-option carries the assigned MoS information to the DHCP
client.
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
G. Bajko & S. Das Expires 08/08/08 [Page 8]
Mobility Services DHCP Options August 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt-code | sub-opt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MoS Type | |
+-+-+-+-+-+-+-+-+ +
. MoS Information .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sub-opt-code
A 16-bit unsigned integer for the type of the following
MoS Information field. Possible values are:
1 MoS IP address
2 MoS FQDN
sub-opt-len
1 + length of MoS Information field.
MoS type
An 8 bit integer specifying the type of MoS services the
server supports. Valid values are:
0 NULL
1 IS service
2 ES service
3 both IS and ES services
4 CS services
5 IS and CS services
6 ES and CS services
7 IS, ES and CS services
MoS Information
An MoS IP address or MoS FQDN to be provided to a mobile
node according to the sub-opt-code.
The sub-opt-code, sub-opt-len and MoS Information fields are set in
the same manner as those of an IPv6 Relay Agent sub-option.
When MoS type equals NULL, the content of the MoS Information field
MUST be considered NULL.
4. Option Usage
4.1 Usage of DHCPv4 Options for MoS Discovery
G. Bajko & S. Das Expires 08/08/08 [Page 9]
Mobility Services DHCP Options August 2007
The requesting and sending of the proposed DHCPv4 options follow the
rules for DHCP options in [RFC2131].
4.1.1 Mobile Node behavior
The mobile node may perform the MoS information discovery procedure
either during initial association with a network or when the
mobility service is required. It may also try to perform the MoS
information discovery when it lacks the network information for MoS
or needs to change the MoS for some reasons, for instance, to
recover from the single point of failure of the existing MoS.
In order to acquire the MoS information, the mobile node MUST send
either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or
a unicast server address, respectively. In this message the mobile
node (DHCP client) MUST include the Option Code for the MoS
Discovery in the options field.
4.1.2 DHCP Server behavior
When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message
with the MoS Discovery option in the options field, the DHCP server
MUST follow the [RFC2131] logic to construct either a DHCPOFFER or
DHCPACK message including the MoS Discovery option. The reply
message may contain the IP address or the FQDN of the MoS Server.
In case that the server cannot find any MoS information, it MUST
return the MoS Discovery option by setting the MoS Server address
0.0.0.0 with 'enc' 1.
4.2 DHCPv6 Options for MoS discovery
The requesting and sending of the proposed DHCPv6 options follow the
rules for DHCP options in [RFC3315].
4.2.1 Mobile node behavior
The mobile node may perform the MoS information discovery procedure
either during initial association with a network or when the
mobility service is required. It may also try to perform the MoS
information discovery when it lacks the network information for MoS
or needs to change the MoS for some reasons, for instance, to
recover from the single point of failure of the existing MoS
In order to acquire the MoS address, the mobile node MUST send an
Information-request message to the All_DHCP_Relay_Agents_and_Servers
multicast address. In this message the mobile node (DHCP client)
MUST include the Option Code for the MoS Discovery option in the
option_code.
4.2.2 DHCP Relay Agent behavior
G. Bajko & S. Das Expires 08/08/08 [Page 10]
Mobility Services DHCP Options August 2007
Upon receiving the Information-request from the mobile node, the
DHCP relay agent MUST forward the message to the DHCP server as per
[RFC3315].
If the relay agent determines that the AAAV/NAS has passed MoS
information for this mobile node and has available MoS information
for it, the relay agent MUST include the MoS information in the MIP6
Relay Agent option, and attach this option in the Relay-forward
message.
In case the relay agent does not maintain any MoS information for
the requesting mobile node, it simply forwards the received message
to the DHCP server according to the [RFC3315].
Upon receiving a Relay-reply message from the DHCPv6 server, the
relay agent MUST follow the guidelines defined in [RFC3315]. The
relay agent extracts the Reply message from the Relay Message option
in the Relay-reply message and relays it to the mobile node.
4.2.3 DHCP Server behavior
When the DHCP Server receives the Information-request message with
the MoS Identifier option in the Relay-forward message, it looks for
a MIP6 Relay Agent Option containing MoS Information. The
Information-request message may not include the MIP6 Relay Agent
option in case there was no MoS information available at the NAS /
DHCP Relay Agent for a mobile node.
The DHCP server MUST follow the following logic to construct a Reply
message with the MoS Information option, and include the Reply
message in the payload of a Relay Message option of Relay-reply
message.
If the DHCP server has the requested MoS information, it MUST
include the information in the MoS Information option. The server
may provide the matching information either extracted from the MIP6
Relay Agent option or from the preconfigured information available
locally.
5. Security Considerations
The security considerations in [RFC2131] apply. If an adversary
manages to modify the response from a DHCP server or insert its own
response, an MN could be led to contact a rogue Mobility Server,
possibly one that then would provide wrong information, event or
command for handover.
It is recommended to use either DHCP authentication option described
in [RFC3118] where available, or rely upon link layer security. This
will also protect the denial of service attacks to DHCP servers.
[RFC3118] provides mechanisms for both entity authentication and
message authentication.
6. IANA Considerations
G. Bajko & S. Das Expires 08/08/08 [Page 11]
Mobility Services DHCP Options August 2007
This document registers the following dhcpv4 options with IANA:
IPv4-IS
IPv4-ES
IPv4-CS
This document also registers the following dhcpv6 options with IANA:
IPv6-MoSINF
IPv6-MoS
This document also registers the following dhcpv6 Relay options with
IANA:
IPv6-MoS-RELAY
7. Acknowledgements
Acknowledgements to the design team members for their comments.
8. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
RFC3396, November 2002.
[RFC3118] Authentication for DHCP Messages, Droms et al, June 2001
[RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6),
Droms et al, July 2003
9. Informative References
[IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services
[MoS-DNS] Bajko, G. " Locating Mobility Servers", draft-bajko-mos-
dns-discovery-01, November 2007, work in progress.
10. Authors' Addresses
Gabor Bajko
G. Bajko & S. Das Expires 08/08/08 [Page 12]
Mobility Services DHCP Options August 2007
Nokia
gabor.bajko@nokia.com
Subir Das
Telcordia
subir@research.telcordia.com
G. Bajko & S. Das Expires 08/08/08 [Page 13]
Mobility Services DHCP Options August 2007
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).
G. Bajko & S. Das Expires 08/08/08 [Page 14]