Transcript Proposal of new IPv6 Address Policy 2001.8.26 Takashi Arano (Asia Global Crossing) JPNIC Current IPv6 Address Policy  Provisional IPv6 Assignment and Allocation Policy Document – http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html –

Proposal of new IPv6 Address
Policy
2001.8.26
Takashi Arano (Asia Global Crossing)
JPNIC
Current IPv6 Address Policy
 Provisional IPv6 Assignment and Allocation
Policy Document
– http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html
– Documented by RIRs, based on RFC2374 in May, 1999
– RIRs started to allocate sTLAs in August, 1999,
according to this document.
 Decides sTLA allocation criteria, etc.
 Basic Idea follows IPv4’s policy
 Undefined parts remains
– Assignment
– Subsequent allocation
• How to get TLA, etc.
Background
 A proposal from IESG/IAB
– 1-3bit and 48-128bits are so-called “technical
boundary” and will be IETF’s territory
– 3-48bits are policy boundary
• Our address community is responsible for this.
– Collaboration between IETF and address community is
needed
 3-48bit boundary
– No more TLA/sTLA/NLA?
– Several ISPs have started commercial services and
trials.
– Needs more concrete policy
Basic Idea
 Follows idea of traditional IPv4 address policy
– Slow start, concept of address lease, etc.
– 5 Goals
•
•
•
•
•
Uniqueness
Registration
Aggregation
Conservation
Fairness
– Mutually conflicted goals should be balanced
 Main difference in IPv6
– Lower priority on conservation
– More priority on aggregation
IPv6 Policy in this proposal
 Simple study with Figures
 Policy proposal
– We will examine main points in the Provisional
Policy.
• Philosophy of IP address policy
• IPv6 operation experience
• Real bottom-up proposal
Simple Study with Figures
 Some rough estimation to share an idea
about what IPv6 address space is like.
The number of ISPs which can get
independent blocks
 Allocating 2000::/3 (FP=001) to
– Case 1
• Under 500K customer ISP(/29) : 67M ISPs
– Case 2
• 1.5M - 18M customer ISP(/24+/28+/29): 260K +
• 500K - 1.5M customer ISP(/28+/29): 8.4M +
• Under 500K customer ISP(/29): 33M
 Probably allocating even /3 seems to be
enough for the number of independent
Internet connectivity business sectors.
The number of external routes
 Case 2 means that we will have 42M routes
– When will we encounter such situation?
– Will can future routers handle such a number of routes?
– No one knows…..
 Since each AS holder announces at least one route.
 Probably it would be better to allocate as less
blocks as possible per an AS holder.
• 10K AS times (average) 2.0 prefixes/AS = 20K prefixes
• 100K AS times (average) 3.0 prefixes/AS = 300K prefixes
 Notes: punching holes of /48 etc would heavily
affect the number of external routes, if happened
Taking care of internal routes
 Case 1
– 4.2M customer ISP = /26
– If aggregation unit is….
•
•
•
•
/48 -> then, IGP has 4.2M routes
/44 -> then, IGP has 260K routes
/40 -> then, IGP has 16K routes
/38 -> then, IGP has 4K routes
 Case 2
– 18M customers = /24+/28+/29
• /40 -> 72K routes
• /38 -> 18K routes
• /36 -> 4.5K routes
 Large ISPs will probably need at least /36-/40
aggregation in their IGP
Items in the Proposal
 Initial allocation
 Subsequent allocation
 LIR-to-ISP allocation
 Assignment
 DB registration
 Special cases and miscellaneous
Revision History
 6/6/2001 JPNIC IP-USERS
 6/14/2001 IPv6 Operation Study Group
 7/14/2001 WIDE meeting
 7/26/2001 JANOG IPv6 BOF
 7/27/2001 JANOG8 meeting
 7/31/2001 JPNIC IP-WG
 6/6/2001-7/31/2001 Comments in JPNIC
public mailing lists
Initial allocation criteria(I)
 Provisional Criteria
– (a) AND at least one part of criterion (b), as
follows:
• a. The requesting organization's IPv6 network must have
exterior routing protocol peering relationships with the
IPv6 networks of at least three other organizations that
have a sub-TLA allocated to them.
• AND either
• b(i). The requesting organization must have reassigned
IPv6 addresses received from its upstream provider or
providers to 40 SLA customer sites with routed networks
connected by permanent or semi-permanent links. OR
• b(ii). The requesting organization must demonstrate a
clear intent to provide IPv6 service within 12 months after
receiving allocated address space. This must be
substantiated by such documents as an engineering plan
or deployment plan.
Initial allocation criteria(II)
 Proposed Criteria
