APNIC IPv6 Activities:
Past,Present and Future
Paul Wilson
APNIC
Overview
The Past
– Introduction to APNIC
– History of the RIR System
The Present
– APNIC Membership
– Internet resource status – IPv4 and IPv6
– IPv6 policy status
The Future
– Address management policies
Introduction to APNIC
What is APNIC?
Regional Internet Registry (RIR)
for the Asia Pacific Region
– Regional authority for Internet Resource distribution
– IP addresses (IPv4 and IPv6),AS numbers,
reverse DNS delegation
– Provide services to ~800 ISPs
Industry self-regulatory body
– Established in 1993,in the,Internet Tradition”…
– Consensus-based,open and transparent
– Non-profit,neutral and independent
– Open membership-based structure
What does APNIC do?
1,Internet resource management
– IP address allocation to ISPs and NIRs
– IP address assignment to end users
– AS number assignments
2,Resource registration
– Authoritative registration server,whois.apnic.net
– Internet Routing Registry,apirr.apnic.net
3,DNS management
– Delegate reverse DNS zones/domains
– Authoritative DNS servers
in-addr.arpa,ip6.arpa (ip6.int)
What else does APNIC do?
Policy development and coordination
– APNIC Open Policy Meetings,2 per year
SIGs,WGs,BOFs,Training
– ASO and ICANN processes
– Liaison,IETF,ITU etc
Training and outreach
– Frequent regional training courses
– Presentations ay seminars,conferences etc
Publications
– Newsletter,web site,mailing lists etc
– Regional and global resource reports
Where is APNIC?
History of the RIR System
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
Pre 1992
RFC 1261
1991
“The assignment of numbers is also handled by Jon,
If you are developing a protocol or application that
will require the use of a link,socket,port,protocol,or
network number please contact Jon to receive a
number assignment.”
RFC 790
1981
RFC 1020
1987
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1992
RFC 1366
Geographic Allocations
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1993
RFC 1466
1993
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1996
RFC 2050
1996
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1997
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1998
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1999
ASO MoU
GAC
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
2002
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
2003
Emerging
RIR
APNIC Membership
Total APNIC Membership
0
100
200
300
400
500
600
700
800
900
Jun-
96
Dec-
96
Jun-
97
Dec-
97
Jun-
98
Dec-
98
Jun-
99
Dec-
99
Jun-
00
Dec-
00
Jun-
01
Dec-
01
Jun-
02
Dec-
02
Extra Large
Very Large
Large
Medium
Small
Very Small
Associate
1999
147
1998
49
1997
86
2000
206
2001
97
2002
68
Total APNIC Membership
-20
-10
0
10
20
30
40
Jun-
96
Dec-
96
Jun-
97
Dec-
97
Jun-
98
Dec-
98
Jun-
99
Dec-
99
Jun-
00
Dec-
00
Jun-
01
Dec-
01
Jun-
02
Dec-
02
Closed Members
New Members
Net Change
Total APNIC Membership
AU
21%
HK
12%
IN
12%
PH
6%
SG
5%
TW
3%
MY
3%
Other
9%
Other
30%
LK
1%
AP
4%
PK
4%
TH
4%
BD
3%
CN
4%
NZ
4%
JP
5%
Sub-regional Distribution
2
209
223
31
165
163
0
50
100
150
200
250
Africa East Oceania Regional South-Central South-East
Ref http://www.un.org/depts/dhl/maplib/worldregions.htm
Internet Resource Status
IPv4
IPv4 Allocations
0
16
32
48
64
80
96
112
128
Jan-96 Jan-97 Jan-98 Jan-99 Jan-00 Jan-01 Jan-02 Jan-03
M
i
llio
n
s
223
222
221
220
219
218
211
210
203
202
061
IPv4 Distribution - APNIC
SG
1%
NZ
1%
TH
1%
AU
6%
ID
1%
KR
18%
CN
24%
JP
35%
Other
1%
PK
0%
Other
5%
AP
0%
PH
0%
TW
6%
HK
3%
IN
2% MY
1%
IPv4 Distribution – Sub-regional
0
16
32
48
64
80
96
112
128
East Oceania South-East South-Central Regional Africa
M
illio
n
s
Ref http://www.un.org/depts/dhl/maplib/worldregions.htm
IPv4 Allocations - Global
0.00
0.50
1.00
1.50
2.00
2.50
1999 2000 2001 2002
APNIC
ARIN
LACNIC
RIPE NCC
IPv4 Distribution - Global
Early Allocs
94
36.7%
RIPE NCC
10
3.9%
Experimental
16
6.3%
Multicast
16
6.3%
To IANA Reserve
17
6.6%
APNIC
9
3.5%
LACNIC
1
0.4%
IANA Reserve
77
30.1%
ARIN
16
6.3%
Internet Resource Status
IPv6
IPv6 Allocations - APNIC
Unit,IPv6 prefix
0
20
40
60
80
100
120
Jul-99 Jan-00 Jul-00 Jan-01 Jul-01 Jan-02 Jul-02 Jan-03
IPv6 Distribution - APNIC
Unit,IPv6 prefix
JP
55
KR
16
Other
11
TW
8
CN
4
AU
5
TH
3
PG
1
MY
3
IN
1
HK
2
SG
4
ID
1
IPv6 Allocations - Global
0
20
40
60
80
100
1999 2000 2001 2002
APNIC
ARIN
LACNIC
RIPE NCC
IPv6 Distribution - Global
APNIC
103
ARIN
58
RIPE-NCC
180
Unit,IPv6 prefix
IPv6 Policy Status
IPv6 Policy - History
First published in 1999
–,Provisional IPv6 Policy” adopted by all RIRs
Policy review during 2001
– Final policy approved in all RIR regions
APNIC,Bangkok,March 2002
ARIN,Las Vegas,April 2002
RIPE NCC,Amsterdam,May 2002
New policy established
– Implemented in APNIC region since 1 July 2002
Public mailing lists and documentation
– http://www.apnic.net/ipv6
New IPv6 Policy - Details
Addressing structure overview
Initial allocation criteria
Subsequent allocation criteria
Utilisation requirements
Address assignment
Other conditions
IPv6 Address Structure
Topological Interface
0/64127
001 Infrastructure End Site
03 63/48
001 TLA SLANLASub-TLA
IPv6 Allocation Criteria
Initial allocation size is /32
– Allocated to any IPv6 LIR (ISP) planning to
connect 200 End Sites within 2 years
– This is the default initial allocation to,new”
ISPs (“slow start” policy)
– Provides 16 bits of site address space
Larger initial allocations can be made if
justified according to:
– IPv6 network infrastructure plan
– Existing IPv4 infrastructure and customer
base
IPv6 Allocation Criteria
Existing ISP infrastructure
– Policy assumes that transition is inevitable
– Large IPv4 ISPs will receive IPv6 allocations
consistent with the scale of existing networks
IPv4
IPv6
IPv6 Assignments
Default assignment /48 for all End Sites
– Providing /16 bits of space for subnets
End Site defined as an end user of an ISP
where:
The ISP assigns address space to the end user
The ISP provides Internet transit service to the end user
The ISP advertises an aggregate prefix route that contains
the end user's assignment
– ISP POPs are also defined as End Sites
– /48s will also be assigned for sub-assignment of /64
and /128 to mobile devices,sensors etc
IPv6 Assignments
Larger assignments,Multiple /48s
– Some end sites will need more than one /48
– Requests for multiple (or additional) /48s will be
reviewed at NIR/RIR level
Smaller assignments,/64
– Single subnet devices should receive /64 only
– E.g,mobile phone
Smaller assignments,/128
– Devices with no subnets should receive /128 only
– E.g,remote sensor
See RFC3177 (Sep 2001)
IPv6 Assignments
IPv6 assignments to End Sites are used
to determine utilisation of IPv6 address
blocks
– Intermediate allocation hierarchy not
considered
– All assignments must be registered
– Utilisation is determined from registrations
Intermediate allocation and assignment
practices are the responsibility of the
LIR…
IPv6 Registration
LIR is responsible for all registrations
RIR/NIR
LIR/NIR
ISP
Assignment
Allocation
Allocation
Assignment
Registration
IPv6 Utilisation Requirement
Subsequent allocation may be requested
when IPv6 utilisation requirement is met
Utilisation of IPv6 address space is
measured differently from IPv4
IPv6 Utilisation Requirement
Under IPv4,address space utililsation
measured as simple pecentage:
IPv4 utilisation requirement is 80%
– When 80% of address space has been assigned or
allocated,LIR may receive more
– E.g,ISP has assigned 55,000 addresses from /16
available
assigned
nUtilisatio =
%84
536,65
000,55
==
available
assigned
IPv6 Utilisation Requirement
Under new IPv6 policy utilisation is determined
by HD-Ratio (RFC 3194):
IPv6 utilisation requirement is HD=0.80
– Measured according to end-site assignments only
(intermediate allocations are ignored)
– E.g,ISP has assigned 10,000 addresses from /32
)log(
)log(
available
assigned
HD
nUtilisatio =
83.0
)536,65log(
)000,10log(
)log(
)log(
==
available
assigned
IPv6 utilisation (HD = 0.80)
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
48 44 40 36 32 28 24 20 16 12 8 4 0
/32
10.9%
1.18%
/16
0.13%
/0
0.80
)log(
)log(
=
total
utilised
RFC3194,The Host-Density Ratio for Address Assignment Efficiency”
Subsequent Allocation
Subsequent allocation can be made
when IPS’s existing address space
reaches utilisation of HD = 0.80
Other address management policies
should also be met
– Correct registrations
– Correct assignment practices etc
Subsequent allocation size is at least
double
– Resulting IPv6 Prefix is at least 1 bit shorter
– Should be sufficient for 2 years requirement
Other conditions
License model of allocation
– Allocations are not considered permanent,
but always subject to review and
reclamation
– Licenses renewed automatically while
addresses in use,consistent with policies
Existing /35 Allocations
– A number of /35s have been assigned
under provisional IPv6 policy
– Holders of /35s are eligible to request /32
IPv6 Policy - Summary
New policy now active globally
Policy is subject to review
– Policy will evolve as experience gained
– Any member of the community may propose
changes,alternatives
Review is starting now
– Initial allocation criteria under review
– Size of initial allocation may be reviewed
Public mailing lists and documentation
– http://www.apnic.net/ipv6
IPv6 Resource Management
- RIR Proposal
Background and Motivation
IANA-RIR allocation system
– Unchanged in 10+ years
– Major IPv4 address space fragmentation
Many ISPs have many separate prefixes
– IPv6 should not go the same way
Proposal for new system for IPv6
– Designed to minimise fragmentation
Most ISPs will have 1 prefix for many years
Document development
– Document jointly authored by RIRs
– Published as ripe-261
Current Allocation System
IANA allocates to RIR
– RIR maintains a pool of addresses
– Attempts to maximise aggregation within
pool
Short-term reservations
Sparse allocation
RIRs allocate to LIRs/ISPs
– When pool runs low,RIR receives more
from IANA
– Subsequent allocations to existing ISPs
cannot be aggregated
Current Allocation System (v4)
LIR/ISP
IANA
RIR
X 212/8 [ 213/8
Y 212.100/16
Z 212.101/16
212.100/15 \ 213.50/16
ISP has 2 prefixes after 3 requests!
Current Allocation System
IPv4
– IANA to RIR allocation unit,/8
– RIR to LIR/ISP,/20… /10…
– Many ISPs have multiple prefixes
IPv6
– IANA to RIR allocation unit,/23 (64 x /29)
– RIR to LIR/ISP,/32 minimum
– IPv6 swamp is being created already
Maximum reservation per ISP is /29
Proposal
,Sparse Allocation” system
– Maximise,distance” between separate portable
allocations
– Maximise chance of aggregation of subsequent
allocations
– Implemented as list of address prefixes to be
allocated in order
For example…
ISP A
X
ISP B
Y
ISP C
Z
ISP D
[
ISP E
\
ISP G ISP F
]
ISP H
Available IPv6 address pool
Proposal
Sparse allocation system will maximise
aggregation
– Simple system,easily understood
Otherwise known as,binary chop”
– Used in practice by RIRs already (IPv4)
Within large address blocks (eg /8)
– Used in other allocation systems
e.g,dynamic memory allocation
Proposal
Benefits increase as address pool
increases
– System breaks down in,overflow condition”
i.e,where pool becomes too crowded or full,and
another pool must be allocated
– Therefore RIRs propose to share a single
global pool
Known as Common Address Pool (CAP)
Managed by RIRs jointly,under,Common
Registry Service” (CRS)
Proposal
CAP needs to be as large as possible
– to ensure long life of single pool
– to avoid unaggregatable allocations
So…
– IANA to allocate 2000::/3 (FP001) for CAP
For management by CRS
This address space already designated by IETF
as Global Unicast,for allocation by RIRs
Allocation Request Process
1,First IPv6 allocation to ISP
– RIR sends request to CRS for new block of
specified size
– CRS allocates next entry from list of start
addresses
2,Subsequent allocation to ISP
– RIR sends request to CRS for expansion of
existing allocation for that ISP (to certain
specified size)
– CRS provides extension of existing allocation
If extension is not available,new prefix must be
allocated
Avoiding Fragmentation
Distance between neighboring
allocations is initially very large
–,Dumb” algorithm can be used initially
However,some ISP allocations will grow
faster
– Threatening to,collide” with neighbour
,Smarter” algorithm for new allocations
– e.g If existing preceding allocation has
grown to occupy more than a certain % of
address space available to it,select next
start address from the list
Avoiding Fragmentation
,Smarter” algorithm…
ISP A
X
ISP B
Y
ISP C
Z
ISP E
\
ISP F
]
ISP D
[
ISP G
However note that this is a far future scenario…
Other Details
Review of allocation process
– Initial set of allocations limited to 2048
– Providing each ISP with up to /14 (!)
Commence review after 1024
th
entry (2-3 years?)
Common registration service
– Function to rotate between RIRs
– ‘Master’ server at one RIR
Mirror servers elsewhere
Reverse DNS requirements (ip6.arpa)
– CRS administers master DNS server
– Other RIRs will be mirrors of master
Disadvantages
Requires single large allocation
–,Putting all out eggs in one basket”
– RIR proposal is to allocate large block but
not all address space available for unicast
Not possible to identify specific blocks
allocated to specific RIRs
– e.g,for filtering purposes
– RIRs note that this is not possible in IPv4
Further information
Document available from
– http://www.ripe.net/ripe/docs/ipv6-
sparse.html
APNIC IPv6 SIG
– http://www.apnic.net/meetings
– http://www.apnic.net/lists
Thank You
Paul Wilson
pwilson@apnic.net
Past,Present and Future
Paul Wilson
APNIC
Overview
The Past
– Introduction to APNIC
– History of the RIR System
The Present
– APNIC Membership
– Internet resource status – IPv4 and IPv6
– IPv6 policy status
The Future
– Address management policies
Introduction to APNIC
What is APNIC?
Regional Internet Registry (RIR)
for the Asia Pacific Region
– Regional authority for Internet Resource distribution
– IP addresses (IPv4 and IPv6),AS numbers,
reverse DNS delegation
– Provide services to ~800 ISPs
Industry self-regulatory body
– Established in 1993,in the,Internet Tradition”…
– Consensus-based,open and transparent
– Non-profit,neutral and independent
– Open membership-based structure
What does APNIC do?
1,Internet resource management
– IP address allocation to ISPs and NIRs
– IP address assignment to end users
– AS number assignments
2,Resource registration
– Authoritative registration server,whois.apnic.net
– Internet Routing Registry,apirr.apnic.net
3,DNS management
– Delegate reverse DNS zones/domains
– Authoritative DNS servers
in-addr.arpa,ip6.arpa (ip6.int)
What else does APNIC do?
Policy development and coordination
– APNIC Open Policy Meetings,2 per year
SIGs,WGs,BOFs,Training
– ASO and ICANN processes
– Liaison,IETF,ITU etc
Training and outreach
– Frequent regional training courses
– Presentations ay seminars,conferences etc
Publications
– Newsletter,web site,mailing lists etc
– Regional and global resource reports
Where is APNIC?
History of the RIR System
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
Pre 1992
RFC 1261
1991
“The assignment of numbers is also handled by Jon,
If you are developing a protocol or application that
will require the use of a link,socket,port,protocol,or
network number please contact Jon to receive a
number assignment.”
RFC 790
1981
RFC 1020
1987
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1992
RFC 1366
Geographic Allocations
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1993
RFC 1466
1993
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1996
RFC 2050
1996
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1997
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1998
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
1999
ASO MoU
GAC
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
2002
24 March 2003 RIR Meeting with the ICANN GAC Rio de Janeiro
2003
Emerging
RIR
APNIC Membership
Total APNIC Membership
0
100
200
300
400
500
600
700
800
900
Jun-
96
Dec-
96
Jun-
97
Dec-
97
Jun-
98
Dec-
98
Jun-
99
Dec-
99
Jun-
00
Dec-
00
Jun-
01
Dec-
01
Jun-
02
Dec-
02
Extra Large
Very Large
Large
Medium
Small
Very Small
Associate
1999
147
1998
49
1997
86
2000
206
2001
97
2002
68
Total APNIC Membership
-20
-10
0
10
20
30
40
Jun-
96
Dec-
96
Jun-
97
Dec-
97
Jun-
98
Dec-
98
Jun-
99
Dec-
99
Jun-
00
Dec-
00
Jun-
01
Dec-
01
Jun-
02
Dec-
02
Closed Members
New Members
Net Change
Total APNIC Membership
AU
21%
HK
12%
IN
12%
PH
6%
SG
5%
TW
3%
MY
3%
Other
9%
Other
30%
LK
1%
AP
4%
PK
4%
TH
4%
BD
3%
CN
4%
NZ
4%
JP
5%
Sub-regional Distribution
2
209
223
31
165
163
0
50
100
150
200
250
Africa East Oceania Regional South-Central South-East
Ref http://www.un.org/depts/dhl/maplib/worldregions.htm
Internet Resource Status
IPv4
IPv4 Allocations
0
16
32
48
64
80
96
112
128
Jan-96 Jan-97 Jan-98 Jan-99 Jan-00 Jan-01 Jan-02 Jan-03
M
i
llio
n
s
223
222
221
220
219
218
211
210
203
202
061
IPv4 Distribution - APNIC
SG
1%
NZ
1%
TH
1%
AU
6%
ID
1%
KR
18%
CN
24%
JP
35%
Other
1%
PK
0%
Other
5%
AP
0%
PH
0%
TW
6%
HK
3%
IN
2% MY
1%
IPv4 Distribution – Sub-regional
0
16
32
48
64
80
96
112
128
East Oceania South-East South-Central Regional Africa
M
illio
n
s
Ref http://www.un.org/depts/dhl/maplib/worldregions.htm
IPv4 Allocations - Global
0.00
0.50
1.00
1.50
2.00
2.50
1999 2000 2001 2002
APNIC
ARIN
LACNIC
RIPE NCC
IPv4 Distribution - Global
Early Allocs
94
36.7%
RIPE NCC
10
3.9%
Experimental
16
6.3%
Multicast
16
6.3%
To IANA Reserve
17
6.6%
APNIC
9
3.5%
LACNIC
1
0.4%
IANA Reserve
77
30.1%
ARIN
16
6.3%
Internet Resource Status
IPv6
IPv6 Allocations - APNIC
Unit,IPv6 prefix
0
20
40
60
80
100
120
Jul-99 Jan-00 Jul-00 Jan-01 Jul-01 Jan-02 Jul-02 Jan-03
IPv6 Distribution - APNIC
Unit,IPv6 prefix
JP
55
KR
16
Other
11
TW
8
CN
4
AU
5
TH
3
PG
1
MY
3
IN
1
HK
2
SG
4
ID
1
IPv6 Allocations - Global
0
20
40
60
80
100
1999 2000 2001 2002
APNIC
ARIN
LACNIC
RIPE NCC
IPv6 Distribution - Global
APNIC
103
ARIN
58
RIPE-NCC
180
Unit,IPv6 prefix
IPv6 Policy Status
IPv6 Policy - History
First published in 1999
–,Provisional IPv6 Policy” adopted by all RIRs
Policy review during 2001
– Final policy approved in all RIR regions
APNIC,Bangkok,March 2002
ARIN,Las Vegas,April 2002
RIPE NCC,Amsterdam,May 2002
New policy established
– Implemented in APNIC region since 1 July 2002
Public mailing lists and documentation
– http://www.apnic.net/ipv6
New IPv6 Policy - Details
Addressing structure overview
Initial allocation criteria
Subsequent allocation criteria
Utilisation requirements
Address assignment
Other conditions
IPv6 Address Structure
Topological Interface
0/64127
001 Infrastructure End Site
03 63/48
001 TLA SLANLASub-TLA
IPv6 Allocation Criteria
Initial allocation size is /32
– Allocated to any IPv6 LIR (ISP) planning to
connect 200 End Sites within 2 years
– This is the default initial allocation to,new”
ISPs (“slow start” policy)
– Provides 16 bits of site address space
Larger initial allocations can be made if
justified according to:
– IPv6 network infrastructure plan
– Existing IPv4 infrastructure and customer
base
IPv6 Allocation Criteria
Existing ISP infrastructure
– Policy assumes that transition is inevitable
– Large IPv4 ISPs will receive IPv6 allocations
consistent with the scale of existing networks
IPv4
IPv6
IPv6 Assignments
Default assignment /48 for all End Sites
– Providing /16 bits of space for subnets
End Site defined as an end user of an ISP
where:
The ISP assigns address space to the end user
The ISP provides Internet transit service to the end user
The ISP advertises an aggregate prefix route that contains
the end user's assignment
– ISP POPs are also defined as End Sites
– /48s will also be assigned for sub-assignment of /64
and /128 to mobile devices,sensors etc
IPv6 Assignments
Larger assignments,Multiple /48s
– Some end sites will need more than one /48
– Requests for multiple (or additional) /48s will be
reviewed at NIR/RIR level
Smaller assignments,/64
– Single subnet devices should receive /64 only
– E.g,mobile phone
Smaller assignments,/128
– Devices with no subnets should receive /128 only
– E.g,remote sensor
See RFC3177 (Sep 2001)
IPv6 Assignments
IPv6 assignments to End Sites are used
to determine utilisation of IPv6 address
blocks
– Intermediate allocation hierarchy not
considered
– All assignments must be registered
– Utilisation is determined from registrations
Intermediate allocation and assignment
practices are the responsibility of the
LIR…
IPv6 Registration
LIR is responsible for all registrations
RIR/NIR
LIR/NIR
ISP
Assignment
Allocation
Allocation
Assignment
Registration
IPv6 Utilisation Requirement
Subsequent allocation may be requested
when IPv6 utilisation requirement is met
Utilisation of IPv6 address space is
measured differently from IPv4
IPv6 Utilisation Requirement
Under IPv4,address space utililsation
measured as simple pecentage:
IPv4 utilisation requirement is 80%
– When 80% of address space has been assigned or
allocated,LIR may receive more
– E.g,ISP has assigned 55,000 addresses from /16
available
assigned
nUtilisatio =
%84
536,65
000,55
==
available
assigned
IPv6 Utilisation Requirement
Under new IPv6 policy utilisation is determined
by HD-Ratio (RFC 3194):
IPv6 utilisation requirement is HD=0.80
– Measured according to end-site assignments only
(intermediate allocations are ignored)
– E.g,ISP has assigned 10,000 addresses from /32
)log(
)log(
available
assigned
HD
nUtilisatio =
83.0
)536,65log(
)000,10log(
)log(
)log(
==
available
assigned
IPv6 utilisation (HD = 0.80)
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
48 44 40 36 32 28 24 20 16 12 8 4 0
/32
10.9%
1.18%
/16
0.13%
/0
0.80
)log(
)log(
=
total
utilised
RFC3194,The Host-Density Ratio for Address Assignment Efficiency”
Subsequent Allocation
Subsequent allocation can be made
when IPS’s existing address space
reaches utilisation of HD = 0.80
Other address management policies
should also be met
– Correct registrations
– Correct assignment practices etc
Subsequent allocation size is at least
double
– Resulting IPv6 Prefix is at least 1 bit shorter
– Should be sufficient for 2 years requirement
Other conditions
License model of allocation
– Allocations are not considered permanent,
but always subject to review and
reclamation
– Licenses renewed automatically while
addresses in use,consistent with policies
Existing /35 Allocations
– A number of /35s have been assigned
under provisional IPv6 policy
– Holders of /35s are eligible to request /32
IPv6 Policy - Summary
New policy now active globally
Policy is subject to review
– Policy will evolve as experience gained
– Any member of the community may propose
changes,alternatives
Review is starting now
– Initial allocation criteria under review
– Size of initial allocation may be reviewed
Public mailing lists and documentation
– http://www.apnic.net/ipv6
IPv6 Resource Management
- RIR Proposal
Background and Motivation
IANA-RIR allocation system
– Unchanged in 10+ years
– Major IPv4 address space fragmentation
Many ISPs have many separate prefixes
– IPv6 should not go the same way
Proposal for new system for IPv6
– Designed to minimise fragmentation
Most ISPs will have 1 prefix for many years
Document development
– Document jointly authored by RIRs
– Published as ripe-261
Current Allocation System
IANA allocates to RIR
– RIR maintains a pool of addresses
– Attempts to maximise aggregation within
pool
Short-term reservations
Sparse allocation
RIRs allocate to LIRs/ISPs
– When pool runs low,RIR receives more
from IANA
– Subsequent allocations to existing ISPs
cannot be aggregated
Current Allocation System (v4)
LIR/ISP
IANA
RIR
X 212/8 [ 213/8
Y 212.100/16
Z 212.101/16
212.100/15 \ 213.50/16
ISP has 2 prefixes after 3 requests!
Current Allocation System
IPv4
– IANA to RIR allocation unit,/8
– RIR to LIR/ISP,/20… /10…
– Many ISPs have multiple prefixes
IPv6
– IANA to RIR allocation unit,/23 (64 x /29)
– RIR to LIR/ISP,/32 minimum
– IPv6 swamp is being created already
Maximum reservation per ISP is /29
Proposal
,Sparse Allocation” system
– Maximise,distance” between separate portable
allocations
– Maximise chance of aggregation of subsequent
allocations
– Implemented as list of address prefixes to be
allocated in order
For example…
ISP A
X
ISP B
Y
ISP C
Z
ISP D
[
ISP E
\
ISP G ISP F
]
ISP H
Available IPv6 address pool
Proposal
Sparse allocation system will maximise
aggregation
– Simple system,easily understood
Otherwise known as,binary chop”
– Used in practice by RIRs already (IPv4)
Within large address blocks (eg /8)
– Used in other allocation systems
e.g,dynamic memory allocation
Proposal
Benefits increase as address pool
increases
– System breaks down in,overflow condition”
i.e,where pool becomes too crowded or full,and
another pool must be allocated
– Therefore RIRs propose to share a single
global pool
Known as Common Address Pool (CAP)
Managed by RIRs jointly,under,Common
Registry Service” (CRS)
Proposal
CAP needs to be as large as possible
– to ensure long life of single pool
– to avoid unaggregatable allocations
So…
– IANA to allocate 2000::/3 (FP001) for CAP
For management by CRS
This address space already designated by IETF
as Global Unicast,for allocation by RIRs
Allocation Request Process
1,First IPv6 allocation to ISP
– RIR sends request to CRS for new block of
specified size
– CRS allocates next entry from list of start
addresses
2,Subsequent allocation to ISP
– RIR sends request to CRS for expansion of
existing allocation for that ISP (to certain
specified size)
– CRS provides extension of existing allocation
If extension is not available,new prefix must be
allocated
Avoiding Fragmentation
Distance between neighboring
allocations is initially very large
–,Dumb” algorithm can be used initially
However,some ISP allocations will grow
faster
– Threatening to,collide” with neighbour
,Smarter” algorithm for new allocations
– e.g If existing preceding allocation has
grown to occupy more than a certain % of
address space available to it,select next
start address from the list
Avoiding Fragmentation
,Smarter” algorithm…
ISP A
X
ISP B
Y
ISP C
Z
ISP E
\
ISP F
]
ISP D
[
ISP G
However note that this is a far future scenario…
Other Details
Review of allocation process
– Initial set of allocations limited to 2048
– Providing each ISP with up to /14 (!)
Commence review after 1024
th
entry (2-3 years?)
Common registration service
– Function to rotate between RIRs
– ‘Master’ server at one RIR
Mirror servers elsewhere
Reverse DNS requirements (ip6.arpa)
– CRS administers master DNS server
– Other RIRs will be mirrors of master
Disadvantages
Requires single large allocation
–,Putting all out eggs in one basket”
– RIR proposal is to allocate large block but
not all address space available for unicast
Not possible to identify specific blocks
allocated to specific RIRs
– e.g,for filtering purposes
– RIRs note that this is not possible in IPv4
Further information
Document available from
– http://www.ripe.net/ripe/docs/ipv6-
sparse.html
APNIC IPv6 SIG
– http://www.apnic.net/meetings
– http://www.apnic.net/lists
Thank You
Paul Wilson
pwilson@apnic.net
