One document matched: draft-hares-bose-dynamic_as-01.txt
Differences from draft-hares-bose-dynamic_as-00.txt
IDR Working Group S. Hares
Internet-Draft NextHop Technologies
Expires: April 19, 2006 P. Bose
Lockheed
October 16, 2005
Dynamic AS Re-Association
draft-hares-bose-dynamic_as-01.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, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides a mechanism for Autonomous Systems within an
AS Confederation to survive the disconnection to other AS within the
AS confederation without dropping peers. When all links to the other
AS in the Confederation break, this mechanism allows the AS to revert
to local AS to continue communication with E-BGP peers. This
mechanism has two parts: Capability signaling between the two parties
at connection start to save two AS (internal and AS Confederation AS)
Hares & Bose Expires April 19, 2006 [Page 1]
Internet-Draft DYNAMIC-AS October 2005
and a mechanism to signal the switch between AS Confederation AS and
internal AS.
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Mechanism overview for Dynamic AS Re-association . . . . . . . 5
4. Open Dynamic AS Capability . . . . . . . . . . . . . . . . . . 8
5. Capability Message . . . . . . . . . . . . . . . . . . . . . . 10
6. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Hares & Bose Expires April 19, 2006 [Page 2]
Internet-Draft DYNAMIC-AS October 2005
1. Definitions
1.1. Conventions used in this document
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].
Hares & Bose Expires April 19, 2006 [Page 3]
Internet-Draft DYNAMIC-AS October 2005
2. Introduction
This mechanism provides a mechanism for two BGP peers switching AS
values within a BGP association without dropping the AS connection.
When two BGP wish to re-configure with a different Autonomous
numbers, the current mechanisms in BGP require that the AS drop the
connection. If an AS has considerable fan-in of peers, this dropping
of the connection to re-associate a new AS may cause significant
outages.
This Dynamic AS re-association capability allows two Autonomous
Systems and their BGP peers to collude to reset the AS associated
with a BGP peer session without dropping the AS connection. The two
BGP peers agree upon a fail-over to another AS based on a list of
Autonomous Systems.
Hares & Bose Expires April 19, 2006 [Page 4]
Internet-Draft DYNAMIC-AS October 2005
3. Mechanism overview for Dynamic AS Re-association
The mechanism has two parts:
1) An Dynamic AS capability
The Dynamic AS capability signals the ability to use the Dynamic AS
re-association function.
The format of the AS-Edge capability is described in section 4 and
contains a list of Autonomous systems that the BGP peer may re-
associated to. This capability also indicates the mechanism by which
the node will signal the switch is the dynamic capabilities message.
Within an AS, any BGP peer that will send an AS-Edge Capability to an
Exterior peer MUST send the AS-Edge capability to all IBGP peers.
Only if all IBGP Peers successfully negotiated the AS-Edge
capability, can BGP dynamically switch over to another AS.
2) Signaling the Dynamic AS Switch-over - Originator
Signaling a Dynamic Switch is done via the Dynamic Capability message
with the Dynamic AS capability (format in section 5).
The BGP peer decides to initiate the dynamic AS switch over by using
local policy and implementation specific mechanisms. To signal the
Dynamic AS switch over, the initiating BGP peer has two steps.
Step 1: Send IBGP peers a "Dynamic AS Switch-over
Upon receiving a "Dynamic AS change" indication to the BGP
process, the BGP process will send to IBGP peers a "Dynamic AS
Switch-over" message. Upon receiving the ACK from all IBGP
peers for the Dynamic AS Capability, the BGP peer canstart step
2.
In case of the receiving IBGP peer's local BGP implementation
detecting a failure to switch to a new AS, the Dynamic
Capability will be signaled with a "failure" flag. This
failure will halt the originating Peer switch to the new AS.
Any failure of an IBGP peer in the IBGP cloud, will not allow
the BGP peer to progress to step 2.
If the IBGP peers are part of a Route-Reflection hierarchy, a
Route Reflector MUST wait to send an ack to the Dynamic AS
change after it has signaled all of its clients and all of it
total mesh peers. In this way, when the initiating IBGP peer
Hares & Bose Expires April 19, 2006 [Page 5]
Internet-Draft DYNAMIC-AS October 2005
receives the Dynamic Capability ACK, the rest of the IBGP peer
has been informed.
The Dynamic Capability may pass back success or failure in the
Dynamic AS flag word. The Dynamic Capability ACK MUST only use
the Short form (sequence number only) for Dynamic AS
Capabilities that are a success. If the Dynamic AS capability
is a failure, the full Dynamic Capability must be used with the
failure flag.
Step 2: Send all EBGP peers the Dynamic AS Change.
Signal each EBGP peers to change AS by sending the Dynamic AS
dynamic capability in a Capability message.
Upon receiving this dynamic capability from an E-BGP peer, the
BGP speaker associated with the AS Edge processes the switch of
the peer from the current AS number to the one specified in the
capability. This change in processing includes:
-All checking of the local AS in BGP packets utilizes the
new AS.
-All new routes will be announced with the new AS number.
-All older routes will be re-announced based on the AS
resend flag.
Upon successful processing, the EBGP peer will acknolwedge the
Dynamic AS capability by sending a Dynamic Capability with an
Ack in the Dynamic Capability flag and an "ack-succeess"
indication in the Dynamic Capabiity flag word.
3) E-BGP Peer Receiving a Signaling the Dynamic AS Switch-over
Upon receiving a "Dynamic AS Change" Dynamic capability from an EBGP
peer, the EBGP peer will follow 2 steps:
Step 1: Upon receiving a "Dynamic AS change" capability to the BGP
process, the BGP process will send to IBGP peers "Dynamic AS
Switch-over" message with the E-BGP peer flag set.
Upon receiving the Dynamic Capability with the "Ack" bit set
from all IBGP peers for the Dynamic AS Capability, the BGP peer
can start step 2.
Again, if the IBGP peers of the receiving BGP are part of a
Route-Reflection hierarchy, a Route Reflector MUST only send an
Hares & Bose Expires April 19, 2006 [Page 6]
Internet-Draft DYNAMIC-AS October 2005
ACK to the Dynamic AS change after it has successfully sent the
Dynamic Capability to its clients and all of it total mesh
peers. In this way, when the initiating IBGP peer receives the
Dynamic capability ACK, the rest of the IBGP peer has been
informed.
In case of errors in resetting the Dynamic AS capability, the
receiving IBGP peer can set the "Failure" flag in the Dynamic
capability that is being ACK. Any failures will be signaled to
the originating AS, and the Dynamic AS switch terminated.
Step 2: Respond to E-BGP AS with Dynamic AS change
The E-BGP peer responds to the originated AS with a Dynamic AS
change with an EBGP flag set and the Failure bit off.
Upon receiving this dynamic capability from an E-BGP peer, the
BGP speaker associated with the AS Edge process the switch of
the peer from the current AS number to the one specified in the
capability. This switch includes:
-All checking of the local AS in BGP packets utilizes the
new AS.
-All new routes will be announced with the new AS number.
-All older routes will be re-announced based on the AS
resend flag.
Hares & Bose Expires April 19, 2006 [Page 7]
Internet-Draft DYNAMIC-AS October 2005
4. Open Dynamic AS Capability
RFC 3992 [2] describes the open capability mechanisms. This document
describes a new Capability: Dynamic AS.
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
Where the Capability value is:
+------------------------------+
| Length of AS (1 octet) | - length of AS field (2 or 4)
+------------------------------+
| Reserved (5 bits) | - Reserved
+------------------------------+
| resend prefix flag (3 bits) | - Resend/AS Flag
+------------------------------+
| Number of AS supported | - # of AS in re-associate list
+------------------------------+
| AS originating capability | - AS that send this open cap.
+------------------------------+
| Autonomous System 1 | - AS 1 dynamic re-association
+------------------------------+
| ......... |
+------------------------------+
| Autonomous System N | - AS N dynamic re-association
+------------------------------+
Figure 1: Dynamic AS Open Capability Bytes
The resend prefix flag indicates when the AS will resend the routes
with the new AS. The flag values are set as a bit pattern to
indicate that
0x00 - Resend routes based on local timer (in bataches)
0x01 - Resend routes immediately
0x02 - Don't resend routes (leave with old AS confederation)
Hares & Bose Expires April 19, 2006 [Page 8]
Internet-Draft DYNAMIC-AS October 2005
The number of AS supported field gives the number of the Autonomous
Systems fin the dynamic re-association list.The Autonomous Systems in
the AS list are the list of ASes that this peer may switch to in when
dynamically re-association from the original AS to a new AS.
Each side of the peer will send a list of Autonomous Systems that it
will dynamic re-associate with. Upon start-up the re-associations
list can be check by policy to determine that each side can support
the required re-associations.
Hares & Bose Expires April 19, 2006 [Page 9]
Internet-Draft DYNAMIC-AS October 2005
5. Capability Message
This BGP dynamic capability uses the new BGP Dynamic Capability DYN-
CAP [3] format of:
+------------------------------+
| Init/Ack (1 bit) |
+------------------------------+
| Ack Request (1 bit) |
+------------------------------+
| Reserved (5 bits) |
+------------------------------+
| Action (1 bit) |
+------------------------------+
| Sequence Number (4 octets) |
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (2 octets) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
The capability value is:
+------------------------------+
| Length of AS | - Length of AS field
+------------------------------+
| Source (1 bits) | - Source flag
+------------------------------+
| Failure flag (1 bits) | - Resend/AS Flag
+------------------------------+
| Confed AS in Use (1 bit) | - Confederation AS in use
+------------------------------+
+ IBGP Reserve or Send (1 bit) + - Reserve/Start IBGP peers
+-------------------------------
| reserved (1 bit) | - Reserved
+------------------------------+
| resend prefix flag (3 bits) | - Resend/AS Flag
+------------------------------+
| Current AS number | - Old AS number
+------------------------------+
| New AS number | - new AS number
+------------------------------+
Hares & Bose Expires April 19, 2006 [Page 10]
Internet-Draft DYNAMIC-AS October 2005
Source Flag flag (1 bits)
0 - node originated
1 - EBGP peer originated
Failiure Flag (1 bit)
1 - failure
0 - success
AS in USE:
0x0 - Internal AS number
0x1 - AS Confederation number
IBGP Negotiation Stage
0x0 - Reserve IBGP peers only, Do not start EBGP peers
0x1 - Start IBGP peers and Start EBGP negotiation
Resend flag values
0x00 - Resend routes based on local timer
0x01 - Resend routes immediately
0x02 - Don't resend routes (leave with old AS confederation)
Hares & Bose Expires April 19, 2006 [Page 11]
Internet-Draft DYNAMIC-AS October 2005
6. Prevention of Loops
Because all IBGP nodes are synchronized before an EBGP peer is
transition to a new AS, the local BGP logic can detect the full
transition.
If any active IBGP peer is unable to transition, the whole transition
to the new AS stops.
If there is any local consideration that the AS has split and
existing routes may cause a black hole, implementation MAY set the
"re-announce all routes now" flag to prevent loops.
The two stages of IBGP negotation (IBGP only and EBGP/IBGP
negotiation) allow the peer to negotiated the ability to AS change
before information exterior peers. The two stage IBGP negotiation
can reduce or eliminate chatter to EBGP peers while the IBGP peers
settle on the decision to change the AS. In an IBGP cloud with
single or double level Route-Reflector hierarchy and hundreds of
E-BGP peers, this Route-Reflector hierarchy can reduce chatter.
AS confederation with several ASes internal to the IBGP that desire
to use the Dynamic AS re-association may benefit from a two stage
IBGP negotiation for internal synchronization before re-negotiation
with exterior peers.
1) Route Reflector Example
Nodes B, C, D, an E form an AS 200. Node A is in AS 300. Node F is
AS 500.
Node A is connected to Node B and Node E.
Node B is connected to Node C and Node E
Node C is connected to Node B, Node D, Node E and Node F.
Node D is connected to Node C and Node F.
Node E is connected to Node C, B, and A.
Node F is connected to Node D and Node C.
[Note: The authors did not say who was on first base. Just what
nodes are playing in the game. ;-) (it's a joke.)]
When node D is disconnected from Node C, the Dynamic AS switch takes
place. Node C decides to switch switch to AS 1000 for IBGP and EBGP.
Hares & Bose Expires April 19, 2006 [Page 12]
Internet-Draft DYNAMIC-AS October 2005
C takes up a split view of the world (AS 200/1000) until the Dynamic
AS re-numbering can resolve it to either AS 200 or AS 1000. just AS
1000.
+--------+ +-------------------+ +-------------------+ +--------+
+EBGP + + EBGP |IBGP Peer+ +IBGP peer| IBGP + + IBGP +
+outside +--+ AS 200 | AS 200 + + Initial | Initial + X + +
+ confed + + | +-|-+ AS 200 | AS 200 +-X-+ +
+ AS 300 + + --------|-------- + | + ------- |-------- + X + AS 200 +
+ + + AS 1000 | AS 1000 + | + AS 1000 | AS 1000 + + Node D +
+ + + | + | + |-------- + +--------+
+ A + + Node B + | + Node C | S 200 + +AS 200 +
+----|---+ +-------------------+ | +---------+------|--+ +--|-----+
| | | |
| +---------------------+ +------------+ |
| |EBGP Peer | IBGP Peer| | EBGP peer +---
+-----------|AS 200 | AS 200 | | outside +
|-------- |--------- | | Confed +
| AS 1000 | AS 1000 | | AS 500 +
| | | | +
| Node E| | | Node F +
+---------------------+ +------------+
Figure 3: Dual AS identities for an IBGP with Dynamic AS
Confederation
Loop Prevention
Note: Sequence numbers are peer-to-peer specific on a BGP session
using the dynamic capability message.
1) Two stage commit in IBGP peers with failure
1. Node C's sends a Capability message to Node B with sequence
number 10 and an add capability for Dynamic AS Capability.
Inside the Dynamic AS capability the flags are set for: IBGP,
Reserve and AS-in-Use Internal, Success (always on request
capability); the current AS is is 200, and the new AS is 1000.
2. Node C's sends a capability message to Node E with sequence
number 30 and an Add capability for Dynamic AS Capability.
Inside the Dynamic AS Capability the flags are set for: IBGP,
Reserve and AS-in-Use Internal, Success (always on request
capability); the current AS is 200, and the new AS is 1000.
3. Node B trys to renumber to the AS 1000 switch but fails due to
some internal problem.
Hares & Bose Expires April 19, 2006 [Page 13]
Internet-Draft DYNAMIC-AS October 2005
4. Node B sends a dynamic capability (seqence number 10) with an
ACK flag sest and a Dynamic AS capability inside with flags
set to: IBGP, Reserve, AS-in-Use Internal, Failure.
5. Node E successful can switch to the Internal AS. Node E sends
the capability message with an ACK flag, sequence number 30,
and an Dynamic AS capability inside. The flags inside the
Dynamic AS capability are set to: IBGP, Reserve, AS-In Use
Internal, and Success.
6. Node C sends sends a capability message to Node E with
sequence number 31, Delete flag, Dynamic AS capability with
flag bits set to: IBGP, Reserve, AS-in-Use Internal, and
Failure.
7. Node E clears all Dynamic AS state and respond with a
capability messages with an "Ack" flag set, sequence number
31, Delete Flag, Dynanic AS capability with flag bits set to:
IBGP, Reserve, AS-in-Use Internal and Failure.
8. Node C, B, and E form one portion of AS 200, and Node D forms
another portion of AS 200. Loops will occur in AS F and AS a
talking to AS 200. These loops are possible with an AS that
splits into 2 halfs. The Dynamic AS renumbering failiure
simple fails back to the normal BGP case.
2) Two stage commit with IBGP peers with success
1. Node C's sends a Capability message to Node B with sequence
number 10 and an Add capability for Dynamic AS Capability.
Inside the Dynamic AS capability the flags are set for: IBGP,
Reserve and AS-in-Use Internal, Success (always on request
capability). Inside the Dynamic AS Confed_Edge capability
the cur AS is 200, and the new AS is 1000.
2. Node C's sends a Capability message to Node E with sequence
number 30 and an Add capability for Dynamic AS Capability.
Inside the Dynamic AS capability the flags are set for: IBGP,
Reserve and AS-in-Use Internal,and sucess. Success (always
on request capability). Inside the Dynamic AS capability,
the cur AS is 200 and the new AS is 1000.
3. Node B trys to engage the AS 1000 switch and succeeds. Node
B responds to Node C with a capability message with sequence
number 10, Ack Flag set, and a Dynamic AS capability inside.
The Dynmic AS capability has flags set for: IBGP, Reserve, AS
in-Use, and Success.
Hares & Bose Expires April 19, 2006 [Page 14]
Internet-Draft DYNAMIC-AS October 2005
4. Node E successful can switch to the Internal AS. Node E
sends the capability message with an ACK flag, sequence
number 30, and an AS capability inside. The flags inside the
AS capability are set to: IBGP, Reserve, AS-In Use Internal,
and Success.
5. Node C's sends a capability message to Node B (seq 11) and
Node E (sequence 31) with an Add capability for Dynamic AS
capability. Inside the Dynamic AS Capability,the flags are
set to: IBGP, Reserve and AS-in-Use Internal, Start, and
Success (always on request capability. AS 200 is in the
current AS. AS 1000 is in the new AS.
6. Node B (sequence 11) sends back a capability messages with
ACK bit set on the Add of the Dynamic AS capability. Within
the Dynamc AS capability, the flags are set to: IBGP, Start,
AS-in-Use Internal, and Success. Node B starts to send
capability mesages with Dynamic AS capability to the E-BGP
peers.
1. Node B sends to Node A a capability message with Add of
Dynamic AS capability with sequence number 5. Inside the
Dynamic AS capability, the flags are set to: EBGP, Start,
AS-in-Use Internal, and Success. The current AS is 200
and the new AS is 1000.
2. Node A validates it can switch the E-BGP session to
receive AS 1000 from Node B. Node A sends back a
capability message with sequence number 5 with an ACK
flag set with an Dynamic AS capability inside. Inside
the Dynamic AS capability the flags are set to: EBGP,
Start, AS-in-Use Internal and Success.
7. Node E sends node C a capability messages with sequence
number 31, Action Add and An Ack Flag set. The Dynamic AS
capabilty is contained inside with flags set to: EBGP, Start,
AS-in-Use Internal, and Success. Node E starts to send
capability messages iwth Dynamic AS capability to the E-BGP
peers.
1. Node E sends to Node A a capability messages with
sequence number of 15. Action Add and a Dynamic AS
capability inside. Inside the Dynamic AS Confed_edge
capability the flags are set to: EBGP, Start, AS-in-Use
Internal,and Success. The AS information is current AS
200 and new AS 1000.
Hares & Bose Expires April 19, 2006 [Page 15]
Internet-Draft DYNAMIC-AS October 2005
2. Node A validates it can change the EBGP session to AS 300
to AS 1000, and then sends a capability to confirm the
Ack. The capability messages contains sequence number 15,
Add Action, Ack flag, and a Dynamic AS Confed_Edge
capability inside with flags of: EBGP, Start, AS-in-Use
Internal, and Success/ Of course, the AS information is
current AS 200, and new AS 1000.
8. After Node C sends the capability messages to it's internal
peers (Node E and Node B), it sends dynamic capabilities to
Node F (in AS 500 external to the new AS 1000.)
9. Node F process C's capability message
1. Node F receives a capability message from Node C with
sequence number 200, Add Action, and Dynamic AS
Confed_Edge capability inside. Inside the Dynamic AS
Confed_Edge capability the flags are set to: EBGP, Start,
AS-in-Use Internal, and Success. The AS information is:
current AS 200 and new AS 1000.
2. Node F determines it can switch the EBGP session with
Node C to AS 1000.
3. Node F sends back a capability message with sequence
number 200, Add Action, and Dynamic AS capabiliity
inside. Inside the Dynamic AS capability, the flags are
set to: EBGP, Start, AS-in-Use Internal and Success.
AGain, the AS information is: current AS 200 and new AS
1000.
10. At this point:
1. AS 300 has: Node A
2. AS 1000 has: Node C, B and E
3. AS 200 has Node D
4. AS 500 has Node F
5. AS 300 peers with AS 1000
6. AS 1000 peers with AS 300 (Node A), and AS 500 (Node F).
7. AS 500 peers with AS 200 (Node D) and AS 1000 (Node)
Hares & Bose Expires April 19, 2006 [Page 16]
Internet-Draft DYNAMIC-AS October 2005
8. Traffic can flow to Node E via an E-BGP path.
The two stage commit allows the internal AS one stage to confirm
resources with IBGP peers prior to disturbing and E-BGP peers. If an
E-BGP peer fails after the IBGP cloud has switched, the single E-BGP
peer can be dropped and re-initialized.
If there is any local consideration that the AS has split and
existing routes may cause a black hole, implementation MAY set the
"re-announce all routes now" flag to prevent loops.
Hares & Bose Expires April 19, 2006 [Page 17]
Internet-Draft DYNAMIC-AS October 2005
7. Security Considerations
The security of the BGP exchange is optionally secured by the TCP MD5
key.
Upon discussion with security reviewers, the addition of this feature
will neither improve nor detract from the TCP MD5 level of security.
The authors considered adding a "cookie" feature to further secure
this exchange. Again, review with security experts indicated this
"cookie" feature would not improve the security level.
The TCP session security will continue across the dynamic BGP peer
re-association. The TCP sessions dynamic MD5 re-association or key
switch would also allow TCP sessions to continue for a long period.
8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.
[2] ""Capability Adverstisement with BGP-4"", November 2002,
<http://www.ietf.org/rfc/rfc3392.txt>.
[3] ""Dynamic Capability for BGP-4"", March 2000, <http://
www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-06.txt>.
Hares & Bose Expires April 19, 2006 [Page 18]
Internet-Draft DYNAMIC-AS October 2005
Authors' Addresses
Susan Hares
NextHop Technologies
825 Victors Way
Ann Arbor, MI 48105
Phone: +1-734-222-1610
Email: shares@nexthop.com
Pratik Bose
Lockheed
700 N Frederick Ave
Gaithersburg, MD 20879
Phone: +1-301-428-4215
Email: pratik.bose@lmco.com
Hares & Bose Expires April 19, 2006 [Page 19]
Internet-Draft DYNAMIC-AS October 2005
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 (2005). 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.
Hares & Bose Expires April 19, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 02:47:27 |