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

Scott Leibrand sleibrand at internap.com
Sat Feb 18 11:13:25 EST 2006

Re-statement for the record (nothing new here):

This seems like a reasonable IPv6 MicroAllocation policy.  If we're going
to replace the "/24 using IPv4 or a /48 using IPv6" language of section
6.10 with the text below, IMO we should also modify section 4.4 to remove
the "/48 using IPv6" language and instead refer users to 6.10 for the IPv6
MicroAllocation policy.

Aside from that quibble, I currently support the policy proposal as


----- Original Message ----- 
From: "Member Services" <memsvcs at arin.net>
To: <ppml at arin.net>
Sent: Friday, February 17, 2006 11:31 AM
Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for 

> On February 16, 2006, the ARIN Advisory Council concluded its review of
> 'Micro-allocations for Internal Infrastructure' and accepted it as a
> formal policy proposal for discussion by the community. This proposal is
> designated Policy Proposal 2006-2: Micro-allocations for Internal
> infrastructure. The proposal text is below and can be found at:
> http://www.arin.net/policy/proposals/2006_2.html
> All persons in the community are encouraged to discuss Policy Proposal
> 2006-2 in the weeks leading to the ARIN Public Policy Meeting in
> Montreal scheduled for April 10-11, 2006. Both the discussion on the
> Public Policy Mailing List and at the Public Policy Meeting will be used
> to determine the community consensus regarding this policy proposal.
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
> ARIN's Policy Proposal Archive can be found at:
> http://www.arin.net/policy/proposals/proposal_archive.html
> Regards,
> Member Services
> American Registry for Internet Numbers (ARIN)
> ### * ###
> Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure
> Author: Jason Schiller, Chris Morrow, Heather Skanks, Greg Stilwell, Beth 
> Vu
> Proposal type: modify
> Policy term: permanent
> 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.
> 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
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml

More information about the ARIN-PPML mailing list