Dear SIG members,
The proposal, 'Alternative criteria for subsequent
IPv6 allocations',
has been sent to the Policy SIG for review. It will be
presented at the
Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March
2010.
We invite you to review and comment on the proposal on the mailing
list
before the meeting.
The comment period on the mailing list before
an APNIC meeting is an
important part of the policy development process. We
encourage you to
express your views on the
proposal:
- Do you support or oppose this
proposal?
- Does this proposal solve a problem you
are experiencing? If so,
tell the
community about your situation.
- Do you see any
disadvantages in this proposal?
- Is there anything
in the proposal that is not clear?
- What changes
could be made to this proposal to make it
more
effective?
Information
about this and other policy proposals is available
from:
http://www.apnic.net/policy/proposalsRandy, Ching-Heng,
and
Terence
___________________________________________________________________
prop-083-v001:
Alternative criteria for subsequent IPv6
allocations
___________________________________________________________________
Author:
Skeeve
Stevens
<
skeeve@eintellego.net>
Version:
1
Date: 3 February 2010
1.
Introduction
----------------
This is a proposal to enable current
APNIC account holders with existing
IPv6 allocations to receive subsequent
IPv6 allocations from APNIC for
use in networks that are not connected to the
initial IPv6 allocation.
2. Summary of current
problem
------------------------------
An APNIC account holder with an
existing /32 IPv6 allocation (or larger)
is unable to deaggregate that
allocation into routes smaller than a /32
due to the community practice of
'filter blocking' or 'bogon lists'
associated with RIR blocks which are known
to have a minimum allocation
size of /32 [1].
An LIR may want to build
a network in a separate location and provide
IPv6 connectivity; however,
because the LIR risks routability problems
if they deaggregate, they cannot
use a subset of their initial
allocation in the new location.
For
example:
An ISP has a /32 allocation which
they announce via an upstream
in New
Zealand. The ISP wants to build a new network in
Singapore.
The ISP's new network in Singapore
is not connected to the existing
New Zealand
network and the ISP is using a local transit
provider
to obtain dual stacked
connectivity.
If the network was using
IPv4 addresses, the ISP would usually
be able
to deaggregate their allocation and announce one part
of
the deaggregated range to the local transit
provider.
In IPv6, however, this is not
possible due to 'community filtering'
on
ranges smaller than a /32.
Such a filter
may look like the
following:
ipv6
prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le
32
This above statement in the IPv6 BGP
filter recommendations would
cause any
announcements by an ISP which had an
allocation,
such as 2400:0000::/32, to
announce smaller routes from that block,
such
as multiple /35s for example, to be filtered. In a
default
free situation, connectivity to the
ISP would be problematic.
Instead, the ISP
needs to obtain a new /32 allocation to be able
to
have IPv6 connectivity in the new location
with an independent
(from their primary
network) transit provider.
3. Situation in other
RIRs
---------------------------
AfriNIC, ARIN, LACNIC and RIPE
currently have no similar policies or
proposals. However, ARIN mailing lists
are presently discussing this
situation and there seems to be significant
support.
4. Details of the
proposal
---------------------------
4.1 It is proposed that
alternative criteria be added to the subsequent
IPv6
allocation policy [2] to allow current APNIC account
holders
with networks in multiple locations but
without a connecting
infrastructure to obtain IPv6
resources for each location.
4.2 To qualify for subsequent IPv6
allocations under the proposed
alternative criteria,
account holders must:
- Be a current APNIC
account holder with an existing
IPv6
allocation
- Be announcing its existing IPv6
allocation
- Demonstrate that the LIR has
additional networks that are not
connected to the network announcing its existing IPv6
allocation
5. Advantages and disadvantages of the
proposal
------------------------------------------------
5.1
Advantages
- This proposal enables current
APNIC account holders to avoid
problematic network design issues and policy issues related
to
deaggregation.
- Current APNIC account
holders will be able to acquire
resources
and announce them
separately to transit providers in
disparate
locations.
5.2 Disadvantages
-
This proposal could cause faster consumption of IPv6
address
space. However, given the
size of the total IPv6 pool, the
author
of this proposal does not
see this as a significant issue.
6. Effect on APNIC
members
---------------------------
APNIC members would be able to
build networks in separate locations and
obtain local IPv6 connectivity and
announce their own resources.
7. Effect on
NIRs
------------------
The proposal allows for NIRs to have the
choice as to when to adopt this
policy for their
members.
8. References
---------------
[1] For
example, see "IPv6 BGP filter recommendations"
http://www.space.net/~gert/RIPE/ipv6-filters.html[2] See
section 5.2, "Subsequent Allocation Section" in "IPv6
Address
Allocation and Assignment
Policy"
http://www.apnic.net/policy/ipv6-address-policy#5.2_______________________________________________