draft-ietf-grow-rfc1519bis-03.txt   draft-ietf-grow-rfc1519bis-04.txt 
GROW V. Fuller GROW V. Fuller
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: May 12, 2006 T. Li Expires: July 5, 2006 T. Li
Portola Networks Li Consulting
November 8, 2005 January 2006
Classless Inter-Domain Routing (CIDR): The Internet Address Assignment Classless Inter-Domain Routing (CIDR): The Internet Address Assignment
and Aggregation Plan and Aggregation Plan
draft-ietf-grow-rfc1519bis-03 draft-ietf-grow-rfc1519bis-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 will expire on May 12, 2006. This Internet-Draft will expire on July 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo discusses the strategy for address assignment of the This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the existing 32-bit IPv4 address space with a view toward conserving the
address space and limiting the growth rate of global routing state. address space and limiting the growth rate of global routing state.
This document obsoletes the original CIDR spec [RFC1519], with This document obsoletes the original CIDR spec [RFC1519], with
changes made both to clarify the concepts it introduced and, after changes made both to clarify the concepts it introduced and, after
more than twelve years, to update the Internet community on the more than twelve years, to update the Internet community on the
results of deploying the technology described. results of deploying the technology described.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. History and Problem Description . . . . . . . . . . . . . . . 3 2. History and Problem Description . . . . . . . . . . . . . . . 3
3. Classless addressing as a solution . . . . . . . . . . . . . . 4 3. Classless addressing as a solution . . . . . . . . . . . . . . 4
3.1. Basic concept and prefix notation . . . . . . . . . . . . 5 3.1. Basic concept and prefix notation . . . . . . . . . . . . 5
4. Address assignment and routing aggregation . . . . . . . . . . 8 4. Address assignment and routing aggregation . . . . . . . . . . 8
4.1. Aggregation efficiency and limitations . . . . . . . . . . 8 4.1. Aggregation efficiency and limitations . . . . . . . . . . 8
4.2. Distributed assignment of address space . . . . . . . . . 9 4.2. Distributed assignment of address space . . . . . . . . . 9
5. Routing implementation considerations . . . . . . . . . . . . 10 5. Routing implementation considerations . . . . . . . . . . . . 10
5.1. Rules for route advertisement . . . . . . . . . . . . . . 11 5.1. Rules for route advertisement . . . . . . . . . . . . . . 11
5.2. How the rules work . . . . . . . . . . . . . . . . . . . . 12 5.2. How the rules work . . . . . . . . . . . . . . . . . . . . 12
5.3. A note on prefix filter formats . . . . . . . . . . . . . 12 5.3. A note on prefix filter formats . . . . . . . . . . . . . 13
5.4. Responsibility for and configuration of aggregation . . . 13 5.4. Responsibility for and configuration of aggregation . . . 13
5.5. Route propagation and routing protocol considerations . . 14 5.5. Route propagation and routing protocol considerations . . 14
6. Example of new address assignments and routing . . . . . . . . 15 6. Example of new address assignments and routing . . . . . . . . 15
6.1. Address delegation . . . . . . . . . . . . . . . . . . . . 15 6.1. Address delegation . . . . . . . . . . . . . . . . . . . . 15
6.2. Routing advertisements . . . . . . . . . . . . . . . . . . 17 6.2. Routing advertisements . . . . . . . . . . . . . . . . . . 17
7. Domain Name Service considerations . . . . . . . . . . . . . . 18 7. Domain Name Service considerations . . . . . . . . . . . . . . 18
8. Transition to a long term solution . . . . . . . . . . . . . . 20 8. Transition to a long term solution . . . . . . . . . . . . . . 18
9. Analysis of CIDR's effect on global routing state . . . . . . 20 9. Analysis of CIDR's effect on global routing state . . . . . . 18
10. Conclusions and Recommendations . . . . . . . . . . . . . . . 22 10. Conclusions and Recommendations . . . . . . . . . . . . . . . 20
11. Status updates to CIDR documents . . . . . . . . . . . . . . . 22 11. Status updates to CIDR documents . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
15. Appendix A: Area Director Comments and Responses . . . . . . . 26 15. Appendix A: Area Director Comments and Responses . . . . . . . 24
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16.1. Normative References . . . . . . . . . . . . . . . . . . . 27 16.1. Normative References . . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . . 27 16.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
This memo discusses the strategy for address assignment of the This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the existing 32-bit IPv4 address space with a view toward conserving the
address space and limiting the growth rate of global routing state. address space and limiting the growth rate of global routing state.
This document obsoletes the original CIDR spec [RFC1519], with This document obsoletes the original CIDR spec [RFC1519], with
changes made both to clarify the concepts it introduced and, after changes made both to clarify the concepts it introduced and, after
more than twelve years, to update the Internet community on the more than twelve years, to update the Internet community on the
results of deploying the technology described. results of deploying the technology described.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
There are two, more complex, situations that reduce the effectiveness There are two, more complex, situations that reduce the effectiveness
of aggregation: of aggregation:
o An organization which is multi-homed. Because a multi-homed o An organization which is multi-homed. Because a multi-homed
organization must be advertised into the system by each of its organization must be advertised into the system by each of its
service providers, it is often not feasible to aggregate its service providers, it is often not feasible to aggregate its
routing information into the address space of any one of those routing information into the address space of any one of those
providers. Note that the organization still may receive its providers. Note that the organization still may receive its
address assignment out of a service provider's address space address assignment out of a service provider's address space
(which has other advantages), but a route to the organization's (which has other advantages), but a route to the organization's
prefix must still be explicitly advertised by all of its service prefix is, in the most general case, explicitly advertised by all
providers. For this reason, the global routing cost for a multi- of its service providers. For this reason, the global routing
homed organization is generally the same as it was prior to the cost for a multi-homed organization is generally the same as it
adoption of CIDR. was prior to the adoption of CIDR. A more detailed consideration
of multi-homing practices can be found in [RFC4116].
o An organization which changes service provider but does not o An organization which changes service provider but does not
renumber. This has the effect of "punching a hole" in one of the renumber. This has the effect of "punching a hole" in one of the
original service provider's aggregated route advertisements. CIDR original service provider's aggregated route advertisements. CIDR
handles this situation by requiring the newer service provider to handles this situation by requiring the newer service provider to
advertise a specific advertisement for the re-homed organization; advertise a specific advertisement for the re-homed organization;
this advertisement is preferred over provider aggregates because this advertisement is preferred over provider aggregates because
it is a longer match. To maintain efficiency of aggregation, it it is a longer match. To maintain efficiency of aggregation, it
is recommended that an organization which changes service is recommended that an organization which changes service
providers plan to eventually migrate its network into a an prefix providers plan to eventually migrate its network into a an prefix
skipping to change at page 9, line 25 skipping to change at page 9, line 25
is recommended that mechanisms to facilitate such migration, such is recommended that mechanisms to facilitate such migration, such
as dynamic host address assignment using [RFC2131]) be deployed as dynamic host address assignment using [RFC2131]) be deployed
wherever possible, and that additional protocol work be done to wherever possible, and that additional protocol work be done to
develop improved technology for renumbering. develop improved technology for renumbering.
Note that some aggregation efficiency gain can still be had for Note that some aggregation efficiency gain can still be had for
multi-homed sites (and, in general, for any site composed of multi-homed sites (and, in general, for any site composed of
multiple, logical IPv4 networks) - by allocating a contiguous power- multiple, logical IPv4 networks) - by allocating a contiguous power-
of-two block address space to the site (as opposed to multiple, of-two block address space to the site (as opposed to multiple,
independent prefixes) the site's routing information may be independent prefixes) the site's routing information may be
aggregated into a single prefix. aggregated into a single prefix. Also, since the routing cost
associated with assigning a multi-homed site out of a service
provider's address space is no greater than the old method of
sequential number assignment by a central authority, it makes sense
to assign all end-site address space out of blocks allocated to
service providers.
It is also worthwhile to mention that since aggregation may occur at It is also worthwhile to mention that since aggregation may occur at
multiple levels in the system, it may still be possible to aggregate multiple levels in the system, it may still be possible to aggregate
these anomalous routes at higher levels of whatever hierarchy may be these anomalous routes at higher levels of whatever hierarchy may be
present. For example, if a site is multi-homed to two relatively present. For example, if a site is multi-homed to two relatively
small providers that both obtain connectivity and address space from small providers that both obtain connectivity and address space from
the same large provider, then aggregation by the large provider of the same large provider, then aggregation by the large provider of
routes from the smaller networks will include all routes to the routes from the smaller networks will include all routes to the
multi-homed site. The feasibility of this sort of second-level multi-homed site. The feasibility of this sort of second-level
aggregation depends on whether topological hierarchy exists between a aggregation depends on whether topological hierarchy exists between a
skipping to change at page 10, line 47 skipping to change at page 11, line 5
5. Routing implementation considerations 5. Routing implementation considerations
With the change from classful network numbers to classless prefixes, With the change from classful network numbers to classless prefixes,
it is not possible to infer the network mask from the initial bit it is not possible to infer the network mask from the initial bit
pattern of an IPv4 address. This has implications for how routing pattern of an IPv4 address. This has implications for how routing
information is stored and propagated. Network masks or prefix information is stored and propagated. Network masks or prefix
lengths must be explicitly carried in routing protocols. Interior lengths must be explicitly carried in routing protocols. Interior
routing protocols such as OSPF [RFC2178], IS-IS [RFC1195], RIPv2 routing protocols such as OSPF [RFC2178], IS-IS [RFC1195], RIPv2
[RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol [RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol
[RFC1771] all support this functionality, having been developed or [RFC4271] all support this functionality, having been developed or
modified as part of the deployment of classless inter-domain routing modified as part of the deployment of classless inter-domain routing
during the 1990s. during the 1990s.
Older interior routing protocols, such as RIP [RFC1058], HELLO, and Older interior routing protocols, such as RIP [RFC1058], HELLO, and
Cisco IGRP, and older exterior routing protocols, such as EGP Cisco IGRP, and older exterior routing protocols, such as EGP
[RFC904], do not support explicit carriage of prefix length/mask and [RFC904], do not support explicit carriage of prefix length/mask and
thus cannot be effectively used on the Internet in other than very thus cannot be effectively used on the Internet in other than very
limited, stub configurations. While their use may be appropriate in limited, stub configurations. While their use may be appropriate in
simple, legacy end-site configurations, they are considered obsolete simple, legacy end-site configurations, they are considered obsolete
and should NOT be used in transit networks connected to the global and should NOT be used in transit networks connected to the global
skipping to change at page 11, line 24 skipping to change at page 11, line 28
Similarly, routing and forwarding tables in layer-3 network equipment Similarly, routing and forwarding tables in layer-3 network equipment
must be organized to store both prefix and prefix length or mask. must be organized to store both prefix and prefix length or mask.
Equipment which organizes its routing/forwarding information Equipment which organizes its routing/forwarding information
according to legacy class A/B/C network/subnet conventions cannot be according to legacy class A/B/C network/subnet conventions cannot be
expected to work correctly on networks connected to the global expected to work correctly on networks connected to the global
Internet; use of such equipment is not recommended. Fortunately, Internet; use of such equipment is not recommended. Fortunately,
very little such equipment is in use today. very little such equipment is in use today.
5.1. Rules for route advertisement 5.1. Rules for route advertisement
1. Routing to all destinations must be done on a longest-match basis 1. Forwarding in the Internet is done on a longest-match basis.
only. This implies that destinations which are multi-homed This implies that destinations which are multi-homed relative to
relative to a routing domain must always be explicitly announced a routing domain must always be explicitly announced into that
into that routing domain - they cannot be summarized (this makes routing domain - they cannot be summarized (this makes intuitive
intuitive sense - if a network is multi-homed, all of its paths sense - if a network is multi-homed, all of its paths into a
into a routing domain which is "higher" in the hierarchy of routing domain which is "higher" in the hierarchy of networks
networks must be known to the "higher" network). must be known to the "higher" network).
2. A router which generates an aggregate route for multiple, more- 2. A router which generates an aggregate route for multiple, more-
specific routes must discard packets which match the aggregate specific routes must discard packets which match the aggregate
route but not any of the more-specific routes. In other words, route but not any of the more-specific routes. In other words,
the "next hop" for the aggregate route should be the null the "next hop" for the aggregate route should be the null
destination. This is necessary to prevent forwarding loops when destination. This is necessary to prevent forwarding loops when
some addresses covered by the aggregate are not reachable. some addresses covered by the aggregate are not reachable.
Note that during failures, partial routing of traffic to a site which Note that during failures, partial routing of traffic to a site which
takes its address space from one service provider but which is takes its address space from one service provider but which is
skipping to change at page 12, line 12 skipping to change at page 12, line 17
"problem" is beyond the scope of this document - it lies with better "problem" is beyond the scope of this document - it lies with better
education of the user/operator community, not in routing technology. education of the user/operator community, not in routing technology.
An implementation following these rules should also be generalized, An implementation following these rules should also be generalized,
so that an arbitrary network number and mask are accepted for all so that an arbitrary network number and mask are accepted for all
routing destinations. The only outstanding constraint is that the routing destinations. The only outstanding constraint is that the
mask must be left contiguous. Note that the degenerate route to mask must be left contiguous. Note that the degenerate route to
prefix 0.0.0.0/0 is used as a default route and MUST be accepted by prefix 0.0.0.0/0 is used as a default route and MUST be accepted by
all implementations. Further, to protect against accidental all implementations. Further, to protect against accidental
advertisements of this route via the inter-domain protocol, this advertisements of this route via the inter-domain protocol, this
route should only be advertised when a router is explicitly route should only be advertised to another routing domain when a
configured to do so - never as a non-configured, "default" option. router is explicitly configured to do so - never as a non-configured,
"default" option.
5.2. How the rules work 5.2. How the rules work
Rule #1 guarantees that the routing algorithm used is consistent Rule #1 guarantees that the forwarding algorithm used is consistent
across implementations and consistent with other routing protocols, across routing protocols and implementations. Multi-homed networks
such as OSPF. Multi-homed networks are always explicitly advertised are always explicitly advertised by every service provider through
by every service provider through which they are routed even if they which they are routed even if they are a specific subset of one
are a specific subset of one service provider's aggregate (if they service provider's aggregate (if they are not, they clearly must be
are not, they clearly must be explicitly advertised). It may seem as explicitly advertised). It may seem as if the "primary" service
if the "primary" service provider could advertise the multi-homed provider could advertise the multi-homed site implicitly as part of
site implicitly as part of its aggregate, but the assumption that its aggregate, but longest-match forwarding causes this not to work.
longest-match routing is always done causes this not to work. More details are provided in [RFC4116].
Rule #2 guarantees that no routing loops form due to aggregation. Rule #2 guarantees that no routing loops form due to aggregation.
Consider a site that has been assigned 192.168.64/19 by its "parent" Consider a site that has been assigned 192.168.64/19 by its "parent"
provider that has 192.168.0.0/16. The "parent" network will provider that has 192.168.0.0/16. The "parent" network will
advertise 192.168.0.0/16 to the "child" network. If the "child" advertise 192.168.0.0/16 to the "child" network. If the "child"
network were to lose internal connectivity to 192.168.65.0/24 (which network were to lose internal connectivity to 192.168.65.0/24 (which
is part of its aggregate), traffic from the "parent" to the to the is part of its aggregate), traffic from the "parent" to the to the
"child" destined for 192.168.65.1 will follow the "child's" "child" destined for 192.168.65.1 will follow the "child's"
advertised route. When that traffic gets to the "child", however, advertised route. When that traffic gets to the "child", however,
the mid-level *must not* follow the route 192.168.0.0/16 back up to the child *must not* follow the route 192.168.0.0/16 back up to the
the "parent", since that would result in a forwarding loop. Rule #2 "parent", since that would result in a forwarding loop. Rule #2 says
says that the "child" may not follow a less-specific route for a that the "child" may not follow a less-specific route for a
destination which matches one of its own aggregated routes destination which matches one of its own aggregated routes
(typically, this is implemented by installing a "discard" or "null" (typically, this is implemented by installing a "discard" or "null"
route for all aggregated prefixes which one network advertises to route for all aggregated prefixes which one network advertises to
another). Note that handling of the "default" route (0.0.0.0/0) is a another). Note that handling of the "default" route (0.0.0.0/0) is a
special case of this rule - a network must not follow the default to special case of this rule - a network must not follow the default to
destinations which are part of one of it's aggregated advertisements. destinations which are part of one of it's aggregated advertisements.
5.3. A note on prefix filter formats 5.3. A note on prefix filter formats
Systems which process route announcements must be able to verify that Systems which process route announcements must be able to verify that
skipping to change at page 13, line 48 skipping to change at page 14, line 7
(for example, a customer may wish for its service provider to (for example, a customer may wish for its service provider to
generate aggregated routing information on its behalf); in such generate aggregated routing information on its behalf); in such
cases, aggregation is performed by a router in the second AS based on cases, aggregation is performed by a router in the second AS based on
the routes that it receives from the first combined with configured the routes that it receives from the first combined with configured
policy information describing how those routes should be aggregated. policy information describing how those routes should be aggregated.
It should be mentioned that one provider may choose to perform It should be mentioned that one provider may choose to perform
aggregation on the routes it receives from another without explicit aggregation on the routes it receives from another without explicit
agreement; this is termed "proxy aggregation". This can be a useful agreement; this is termed "proxy aggregation". This can be a useful
tool for reducing the amount of routing state that an AS must carry tool for reducing the amount of routing state that an AS must carry
and propagate to its customers and neighbors, proxy aggregation can and propagate to its customers and neighbors. However, proxy
also create inconsistencies in global routing state. Consider what aggregation can also create unintended consequences in traffic
happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs engineering. Consider what happens if both AS 2 and 3 receive routes
proxy aggregation while AS 3 does not. Other AS's which receive from AS 1 but AS 2 performs proxy aggregation while AS 3 does not.
transit routing information from both AS 2 and AS 3 will see an Other AS's which receive transit routing information from both AS 2
inconsistent view of the routing information originated by AS 1. and AS 3 will see an inconsistent view of the routing information
This may cause an unexpected shift of traffic toward AS 1 through AS originated by AS 1. This may cause an unexpected shift of traffic
3 for AS 3's customers and any others receiving transit routes from toward AS 1 through AS 3 for AS 3's customers and any others
AS 3. Because proxy aggregation can cause unanticipated consequences receiving transit routes from AS 3. Because proxy aggregation can
for parts of the Internet that have no relationship with either the cause unanticipated consequences for parts of the Internet that have
source of the aggregated routes or the party providing aggregation, no relationship with either the source of the aggregated routes or
it should be used with extreme caution. the party providing aggregation, it should be used with extreme
caution.
Configuration of the routes to be combined into aggregates is an Configuration of the routes to be combined into aggregates is an
implementation of routing policy and does require some manually- implementation of routing policy and does require some manually-
maintained information. As an addition to the information that must maintained information. As an addition to the information that must
be maintained for a set of routeable prefixes, aggregation be maintained for a set of routeable prefixes, aggregation
configuration is typically just a line or two defining the range of configuration is typically just a line or two defining the range of
the block of IPv4 addresses to aggregate. A site performing its own the block of IPv4 addresses to aggregate. A site performing its own
aggregation is doing so for address blocks that it has been assigned; aggregation is doing so for address blocks that it has been assigned;
a site performing aggregation on behalf of another knows this a site performing aggregation on behalf of another knows this
information based on an agreement to delegate aggregation. Assuming information based on an agreement to delegate aggregation. Assuming
a best common practice for network administrators to exchange lists that the best common practice for network administrators is to
of prefixes to accept from one and other, configuration of exchange lists of prefixes to accept from each other, configuration
aggregation information does not introduce significant additional of aggregation information does not introduce significant additional
administrative overhead. administrative overhead.
The generation of an aggregate route is usually specified either The generation of an aggregate route is usually specified either
statically or in response to learning an active dynamic route for a statically or in response to learning an active dynamic route for a
prefix contained within the aggregate route. If such dynamic prefix contained within the aggregate route. If such dynamic
aggregate route advertisement is done, care should be taken that aggregate route advertisement is done, care should be taken that
routes are not excessively added or withdrawn (known as "route routes are not excessively added or withdrawn (known as "route
flapping"); in general, a dynamic aggregate route advertisement is flapping"); in general, a dynamic aggregate route advertisement is
added when at least one component of the aggregate becomes reachable added when at least one component of the aggregate becomes reachable
and it is withdrawn only when all components become unreachable. and it is withdrawn only when all components become unreachable.
skipping to change at page 15, line 41 skipping to change at page 16, line 4
o "C5" requiring fewer than 512 addresses (/23 or 2 x /24) o "C5" requiring fewer than 512 addresses (/23 or 2 x /24)
o "C6" requiring fewer than 512 addresses (/23 or 2 x /24) o "C6" requiring fewer than 512 addresses (/23 or 2 x /24)
In all cases, the number of IPv4 addresses "required" by each site is In all cases, the number of IPv4 addresses "required" by each site is
assumed to allow for significant growth. The service provider assumed to allow for significant growth. The service provider
delegates its address space as follows: delegates its address space as follows:
o C1: assign 10.24.0 through 10.24.7. This block of networks is o C1: assign 10.24.0 through 10.24.7. This block of networks is
described by the route 10.24.0.0/21 (mask 255.255.248.0) described by the route 10.24.0.0/21 (mask 255.255.248.0)
o C2: assign 10.24.16 through 10.24.31. This block is described by o C2: assign 10.24.16 through 10.24.31. This block is described by
the route 10.24.16.0/20 (mask 255.255.240.0) the route 10.24.16.0/20 (mask 255.255.240.0)
o C3: assign 10.24.8 through 10.24.11. This block is described by o C3: assign 10.24.8 through 10.24.11. This block is described by
the route 10.24.8.0/22 (mask 255.255.252.0) the route 10.24.8.0/22 (mask 255.255.252.0)
o C4: assign 10.24.12 through 10.24.15. This block is described by o C4: assign 10.24.12 through 10.24.15. This block is described by
the route 10.24.12.0/22 (mask 255.255.252.0) the route 10.24.12.0/22 (mask 255.255.252.0)
o C5: assign 10.24.32 and 10.24.33. This block is described by the o C5: assign 10.24.32 and 10.24.33. This block is described by the
route 10.24.32.0/23 (mask 255.255.254.0) route 10.24.32.0/23 (mask 255.255.254.0)
o C6: assign 10.24.34 and 10.24.35. This block is described by the o C6: assign 10.24.34 and 10.24.35. This block is described by the
route 10.24.34.0/23 (mask 255.255.254.0) route 10.24.34.0/23 (mask 255.255.254.0)
These six sites should be represented as six prefixes of varying size These six sites should be represented as six prefixes of varying size
within the provider IGP. If, for some reason, the provider were to within the provider's IGP. If, for some reason, the provider uses an
use an obsolete IGP that doesn't support classless routing, then obsolete IGP that doesn't support classless routing or variable-
explicit routes all /24s will have to be carried. length subnets, then explicit routes for all /24s will have to be
carried.
To make this example more realistic, assume that C4 and C5 are multi- To make this example more realistic, assume that C4 and C5 are multi-
homed through some other service provider, "PB". Further assume the homed through some other service provider, "PB". Further assume the
existence of a site "C7" which was originally connected to "RB" but existence of a site "C7" which was originally connected to "RB" but
has moved to "PA". For this reason, it has a block of network has moved to "PA". For this reason, it has a block of network
numbers which are assigned out "PB"'s block of (the next) 2048 x /24. numbers which are assigned out "PB"'s block of (the next) 2048 x /24.
o C7: assign 10.32.0 through 10.32.15. This block is described by o C7: assign 10.32.0 through 10.32.15. This block is described by
the route 10.32.0.0/20 (mask 255.255.240.0) the route 10.32.0.0/20 (mask 255.255.240.0)
skipping to change at page 18, line 32 skipping to change at page 18, line 32
7. Domain Name Service considerations 7. Domain Name Service considerations
One aspect of Internet services which was notably affected by the One aspect of Internet services which was notably affected by the
move to CIDR was the mechanism used for address-to-name translation: move to CIDR was the mechanism used for address-to-name translation:
the IN-ADDR.ARPA zone of the domain system. Because this zone is the IN-ADDR.ARPA zone of the domain system. Because this zone is
delegated on octet boundaries only, the move to an address assignment delegated on octet boundaries only, the move to an address assignment
plan which uses bitmask-oriented addressing caused some increase in plan which uses bitmask-oriented addressing caused some increase in
work for those who maintain parts of the IN-ADDR.ARPA zone. work for those who maintain parts of the IN-ADDR.ARPA zone.
As described above, the IN-ADDR.ARPA zone is necessarily organized A description of techniques to populate the IN-ADDR.ARPA zone when
along octet boundaries. Prior to the adoption of CIDR, IN-ADDR.ARPA using address blocks that do not align to octet boundaries is
was also constrained such that delegations were only permitted along described in [RFC2317].
legacy, class A/B/C network number boundaries. This created a
difficult situation for more flexible, CIDR prefixes. Consider a
hypothetical large network provider named "BigNet" which has been
allocated the block 10.4.0.0 through 10.7.255.0 (the CIDR prefix
10.4.0.0/14). Under the old delegation policies, the top-level IN-
ADDR.ARPA domain servers would need to have 1024 entries of the form:
0.4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
1.4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
....
255.7.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
By revising the policy as described above, this was reduced to four
delegation records:
4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
5.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
6.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
7.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
The provider then maintains further delegations of naming authority
for each individual /24 which it assigns, rather than having each
registered separately. Note that due to the way the DNS is designed,
it is still possible for the top-level IN-ADDR.ARPA name servers to
maintain the delegation information for individual networks for which
the provider is unwilling or unable to do so. The example above
illustrates only the records for a single name server. In the normal
case, there are usually several name servers for each domain, thus
the size of the examples will double or triple in the common cases.
For BIG.NET to assign a blocks smaller than /24 to its customers, it
can similarly delegate DNS authority for those addresses. For
example, if it were to assign 10.4.99.64/26 to its customer
CUSTONE.COM and 10.4.99.128/27 to its customer CUSTTWO.COM, it could
add the following records to delegate DNS for the addresses to those
customers:
64.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM.
65.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM.
....
127.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM
128.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM
129.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM
....
159.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM
And if BIG.NET also assigned 10.4.99.160/30 to CUSTTHREE.COM but this
customer did not want to run its own DNS, BIG.NET could provide that
service for the customer by installing the appropriate PTR records:
160.99.4.10.IN-ADDR.ARPA. IN PTR NET.CUSTTHREE.COM.
161.99.4.10.IN-ADDR.ARPA. IN PTR HOST1.CUSTTHREE.COM.
162.99.4.10.IN-ADDR.ARPA. IN PTR HOST2.CUSTTHREE.COM.
163.99.4.10.IN-ADDR.ARPA. IN PTR BCAST.CUSTTHREE.COM.
See [RFC2317] for a much more detailed discussion of DNS delegation
with classless addressing.
8. Transition to a long term solution 8. Transition to a long term solution
CIDR was designed to be a short-term solution to the problems of CIDR was designed to be a short-term solution to the problems of
routing state and address depletion on the IPv4 Internet. It does routing state and address depletion on the IPv4 Internet. It does
not change the fundamental Internet routing or addressing not change the fundamental Internet routing or addressing
architectures. It is not expected to affect any plans for transition architectures. It is not expected to affect any plans for transition
to a more long-term solution except, perhaps, by delaying the urgency to a more long-term solution except, perhaps, by delaying the urgency
of developing such a solution. of developing such a solution.
skipping to change at page 22, line 9 skipping to change at page 20, line 27
fundamentally non-scalable and quite detrimental to the community fundamentally non-scalable and quite detrimental to the community
as a whole. In addition, there appear to be many providers as a whole. In addition, there appear to be many providers
advertising both their allocated prefixes and all of the /24 advertising both their allocated prefixes and all of the /24
components of them, probably due to a lack of consistent current components of them, probably due to a lack of consistent current
information about recommended routing configuration. information about recommended routing configuration.
10. Conclusions and Recommendations 10. Conclusions and Recommendations
In 1992, when CIDR was first developed, there were serious problems In 1992, when CIDR was first developed, there were serious problems
facing the continued growth of the Internet. Growth in routing state facing the continued growth of the Internet. Growth in routing state
complexity, and the rapid increase in consumption of address space complexity and the rapid increase in consumption of address space
made it appear that one or both problems would preclude continued made it appear that one or both problems would preclude continued
growth of the Internet within a few short years. growth of the Internet within a few short years.
Deployment of CIDR, in combination with BGP4's support for carrying Deployment of CIDR, in combination with BGP4's support for carrying
classless prefix routes, alleviated the short-term crisis. It was classless prefix routes, alleviated the short-term crisis. It was
only through a concerted effort by both the equipment manufacturers only through a concerted effort by both the equipment manufacturers
and the provider community that this was achieved. The threat (and, and the provider community that this was achieved. The threat (and,
perhaps in some cases, actual implementation of) charging networks perhaps in some cases, actual implementation of) charging networks
for advertising prefixes may have offered an additional incentive to for advertising prefixes may have offered an additional incentive to
share the address space, and hence the associated costs of share the address space, and hence the associated costs of
advertising routes to service providers. advertising routes to service providers.
The IPv4 routing system architecture carries topology information The IPv4 routing system architecture carries topology information
based on aggregate address advertisements and a collection of more- based on aggregate address advertisements and a collection of more-
specific advertisements that are associated with traffic engineering, specific advertisements that are associated with traffic engineering,
multi-homing and local configuration. As of March, 2005, the base multi-homing and local configuration. As of March, 2005, the base
aggregate address load in the routing system has some 75,000 entries. aggregate address load in the routing system has some 75,000 entries.
Approximately 85,000 additional entries are more specific entries of Approximately 85,000 additional entries are more specific entries of
this base "root" collection. There is reason to believe that many of this base "root" collection. There is reason to believe that many of
these additional entries are exist to solve problems of regional or these additional entries exist to solve problems of regional or even
even local scope and should not need to be globally propagated. local scope and should not need to be globally propagated.
An obvious question to ask is whether CIDR can continue to be a An obvious question to ask is whether CIDR can continue to be a
viable approach to keeping global routing state growth and address viable approach to keeping global routing state growth and address
space depletion at sustainable rates. Recent measurements indicate space depletion at sustainable rates. Recent measurements indicate
that exponential growth has resumed but further analysis suggests that exponential growth has resumed but further analysis suggests
that this trend can be mitigated by a more active effort to educate that this trend can be mitigated by a more active effort to educate
service providers on efficient aggregation strategies and proper service providers on efficient aggregation strategies and proper
equipment configuration. Looking farther forward, there is a clear equipment configuration. Looking farther forward, there is a clear
need for better multi-homing technology that does not require global need for better multi-homing technology that does not require global
routing state for each site and for methods of performing traffic routing state for each site and for methods of performing traffic
skipping to change at page 23, line 7 skipping to change at page 21, line 24
aggregation is the only tool available for making routing scale in aggregation is the only tool available for making routing scale in
the global Internet. the global Internet.
11. Status updates to CIDR documents 11. Status updates to CIDR documents
This memo renders obsolete and requests re-classification as Historic This memo renders obsolete and requests re-classification as Historic
the following RFCs describing CIDR usage and deployment: the following RFCs describing CIDR usage and deployment:
o RFC 1467: Status of CIDR Deployment in the Internet o RFC 1467: Status of CIDR Deployment in the Internet
o This Informational RFC described the status of CIDR deployment in This Informational RFC described the status of CIDR deployment in
1993. As of 2005, CIDR has been thoroughly deployed, so this 1993. As of 2005, CIDR has been thoroughly deployed, so this
status note only provides a historical data point. status note only provides a historical data point.
o RFC 1481: IAB Recommendation for an Intermediate Strategy to o RFC 1481: IAB Recommendation for an Intermediate Strategy to
Address the Issue of Scaling Address the Issue of Scaling
o This very short Informational RFC described the IAB's endorsement This very short Informational RFC described the IAB's endorsement
of the use of CIDR to address scaling issues. Because the goal of of the use of CIDR to address scaling issues. Because the goal of
RFC 1481 has been achieved, it is now only of historical value. RFC 1481 has been achieved, it is now only of historical value.
o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing
Database Database
o This Informational RFC describes plans for support of route This Informational RFC describes plans for support of route
aggregation, as specified by CIDR, on the NSFNET. Because the aggregation, as specified by CIDR, on the NSFNET. Because the
NSFNET has long since ceased to exist and CIDR has been been NSFNET has long since ceased to exist and CIDR has been been
ubiquitously deployed, RFC 1482 now only has historical relevance. ubiquitously deployed, RFC 1482 now only has historical relevance.
o RFC 1517: Applicability Statement for the Implementation of o RFC 1517: Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR) Classless Inter-Domain Routing (CIDR)
o This Standards Track RFC described where CIDR was expected to be This Standards Track RFC described where CIDR was expected to be
required and where it was expected to be (strongly) recommended. required and where it was expected to be (strongly) recommended.
With the full deployment of CIDR on the Internet, situations where With the full deployment of CIDR on the Internet, situations where
CIDR is not required are of only historical interest. CIDR is not required are of only historical interest.
o RFC 1518: An Architecture for IP Address Allocation with CIDR o RFC 1518: An Architecture for IP Address Allocation with CIDR
o This Standards Track RFC discussed routing and address aggregation This Standards Track RFC discussed routing and address aggregation
considerations at some length. Some of these issues are considerations at some length. Some of these issues are
summarized in this document in section Section 3.1. Because summarized in this document in section Section 3.1. Because
address assignment policies and procedures now reside mainly with address assignment policies and procedures now reside mainly with
the RIRs, it is not appropriate to try to document those practices the RIRs, it is not appropriate to try to document those practices
in a Standards Track RFC. In addition, [RFC3221] also describes in a Standards Track RFC. In addition, [RFC3221] also describes
many of the same issues from point of view of the routing system. many of the same issues from point of view of the routing system.
o RFC 1520: Exchanging Routing Information Across Provider o RFC 1520: Exchanging Routing Information Across Provider
Boundaries in the CIDR Environment Boundaries in the CIDR Environment
o This Informational RFC described transition scenarios where CIDR This Informational RFC described transition scenarios where CIDR
was not fully supported for exchanging route information between was not fully supported for exchanging route information between
providers. With the full deployment of CIDR on the Internet, such providers. With the full deployment of CIDR on the Internet, such
scenarios are no longer operationally relevant. scenarios are no longer operationally relevant.
o RFC 1817: CIDR and Classful Routing o RFC 1817: CIDR and Classful Routing
o This Informational RFC described the implications of CIDR This Informational RFC described the implications of CIDR
deployment in 1995; it notes that formerly-classful addresses were deployment in 1995; it notes that formerly-classful addresses were
to be allocated using CIDR mechanisms and describes the use of a to be allocated using CIDR mechanisms and describes the use of a
default route for non-CIDR-aware sites. With the full deployment default route for non-CIDR-aware sites. With the full deployment
of CIDR on the Internet, such scenarios are no longer of CIDR on the Internet, such scenarios are no longer
operationally relevant. operationally relevant.
o RFC 1878: Variable Length Subnet Table For IPv4 o RFC 1878: Variable Length Subnet Table For IPv4
o This Informational RFC provided a table of pre-calculated subnet This Informational RFC provided a table of pre-calculated subnet
masks and address counts for each subnet size. With the masks and address counts for each subnet size. With the
incorporation of a similar table into this document (see incorporation of a similar table into this document (see
Section 3.1), it is no longer necessary to document it in a Section 3.1), it is no longer necessary to document it in a
separate RFC. separate RFC.
o RFC 2036: Observations on the use of Components of the Class A o RFC 2036: Observations on the use of Components of the Class A
Address Space within the Internet Address Space within the Internet
o This Informational RFC described several operational issues This Informational RFC described several operational issues
associated with the allocation of classless prefixes from associated with the allocation of classless prefixes from
previously-classful address space. With the full deployment of previously-classful address space. With the full deployment of
CIDR on the Internet and more than half a dozen years of CIDR on the Internet and more than half a dozen years of
experience making classless prefix allocations out of historical experience making classless prefix allocations out of historical
"class A" address space, this RFC now has only historical value. "class A" address space, this RFC now has only historical value.
12. Security Considerations 12. Security Considerations
The introduction of routing protocols which support classless The introduction of routing protocols which support classless
prefixes and a move to a forwarding model that mandates that more- prefixes and a move to a forwarding model that mandates that more-
skipping to change at page 25, line 49 skipping to change at page 24, line 21
practice is to also configure a reasonable maximum number of practice is to also configure a reasonable maximum number of
prefixes that a border router will accept from its neighbors. prefixes that a border router will accept from its neighbors.
Note that this is not intended to be an exhaustive analysis of the Note that this is not intended to be an exhaustive analysis of the
sorts of attacks that CIDR makes easier; a more comprehensive sorts of attacks that CIDR makes easier; a more comprehensive
analysis of security vulnerabilities in the global routing system is analysis of security vulnerabilities in the global routing system is
beyond the scope of this document. beyond the scope of this document.
13. IANA Considerations 13. IANA Considerations
[RFC Editor: This section to be remove prior to publication.] [RFC Editor: This section to be removed prior to publication.]
There are no IANA Considerations raised in this document. There are no IANA Considerations raised in this document.
14. Acknowledgments 14. Acknowledgments
The authors wish to express appreciation to the other original The authors wish to express appreciation to the other original
authors of RFC1519 (Kannan Varadhan, Jessica Yu), to the ROAD group authors of RFC1519 (Kannan Varadhan, Jessica Yu), to the ROAD group
with whom many of the ideas behind CIDR were inspired and developed, with whom many of the ideas behind CIDR were inspired and developed,
and to the early reviewers of this re-spun version of the document and to the early reviewers of this re-spun version of the document
(Barry Greene, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton, (Barry Greene, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton,
Ted Seely, Philip Smith, Pekka Savola) whose comments, corrections, Ted Seely, Philip Smith, Pekka Savola) whose comments, corrections,
skipping to change at page 27, line 9 skipping to change at page 25, line 29
RIRs interact directly with ISPs, or use a mixed mode of RIRs interact directly with ISPs, or use a mixed mode of
interaction with both LIRs and ISPS. interaction with both LIRs and ISPS.
6. The text references dynamic host address assignment [RFC2131] as 6. The text references dynamic host address assignment [RFC2131] as
a recommended technology, and suggests that additional protocol a recommended technology, and suggests that additional protocol
work be undertaken to develop improved technology for work be undertaken to develop improved technology for
renumbering. The review suggested further document references renumbering. The review suggested further document references
and further elaboration in the text. and further elaboration in the text.
7. While it would be possible to include a larger set of references 7. While it would be possible to include a larger set of references
and additional text on this topic, there would then be a and additional text on this topic, it is a matter where there is
distinct risk of the document losing focus. The topic of this a distinct risk of the document losing focus here. The topic of
section is one of situations where there are constraints on this section is one of situations where there are constraints on
aggregation, rather than a detailed examination of various aggregation, rather than a detailed examination of various
mitigating steps. mitigating steps.
8. The example in Section 5 uses network 10 rather than the 8. The example in Section 5 uses network 10 rather than the
documentation prefix 192.0.2.0/24. documentation prefix 192.0.2.0/24.
9. The text is showing a practical example of aggregation using 9. The text is showing a practical example of aggregation using
prefix sizes that would be encountered in an operational prefix sizes that would be encountered in an operational
context. The documentation prefix is too small to encompass context. The documentation prefix is too small to encompass
this example, and designated private address space was used in this example, and designated private address space was used in
skipping to change at page 27, line 46 skipping to change at page 26, line 19
most effective presentation of this material. most effective presentation of this material.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
16.2. Informative References 16.2. Informative References
[RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu, [7007] "NANOG mailing list discussion of the "AS 7007" incident",
"Supernetting: an Address Assignment and Aggregation <http://www.merit.edu/mail.archives/nanog/1997-04/
Strategy", RFC 1338, June 1992. msg00340.html>.
[RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless [CBGP] "Graph: Active BGP Table Entries, 1988 to Present",
Inter-Domain Routing: an Address Assignment and <http://bgp.potaroo.net/as4637/>.
Aggregation Strategy", RFC 1519, September 1993.
[CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP",
<http://www.nanog.org/mtg-0302/cidr.html>.
[CRPT] "The CIDR Report", <http://www.cidr-report.org/>.
[IANA] "Internet Assigned Numbers Authority", [IANA] "Internet Assigned Numbers Authority",
<http://www.iana.org>. <http://www.iana.org>.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the [LWRD] "The Long and Winding Road",
Internet", RFC 3221, December 2001. <http://rms46.vlsm.org/1/42.html>.
[NRO] "Number Resource Organization", <http://www.nro.net>. [NRO] "Number Resource Organization", <http://www.nro.net>.
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing [RFC904] Mills, D., "Exterior Gateway Protocol formal
and Addressing", RFC 1380, November 1992. specification", RFC 904, April 1984.
[LWRD] "The Long and Winding Road",
<http://rms46.vlsm.org/1/42.html>.
[RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178, [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
July 1997. June 1988.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. [RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu,
"Supernetting: an Address Assignment and Aggregation
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 Strategy", RFC 1338, June 1992.
(BGP-4)", RFC 1771, March 1995.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
June 1988. and Addressing", RFC 1380, November 1992.
[RFC904] Mills, D., "Exterior Gateway Protocol formal [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
specification", RFC 904, April 1984. Allocation with CIDR", RFC 1518, September 1993.
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, [RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", Inter-Domain Routing: an Address Assignment and
RFC 3021, December 2000. Aggregation Strategy", RFC 1519, September 1993.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>. [RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178,
July 1997.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", RFC 2317, March 1998. ADDR.ARPA delegation", RFC 2317, March 1998.
[CRPT] "The CIDR Report", <http://www.cidr-report.org/>. [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998.
[CBGP] "Graph: Active BGP Table Entries, 1988 to Present", [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
<http://bgp.potaroo.net/as4637/>. "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
RFC 3021, December 2000.
[CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
<http://www.nanog.org/mtg-0302/cidr.html>. Internet", RFC 3221, December 2001.
[7007] "NANOG mailing list discussion of the "AS 7007" incident", [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
<http://www.merit.edu/mail.archives/nanog/1997-04/ Gill, "IPv4 Multihoming Practices and Limitations",
msg00340.html>. RFC 4116, July 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: vaf@cisco.com Email: vaf@cisco.com
Tony Li Tony Li
Portola Networks, Inc. Li Consulting
Email: tony.li@tony.li Email: tony.li@tony.li
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at page 31, line 41 skipping to change at page 29, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 48 change blocks. 
198 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/