draft-ietf-vrrp-ipv6-spec-07.txt   draft-ietf-vrrp-ipv6-spec-08.txt 
INTERNET-DRAFT R. Hinden / Nokia Network Working Group R. Hinden
September 28, 2004 Internet-Draft Nokia
Expires: August 23, 2007 J.Cruz, Editor
Cisco Systems
February 23, 2007
Virtual Router Redundancy Protocol for IPv6 Virtual Router Redundancy Protocol for IPv6
<draft-ietf-vrrp-ipv6-spec-07.txt> <draft-ietf-vrrp-ipv6-spec-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This internet draft expires on April 3, 2005. This internet draft expires on April 3, 2005.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo defines the Virtual Router Redundancy Protocol (VRRP) for This memo defines the Virtual Router Redundancy Protocol (VRRP) for
IPv6. It is version three (3) of the protocol. It is based on the IPv6. It is version three (3) of the protocol. It is based on the
original version of VRRP (version 2) for IPv4 that is defined in original version of VRRP (version 2) for IPv4 that is defined in
RFC2338. RFC2338.
VRRP specifies an election protocol that dynamically assigns VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a responsibility for a virtual router to one of the VRRP routers on a
LAN. The VRRP router controlling the IP address(es) associated with LAN. The VRRP router controlling the IP address(es) associated with
skipping to change at page 3, line 41 skipping to change at page 3, line 41
9. Operation over FDDI, Token Ring, and ATM LANE.............22 9. Operation over FDDI, Token Ring, and ATM LANE.............22
9.1 Operation over FDDI...................................22 9.1 Operation over FDDI...................................22
9.2 Operation over Token Ring.............................22 9.2 Operation over Token Ring.............................22
9.3 Operation over ATM LANE...............................25 9.3 Operation over ATM LANE...............................25
10. Security Considerations...................................25 10. Security Considerations...................................25
11. Intellectual Property.....................................26 11. Intellectual Property.....................................26
12. Acknowledgments...........................................26 12. Acknowledgments...........................................26
13. IANA Considerations.......................................27 13. IANA Considerations.......................................27
14. Normative References......................................27 14. Normative References......................................27
15. Informative References....................................28 15. Informative References....................................28
16. Authors' Address..........................................28 16. Changes from RFC2338......................................29
17. Changes from RFC2338......................................29
18. Disclaimer of Validity....................................31
19. Copyright Statement.......................................31
1. Introduction 1. Introduction
IPv6 hosts on a LAN will usually learn about one or more default IPv6 hosts on a LAN will usually learn about one or more default
routers by receiving Router Advertisements sent using the IPv6 routers by receiving Router Advertisements sent using the IPv6
Neighbor Discovery protocol [ND]. The Router Advertisements are Neighbor Discovery protocol [ND]. The Router Advertisements are
multicast periodically at a rate that the hosts will learn about the multicast periodically at a rate that the hosts will learn about the
default routers in a few minutes. They are not sent frequently enough default routers in a few minutes. They are not sent frequently enough
to rely on the absence of the router advertisement to detect router to rely on the absence of the router advertisement to detect router
failures. failures.
skipping to change at page 14, line 46 skipping to change at page 14, line 46
IPv6_Addresses One or more IPv6 addresses associated with IPv6_Addresses One or more IPv6 addresses associated with
this virtual router. Configured item. No this virtual router. Configured item. No
default. The first address must be the default. The first address must be the
Link-Local address associated with the Link-Local address associated with the
virtual router. virtual router.
Advertisement_Interval Time interval between ADVERTISEMENTS Advertisement_Interval Time interval between ADVERTISEMENTS
(centiseconds). Default is 100 centiseconds (centiseconds). Default is 100 centiseconds
(1 second). (1 second).
Master_Adver_Interval Advertisement interval contained in
ADVERTISEMENTS received from the Master
(centiseconds). This value is saved by
virtual routers in Backup state and used to
compute Skew_Time and Master_Down_Interval.
The initial value is same as
Advertisement_Interval.
Skew_Time Time to skew Master_Down_Interval in Skew_Time Time to skew Master_Down_Interval in
centiseconds. Calculated as: centiseconds. Calculated as:
(((256 - priority) * (((256 - priority) *
Advertisement_Interval) / 256). Master_Adver_Interval) / 256).
Master_Down_Interval Time interval for Backup to declare Master Master_Down_Interval Time interval for Backup to declare Master
down (centiseconds). Calculated as: down (centiseconds). Calculated as:
(3 * Advertisement_Interval) + Skew_time (3 * Master_Adver_Interval) + Skew_time
Preempt_Mode Controls whether a higher priority Backup Preempt_Mode Controls whether a higher priority Backup
router preempts a lower priority Master. router preempts a lower priority Master.
Values are True to allow preemption and Values are True to allow preemption and
False to prohibit preemption. Default is False to prohibit preemption. Default is
True. True.
Note: Exception is that the router that owns Note: Exception is that the router that owns
the IPv6 address associated with the virtual the IPv6 address associated with the virtual
router always preempts independent of the router always preempts independent of the
skipping to change at page 16, line 48 skipping to change at page 16, line 48
o Send an unsolicited ND Neighbor Advertisement with the Router o Send an unsolicited ND Neighbor Advertisement with the Router
Flag (R) set, the Solicited Flag (S) unset, the Override flag Flag (R) set, the Solicited Flag (S) unset, the Override flag
(O) set, the Target Address set to the IPv6 link-local address (O) set, the Target Address set to the IPv6 link-local address
of the Virtual Router, and the Target Link Layer address set to of the Virtual Router, and the Target Link Layer address set to
the virtual router MAC address. the virtual router MAC address.
o Set the Adver_Timer to Advertisement_Interval o Set the Adver_Timer to Advertisement_Interval
o Transition to the {Master} state o Transition to the {Master} state
else else
o Set Master_Adver_Interval to Advertisement_Interval
o Set the Master_Down_Timer to Master_Down_Interval o Set the Master_Down_Timer to Master_Down_Interval
o Transition to the {Backup} state o Transition to the {Backup} state
endif endif
6.4.2 Backup 6.4.2 Backup
The purpose of the {Backup} state is to monitor the availability and The purpose of the {Backup} state is to monitor the availability and
state of the Master Router. state of the Master Router.
While in this state, a VRRP router MUST do the following: While in this state, a VRRP router MUST do the following:
- MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 - MUST NOT respond to ND Neighbor Solicitation messages for the IPv6
skipping to change at page 18, line 4 skipping to change at page 18, line 8
o Set the Adver_Timer to Advertisement_Interval o Set the Adver_Timer to Advertisement_Interval
o Transition to the {Master} state o Transition to the {Master} state
endif endif
- If an ADVERTISEMENT is received, then: - If an ADVERTISEMENT is received, then:
If the Priority in the ADVERTISEMENT is Zero, then: If the Priority in the ADVERTISEMENT is Zero, then:
o Set the Master_Down_Timer to Skew_Time o Set the Master_Down_Timer to Skew_Time
else: else:
If Preempt_Mode is False, or If the Priority in the If Preempt_Mode is False, or If the Priority in the
ADVERTISEMENT is greater than or equal to the local ADVERTISEMENT is greater than or equal to the local
Priority, then: Priority, then:
o Set Master_Adver_Interval to Adver Interval contained in
the ADVERTISEMENT.
o Reset the Master_Down_Timer to Master_Down_Interval o Reset the Master_Down_Timer to Master_Down_Interval
else: else:
o Discard the ADVERTISEMENT o Discard the ADVERTISEMENT
endif endif
endif endif
endif endif
skipping to change at page 19, line 28 skipping to change at page 19, line 35
else: else:
If the Priority in the ADVERTISEMENT is greater than the If the Priority in the ADVERTISEMENT is greater than the
local Priority, local Priority,
or or
If the Priority in the ADVERTISEMENT is equal to the local If the Priority in the ADVERTISEMENT is equal to the local
Priority and the IPv6 Address of the sender is greater than Priority and the IPv6 Address of the sender is greater than
the local IPv6 Address, then: the local IPv6 Address, then:
o Cancel Adver_Timer o Cancel Adver_Timer
o Set Master_Adver_Interval to Adver Interval contained in
the ADVERTISEMENT.
o Set Master_Down_Timer to Master_Down_Interval o Set Master_Down_Timer to Master_Down_Interval
o Transition to the {Backup} state o Transition to the {Backup} state
else: else:
o Discard ADVERTISEMENT o Discard ADVERTISEMENT
endif endif
endif endif
endif endif
skipping to change at page 20, line 38 skipping to change at page 20, line 38
SHOULD indicate via network management that a misconfiguration was SHOULD indicate via network management that a misconfiguration was
detected. If the packet was not generated by the address owner detected. If the packet was not generated by the address owner
(Priority does not equal 255 (decimal)), the receiver MUST drop the (Priority does not equal 255 (decimal)), the receiver MUST drop the
packet, otherwise continue processing. packet, otherwise continue processing.
- MUST verify that the Adver Interval in the packet is the same as - MUST verify that the Adver Interval in the packet is the same as
the locally configured for this virtual router the locally configured for this virtual router
If the above check fails, the receiver SHOULD log the event and If the above check fails, the receiver SHOULD log the event and
SHOULD indicate via network management that a misconfiguration was SHOULD indicate via network management that a misconfiguration was
detected. detected. However, the packet is not discarded. If the virtual
router is in Backup state, it uses the received Adver Interval to re-
calculate its Master_Down_Interval.
7.2 Transmitting VRRP Packets 7.2 Transmitting VRRP Packets
The following operations MUST be performed when transmitting a VRRP The following operations MUST be performed when transmitting a VRRP
packet. packet.
- Fill in the VRRP packet fields with the appropriate virtual - Fill in the VRRP packet fields with the appropriate virtual
router configuration state router configuration state
- Compute the VRRP checksum - Compute the VRRP checksum
- Set the source MAC address to Virtual Router MAC Address - Set the source MAC address to Virtual Router MAC Address
skipping to change at page 26, line 36 skipping to change at page 26, line 36
Operation of VRRP over ATM LANE on routers with ATM LANE interfaces Operation of VRRP over ATM LANE on routers with ATM LANE interfaces
and/or routers behind proxy LEC's are beyond the scope of this and/or routers behind proxy LEC's are beyond the scope of this
document. document.
10. Security Considerations 10. Security Considerations
VRRP for IPv6 does not currently include any type of authentication. VRRP for IPv6 does not currently include any type of authentication.
Earlier versions of the VRRP (for IPv4) specification included Earlier versions of the VRRP (for IPv4) specification included
several types of authentication ranging from none to strong. several types of authentication ranging from none to strong.
Operational experience and further analysis determined that these did Operational experience and further analysis determined that these did
not provide any real measure of security. Due to the nature of the not provide sufficient security to overcome the vulnerability of
VRRP protocol, even if VRRP messages are cryptographically protected, misconfigured secrets causing multiple masters to be elected. Due to
it does not prevent hostile routers from behaving as if they are a the nature of the VRRP protocol, even if VRRP messages are
VRRP master, creating multiple masters. Authentication of VRRP cryptographically protected, it does not prevent hostile routers from
messages could have prevented a hostile router from causing all behaving as if they are a VRRP master, creating multiple masters.
properly functioning routers from going into backup state. However, Authentication of VRRP messages could have prevented a hostile router
having multiple masters can cause as much disruption as no routers, from causing all properly functioning routers from going into backup
which authentication cannot prevent. Also, even if a hostile router state. However, having multiple masters can cause as much disruption
could not disrupt VRRP, it can disrupt ARP and create the same effect as no routers, which authentication cannot prevent. Also, even if a
as having all routers go into backup. hostile router could not disrupt VRRP, it can disrupt ARP and create
the same effect as having all routers go into backup.
It should be noted that these attacks are not worse and are a subset It should be noted that these attacks are not worse and are a subset
of the attacks that any node attached to a LAN can do independently of the attacks that any node attached to a LAN can do independently
of VRRP. The kind of attacks a malicious node on a LAN can do of VRRP. The kind of attacks a malicious node on a LAN can do
include promiscuously receiving packets for any routers MAC address, include promiscuously receiving packets for any router's MAC address,
sending packets with the routers MAC address as the source MAC sending packets with the router's MAC address as the source MAC
addresses in the L2 header to tell the L2 switches to send packets addresses in the L2 header to tell the L2 switches to send packets
addressed to the router to the malicious node instead of the router, addressed to the router to the malicious node instead of the router,
send redirects to tell the hosts to send their traffic somewhere send redirects to tell the hosts to send their traffic somewhere
else, send unsolicited ND replies, answer ND requests, etc., etc. else, send unsolicited ND replies, answer ND requests, etc., etc.
All of this can be done independently of implementing VRRP. VRRP All of this can be done independently of implementing VRRP. VRRP
does not add to these vulnerabilities. does not add to these vulnerabilities.
Independent of any authentication type VRRP includes a mechanism Independent of any authentication type VRRP includes a mechanism
(setting TTL=255, checking on receipt) that protects against VRRP (setting TTL=255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits most packets being injected from another remote network. This limits most
vulnerabilities to local attacks. vulnerabilities to local attacks.
VRRP does not provide any confidentiality. Confidentiality is not VRRP does not provide any confidentiality. Confidentiality is not
necessary for the correct operation of VRRP and there is no necessary for the correct operation of VRRP and there is no
information in the VRRP messages that must be kept secret from other information in the VRRP messages that must be kept secret from other
nodes on the LAN. nodes on the LAN.
If SEcure Neighbor Discovery (SEND) [SEND] is deployed, VRRP
authentication could be usefully added, because misconfiguration of
secrets will not be an issue. Routers with different secrets will
have different IP addresses, and therefore there will be no issue
with multiple masters with the same IP (and MAC) addresses. Also,
SEND will prevent malicious routers from sending misleading ND
messages.
11. Intellectual Property 11. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 28, line 47 skipping to change at page 29, line 11
for VRRP for IPv6. Similar assignments are documented in: for VRRP for IPv6. Similar assignments are documented in:
http://www.iana.org/assignments/ethernet-numbers http://www.iana.org/assignments/ethernet-numbers
14. Normative References 14. Normative References
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
802.1D, 1993 edition. 802.1D, 1993 edition.
[ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing [ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing
Architecture", RFC3513, April 2003. Architecture", RFC4291, February 2006.
[CKSM] Braden, R., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC1071, September 1988.
[ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol [ICMPv6] Conta, A., S. Deering, M. Gupta, "Internet Control Message
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", Protocol (ICMPv6) for the Internet Protocol Version 6
RFC2463, December 1998. (IPv6) Specification", RFC4443, March 2006.
[IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998. (IPv6) Specification", RFC2460, December 1998.
[IPX] Novell Incorporated., "IPX Router Specification", Version [IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992. 1.10, October 1992.
[ND] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery [ND] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC2461, December 1998. for IP Version 6 (IPv6)", RFC2461, December 1998.
[RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area
Networks", RFC1469, June 1993.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC2026, BCP00009, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP0014, March 1997. Requirement Levels", RFC2119, BCP0014, March 1997.
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)", RFC3971,
March 2005.
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
SC30-3374-02, Third Edition, (September, 1989). SC30-3374-02, Third Edition, (September, 1989).
[VRRP-V4] Knight, S., et. al., "Virtual Router Redundancy Protocol", [VRRP-V4] Hinder, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC2338, April 1998. RFC3768, April 2004.
15. Informative References 15. Informative References
[HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby
Router Protocol (HSRP)", RFC2281, March 1998. Router Protocol (HSRP)", RFC2281, March 1998.
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
Provide Fast Failover in IP Networks", Digital Technical Provide Fast Failover in IP Networks", Digital Technical
Journal, Volume 9 Number 3, Winter 1997. Journal, Volume 9 Number 3, Winter 1997.
[OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998. [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC1071, September 1988.
[RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November
1998.
16. Author's Address
Robert Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625-2004 [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area
EMail: bob.hinden@nokia.com Networks", RFC1469, June 1993.
17. Changes from RFC2338 16. Changes from RFC2338
- Added new subsection (8.3) that provided more detail on sending ND - Added new subsection (8.3) that provided more detail on sending ND
Router Advertisements. Router Advertisements.
- Added new subsection (8.5) with recommendations about setting - Added new subsection (8.5) with recommendations about setting
priority values and it's relationship to the preempt flag. priority values and it's relationship to the preempt flag.
- Changed rules for receiving VRRP packets to not drop the packet if - Changed rules for receiving VRRP packets to not drop the packet if
the Adver Interval is not consistent with the local configuration the Adver Interval is not consistent with the local configuration
for the virtual router. Only log and notify network management. for the virtual router. Only log and notify network management.
Moreover, use the Master's Adver Interval to compute
Master_Down_Interval and Skew_Time.
- Reduced granularity of the Advertisement_Interval to centiseconds - Reduced granularity of the Advertisement_Interval to centiseconds
(i.e., 1/100 of a second). Changes include: (i.e., 1/100 of a second). Changes include:
o Made Adver Int field in the header 12-bits to allow range from o Made Adver Int field in the header 12-bits to allow range from
1 to 4096 centiseconds. 1 to 4096 centiseconds.
o Change Skew_Timer calculation to skew over one o Change Skew_Timer calculation to skew over one
Advertisement_Interval. Advertisement_Interval.
- Added switch (Accept_Mode) to control whether a virtual router in - Added switch (Accept_Mode) to control whether a virtual router in
Master state will accept packets addresses to the address owner's Master state will accept packets addresses to the address owner's
IPv6 address as its own if it is not the IPv6 address owner. IPv6 address as its own if it is not the IPv6 address owner.
- Changed VMAC assignments to a separate block of IANA Ethernet - Changed VMAC assignments to a separate block of IANA Ethernet
skipping to change at page 31, line 4 skipping to change at page 30, line 44
o Change packet format to support an 128-bit IPv6 address. o Change packet format to support an 128-bit IPv6 address.
o Rewrote text to specify IPv6 Neighbor Discovery mechanisms o Rewrote text to specify IPv6 Neighbor Discovery mechanisms
instead of ARP. instead of ARP.
o Changed state machine actions to use Neighbor Discovery o Changed state machine actions to use Neighbor Discovery
mechanisms. This includes sending unsolicited Neighbor mechanisms. This includes sending unsolicited Neighbor
Advertisements, Receiving Neighbor Solicitations, joining the Advertisements, Receiving Neighbor Solicitations, joining the
appropriate solicited node multicast group, sending Router appropriate solicited node multicast group, sending Router
Advertisements, and receiving Router Solicitations. Advertisements, and receiving Router Solicitations.
- Revised the section 4 examples text with a clearer description of - Revised the section 4 examples text with a clearer description of
mapping of IPv6 address owner, priorities, etc. mapping of IPv6 address owner, priorities, etc.
- Clarify the section 7.1 text describing address list validation. - Clarify the section 7.1 text describing address list validation.
- Corrected text in Preempt_Mode definition. - Corrected text in Preempt_Mode definition.
- Changed authentication to be per Virtual Router instead of per - Changed authentication to be per Virtual Router instead of per
Interface. Interface.
- Added new subsection (9.3) stating that VRRP over ATM LANE is - Added new subsection (9.3) stating that VRRP over ATM LANE is
beyond the scope of this document. beyond the scope of this document.
- Clarified text describing received packet length check. - Clarified text describing received packet length check.
- Clarified text describing received authentication check. - Clarified text describing received authentication check.
- Clarified text describing VRID verification check. - Clarified text describing VRID verification check.
- Added new subsection (8.3) describing need to not forward packets - Added new subsection (8.3) describing need to not forward packets
for adopted IPv6 addresses. for adopted IPv6 addresses.
- Added clarification to the security considerations section. - Added clarification to the security considerations section. Added
reference to SEND.
- Added reference for computing the internet checksum. - Added reference for computing the internet checksum.
- Updated references and author information. - Updated references and author information.
18. Disclaimer of Validity 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
19. Copyright Statement Authors' Addresses
Copyright (C) The Internet Society (2004). This document is subject Robert Hinden
to the rights, licenses and restrictions contained in BCP 78, and Nokia, Inc.
except as set forth therein, the authors retain all their rights. 313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com
John Cruz
Cisco Systems, Inc.
3600 Cisco Way
San Jose, CA 95134
USA
Phone: +1 408 527 1034
Email: johcruz@cisco.com
 End of changes. 33 change blocks. 
67 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/