– (a) (c) AND at least one part of criterion (b), as follows:
• a. The requesting organization's IPv6 network will have
exterior routing protocol peering relationships with the
IPv6 networks of at least three other organizations that
have a sub-TLA allocated to them in three months.
• AND either
• b(i). The requesting organization must have reassigned
IPv6 addresses received from its upstream provider or
providers to 40 SLA customer sites with routed networks
connected by permanent or semi-permanent links. OR
• b(ii). The requesting organization must demonstrate a
clear intent to provide IPv6 service within 12 months after
receiving allocated address space. This must be
substantiated by such documents as an engineering plan
or deployment plan.
• (c) The requesting organization should be service
provider which does not only use addresses internally in
the organization but also allocate and/or assign
addresses to others.
Initial allocation criteria(III)
 Discussion
– Current policy is not realistic unless a
requesting organization doesn’t have pTLA. If
it has PA address from upstream, it may not be
allowed to have peering.
– A requesting organization should be a service
provider and basically enterprises should have
/48 or multiple /48s.
Initial allocation size
 Provisional policy
– /35 out of reserved /29
 Proposed policy
– /29
– Current sTLA holders will get /29 automatically.
 Discussion
– /35 is too small for ISP which will start real services. It
can only serves 8192 customers.
– If /29 is reserved, it is no difference in address
consumption standpoint.
– /35 prevents aggregation in internal routes.
Subsequent allocation criteria(I)
 Provisional criteria
– 80%
 Proposed criteria
– Registries should check if /48s are assigned
appropriately but should not check usage within
assigned /48s.
– So address usage x% is measured by # of customers,
which can make every registry’s efforts unburdened.
– 50%
 Discussion
– 80% causes address fragmentation in IGP, which was
originally required by “conservation” point of view.
Subsequent allocation criteria(II)
 Suppose to allocate /29 to an ISP which has 50PoP
(comparable to # of Japan’s prefectures, China’s provinces)
– Reserve /36 to each PoP initially
– Worst scenario
• 49PoP get just one customer (a little more than /31+/32)
• 1PoP gets 260K customers and assigns /30
• Then, it is desirable to allow the ISP to make subsequent
request while keeping aggregation level in /36.
-> 50% criteria
– Although this scenario is extreme,
• the ISP needs some room to compensate for gap between
requesting time and allocation time, and
• sometimes the ISP may have more than 100 PoPs.
Subsequent allocation size
 Provisional Policy
– Not clear
– “The size of subsequent allocations depend on the
demonstrated usage rate of the previous allocations.”
 Proposed Policy
– Fixed Size
• 2nd Allocation /28 (= 1M customers)
• 3rd Allocation /24 (= 16M customers)
• 4th Allocation or later /24 (= 16M customers)
– Not necessary to return previously allocated blocks
 Discussion
– Aggregation is more important
LIR-to-ISP allocation(I)
 So-called old NLA allocation
 Proposed size:
– Basically /40 (for 256 customers) for every request
including initial and subsequent allocation.
– Multiple /40s can be allocated if /40 will be used up
immediately
 Proposed Criteria:
– ISP can make a subsequent request when 50% of the
previously allocated block is assigned in terms of # of
customers
 Discussion
• Simpleness reduces LIR’s operational burdens including IGP.
• This assumes that allocation process for the request will be
done very quickly because process is very simple (just check #
of customers, etc.)
LIR-to-ISP allocation(II)
 No recursion
– ISP must not allocate to other ISPs, i.e., only
LIR can do.
– This is for registries to check the total
assignment status of their own allocated blocks.
– Assumes that ISP is not a big national provider.
Assignment(I)
 Which should be assigned, /48, /64, /128?
– It’s within the IETF boundary.
– Upper layer’s registries must not concern which
size LIRs/ISPs assign to end-users.
 Multiple /48s
– If end users use up /48 and need more, they can
request an additional /48 with justification.
– This request will be processed in the RIR/NIR
level.
Assignment(II)
 To whom should /48 be assigned?
– Proposal:
• ISP-connection basis, i.e. every end user can get a /48 when
they get an IPv6 connection from ISP, regardless of
organization, location, etc.
• Exception: Single /48 would be enough for just one LAN even
if they have multiple connection from one ISP.
– Discussion
• Organization basis is not practical.
• ISP-connection basis is easy to operate, under the condition
conservation is less important.
 Assignment to Infrastructure
– Basically /48 (regarded as just one assignment)
– Office use can be regarded separately.
DB Registration
 Every /48 should be registered.
 Admin-c and tech-c of home residential
users can be substituted by ISP contacts.
– Privacy reason
 Details: TBD
Special cases
 Assignment to IX
– Separate discussion
 Assignment to closed networks which do
not need global addresses but want unique
addresses
– Future and separate discussion
Miscellaneous
 Effective for at most 3 years
 The policy will be reviewed and revised
whenever necessary.
Now we have to discuss in AP region!
 We have reached rough consensus in various
Japanese communities for this proposal
–
–
–
–
JPNIC IP-USERS and IP-WG
IPv6 Operation Study Group
WIDE
JANOG
 We need good balanced policy
– Aggregation would be more important
– Bottom-up proposal
 Future plan
– Can we have an APNIC IPv6 WG to discuss this
important policy?
– Our consensus in AP will be brought to ARIN,
RIPE/NCC and ICANN ASO.