Policy 2006-2: Micro-allocations for Internal Infrastructure [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

Status: Adopted -NRPM Section 6.10.2

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 17 February 2006

To be revised - 14 April 2006
Revised - 18 July 2006
Staff Assessment - 4 October 2006
Last Call - 13-27 October 2006 Public Policy Mailing List

Author(s):

Jason Schiller,
Chris Morrow,
Heather Skanks,
Greg Stilwell,
Beth Vu

Proposal type: modify

Policy term: permanent

Policy statement:

6.10.1 Micro-allocations for Internal Infrastructure

Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose.

Rationale:

Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP.

It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed.

BGP Re-Convergence

ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail.

If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time

(typically 3 minutes)

The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate.

A detailed description of the problem space follows in the next three paragraphs.

Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP’s entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network.

If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2.

If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second.

---------------
                      | Core Router |static route
                      | |2001:DB8::/32 discard
                      ----+------+---
                          | |
                          / \
           /-------------/ \--------\
          / \
         / /----------------------------\ \
         | | | |
------+---+-- --+---+------
|_Core Router|static route |Core Router|static route_| _|2001:DB8::/32 discard | |2001:DB8::/32 discard_---------+--- ---------+---
         | |
---------+--------- ---------+---------
| _edge-router1 | | edge-router2 |_| _2001:DB8::1/128 | | 2001:DB8::2/128 |_---------+--------- ---------+---------
         | |
          \ link1 link2 /
           \------------\ /---------/
                         \ /
                          | |
                      ----+---------+----
                      | CPE |
                      | |
                      ---------+---------
                               |
                     LAN 2001:DB8:1000::/48

Internal Infrastructure Security Considerations

Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation.

In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block.

Private Address Considerations

Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP messages may get dropped due to such a policy. This can lead to perceived odd behavior and make troubleshooting difficult.

Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space.

DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who’s traffic transits that provider’s network to also get ‘inconsistent’ answers with respect to the private address space in question.

For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs.

Timetable for implementation: Immediate

Policy 2006-2: Micro-allocations for Internal Infrastructure [Archived]

OUT OF DATE?

Tracking Information

Discussion Tracking

Mailing List:

ARIN Public Policy Meeting:

ARIN Advisory Council:

ARIN Board of Trustees:

Revisions:

Implementation:

Author(s):

OUT OF DATE?