ARIN-PPML Message

[ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised

The ARIN Advisory Council (AC), acting under the provisions of the ARIN 
Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy 
proposal 2006-2: Micro-allocations for Internal Infrastructure and has 
determined that while there is no community consensus in favor of the 
proposal, there is consensus that the proposal should be revised and 
discussed further. The AC made this determination at their meeting at 
the conclusion of the ARIN Public Policy meeting on April 11, 2006. The 
results of the AC meeting were reported by the Chair of the AC at the 
member meeting. This report can be found at 
http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html

The AC will work with the author of the proposal to make the community 
suggested revisions and return the proposal to the PPML for further 
discussion.

The current policy proposal text is provided below and is also available 
at http://www.arin.net/policy/proposals/2006_2.html

The ARIN Internet Resource Policy Evaluation Process can be found at 
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


###*###
Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure

Policy statement:

To replace section 6.10

6.10 Micro-allocation

ARIN will make micro-allocations for critical infrastructure, and the 
RIRs and IANA as defined in the sub-sections below. These allocations 
will be no longer (more specific) than a IPv6 /48. Multiple allocations 
may be granted in certain situations. Micro-allocations MUST be provided 
from a specific range of addresses. ARIN will make a list of these 
blocks publicly available. ISPs and other organizations receiving these 
micro-allocations will be charged under the ISP fee schedule, while 
end-users will be charged under the fee schedule for end-users. This 
policy does not preclude organizations from requesting address space 
under other policies.

6.10.1 Micro-allocation for public exchange points Public Internet 
exchange point operators must provide justification for the 
micro-allocation, including: connection policy, location, other 
participants (minimum of two total), ASN, and contact information.

Exchange point allocations MUST be allocated from specific blocks 
reserved only for this purpose.

6.10.2 Micro-allocation for core DNS service providers Core DNS service 
providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) must 
provide justification for the micro-allocation, including: name of core 
DNS server, location, ASN, and contact information.

Core DNS server allocations MUST be allocated from the micro-allocation 
block. This block must be separate from the exchange point 
micro-allocation block and the internal infrastructure micro-allocation 
block.

6.10.3 Micro-allocation for internal infrastructure Organizations that 
currently hold IPv6 allocations may apply for a micro-allocation for 
internal infrastructure. Applicant must provide 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 NOT be routed on global Internet.

Internal infrastructure allocations MUST be allocated from specific 
blocks reserved only for this purpose.
Policy 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