[ppml] Proposed Policy: MicroAllocations for Internal Infrastructure

Scott Leibrand sleibrand at internap.com
Thu Feb 9 18:14:54 EST 2006

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


On 02/09/06 at 10:16am -0500, Member Services <memsvcs at arin.net> wrote:

> ARIN received the following proposed policy. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List and being placed on ARIN's
> website.
> The ARIN Advisory Council (AC) will review the proposal and within ten
> working days may decide to:
> 1)  Support the proposal as is,
> 2)  Work with the author to clarify, divide or combine one or more
> policy proposals, or
> 3)  Not support the policy proposal.
> If the AC supports the proposal or reaches an agreement to work with the
> author, then the proposal will be posted as a formal policy proposal to
> the Public Policy Mailing List and it will be presented at the Public
> Policy Meeting. If the AC does not support the proposal, then the author
> may elect to use the petition process to advance the proposal. If the
> author elects not to petition or the petition fails, then the proposed
> policy will be considered closed.
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> 	http://www.arin.net/policy/irpep.html
> Mailing list subscription information can be found at:
> 	http://www.arin.net/mailing_lists/index.html
> Regards,
> Member Services
> American Registry for Internet Numbers (ARIN)
> ### * ###
> Policy Proposal Name: MicroAllocations 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
> mesages may get dropped due to such a policy.  This can lead to
> precieved 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