summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3791.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3791.txt')
-rw-r--r--doc/rfc/rfc3791.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc3791.txt b/doc/rfc/rfc3791.txt
new file mode 100644
index 0000000..a669209
--- /dev/null
+++ b/doc/rfc/rfc3791.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group C. Olvera
+Request for Comments: 3791 Consulintel
+Category: Informational P. Nesser, II
+ Nesser & Nesser Consulting
+ June 2004
+
+
+ Survey of IPv4 Addresses in Currently Deployed
+ IETF Routing Area Standards Track and Experimental Documents
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This investigation work seeks to document all usage of IPv4 addresses
+ in currently deployed IETF Routing Area documented standards. In
+ order to successfully transition from an all IPv4 Internet to an all
+ IPv6 Internet, many interim steps will be taken. One of these steps
+ is the evolution of current protocols that have IPv4 dependencies.
+ It is hoped that these protocols (and their implementations) will be
+ redesigned to be network address independent, but failing that will
+ at least dually support IPv4 and IPv6. To this end, all Standards
+ (Full, Draft, and Proposed) as well as Experimental RFCs will be
+ surveyed and any dependencies will be documented.
+
+Table of Contents
+
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Document Organization . . . . . . . . . . . . . . . . . . . . 2
+ 3. Full Standards. . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . . 3
+ 5. Proposed Standards. . . . . . . . . . . . . . . . . . . . . . 3
+ 6. Experimental RFCs . . . . . . . . . . . . . . . . . . . . . . 7
+ 7. Summary of Results. . . . . . . . . . . . . . . . . . . . . . 9
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
+ 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12
+ 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 13
+
+
+
+
+Olvera & Nesser II Informational [Page 1]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+ 11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14
+ 12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
+
+1. Introduction
+
+ This work aims to document all usage of IPv4 addresses in currently
+ deployed IETF Routing Area documented standards. Also, throughout
+ this document there are discussions on how routing protocols might be
+ updated to support IPv6 addresses.
+
+ This material was originally presented within a single document, but
+ in an effort to have the information in a manageable form, it has
+ subsequently been split into 7 documents conforming to the current
+ IETF main areas (Application [2], Internet [3], Operations &
+ Management [4], Routing [this document], Security [5], Sub-IP [6] and
+ Transport [7]).
+
+ The general overview, methodology used during documentation and scope
+ of the investigation for the whole 7 documents can be found in the
+ introduction of this set of documents [1].
+
+ It is important to mention that to perform this study the following
+ classes of IETF standards are investigated: Full, Draft, and
+ Proposed, as well as Experimental. Informational, BCP and Historic
+ RFCs are not addressed. RFCs that have been obsoleted by either
+ newer versions or as they have transitioned through the standards
+ process are also not covered.
+
+2. Document Organization
+
+ The main Sections of this document are described below.
+
+ Sections 3, 4, 5, and 6 each describe the raw analysis of Full,
+ Draft, Proposed Standards and Experimental RFCs. Each RFC is
+ discussed in its turn starting with RFC 1 and ending (around) RFC
+ 3100. The comments for each RFC are "raw" in nature. That is, each
+ RFC is discussed in a vacuum and problems or issues discussed do not
+ "look ahead" to see if the problems have already been fixed.
+
+ Section 7 is an analysis of the data presented in Sections 3, 4, 5,
+ and 6. It is here that all of the results are considered as a whole
+ and the problems that have been resolved in later RFCs are
+ correlated.
+
+
+
+
+
+
+
+
+Olvera & Nesser II Informational [Page 2]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+3. Full Standards
+
+ Full Internet Standards (most commonly simply referred to as
+ "Standards") are fully mature protocol specification that are widely
+ implemented and used throughout the Internet.
+
+3.1. RFC 1722 (STD 57) RIP Version 2 Protocol Applicability Statement
+
+ RIPv2 is only intended for IPv4 networks.
+
+3.2. RFC 2328 (STD 54) OSPF Version 2
+
+ This RFC defines a protocol for IPv4 routing. It is highly
+ assumptive about address formats being IPv4 in nature.
+
+3.3. RFC 2453 (STD 56) RIP Version 2
+
+ RIPv2 is only intended for IPv4 networks.
+
+4. Draft Standards
+
+ Draft Standards represent the penultimate standard level in the IETF.
+ A protocol can only achieve draft standard when there are multiple,
+ independent, interoperable implementations. Draft Standards are
+ usually quite mature and widely used.
+
+4.1. RFC 1771 A Border Gateway Protocol 4 (BGP-4)
+
+ This RFC defines a protocol used for exchange of IPv4 routing
+ information and does not support IPv6 as is defined.
+
+4.2. RFC 1772 Application of the Border Gateway Protocol in the
+ Internet
+
+ This RFC is a discussion of the use of BGP-4 on the Internet.
+
+4.3. RFC 3392 Capabilities Advertisement with BGP-4
+
+ Although the protocol enhancements have no IPv4 dependencies, the
+ base protocol, BGP-4, is IPv4 only.
+
+5. Proposed Standards
+
+ Proposed Standards are introductory level documents. There are no
+ requirements for even a single implementation. In many cases
+ Proposed are never implemented or advanced in the IETF standards
+ process. They therefore are often just proposed ideas that are
+ presented to the Internet community. Sometimes flaws are exposed or
+
+
+
+Olvera & Nesser II Informational [Page 3]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+ they are one of many competing solutions to problems. In these later
+ cases, no discussion is presented as it would not serve the purpose
+ of this discussion.
+
+5.1. RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual
+ environments
+
+ This document specifies a protocol for the exchange of IPv4 routing
+ information.
+
+5.2. RFC 1370 Applicability Statement for OSPF
+
+ This document discusses a version of OSPF that is limited to IPv4.
+
+5.3. RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of
+ The Border Gateway Protocol
+
+ BGP2 and BGP3 are both deprecated and therefore are not discussed in
+ this document.
+
+5.4. RFC 1478 An Architecture for Inter-Domain Policy Routing
+
+ The architecture described in this document has no IPv4 dependencies.
+
+5.5. RFC 1479 Inter-Domain Policy Routing Protocol Specification:
+ Version 1 (IDPR)
+
+ There are no IPv4 dependencies in this protocol.
+
+5.6. RFC 1517 Applicability Statement for the Implementation of
+ Classless Inter-Domain Routing (CIDR)
+
+ This document deals exclusively with IPv4 addressing issue.
+
+5.7. RFC 1518 An Architecture for IP Address Allocation with CIDR
+
+ This document deals exclusively with IPv4 addressing issue.
+
+5.8. RFC 1519 Classless Inter-Domain Routing (CIDR): an Address
+ Assignment and Aggregation Strategy
+
+ This document deals exclusively with IPv4 addressing issue.
+
+5.9. RFC 1582 Extensions to RIP to Support Demand Circuits
+
+ This protocol is an extension to a protocol for exchanging IPv4
+ routing information.
+
+
+
+
+Olvera & Nesser II Informational [Page 4]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+5.10. RFC 1584 Multicast Extensions to OSPF
+
+ This document defines the use of IPv4 multicast to an IPv4 only
+ routing protocol.
+
+5.11. RFC 1793 Extending OSPF to Support Demand Circuits
+
+ There are no IPv4 dependencies in this protocol other than the fact
+ that it is a new functionality for a routing protocol that only
+ supports IPv4 networks.
+
+5.12. RFC 1997 BGP Communities Attribute
+
+ Although the protocol enhancements have no IPv4 dependencies, the
+ base protocol, BGP-4, is IPv4 only.
+
+5.13. RFC 2080 RIPng for IPv6
+
+ This RFC documents a protocol for exchanging IPv6 routing information
+ and is not discussed in this document.
+
+5.14. RFC 2091 Triggered Extensions to RIP to Support Demand Circuits
+
+ This RFC defines an enhancement for an IPv4 routing protocol and
+ while it has no IPv4 dependencies it is inherently limited to IPv4.
+
+5.15. RFC 2338 Virtual Router Redundancy Protocol (VRRP)
+
+ This protocol is IPv4 specific, there are numerous references to 32-
+ bit IP addresses.
+
+5.16. RFC 2370 The OSPF Opaque LSA Option
+
+ There are no IPv4 dependencies in this protocol other than the fact
+ that it is a new functionality for a routing protocol that only
+ supports IPv4 networks.
+
+5.17. RFC 2439 BGP Route Flap Damping
+
+ The protocol enhancements have no IPv4 dependencies, even though the
+ base protocol, BGP-4, is IPv4 only routing protocol.
+
+5.18. RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-
+ Domain Routing
+
+ This RFC documents IPv6 routing methods and is not discussed in this
+ document.
+
+
+
+
+Olvera & Nesser II Informational [Page 5]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+5.19. RFC 2740 OSPF for IPv6
+
+ This document defines an IPv6 specific protocol and is not discussed
+ in this document.
+
+5.20. RFC 2784 Generic Routing Encapsulation (GRE)
+
+ This protocol is only defined for IPv4. The document states in the
+ Appendix:
+
+ o IPv6 as Delivery and/or Payload Protocol
+
+ This specification describes the intersection of GRE currently
+ deployed by multiple vendors. IPv6 as delivery and/or payload
+ protocol is not included.
+
+5.21. RFC 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP
+
+ Although the protocol enhancements have no IPv4 dependencies, the
+ base protocol, BGP-4, is IPv4 only routing protocol. This
+ specification updates but does not obsolete RFC 1966.
+
+5.22. RFC 2858 Multiprotocol Extensions for BGP-4
+
+ In the Abstract:
+
+ Currently BGP-4 is capable of carrying routing information only for
+ IPv4. This document defines extensions to BGP-4 to enable it to
+ carry routing information for multiple Network Layer protocols (e.g.,
+ IPv6, IPX, etc...). The extensions are backward compatible - a
+ router that supports the extensions can interoperate with a router
+ that doesn't support the extensions.
+
+ The document is therefore not examined further in this document.
+
+5.23. RFC 2890 Key and Sequence Number Extensions to GRE
+
+ There are no IPv4 dependencies in this protocol.
+
+5.24. RFC 2894 Router Renumbering for IPv6
+
+ The RFC defines an IPv6 only document and is not concerned in this
+ survey.
+
+5.25. RFC 2918 Route Refresh Capability for BGP-4
+
+ Although the protocol enhancements have no IPv4 dependencies, the
+ base protocol, BGP-4, is IPv4 only routing protocol.
+
+
+
+Olvera & Nesser II Informational [Page 6]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+5.26. RFC 3065 Autonomous System Confederations for BGP
+
+ Although the protocol enhancements have no IPv4 dependencies, the
+ base protocol, BGP-4, is IPv4 only routing protocol.
+
+5.27. RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option
+
+ This document defines an extension to an IPv4 routing protocol.
+
+5.28. RFC 3107 Carrying Label Information in BGP-4
+
+ There are no IPv4 dependencies in this protocol.
+
+5.29. RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse
+ Discovery Specification
+
+ This is an IPv6 related document and is not discussed in this
+ document.
+
+6. Experimental RFCs
+
+ Experimental RFCs typically define protocols that do not have wide
+ scale implementation or usage on the Internet. They are often
+ propriety in nature or used in limited arenas. They are documented
+ to the Internet community in order to allow potential
+ interoperability or some other potential useful scenario. In a few
+ cases they are presented as alternatives to the mainstream solution
+ to an acknowledged problem.
+
+6.1. RFC 1075 Distance Vector Multicast Routing Protocol (DVMRP)
+
+ This document defines a protocol for IPv4 multicast routing.
+
+6.2. RFC 1383 An Experiment in DNS Based IP Routing
+
+ This proposal is IPv4 limited:
+
+ This record is designed for easy general purpose extensions in the
+ DNS, and its content is a text string. The RX record will contain
+ three fields: A record identifier, A cost indicator, and An IP
+ address.
+
+
+
+
+
+
+
+
+
+
+Olvera & Nesser II Informational [Page 7]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+ The three strings will be separated by a single comma. An example of
+ record would thus be:
+
+ ___________________________________________________________________
+ | domain | type | record | value |
+ | - | | | |
+ |*.27.32.192.in-addr.arpa | IP | TXT | RX, 10, 10.0.0.7|
+ |_________________________|________|__________|___________________|
+
+ which means that for all hosts whose IP address starts by the three
+ octets "192.32.27" the IP host "10.0.0.7" can be used as a gateway,
+ and that the preference value is 10.
+
+6.3. RFC 1476 RAP: Internet Route Access Protocol
+
+ This document defines an IPv7 routing protocol and has been abandoned
+ by the IETF as a feasible design. It is not considered in this
+ document.
+
+6.4. RFC 1765 OSPF Database Overflow
+
+ There are no IPv4 dependencies in this protocol other than the fact
+ that it is a new functionality for a routing protocol that only
+ supports IPv4 networks.
+
+6.5. RFC 1863 A BGP/IDRP Route Server alternative to a full mesh
+ routing
+
+ This protocol is both IPv4 and IPv6 aware and needs no changes.
+
+6.6. RFC 1966 BGP Route Reflection An alternative to full mesh IBGP
+
+ Although the protocol enhancements have no IPv4 dependencies, the
+ base protocol, BGP-4, is IPv4 only routing protocol. This
+ specification has been updated by RFC 2796.
+
+6.7. RFC 2189 Core Based Trees (CBT version 2) Multicast Routing
+
+ The document specifies a protocol that depends on IPv4 multicast.
+ There are many packet formats defined that show IPv4 usage.
+
+6.8. RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture
+
+ See previous Section for the IPv4 limitation in this protocol.
+
+
+
+
+
+
+
+Olvera & Nesser II Informational [Page 8]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+6.9. RFC 2337 Intra-LIS IP multicast among routers over ATM using
+ Sparse Mode PIM
+
+ This protocol is designed for IPv4 multicast.
+
+6.10. RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM):
+ Protocol Specification
+
+ This protocol is both IPv4 and IPv6 aware and needs no changes.
+
+6.11. RFC 2676 QoS Routing Mechanisms and OSPF Extensions
+
+ There are IPv4 dependencies in this protocol. It requires the use of
+ the IPv4 TOS header field.
+
+7. Summary of Results
+
+ In the initial survey of RFCs, 23 positives were identified out of a
+ total of 46, broken down as follows:
+
+ Standards: 3 out of 3 or 100.00%
+ Draft Standards: 1 out of 3 or 33.33%
+ Proposed Standards: 13 out of 29 or 44.83%
+ Experimental RFCs: 6 out of 11 or 54.54%
+
+ Of those identified many require no action because they document
+ outdated and unused protocols, while others are document protocols
+ that are actively being updated by the appropriate working groups.
+ Additionally there are many instances of standards that should be
+ updated but do not cause any operational impact if they are not
+ updated. The remaining instances are documented below. The authors
+ have attempted to organize the results in a format that allows easy
+ reference to other protocol designers. The assignment of statements
+ has been based entirely on the authors perceived needs for updates
+ and should not be taken as an official statement.
+
+7.1. Standards
+
+7.1.1. STD 57 RIP Version 2 Protocol Applicability Statement (RFC 1722)
+
+ This problem has been fixed by RFC 2081, RIPng Protocol Applicability
+ Statement.
+
+
+
+
+
+
+
+
+
+Olvera & Nesser II Informational [Page 9]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+7.1.2. STD 54 OSPF Version 2 (RFC 2328)
+
+ This problem has been fixed by RFC 2740, OSPF for IPv6.
+
+7.1.3. STD 56 RIP Version 2 (RFC 2453)
+
+ This problem has been fixed by RFC 2080, RIPng for IPv6.
+
+7.2. Draft Standards
+
+7.2.1. Border Gateway Protocol 4 (RFC 1771)
+
+ This problem has been fixed in RFC 2858 Multiprotocol Extensions for
+ BGP-4, RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6
+ Inter-Domain Routing, and in [8].
+
+ RFC 2858 extends BGP to support multi-protocol extensions that allows
+ routing information for other address families to be exchanged. RFC
+ 2545 further extends RFC 2858 for full support of exchanging IPv6
+ routing information and additionally clarifies support of the
+ extended BGP-4 protocol using TCP+IPv6 as a transport mechanism. RFC
+ 1771, 2858 & 2545 must be supported in order to provide full IPv6
+ support.
+
+ Note also that all the BGP extensions analyzed previously in this
+ memo function without changes with the updated version of BGP-4.
+
+7.3. Proposed Standards
+
+7.3.1. Use of OSI IS-IS for routing in TCP/IP and dual environments
+ (RFC 1195)
+
+ This problem is being addressed by the IS-IS WG [9].
+
+7.3.2. Applicability Statement for OSPFv2 (RFC 1370)
+
+ This problem has been resolved in RFC 2740, OSPF for IPv6.
+
+7.3.3. Applicability of CIDR (RFC 1517)
+
+ The contents of this specification has been treated in various IPv6
+ addressing architecture RFCs, see RFC 3513 & 3587.
+
+7.3.4. CIDR Architecture (RFC 1518)
+
+ The contents of this specification has been treated in various IPv6
+ addressing architecture RFCs, see RFC 3513 & 3587.
+
+
+
+
+Olvera & Nesser II Informational [Page 10]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+7.3.5. Classless Inter-Domain Routing (CIDR): an Address Assignment
+ and Aggregation Strategy (RFC 1519)
+
+ The contents of this specification has been treated in various IPv6
+ addressing architecture RFCs, see RFC 3513 & 3587.
+
+7.3.6. RIP Extensions for Demand Circuits (RFC 1582)
+
+ This problem has been addressed in RFC 2080, RIPng for IPv6.
+
+7.3.7. OSPF Multicast Extensions (RFC 1584)
+
+ This functionality has been covered in RFC 2740, OSPF for IPv6.
+
+7.3.8. OSPF For Demand Circuits (RFC 1793)
+
+ This functionality has been covered in RFC 2740, OSPF for IPv6.
+
+7.3.9. RIP Triggered Extensions for Demand Circuits (RFC 2091)
+
+ This functionality is provided in RFC 2080, RIPng for IPv6.
+
+7.3.10. Virtual Router Redundancy Protocol (VRRP)(RFC 2338)
+
+ The problems identified are being addressed by the VRRP WG [10].
+
+7.3.11. OSPF Opaque LSA Option (RFC 2370)
+
+ This problem has been fixed by RFC 2740, OSPF for IPv6. Opaque
+ options support is an inbuilt functionality in OSPFv3.
+
+7.3.12. Generic Routing Encapsulation (GRE)(RFC 2784)
+
+ Even though GRE tunneling over IPv6 has been implemented and used,
+ its use has not been formally specified. Clarifications are
+ required.
+
+7.3.13. OSPF NSSA Option (RFC 3101)
+
+ This functionality has been covered in RFC 2740, OSPF for IPv6.
+
+7.4. Experimental RFCs
+
+7.4.1. Distance Vector Multicast Routing Protocol (RFC 1075)
+
+ This protocol is a routing protocol for IPv4 multicast routing. It
+ is no longer in use and need not be redefined.
+
+
+
+
+Olvera & Nesser II Informational [Page 11]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+7.4.2. An Experiment in DNS Based IP Routing (RFC 1383)
+
+ This protocol relies on IPv4 DNS RR, but is no longer relevant has
+ never seen much use; no action is necessary.
+
+7.4.3. Core Based Trees (CBT version 2) Multicast Routing (RFC 2189)
+
+ This protocol relies on IPv4 IGMP Multicast and a new protocol
+ standard may be produced. However, the multicast routing protocol
+ has never been in much use and is no longer relevant; no action is
+ necessary.
+
+7.4.4. Core Based Trees (CBT) Multicast Routing Architecture (RFC 2201)
+
+ See previous Section for the limitation in this protocol.
+
+7.4.5. Intra-LIS IP multicast among routers over ATM using Sparse
+ Mode PIM (RFC 2337)
+
+ This protocol is designed for IPv4 multicast. However, Intra-LIS IP
+ multicast among routers over ATM is not believed to be relevant
+ anymore. A new mechanism may be defined for IPv6 multicast.
+
+7.4.6. QoS Routing Mechanisms and OSPF Extensions (RFC 2676)
+
+ QoS extensions for OSPF were never used for OSPFv2, and there seems
+ to be little need for them in OSPFv3.
+
+ However, if necessary, an update to this document could simply define
+ the use of the IPv6 Traffic Class field since it is defined to be
+ exactly the same as the IPv4 TOS field.
+
+8. Security Considerations
+
+ This document examines the IPv6-readiness of routing specification;
+ this does not have security considerations in itself.
+
+9. Acknowledgements
+
+ The original author, Philip J. Nesser II, would like to acknowledge
+ the support of the Internet Society in the research and production of
+ this document.
+
+ He also would like to thanks his partner in all ways, Wendy M.
+ Nesser.
+
+
+
+
+
+
+Olvera & Nesser II Informational [Page 12]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+ Cesar Olvera would like to thanks Pekka Savola for an extended
+ guidance and comments for the edition of this document, and Jordi
+ Palet for his support and reviews.
+
+ Additionally, he would further like to thank Andreas Bergstrom, Brian
+ Carpenter, Jeff Haas, Vishwas Manral, Gabriela Medina, Venkata Naidu,
+ Jeff Parker and Curtis Villamizar for valuable feedback.
+
+10. References
+
+10.1. Normative References
+
+ [1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the
+ Survey of IPv4 Addresses in Currently Deployed IETF Standards",
+ RFC 3789, June 2004.
+
+ [2] Sofia, R. and P. Nesser, II, "Survey of IPv4 Addresses in
+ Currently Deployed IETF Application Area Standards", RFC 3795,
+ June 2004.
+
+ [3] Mickles, C. and P. Nesser, II, "Internet Area: Survey of IPv4
+ Addresses Currently Deployed IETF Standards", RFC 3790, June
+ 2004.
+
+ [4] Nesser, II, P. and A. Bergstrom, "Survey of IPv4 addresses in
+ Currently Deployed IETF Operations & Management Area
+ Standards", RFC 3796, June 2004.
+
+ [5] Nesser, II, P. and A. Bergstrom. "Survey of IPv4 Addresses in
+ Currently Deployed IETF Security Area Standards", RFC 3792,
+ June 2004.
+
+ [6] Nesser, II, P. and A. Bergstrom. "Survey of IPv4 Addresses in
+ Currently Deployed IETF Sub-IP Area Standards", RFC 3793, June
+ 2004.
+
+ [7] Nesser, II, P. and A. Bergstrom "Survey of IPv4 Addresses in
+ Currently Deployed IETF Transport Area Standards", RFC 3794,
+ June 2004.
+
+10.2. Informative References
+
+ [8] Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for BGP-
+ 4", Work in Progress, December 2003.
+
+ [9] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, January
+ 2003.
+
+
+
+
+Olvera & Nesser II Informational [Page 13]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+ [10] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", Work
+ in Progress, February 2004.
+
+11. Authors' Addresses
+
+ Please contact the authors with any questions, comments or
+ suggestions at:
+
+ Cesar Olvera Morales
+ Researcher
+ Consulintel
+ San Jose Artesano, 1
+ 28108 - Alcobendas
+ Madrid, Spain
+
+ Phone: +34 91 151 81 99
+ Fax: +34 91 151 81 98
+ EMail: cesar.olvera@consulintel.es
+
+
+ Philip J. Nesser II
+ Principal
+ Nesser & Nesser Consulting
+ 13501 100th Ave NE, #5202
+ Kirkland, WA 98034
+
+ Phone: +1 425 481 4303
+ EMail: phil@nesser.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Olvera & Nesser II Informational [Page 14]
+
+RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). 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 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Olvera & Nesser II Informational [Page 15]
+