[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
written.
-Scott
----- 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
InternalInfrastructure
> 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