1 / 26

Proposal of new IPv6 Address Policy

This document outlines a proposal for a new IPv6 address policy, focusing on addressing the allocation criteria and procedures, collaboration between IETF and address community, goals, and IPv6 policy specifics. It also includes a simple study with figures to illustrate the address space and routing considerations. The proposal discusses the allocation of blocks to ISPs based on customer size and the implications for external and internal routing. Details about initial and subsequent allocations, registration, and revision history are provided.

cquinonez
Download Presentation

Proposal of new IPv6 Address Policy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposal of new IPv6 Address Policy 2001.8.26 Takashi Arano (Asia Global Crossing) JPNIC

  2. 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.

  3. 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

  4. 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

  5. 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

  6. Simple Study with Figures • Some rough estimation to share an idea about what IPv6 address space is like.

  7. 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.

  8. 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

  9. 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

  10. Items in the Proposal • Initial allocation • Subsequent allocation • LIR-to-ISP allocation • Assignment • DB registration • Special cases and miscellaneous

  11. 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

  12. 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.

  13. 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 willhave 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.

  14. 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.

  15. 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.

  16. 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.

  17. 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.

  18. 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

  19. 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.)

  20. 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.

  21. 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.

  22. 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.

  23. 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

  24. 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

  25. Miscellaneous • Effective for at most 3 years • The policy will be reviewed and revised whenever necessary.

  26. 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.

More Related