One document matched: draft-wbeebee-nd-implementation-pitfalls-01.txt
Differences from draft-wbeebee-nd-implementation-pitfalls-00.txt
Network Working Group H. Singh
Internet-Draft W. Beebee
Intended status: Standards Track Cisco Systems, Inc.
Expires: December 31, 2007 June 29, 2007
Data Forwarding and ND Resolution Implementation Pitfalls
draft-wbeebee-nd-implementation-pitfalls-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 December 31, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
RFC 2461 [ND] describes host data forwarding and address resolution.
However, nine years after the ND protocol became an RFC, IPv6 hosts
still do not fully comply with RFC 2461 [ND]. In particular, hosts
incorrectly implement on- vs. off-link data forwarding. This
document clarifies host behavior and associated router behavior to
define explicitly address resolution and data forwarding models. The
set of new requirements beyond what has been specified in RFC 2461
[ND] and RFC 2462 [ADDRCONF] is restricted to clarifications deemed
Singh & Beebee Expires December 31, 2007 [Page 1]
Internet-Draft ND Implementation Pitfalls June 2007
necessary to facilitate correct implementation. The intention of
this document is to incorporate normative changes into
draft-ietf-ipv6-rfc2461bis-11 [NDbis] and
draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]. After this has been
accomplished, this document will be on track to become an
Informational RFC.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Host Models . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RA Sets M and O Bits but does not Include the Prefix
Information Option (PIO) . . . . . . . . . . . . . . . . . 5
2.2. RA Advertises a Prefix with the On-link(L) Bit Set . . . . 5
2.3. RA Advertises a Prefix with the On-link(L) Bit Clear . . . 7
3. Router Models . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Aggregation Router Deployment Model . . . . . . . . . . . 7
4. Redirect Clarifications . . . . . . . . . . . . . . . . . . . 8
5. Changes to draft-ietf-ipv6-rfc2461bis-11 . . . . . . . . . . . 8
6. Changes to draft-ietf-ipv6-rfc2462bis-08 . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Singh & Beebee Expires December 31, 2007 [Page 2]
Internet-Draft ND Implementation Pitfalls June 2007
1. Introduction
IPv6 host data forwarding and address resolution is complex. For
example, RFC 2461 [ND] (section 3.1) implies that if the RA received
by the host does not advertise any prefix, then the host must send
all non-link-local data to the default router. This section of the
RFC also implies that no address resolution is to be performed in
this case. Sections 5.2 and 7.2.2 imply that the host performs
address resolution before transmitting a packet if the destination of
the packet is on the same link as the host. Some current host
implementations perform address resolution in all cases even when the
destination is not clearly on-link. However, RFC 2461 [ND] section
6.3.4 implies that hosts must clearly determine that a destination is
on-link before performing address resolution.
These implications in RFC 2461 [ND] need to be made explicit.
Failure of host implementations to comply can result in lack of IPv6
connectivity. For example, a host receives an RA with no prefix
advertised and incorrectly decides to perform address resolution when
the host should have sent all traffic to the default router. The
router may not respond to the address resolution and the layer 2
driver of the host stops transmitting IPv6 packets.
Host address resolution has implications for router design and
deployment. First, host behavior is clarified in the Host Models
section. Second, a router deployment model is described in the
Router Models section. Third, Redirects are clarified for both
routers and hosts in the Redirect Clarifications section. Finally,
proposed changes to draft-ietf-ipv6-rfc2461bis-11 [NDbis] and
draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] are presented.
Where behavior has not changed between RFC 2461 [ND] and
draft-ietf-ipv6-2461bis-11 [NDbis] and behavior has not changed
between RFC 2462 [ADDRCONF] and draft-ietf-ipv6-rfc2462bis-08
[ADDRCONFbis], this document only refers to RFC 2461 [ND] and RFC
2462 [ADDRCONF] respectively. Where behavior has changed, this
document refers to both the original and the new version.
2. Host Models
A correctly implemented IPv6 host MUST adhere to the following rules:
1. On-link determination and address information MUST NOT persist
across IPv6 interface initializations.
2. The RA and Redirects from the default router are the only sources
of information for on-link determination. DHCPv6 or any other
Singh & Beebee Expires December 31, 2007 [Page 3]
Internet-Draft ND Implementation Pitfalls June 2007
configuration on the host MUST NOT be used for on-link
determination. Manual configuration of a host introduces its own
set of security considerations and is beyond the scope of this
document.
3. The host MUST NOT add a direct delivery route to the prefix from
an assigned address, independent of the information about the
prefix received from the RA or Redirects.
4. Newer host implementations MUST issue NS(DAD)s for all of its
acquired unicast addresses except when the host interface has
DupAddrDetectTransmits variable set to zero. Section 5.4 of RFC
2462 [ADDRCONF] erroneously relaxes this requirement and suffers
from a manual configuration problem as illustrated by the
following example:
Host1 uses EUI-64 to configure a Link Local Address (LLA)
using MAC1 and manually configures a Global Unicast Address
(GUA) that is equal to an address configured using EUI-64 and
MAC2. Host1 completes an NS(DAD) for both its LLA and GUA in
compliance with RFC 2462 [ADDRCONF]. Then, Host2 uses EUI-64
to configure both a LLA and a GUA using MAC2. Host2 completes
an NS(DAD) for the LLA and does not send an NS(DAD) for its
GUA in compliance with RFC 2462 [ADDRCONF]. Now Host1 and
Host2 have the same GUA on the same link.
Therefore, this exception in section 5.4 of RFC 2462 [ADDRCONF]
SHOULD be ignored. Note that draft-ietf-ipv6-rfc2462bis-08
[ADDRCONFbis] refers to an extensibility concern with new
implementations and states in section 5.4:
"Whereas this document does not invalidate such
implementations, this kind of 'optimization' is NOT
RECOMMENDED, and new implementations MUST NOT do that
optimization."
The "Changes to draft-ietf-ipv6-rfc2462bis-08" section in this
document describes the corresponding changes to
draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis].
5. The host SHOULD issue only a single NS(DAD) for each address.
The default value for DupAddrDetectTransmits variable is
specified as 1 in section 5.1 of RFC 2462 [ADDRCONF].
6. If the Default Router List is empty, the host MUST NOT assume
that all destinations are on-link. The host MUST NOT perform
address resolution for non-link-local addresses. The host SHOULD
send an ICMPv6 Destination Unreachable message instead.
Singh & Beebee Expires December 31, 2007 [Page 4]
Internet-Draft ND Implementation Pitfalls June 2007
draft-ietf-v6ops-onlinkassumption-04
[I.D.ietf-v6ops-onlinkassumptions] provides justification for
this rule.
The type of RA received can further determine host behavior.
2.1. RA Sets M and O Bits but does not Include the Prefix Information
Option (PIO)
Section 3.1 of RFC 2461 [ND] describes intended behavior when a host
receives an RA without an advertised prefix:
"Multiple prefixes can be associated with the same link. By
default, hosts learn all on-link prefixes from Router
Advertisements. However, routers may be configured to omit some
or all prefixes from Router Advertisements. In such cases hosts
assume that destinations are off-link and send traffic to routers.
A router can then issue redirects as appropriate."
An IPv6 router sends an RA with no prefix advertised and the M and O
bits set and does not send any Redirects. On receipt of the RA, the
host uses DHCPv6 to acquire an IPv6 address. After completing IPv6
address acquisition, the host MUST obey RFC 2461 [ND], section 3.1.
Since the RA is the only authority to a host for on-link
determination and this RA does not advertise any prefix, the host
cannot determine that a destination is on-link. Therefore, the host
MUST adhere to the following rules:
1. The host MUST NOT assume any default prefix length.
2. The host MUST send all non-link-local traffic to the default
router.
3. The host MUST NOT issue an NS to resolve a destination other than
a link-local address.
2.2. RA Advertises a Prefix with the On-link(L) Bit Set
Security consequences of RFC 2461 [ND] imply that hosts MAY send all
traffic to the default router without performing address resolution
first even when a PIO has been received advertising an on-link
prefix, regardless of whether the host performs DHCPv6 and/or
stateless autoconfiguration.
Section 4.6.2 of RFC 2461 [ND] defines the Valid Lifetime in the PIO
as:
Singh & Beebee Expires December 31, 2007 [Page 5]
Internet-Draft ND Implementation Pitfalls June 2007
"The length of time in seconds (relative to the time the packet is
sent) that the prefix is valid for the purpose of on-link
determination."
Section 11 of RFC 2461 [ND] mentions the following denial of service
attack:
"An example of denial of service attacks is that a node on the
link that can send packets with an arbitrary IP source address can
both advertise itself as a default router and also send 'forged'
Router Advertisement messages that immediately time out all other
default routers as well as all on-link prefixes."
The same security risk is also described in section 5.5.3 of RFC 2462
[ADDRCONF]. This section allows hosts to ignore the Valid Lifetime
stored in an RA in order to prevent denial of service attacks.
Section 6.3.4 of RFC 2461 [ND] mentions that hosts MAY send all
traffic to the default router without performing address resolution
first:
"Stateless address autoconfiguration RFC 2462 [ADDRCONF] may in
some circumstances increase the Valid Lifetime of a prefix or
ignore it completely in order to prevent a particular denial of
service attack. However, since the effect of the same denial of
service targeted at the on-link prefix list is not catastrophic
(hosts would send packets to a default router and receive a
redirect rather than sending packets directly to a neighbor) the
Neighbor Discovery protocol does not impose such a check on the
prefix lifetime values."
Consider the following scenario with one rogue node and two other
hosts on the same link. The rogue sends a malicious RA with an on-
link prefix with a Valid Lifetime of zero. Host1 correctly
implements section 5.5.3 of RFC 2462 [ADDRCONF] and resets its
StoredLifetime (or RemainingLifetime in draft-ietf-ipv6-rfc2462bis-08
[ADDRCONFbis]) to two hours and avoids the denial of service attack.
Host1 tries to send traffic to Host2, but cannot trust its own two
hour StoredLifetime. For instance, a legitimate operator may have
tried to time out the prefix due to an impending renumbering. Host1
decides to send all of its traffic to the on-link authority, the
default router, even though the destination prefix is on-link.
IF the host decides to send all traffic (including on-link traffic)
to the default router, then the host MUST follow the following rule:
1. The host MUST NOT issue an NS to resolve a destination other than
a link-local address.
Singh & Beebee Expires December 31, 2007 [Page 6]
Internet-Draft ND Implementation Pitfalls June 2007
2.3. RA Advertises a Prefix with the On-link(L) Bit Clear
Regardless of whether the host performs DHCPv6 and/or stateless
autoconfiguration, the host MUST adhere to the following rules for
addresses contained within the advertised prefix:
1. The host MUST NOT issue an NS to resolve a destination other than
a link-local address.
2. The host MUST send all non-link-local traffic to the default
router.
3. Router Models
The Redirect Clarifications section clarifies RFC 2461 [ND] host and
router behavior for an aggregation router deployment.
The Aggregation Router Deployment Model section presents a possible
aggregation router deployment model for IPv6 and discusses its
properties with respect to ND. Aggregation routers can service more
than 100,000 subscribers. Due to scaling considerations, any NS for
global address resolution from any host to any other host SHOULD NOT
reach the aggregation router.
3.1. Aggregation Router Deployment Model
A property of routed aggregation networks is that hosts cannot
directly communicate with each other even if they are on the same
link. This design is motivated by scaling and security
considerations. If every host could receive all traffic from every
other host, then the subscriber's privacy would be violated and the
amount of bandwidth available for each subscriber would be very
small. That is why hosts communicate between each other through the
aggregation router, which is also the IPv6 first-hop router.
For scaling reasons, any NS to resolve any address other than that of
the default router SHOULD NOT reach the aggregation router.
+-----+
| |
|Aggre+----(Rtr CPE)----Host1
Core----WAN----+gator|
| Rtr |
| +----(Br CPE)----(Cust Rtr)----Host2
+-----+
Singh & Beebee Expires December 31, 2007 [Page 7]
Internet-Draft ND Implementation Pitfalls June 2007
Figure 1.
In the figure above, the customer premises equipment (CPE) is managed
by the ISP and is deployed behind an aggregation router that is an
IPv6 first-hop router and also a DHCPv6 relay agent. IPv6 CPEs are
either IPv6 routers (Rtr CPE) or IPv6 bridges (Br CPE). If the
customer premises uses a bridge CPE, then a router (Cust Rtr) is
needed. All hosts reside behind a router CPE or a customer router.
No NS to resolve any address other that that of the default router
will reach the aggregation router from any device on the customer
side of the aggregator. CPEs do not communicate with each other in
this deployment model since a CPE does not run any applications that
need to communicate with other CPEs. Hosts do communicate with each
other, but every host is off-link to any other host on the
aggregation router.
4. Redirect Clarifications
Redirects are not sent by aggregation routers except when two hosts
behind the same bridge CPE, with no router between the host and the
aggregation router, communicate with each other. The aggregation
router sends a Redirect to a source host which communicates with a
destination host behind the same bridge CPE if the router can make a
determination that the two hosts lie behind the same bridge CPE.
Since the Redirect contains all the information need to resolve the
address of the destination host, the source host MUST NOT issue an NS
to resolve the destination contained within the Redirect.
5. Changes to draft-ietf-ipv6-rfc2461bis-11
The following paragraph from section 3.1 of
draft-ietf-ipv6-rfc2461bis-11 [NDbis] describes intended behavior
when a host receives an RA without an advertised prefix and needs to
change:
"Multiple prefixes can be associated with the same link. By
default, hosts learn all on-link prefixes from Router
Advertisements. However, routers may be configured to omit some
or all prefixes from Router Advertisements. In such cases hosts
assume that destinations are off-link and send traffic to routers.
A router can then issue redirects as appropriate."
to read as follows:
Singh & Beebee Expires December 31, 2007 [Page 8]
Internet-Draft ND Implementation Pitfalls June 2007
"Multiple prefixes can be associated with the same link. By
default, hosts learn all on-link prefixes from Router
Advertisements. However, routers may be configured to omit some
or all prefixes from Router Advertisements. In such cases hosts
assume that destinations are off-link and send traffic to routers.
A router can then issue redirects as appropriate. Without
advertised prefixes, without manual configuration, and without
redirects, hosts MUST NOT assume a default prefix length, MUST
send all non-link-local traffic to the default router and MUST NOT
issue an NS to resolve any destination other than a link-local
address.
All bullets except 4 from the Host Models section of this document
should be incorporated into draft-ietf-ipv6-rfc2461bis-11 [NDbis].
Then the subsections of Host Models should also be incorporated. The
precise locations of changes in draft-ietf-ipv6-rfc2461bis-11 [NDbis]
and the text are to be determined.
6. Changes to draft-ietf-ipv6-rfc2462bis-08
The following paragraph from section 5.4 of
draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] needs to change:
"Each individual unicast address SHOULD be tested for uniqueness.
Note that there are implementations deployed that only perform
Duplicate Address Detection for the link-local address and skip
the test for the global address using the same interface
identifier as that of the link-local address. Whereas this
document does not invalidate such implementations, this kind of
'optimization' is NOT RECOMMENDED, and new implementations MUST
NOT do that optimization. This optimization came from the
assumption that all of an interface's addresses are generated from
the same identifier. However, the assumption does actually not
stand; new types of addresses have been introduced where the
interface identifiers are not necessarily the same for all unicast
addresses on a single interface [RFC3041] [RFC3972]. Requiring to
perform Duplicate Address Detection for all unicast addresses will
make the algorithm robust for the current and future such special
interface identifiers."
to read as follows:
Each individual unicast address SHOULD be tested for uniqueness.
Note that some deployed implementations perform Duplicate Address
Detection (DAD) only for the link-local address and skip the test
for the global address using the same interface identifier.
Whereas this document does not invalidate such implementations,
Singh & Beebee Expires December 31, 2007 [Page 9]
Internet-Draft ND Implementation Pitfalls June 2007
this kind of 'optimization' is NOT RECOMMENDED, and new
implementations MUST NOT do that optimization. This optimization
came from the assumption that all of an interface's addresses are
generated from the same interface identifier (see RFC 2462
[ADDRCONF]). However, even with this assumption, skipping DAD for
non-link-local addresses with manual configuration creates an
additional problem. This optimization allows an interface to
claim a duplicate address in a way that would not be detected.
For a more detailed description of this problem, see the Host
Models section of
draft-wbeebee-nd-implementation-pitfalls-01. Further, new
types of addresses have been introduced where the interface
identifiers are not necessarily the same for all unicast addresses
on a single interface [RFC3041] [RFC3972]. Requiring an interface
to perform DAD for all unicast addresses will make the algorithm
more robust.
7. Security Considerations
The Host Models section of this document describes valid host
behavior in response to a security threat where a rogue node can send
RAs with a Valid Lifetime of zero. Host Models also describes a
problem with section 5.4 of RFC 2462 [ADDRCONF] that can allow two
hosts with the same address to avoid DAD and come online on the same
link.
8. IANA Considerations
None.
9. Acknowledgements
Thanks (in alphabetical order) to Adeel Ahmed, Alun Evans, Bernie
Volz, Dave Forster, Josh Littlefield, Madhu Sudan, Prashanth
Krishnamurthy, and Ralph Droms of Cisco, for their consistent input,
ideas and review during the production of this document.
10. References
10.1. Normative References
[ADDRCONF]
Thomson, S. and T. Narten, "IPv6 Address autoconfiguration
(IPv6)", RFC 2462, December 1998.
Singh & Beebee Expires December 31, 2007 [Page 10]
Internet-Draft ND Implementation Pitfalls June 2007
[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
10.2. Informative References
[ADDRCONFbis]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Address
autoconfiguration (IPv6)",
draft-ietf-ipv6-rfc2462bis-08 (Work In Progress),
May 2005.
[I.D.ietf-v6ops-onlinkassumptions]
Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
Discovery On-Link Assumption Considered Harmful (IPv6)",
draft-ietf-v6ops-onlinkassumption-04 (Work In Progress),
January 2007.
[NDbis] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP Version 6 (IPv6)",
draft-ietf-ipv6-2461bis-11 (Work In Progress), March 2007.
Appendix A. CHANGE HISTORY
[NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.]
Changes in draft-wbeebee-nd-implementation-pitfalls-01.txt since
-00.txt are:
o Removed the word "corrections" from the abstract when referring to
the proposed changes for the two drafts.
o Added to the abstract declaration of intent for this document.
o Corrected the introduction to say "the host must send all non-
link-local data to the default router" instead of the incorrect
"the host must send all data to the router", which is implied by
the specification, but not explicitly stated.
o Added the proposed changes to 2461bis section and appropriate
reference in the introduction.
o Changed "the host MUST issue NS(DAD)s" to "newer host
implementations MUST issue NS(DAD)s" to match the current state of
2462bis.
Singh & Beebee Expires December 31, 2007 [Page 11]
Internet-Draft ND Implementation Pitfalls June 2007
o Changed "security problem" to "manual configuration problem" to
emphasize that manual configuration of a compliant host combined
with the NS(DAD) optimization of a compliant host can cause
problems.
o Changed recommendation that the exception in section of 5.4 MUST
be ignored to SHOULD be ignored.
o Removed sentence which invalidates existing implementations.
o Changed "the host MUST send all traffic to the default router" to
"the host MUST send all non-link-local traffic to the default
router".
o Changed "the host MUST NOT issue an NS to resolve a destination
other than the Link-Local address of the default router" to "the
host MUST NOT issue an NS to resolve a destination other than a
link-local address".
o Removed MUST NOT and MAY language with respect to redirects used
in the aggregation router model, as these are properties of a
correct implementation rather than normative requirements. Note
that a clause was added that states that a router can send a
redirect "if the router can make a determination that the two
hosts lie behind the same bridge CPE".
o Changed the 2462bis changes section to reflect that existing
implementations are not required to change, but may suffer from
the manual configuration problem described in this draft.
o Added Josh Littlefield to the Acknowledgements section to
recognize his extremely insightful and useful comments on this
draft.
Authors' Addresses
Hemant Singh
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 1622
Email: shemant@cisco.com
URI: http://www.cisco.com/
Singh & Beebee Expires December 31, 2007 [Page 12]
Internet-Draft ND Implementation Pitfalls June 2007
Wes Beebee
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 2030
Email: wbeebee@cisco.com
URI: http://www.cisco.com/
Singh & Beebee Expires December 31, 2007 [Page 13]
Internet-Draft ND Implementation Pitfalls June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Singh & Beebee Expires December 31, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:25 |